Execution Layer Meeting 154

[timbeiko]

Meeting Info

• Feb 2, 2023, 14:00-15:30 UTC
• Youtube Stream: https://youtu.be/E0w8NX5ksWo
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Shanghai Updates
  • zhejiang testnet launch
  • Testnet upgrades order
• Cancun Updates
  • 4844 gas costs benchmarking
  • 4844 0-blobs transactions
  • Transaction pool spec/test suite
  • Blob/block coupling
• Define eth_account execution-apis#329
• SSZ
  • Potential Transaction SSZ Refactor
  • EIP-6404
• Block benchmarking

[dankrad]

I'll probably have to miss (most of) this call as I'll be on a flight. My inputs:

1. On 4844 0-blobs transactions: I think it is completely fine to forbid these from the tx mempool, in fact I would encourage only allowing 1-blob tx in the mempool. At the same time I believe that there is no reason to forbid these in consensus. Construction of the transaction mempool should not be a reason for arbitrary restrictions on consensus. 0-blob transactions just work naturally and don't require any special logic to handle, and at the same time don't pose any DOS vector, so they should just be allowed.
2. On block/blob decoupling: My opinion is that it is very late to make this change, and that my guesstimate of the advantage (maybe 20% [1]) does not justify the potential delays of introducing it now. That said, it's more important to me that we quickly make a decision one way or another so that the decision itself is not a blocker. From the cryptography side, we can get all the changes done to allow separate blob verification [2] in time if we have a decision within a week, in my estimate without having to delay audits.

[1] If you have a higher estimate, I encourage you to back it up with data. So far we don't have any and I want to highlight that so far it has been ignored that there is actually a potential for this to be an overall worse design in terms of networking latency (if the network is latency bottlenecked rather than bandwidth bottlenecked).
[2] This is not strictly necessary to decouple blobs as they are signed, but it would give us more flexibility on blob verification now and in the future and allows for a bigger design space, e.g. erasure coding blobs accelerate networking.

[etan-status]

On (1), EIP-6404 in the SSZ section of the agenda proposes an alternative that wraps the entire blob section in an Optional. This way, the two transaction types (with blob / without blob) can be collapsed into a single SSZ type, allowing the use of SSZ benefits even without blobs. The overhead for 0-blob transactions is 8 bytes (serialization examples in the bottom of EIP-6404).

[adietrichs]

On the call right now, but might have to drop off before we get to the topics relevant for me, so:

0-blobs transactions

• I still think it would be preferable to allow them (easier for L2s, unified SSZ tx type)
• I agree with Dankrad that the cleanest way to handle this would be on the mempool level, without restricting protocol validity rules. Inability to re-insert them in clients on reorgs seems like it would not be an issue.
• But if people feel strongly about it, seems okay to ban for now, with the understanding to potentially unban in a future fork. Would be happy to adjust the EIP accordingly.

Blob/block coupling

• Unclear whether this will have major benefits, and whether those would outweigh the extra complexity / delay
• If we split blobs from blocks, 3 alternatives:
  • Option 1: Keep blobs section as one contiguous chunk. Would not require any changes to the cryptography, but also limits p2p benefits
  • Option 2: Split blobs section, transmit each blob separately. Either:
    • 2a: Keep cryptography the same (aggregate proof) - conceptually ugly, individual blobs can't be verified without downloading all of them
    • 2b: Change cryptography to individual proofs: conceptually cleaner, but overhead of adapting crypto libraries (audit soon!)
  • Option 3: Split blobs section simply by size: Concatenate, treat as opaque data, chunk. Would not require cryptography changes. Downside: No access to individual blobs via p2p. Upside: Generalized solution, could later be extended to the main beacon block / the execution payload.
• I would be in favor of Option 3, but if we go with 2, we should really pick 2b and adapt the cryptography accordingly.

[MariusVanDerWijden]

Oh @timbeiko could I get 2 min at the end for an announcement? We're starting on building some block benchmarks

[timbeiko]

@MariusVanDerWijden yes!

[timbeiko]

Closed in favour of #720

[tebibu654]

am tebibu from Ethiopia I registered in these app recently I need u help I teride to mine some crypto in my wallet but I don't have Eth and bnb swap fee pls help me by supporting send me some swap fee 0x4FBe352e084D8063704E5B795cB416da82fB0d47