Blockspace | Blobspace | |
---|---|---|
Seen by all nodes | Yes | Yes |
Storage | Execution layer | Consensus layer |
EVM access | Yes | No |
Longevity | Forever | 18 days |
Cost | Expensive | Cheap |
nonce
, gasPrice
, gasLimit
, to
, value
, data
, v
, r
, s
.
accessList
parameter to the original set. Introduced by EIP-2930.
maxPriorityFeePerGas
and maxFeePerGas
.
maxFeePerBlobGas
— max fee per blob gas to store the blobblobVersionedHashes
— a blob pointer, which is a hash of the blob’s KZG commitment.env
file with the following variables:
Chainstack
, so we pad it to the fixed size.
Chainstack
in hex and padded to 128 KB (as in our case).
eth_estimateGas
call in Erigon moving forward does not take in the block number or block hash as an argument.
Running this will print out the transaction receipt.
Here’s an example of this transaction on the Sepolia etherscan: 0x5a74bd72aeeb99e874e58b927f9a5c96665278a36b61bed69a4b09597b02edce
On etherscan when viewing the transaction, hit Blobs. You will see:
blob.txt
. It should be the same.
Etherscan, being a great explorer, is providing you the data both from the consensus layer and the execution layer.
What you need to remember here is:
Index 0
in the Sepolia Beacon chain explorer.
A look at the actual cycle of our type-3 transaction:
to
address of the transaction doesn’t really matter as our goal is to put the blob data on the consensus layer.head
, genesis
, finalized
, or slot_number
.
The original Beacon chain API spec also includes hex encoded blockRoot with 0x prefix
, but Nimbus nodes (that Chainstack uses) do not support this for finalized blocks for efficiency. And we don’t need this anyway as you will see later.
Note that the call does not support the execution layer block number, you can only provide the respective slot number on the consensus layer. Programmatically, we’ll deal with this later. For now, we’ll just pick the respective slot number from the Sepolia Beacon chain explorer: slot 5203463.
Here’s our call
sidecars
call in the previous section, we received 4 different blobs with respective KZG commitments.
Let’s now verify that one them is ours and computed correctly by independently taking our own created blob data and getting its KZG commitment.
trusted_setup.txt
that the KZG commitment takes as one of the inputs.
Examples:
create_blob_data.py
earlier and saved as blob.txt
, and take the trusted_setup.txt file.
9493a713dd89eb7fe295efd62545bb93bca395a84d18ecfa2c6c650cddc844ad4c1935cbe7d6830967df9d33c5a2e230
If you look up the KZG commitment in the data you retrieved (or look up in the explorer), you will see that our independently computed KZG for our independently created blob data matches the on-chain one.
sidecar
call and retrieve the blobs associated with the type-3 transactions that we detect on the execution layer.
This is where the EIP-4788 will help us. The EIP introduced the first real way for the execution layer to have access to the consensus layer by having the parent block root of the consensus layer. Each block on the execution layer now has the parent (previous) slot root of the consensus layer in it stored as parentBeaconBlockRoot
.
We’ll retrieve this parent slot root, get the slot number associated with root with the eth/v1/beacon/headers/{parent_beacon_block_root_hex}
call on the consensus layer, and then do a simple + 1
to get the slot number that we need.
trusted_setup.txt
in the same directory with the script.
This will print the results and tell you if the independently computed KZG commitment and blob versioned hash match the ones retrieved off the network.
Example for our transaction: