Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update EIP-7685: remove requests from block body #8908

Closed
wants to merge 2 commits into from
Closed

Update EIP-7685: remove requests from block body #8908

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4afa974
7685: remove requests from block body
lightclient Sep 26, 2024
24127d8
7685: fix typo
lightclient Sep 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 5 additions & 20 deletions EIPS/eip-7685.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,9 @@ created: 2024-04-14
## Abstract

This proposal defines a general purpose framework for storing contract-triggered
requests. It extends the execution header and body with a single field each to
store the request information. This inherently exposes the requests to the
consensus layer, which can then process each one.
requests. It extends the execution header with a single field to store the
request information. This inherently exposes the requests to the consensus
layer, which can then process each one.

## Motivation

Expand Down Expand Up @@ -47,21 +47,6 @@ order by type. For example:

The ordering of requests within a type is to be defined by each request type.

#### Block structure

The block body is appended with a list of requests. RLP encoding of the extended
block body structure is computed as follows:

```python
block_body_rlp = rlp([
field_0,
...,
# Latest block body field before `requests`
field_n,
[request_0, ..., request_k],
])
```

#### Block Header

Extend the header with a new 32 byte value `requests_hash`:
Expand All @@ -70,7 +55,7 @@ Extend the header with a new 32 byte value `requests_hash`:
def compute_requests_hash(list):
return keccak256(rlp.encode([rlp.encode(req) for req in list]))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From Mikhail's comment in #591 description:

Use concatenation to compute the resulting list of all requests instead of RLP, i.e. do executionRequests = requests_00 || requests_01 || requests_02 instead of requests = RLP([requests_00, requests_01, requests_02]). And use the executionRequests in Engine API and in requestsHash computation, the latter can be as simple as requestsHash = executionRequests(requests)

It seems like this should also be updated to:

Suggested change
return keccak256(rlp.encode([rlp.encode(req) for req in list]))
return keccak256(b"".join(list))

Or something along the lines.


block.header.requests_root = compute_requests_hash(block.body.requests)
block.header.requests_hash = compute_requests_hash(requests)
```

### Consensus Layer
Expand Down Expand Up @@ -110,7 +95,7 @@ The authors' recommendations on source and validity of requests are:
### Ordering

The ordering across types is ascending by type. This is to simplify the process
of verifying that all requests which were committed to in `requests_root` were
of verifying that all requests which were committed to in `requests_hash` were
found in the block.

An alternative could be to order by when the request was generated within the
Expand Down
Loading