alloy_rpc_types_debug/
debug.rs

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

alloy_rpc_types_debug/
debug.rs
