Discussion for Add EIP: General purpose execution layer requests by lightclient · Pull Request #8432 · ethereum/EIPs · GitHub
3 Likes
I’ve started a draft implementation of this EIP for ethereumjs and have a question regarding the Intra-type ordering.
The EIP states:
Within the same type, order is not defined. This is because the data of the request is opaque as far as this EIP is concerned. The only valid ordering scheme would be lexicographical ordering of the opaque byte data.
If we don’t define any intratype order and make it exogenous to this EIP, doesn’t that make the requestsRoot non-deterministic where we have multiple requests of the same type since you could reorder them arbitrarily? I suppose we can just create arbitrary test vectors and say we’re assuming the order of requests within a type is lexicographical for now?
My perspective is that if a EIP uses 7685 and doesn’t define it’s intra-type ordering, it’s incomplete. Therefore I’m not sure how the ordering would be non-deterministic. Do you have an example maybe?
Ah, ok, that makes more sense. It might be clearer in the EIP to say something like
Within the same type, order is not defined. This is because the data of the request is opaque as far as this EIP is concerned. Intra-type order should be determined by each request type.
instead of the comment about lexicographical ordering since that made me thing we needed to code that as a fallback in case an order was not otherwise defined.
I’ll create a simple request type and ordering mechanism in my work to use as a proof of concept.
I made the clarification in the EIP Update EIP-7685: clarify intra-type ordering by lightclient · Pull Request #8501 · ethereum/EIPs · GitHub
Then at this point, 7002 and 6110 are incomplete, right? They define the encoding of the request but not the ordering 
Hmm 6110 does specifically say the ordering:
Each deposit accumulated in the block must appear in the EIP-7685 requests list in the order they appear in the logs
However it isn’t said explicitly in 7002. It should be in the order it is pulled out of the queue (FIFO). I can make that explicit.
Ah right, sorry, I did not see that part of 6110. Thanks 
If you could make the order for 7002 more explicit that would be great! 
1 Like
About “Opaque byte array rather than an RLP array” rationale, it also means that it becomes challenging to upgrade existing schemes later on.
For example, EIP-6110 adds more RLP cruft, if it uses EIP-7685 it means that that RLP component cannot easily be replaced with SSZ or a SNARK friendly representation later on.
Also, the proposal attempts to be generic, but is not completely generic. For example, some operations may be desirable to execute at start of the block, some at end of the block, and so on.
It’s also a bit weird, to have deposits follow a completely different scheme than withdrawals. What’s the advantage of mixing different concepts into one tree, instead of continuing the existing scheme of simply using separate lists for separate operations? How many operations do we expect there to be? Is it more than 2-3? Do they thematically overlap, as in, would something as in EIP-6493 work out for these validator dependent operations?
I’m not sure why it is harder to replace. It seems equally as challenging as replacing, say, the withdrawals root with a hash tree root.
Withdrawals are CL → EL communication, whereas deposits, exits, and partial withdrawals are EL → CL communication (a request).
My understanding is that there are many more possibilities for EL → CL requests to manage validators. We’re even discussing another one potentially for Prague: consolidations.
Withdrawals are CL → EL communication, whereas deposits, exits, and partial withdrawals are EL → CL communication (a request).
Makes sense, thanks for the clarification.
Considering that it gets transformed to a deposit_receipts list in the CL ExecutionPayload, maybe still simpler to just match that in the EL block header, as in, make it a deposit_receipts list there as well, instead of the list of prefixed opaque blocks.
How would JSON-RPC look for these? Would it return the prefixed opaque data, or something sensible (as is the case for withdrawals/receipts/transactions atm)?