alloy_rpc_types_debug/
debug.rs

1//! Types for the `debug` API.
2
3use alloy_primitives::Bytes;
4use serde::{Deserialize, Serialize};
5
6/// Represents the execution witness of a block. Contains an optional map of state preimages.
7#[derive(Clone, Debug, Default, PartialEq, Eq, Serialize, Deserialize)]
8pub struct ExecutionWitness {
9    /// List of all hashed trie nodes preimages that were required during the execution of
10    /// the block, including during state root recomputation.
11    pub state: Vec<Bytes>,
12    /// List of all contract codes (created / accessed) preimages that were required during
13    /// the execution of the block, including during state root recomputation.
14    pub codes: Vec<Bytes>,
15    /// List of all hashed account and storage keys (addresses and slots) preimages
16    /// (unhashed account addresses and storage slots, respectively) that were required during
17    /// the execution of the block.
18    pub keys: Vec<Bytes>,
19    /// Block headers required for proving correctness of stateless execution.
20    ///
21    /// This collection stores ancestor(parent) block headers needed to verify:
22    /// - State reads are correct (ie the code and accounts are correct wrt the pre-state root)
23    /// - BLOCKHASH opcode execution results are correct
24    ///
25    /// ## Why this field will be empty in the future
26    ///
27    /// This field is expected to be empty in the future because:
28    /// - EIP-2935 (Prague) will include block hashes directly in the state
29    /// - Verkle/Delayed execution will change the block structure to contain the pre-state root
30    ///   instead of the post-state root.
31    ///
32    /// Once both of these upgrades have been implemented, this field will be empty
33    /// moving forward because the data that this was proving will either be in the
34    /// current block or in the state.
35    ///
36    /// ## State Read Verification
37    ///
38    /// To verify state reads are correct, we need the pre-state root of the current block,
39    /// which is (currently) equal to the post-state root of the previous block. We therefore
40    /// need the previous block's header in order to prove that the state reads are correct.
41    ///
42    /// Note: While the pre-state root is located in the previous block, this field
43    /// will always have one or more items.
44    ///
45    /// ## BLOCKHASH Opcode Verification
46    ///
47    /// The BLOCKHASH opcode returns the block hash for a given block number, but it
48    /// only works for the 256 most recent blocks, not including the current block.
49    /// To verify that a block hash is indeed correct wrt the BLOCKHASH opcode
50    /// and not an arbitrary set of block hashes, we need a contiguous set of
51    /// block headers starting from the current block.
52    ///
53    /// ### Example
54    ///
55    /// Consider a blockchain at block 200, and inside of block 200, a transaction
56    /// calls BLOCKHASH(100):
57    /// - This is valid because block 100 is within the 256-block lookback window
58    /// - To verify this, we need all of the headers from block 100 through block 200
59    /// - These headers form a chain proving the correctness of block 100's hash.
60    ///
61    /// The naive way to construct the headers would be to unconditionally include the last
62    /// 256 block headers. However note, we may not need all 256, like in the example above.
63    pub headers: Vec<Bytes>,
64}
alloy_rpc_types_debug/debug.rs

alloy_rpc_types_debug/
debug.rs
