EIP-4844 Implementers' Call #1

[timbeiko]

Meeting Info

• Oct 25, 2022, 14:30 UTC
• Duration: 60 minutes
• Recording: https://youtu.be/hAa1b4m7tsI
• Notes & action items
• Zoom: posted in #4844-testing prior to the call

📆 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Agenda

• Spec updates
  • Update EIP-4844: Fee Market Update EIPs#5707
  • Exposing the modulus to the EVM
  • EIP4844: couple beacon block and blob sidecar for p2p consensus-specs#3046
  • EIP4844: modify MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS to 18 days consensus-specs#3047
  • EIP4844: Update cryptography API and Fiat-Shamir logic consensus-specs#3038
• Implementation / devnet updates
  • Rebase EIP-4844 on Capella consensus-specs#3052
  • kzg libraries for all client teams
  • Client status updates
• Testing / tooling updates
  • 2MB Block Testings
• Readiness checklist
• Other

[vbuterin]

We should expose the modulus to the EVM in some way. This is necessary if we want rollups that work with the point evaluation precompile to be forward-compatible with future changes that change the EVM. In particular, I expect a significant chance that we'll change the commitment scheme over to STARKed Merkle roots over a 64-bit modulus (!!) as hashes and STARKs are very fast in that context. If the modulus is available in the EVM, rollups would be able to write their proof-of-equivalence circuits to work with whatever modulus is provided, and would be forward-compatible.

A few possible options include:

• A MODULUS opcode that returns the current modulus
• A MODULUS opcode that returns the modulus associated with an inputted version byte
• Modifying the point evaluation precompile to also take as input the modulus as an argument, and fail if the provided modulus does not match that used in the provided commitment
• Modifying the point evaluation precompile to output the modulus used in the given commitment, if evaluation is successful

The last option probably requires the fewest client changes. But whatever we want to do regarding this, it's probably worth agreeing on the exact approach and adding it to the EIP soon.

[terencechain]

I won't be able to make this due to a conflict, but here are prysm updates:

• Cleaning up Experiment Prysm with eip4844 terencechain/prysm#1 into an excellent state to be merged into our canonical master branch
• Raul is looking into storing blobs in the DB with keys as a circular buffer with a length equal to expiration. The current two buckets approach won't work well because bolt freelist is troublesome. We've had a bad experience with slasher db

Spec updates, I opened the following. Thanks everyone for the feedback so far!
ethereum/consensus-specs#3046
ethereum/consensus-specs#3047

2mb testing, I opened this branch to be able to capture attestation arrival latency:
https://github.com/prysmaticlabs/prysm/compare/2mb?expand=1
I'm looking for clarification on whether we need to capture individual attestation latency in DB + additional API support

[roberto-bayardo]

There's also: ethereum/consensus-specs#3038

[timbeiko]

Closed in favour of #650