Struct ExecutionWitness 

pub struct ExecutionWitness {
    pub state: Vec<Bytes>,
    pub codes: Vec<Bytes>,
    pub keys: Vec<Bytes>,
    pub headers: Vec<Bytes>,
}

Represents the execution witness of a block. Contains an optional map of state preimages.

Fields

state: Vec<Bytes>

List of all hashed trie nodes preimages that were required during the execution of the block, including during state root recomputation.

codes: Vec<Bytes>

List of all contract codes (created / accessed) preimages that were required during the execution of the block, including during state root recomputation.

keys: Vec<Bytes>

List of all hashed account and storage keys (addresses and slots) preimages (unhashed account addresses and storage slots, respectively) that were required during the execution of the block.

headers: Vec<Bytes>

Block headers required for proving correctness of stateless execution.

This collection stores ancestor(parent) block headers needed to verify:

• State reads are correct (ie the code and accounts are correct wrt the pre-state root)
• BLOCKHASH opcode execution results are correct

Why this field will be empty in the future

This field is expected to be empty in the future because:

• EIP-2935 (Prague) will include block hashes directly in the state
• Verkle/Delayed execution will change the block structure to contain the pre-state root instead of the post-state root.

Once both of these upgrades have been implemented, this field will be empty moving forward because the data that this was proving will either be in the current block or in the state.

State Read Verification

To verify state reads are correct, we need the pre-state root of the current block, which is (currently) equal to the post-state root of the previous block. We therefore need the previous block’s header in order to prove that the state reads are correct.

Note: While the pre-state root is located in the previous block, this field will always have one or more items.

BLOCKHASH Opcode Verification

The BLOCKHASH opcode returns the block hash for a given block number, but it only works for the 256 most recent blocks, not including the current block. To verify that a block hash is indeed correct wrt the BLOCKHASH opcode and not an arbitrary set of block hashes, we need a contiguous set of block headers starting from the current block.

Example

Consider a blockchain at block 200, and inside of block 200, a transaction calls BLOCKHASH(100):

• This is valid because block 100 is within the 256-block lookback window
• To verify this, we need all of the headers from block 100 through block 200
• These headers form a chain proving the correctness of block 100’s hash.

The naive way to construct the headers would be to unconditionally include the last 256 block headers. However note, we may not need all 256, like in the example above.

Trait Implementations

impl Clone for ExecutionWitness

fn clone(&self) -> ExecutionWitness

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ExecutionWitness

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for ExecutionWitness

fn default() -> ExecutionWitness

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for ExecutionWitness

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for ExecutionWitness

fn eq(&self, other: &ExecutionWitness) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for ExecutionWitness

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl Eq for ExecutionWitness

impl StructuralPartialEq for ExecutionWitness

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 48 bytes