From 73629679582e2f06f4abfcabfd1c7615bc65df08 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Thu, 26 Sep 2024 04:07:15 +0200 Subject: [PATCH] Update EIP-7685: change requests hash to flat hash (#8854) * EIP-7685: change requests hash to flat hash There is no need to create a tree hash over the requests, since proofs related to requests will be made over the CL block. The EL block body stores unvalidated requests and will never be used for proofs. Removing the tree hash simplifies things. * 7685: fix typo --------- Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-7685.md | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/EIPS/eip-7685.md b/EIPS/eip-7685.md index d2f13be207ff69..0480eef89715a7 100644 --- a/EIPS/eip-7685.md +++ b/EIPS/eip-7685.md @@ -64,18 +64,11 @@ block_body_rlp = rlp([ #### Block Header -Extend the header with a new 32 byte value `requests_root`. - -Let `requests_root` be the root of a Merkle-Patricia trie keyed by the index in -the list of `requests`. This is equivalent to how the transaction trie root is -computed. - - The `requests_root` field value is therefore computed as follows: +Extend the header with a new 32 byte value `requests_hash`: ```python -def compute_trie_root_from_indexed_data(data): - trie = Trie.from([(i, obj) for i, obj in enumerate(data)]) - return trie.root +def compute_requests_hash(list): + return keccak256(rlp.encode([rlp.encode(req) for req in list])) block.header.requests_root = compute_trie_root_from_indexed_data(block.body.requests) ``` @@ -89,9 +82,9 @@ EL request. ### Opaque byte array rather than an RLP array -By having the bytes of `request_data` array from second byte on be opaque bytes, rather than an RLP (or other -encoding) list, we can support different encoding formats for the transaction -payload in the future such as SSZ, LEB128, or a fixed width format. +By having the bytes of `request_data` array from second byte on be opaque bytes, rather +than an RLP (or other encoding) list, we can support different encoding formats for the +request payload in the future such as SSZ, LEB128, or a fixed width format. ### Request source and validity