# SHARD BLOB TRANSACTIONS - New transaction format - Large amount of data - Data cannot be accessed by EVM execution - Data Commitment can be accessed - Data space ~16 MB per block ## EIP-4844 (stop-gap solution) - Commonly called **proto-danksharding** - Same tx format that will be in full data sharding - Not actually sharding transactions - Data part of the beacon chain, fully downloaded but can be deleted after short period - Data space cap to ~0.375 MB per block (limit ~0.75 MB) - Adopted in Ethereum **Dencun upgrade** ### PARAMETERS - Bytes/Field element (`BYTES_PER_FIELD_ELEMENT`): 32 - Field elements/Blob (`FIELD_ELEMENTS_PER_BLOB`): 4096 - `Blob` = bytes[BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB] = ~128 KB - Min Epochs for blob sidecars requests: 4096 (~18 days) - Block up to 6 blobs - BlobTx = 1 or 2 blobs ### BLOB TRANSACTION - Type (`BLOB_TX_TYPE`): 3 - Payload (`TransactionPayloadBody`) is RLP serialization of: ``` [chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s] ``` - New fields: * `max_fee_per_blob_gas`: maximum fee user is willing to pay per blob gas * `blob_versioned_hashes`: list of hashed outputs from `kzg_to_versioned_hash` - Cannot have the form of a create transaction - Field `to` must not be nil - Receipt payload (`ReceiptPayload`) is RLP seralization of: ``` [status, cumulative_transaction_gas_used, logs_bloom, logs] ``` ### GAS ACCOUNTING - New type of gas: **blob gas** - Independent of normal gas - Follows its own targeting rule: * If there are more blobs in the block than the target (currently 3) -> increase blob base fee * If there are less blobs in the block than the target -> decrease blob base fee * If there are the same number of blobs in the block as the target -> do not change the blob base fee - Only blobs are priced in blob gas - Deducted from sender balance before transaction execution, not refunded in transaction failure. - Will need to decide between utilizing type-2 and type-3 fee mechanisms to get their rollups on-chain: * There will be times when regular type-2 batch transactions are more expensive than type-3 blob transactions and vice versa * Each L2 will thus have to monitor the two separate markets to determine which one is more advantageous to use depending on the current network conditions - Ethereum JSON-RPC methods: * new `eth_blobBaseFee`: returns blob gas price prediction * update `eth_feeHistory`: add two fields related to blob gas - Base fee per blob gas series (`baseFeePerBlobGas`): array of block base fees per blob gas, includes next block after the newest of the returned range because this value can be derived from the newest block - Blob gas used ratio (`blobGasUsedRatio`): array of block blob gas used ratios, these are calculated as the ratio of blobGasUsed and the max blob gas per block #### BLOCK HEADER EXTENSION New fields: - `blob_gas_used`: Total amount of blob gas consumed by the transactions within the block - `excess_blob_gas`: Running total of blob gas consumed in excess of the target, prior to the block. Used to set blob gas pricing. Blob gas price calculation: to predict blob gas fee for the next blob we just need the values of the current block's header `excess_blob_gas` and `blob_gas_used`. * Simplest: ``` blobGas = ceil(MIN_BLOB_GASPRICE * e**(excess_blob_gas / BLOB_GASPRICE_UPDATE_FRACTION)) ``` * Adjusted (based on gas used stats): ``` to_be_sure_coef = 110 / 100 average_gas_used = 0 for i in range(head.number - N + 1, head.number + 1): average_gas_used += blocks[i].blob_gas_used average_gas_used = average_gas_used / N) blobGas = ceil(MIN_BLOB_GASPRICE * e**((excess_blob_gas + average_gas_used) / BLOB_GASPRICE_UPDATE_FRACTION) * to_be_sure_coef) ``` ### CONSENSUS LAYER - Blobs are referenced in the beacon block body but not fully encoded - Blobs are propagated separately as "sidecars" - It is tasked with persisting blobs for data availability, the execution layer is not. - Changes: * Beacon chain: process updated beacon blocks and ensure blobs are available * P2P network: sync updated beacon block types and new blob sidecars * Honest validator: produce beacon blocks with blobs and publish the associated blob sidecars ### NETWORKING - Blob transactions have two network representations: * During gossip responses (`PooledTransactions`): - tx_payload_body - blobs: list of `Blob` items - commitments: list of `KZGCommitment` of corresponding blobs - proofs: list of `KZGProof` of corresponding blobs and commitments * For body retrieval responses (`BlockBodies`): - tx_payload_body - Nodes **must not broadcast** blob transactions, only announced using `NewPooledTransactionHashes` messages and can then be requested via `GetPooledTransactions` ### ROLLUPS - Put rollup block data into **blobs** instead of a transaction **calldata** * Cheaper * Guarantees availability long enough to ensure honest actors can construct rollup state - ZK rollups provide 2 commitments to their transaction data or state delta data: * blob commitment * ZK rollup's own commitment ## LINKS - [Sepolia Blobscan](https://sepolia.blobscan.com/) ## BIBLIOGRAPHY - [Ethereum EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) - [EIP-4844, Blobs, and Blob Gas: What you need to know](https://www.blocknative.com/blog/eip-4844-blobs-and-blob-gas-what-you-need-to-know) - [EIP-4844 Blob Transaction](https://docs.web3j.io/4.11.0/transactions/EIP_transaction_types/eip4844_blob_transaction/) - [Blob gas price prediction and history methods update](https://hackmd.io/@flcl/Bkn4nq17T) - [PR: Add eth_blobBaseFee, add blobs to eth_feeHistory](https://github.com/ethereum/execution-apis/pull/486) - [EIP-4844-dev-usage](https://github.com/colinlyguo/EIP-4844-dev-usage)