EIP-4844: Add blob details to Block class

[sealer3]

Describe the Feature

In addition to blob transactions (added with #4554), EIP-4844 adds blob_gas_used and excess_blob_gas to block headers. Ethers should allow these to be accessible from the Block class.

Code Example

const block = await provider.getBlock();

// These would return null if the fork has not yet happened
console.log(block.blobGasUsed);
console.log(block.excessBlobGas);

[ricmoo]

This will come in the near future with the sidecar support. But thanks for opening a ticket to track this too.

Also, the fields will need to be added to the TransactionResponse and TransactionReceipt.

If you have any links to BLOb transactions on Sepolia, that would be quite useful too.

Currently, the Transaction object has live fields for the EIP-4844 fields, and support for serializing and inference but will need to add the ability to attach the kzg operations.

[sealer3]

Sure, here's a few type-3 transactions on Sepolia:
0x0f8c63e3c10157c3aceddcbfbed059067e3ad50c96184d2f3bc327f737bc736e (1 blobVersionedHash)
0x56702af308f7608e00d6160732820aee4134e27d651af9a975ecd8a460ed183f (2 blobVersionedHashes)
0x6c4aef4c26410b1fcbf24d0148e3d66a10cb3e9ad4ca10a71782489688cdd45a (4 blobVersionedHashes)
0x6fe578aed357b111ab499cc4e35f087855cfa6b5d65546589ac459f41d3592b8 (1 blobVersionedHash)
0x5662f3daa247990d4f60fbb1bf462b9408fef8ea380e00fb4ab0e025510b358c (3 blobVersionedHashes)

[ricmoo]

Also adding a link to this issue provided by Tim Beiko: Sepolia Blobscan.

[ricmoo]

I've added the fields to the Block, TransactionResponse and TransactionReceipt. I think the kzg will be part of a future minor bump, but would love an extra set of eyes to check on the above commit. :)

[sealer3]

Thank you! The changes in that commit look correct to me.

Another Dencun thing to consider adding soon is the parentBeaconBlockRoot field to the Block object, as per https://eips.ethereum.org/EIPS/eip-4788.

[ricmoo]

Thanks! I've added it, along with receiptsRoot and stateRoot, since I'm updating the Block object anyways.

[sealer3]

Excellent, thank you! The receiptsRoot and stateRoot are under-appreciated yet so powerful.

[ricmoo]

Completely agree! Originally they weren’t included because some nodes don’t return them (Ganche and other simulation nodes), but it seems safe to add them as “possibly null” values.

I will investigate adding a type-guard too for validated Blocks. :)