The problem of 7547 and 3074

This note remarks some of the incompatibilities of the two EIPs considered for inclusion. It also highlights that it is impossible to avoid for the EL state transition function to have to look back at the state prior to applying the parent block, that is, not the pre-state to the current block, but the state before!

Forenote: please remark that committing to a nonce may not actually save us at all from commiting previous block information to the state since the summary is not execution verified, we need to assert that the nonce had the right value before applying the previous block the same can be said about balances. In addition to the problem of account abstraction summarized in this note, this document also points that we need to commit to a contract the list of addresses at the time of including payload, this solves for the nonce issue, but it does not solve it for the balance one.

Account abstraction

The one feature of account abstraction that ruins the current IL mechanism is the following that I will call property (A):

A transaction from address B can change the ETH balance of the account with address A without changing it's nonce.

There are two different design problems currently on ILs that are interrelated and are incompatible with the above property (A)

Transactions in the IL may become invalid

A transaction that was included in the IL for slot N may become invalid for inclusion in N+1 because of some transactions in the payload of N. Validators that attest to N+1 need to be able to notice this and allow the payload to be deemed valid, even though the address for this transactions are included in the signed summary of N+1 and no transaction from that address is included in the payload of N+1

Head may be a descendant of a block without an available IL

It may happen that the payload for N+1 passes validation but the full IL of its parent, that of slot N, was never seen by anyone. The payload for N+1 has a signed summary and it includes all transactions that are includable in N+1, this shows that some IL was indeed available at some point and that this payload should be deemed valid.

Let us analize both of these problems and their proposed solutions:

Transactions that become invalid:

• Proposer of N includes a transaction from address A in the IL.
• Builder of N includes a transaction from address B that sweeps out all the ETH from address A.
• Builder of N+1 can no longer include the transaction from A as it doesn't have funds to pay for gas.

Proposed solution The summary for the IL in slot N commits to

• From Address: A
• Nonce: n
• Balance: k

The validator upon receiving the payload for N+1 verifies that there is no transaction in it that satisfies the above entry. Then it verifies that

• Before applying block N the nonce for address A was exactly n.
• Before applying block N the balance for address A was exactlyk.
• It verifies that before applying N+1 the nonce of account A is higher than n, if it were, it would declare this payload valid. Lets assume that it is not the case. It continues verification:
• Before applying block N+1 the balance for address A is less than k, in this case it declares the payload valid.

Remark. because of the problem mentioned in the first paragraph, the nonce check seems useless and instead the validator would check if the address appears in the list of addresses included in the previous payload. As for balances, this is not solved at all, it seems that the validator will have to look at the balance before applying the parent block hash. Notice that committing to the balances of A is impossible here because the payload of N did not even include A.

Forkchoice nodes without an available IL

As long as the head has an available IL, validators can propose on top of that head. What happens when the forkchoice head does not have an available IL? Possible solutions are:

• Never allow this to happen by not even allowing inclusion of blocks without an available IL. This was discarded due to head split views
• Never allow this to happen by filtering such blocks from forkchoice. There is no known mechanisms to do this safely, it easily lends itself to propose unreorgeable blocks (by not sending an IL to anyone except the builder of the next block) or to have long chains of blocks without available ILs such that if we remove them the head may have an inconsistent FFG vote than the store.
• The simplest solution seems to require the EL to reconstruct the IL from the node and any of its children. Without property (A) this can be done as follows. Suppose the last two blocks you have received are N and its child N+1 and you do not have an IL for any of them, but both have passed validation. The EL takes the summary from N+1, from the list of addresses in this summary it gathers all transactions in N+1 that satisfy some entry in the summary. It then grabs all transactions in the payload of N that satisfy the remaining entries in the summary. This is guaranteed to recover the full summary thus producing a full IL that can be included in a future block that takes N for head.

With property (A) the reconstruction above fails.

The key point is that property (A) makes it possible for a transaction in the IL to become unincludable without any transaction from address A in either N nor its child N+1, thus a validator can never produce the actual transaction that was invalidated because it was never included.