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.
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 subdirectoriesrisc0/andsp1. Each will have subdirectoriestestnet/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 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.