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

New compilation and read ELF from files system #1476

Open
eyusufatik opened this issue Nov 18, 2024 · 0 comments · May be fixed by #1495
Open

New compilation and read ELF from files system #1476

eyusufatik opened this issue Nov 18, 2024 · 0 comments · May be fixed by #1495
Assignees
Milestone

Comments

@eyusufatik
Copy link
Member

eyusufatik commented Nov 18, 2024

checkout esad/new-compilation-system branch

The goal we have with this issue is to read ELfs from files instead of by building and putting it as a constant in the binary. With this change, our provers will be able to prove with any ELF at any point in time. (If we don't do this forking becomes very time dependent for deployment). However, for test builds, we would like to use the newly compiled ELF, this is already implemented in the branch. So for non-testnet builds, we'd like to not see risc0 guests get compiled.

Ideally, we would like a new directory in project root, elfs/, which would have two subdirectories risc0/ and sp1. Each will have subdirectories testnet/ mainnet/ and the ELFs will be inside these subdirectories. The naming convention can be 0.elf 1.elf ... for different forks. However, it's ok to implement them differently if implementor wishes.

Now, notice that for the production builds, we now don't depend on citrea-risc0, the crate that holds our ZK guests, and we can use the same binary on both testnet and mainnet. (This would become a problem, let's say, if we put genesis state root of the rollup as a constant in the light client proof guest. We would need to build two guests, hence two binaries. But we can do 2 ELFs and one binary, which we point at which elfs to load. see #1444 )

A new CLI arg --testnet is needed to indicate that the node is going to be run on Citrea testnet. (absence of --testnet indicates mainnet run.). This would load ELFs from elfs/../testnet.

Now that we get our provers to load multiple ELFs, we'd also need to change prover service trait so that the prover runner can signal which ELF will be used by proving. To actually decide on which ELF to use for proving see below:

  • the batch prover will look at the L2 range it is about to prove, if at any point fork x is activated, it will use the elf for fork x.
  • the light client prover will always use the latest ELF, we can change this behaviour later. I am not sure at this moment.

The full node behaviour of loading up method id's as constants are now also gone, the full nodes will load ELF's at the corresponding directory and calculate method id's on their own. They can discard the ELF's afterwards.

In the PR, please also go back to our latest release, do a reproducible build of the batch proof guest, and put it under testnet's first elf.

@rakanalh rakanalh self-assigned this Nov 18, 2024
@rakanalh rakanalh linked a pull request Nov 20, 2024 that will close this issue
4 tasks
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

Successfully merging a pull request may close this issue.

2 participants