-
Notifications
You must be signed in to change notification settings - Fork 406
Closed
Labels
A-spec-specsArea: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)Area: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)E-easyExperience: easy, good for newcomersExperience: easy, good for newcomersP-high
Milestone
Description
From @jochem-brouwer
Hey EELS, I'm implementing EEST tests for the EIP-6110 (deposits) changes from here ethereum/EIPs#9460 in this EEST PR: ethereum/execution-spec-tests#1371
There is a problem though from the EELS implementation of the checks. Here is an excerpt from EIP-6110 https://eips.ethereum.org/EIPS/eip-6110#block-validity
def get_deposit_request_data(receipts)
# Retrieve all deposits made in the block
deposit_requests = []
for receipt in receipts:
for log in receipt.logs:
if log.address == DEPOSIT_CONTRACT_ADDRESS:
if len(log.topics) > 0 and log.topics[0] == DEPOSIT_EVENT_SIGNATURE_HASH:
assert is_valid_deposit_event_data(log.data), 'invalid deposit log: unsupported data layout'
deposit_request = event_data_to_deposit_request(log.data)
deposit_requests.append(deposit_request)
EELS seems to append DepositEvent requests after each tx (not after all txs have executed). But this is not in the spec: it scans all receipts (so after all txs have ran). This is problematic in EEST because EELS will mark a tx which triggers the wrong deposit layout test as invalid, while the spec can only mark the entire block as invalid (and not a single tx)
Metadata
Metadata
Assignees
Labels
A-spec-specsArea: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)Area: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)E-easyExperience: easy, good for newcomersExperience: easy, good for newcomersP-high