# 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)