0

According to EIP-4844

Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded by all consensus nodes (but can be deleted after only a relatively short delay).

Additionally, this EIP adds a new opcode and precompile, namely BLOBHASH and point evaluation, where BLOBHASH is defined as:

reads index from the top of the stack as big-endian uint256, and replaces it on the stack with tx.blob_versioned_hashes[index] if index < len(tx.blob_versioned_hashes)...

So, since the blob itself doesn't have to propagate, when the blob is pruned, what does the BLOBHASH return?

1 Answer 1

1

The BLOBHASH opcode only operates on the current transaction context, so it never has to concern itself with pruned blobs. Also, versioned hashes are persisted in the execution layer state (as 4844 transactions have a versioned_hashes array field), so we don't have to worry about these disappearing. When the spec mentions:

reads index from the top of the stack as big-endian uint256, and replaces it on the stack with tx.blob_versioned_hashes[index] if index < len(tx.blob_versioned_hashes)...

it implies that we're reading directly from the blob_versioned_hashes field of the current transaction that is being executed.

2
  • Ahhhh I see. So in that single transaction I can access the blob_versioned_hashes array, but no other transaction would ever be able to access that array? Commented May 1 at 21:22
  • 1
    Correct! Though, a contract that a blob transaction was sent to can persist versioned blob hashes for future consumption in the EVM by retrieving the versioned hashes via BLOBHASH and then sstoreing them.
    – clabby
    Commented May 1 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.