Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-4844 Implementers' Call #1 #647

Closed
timbeiko opened this issue Oct 19, 2022 · 4 comments
Closed

EIP-4844 Implementers' Call #1 #647

timbeiko opened this issue Oct 19, 2022 · 4 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Oct 19, 2022

Meeting Info

📆 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Agenda

@vbuterin
Copy link
Collaborator

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
Copy link
Contributor

terencechain commented Oct 24, 2022

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
Copy link

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

@timbeiko
Copy link
Collaborator Author

Closed in favour of #650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants