-
Notifications
You must be signed in to change notification settings - Fork 0
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
optimizing proof generation #46
Comments
Status update: According to the profiling in branch Two optimizations mentioned before could shave of roughly 3~5m cycles out of 70m cycles in order to prove ~55k bytes of rollup transactions. For namespace verification, roughly 40%~50% of cycles are spent on FFT, and they could be avoided after EspressoSystems/jellyfish#339 . Also proving 10k bytes of transactions requires more than 128GB RAM.
|
Nice. Have a couple of thoughts below:
|
Right now we are paying for each block.
#cycles depends on the total size of the given namespace across all blocks. It's irrelevant to the block sizes.
128GB RAM is insufficient for proving 50k bytes. In the above profiling result, the entry |
stdouts: |
There are two problems:
Canonical serialization of this struct uses compressed form. Therefore the overall
block_derivation_proofs
deserialization takes over 1.7m cycles over 5.8 cycles.this comment observed that most cycles are spent on Montgomery inversion, and they are invoked by
Radix2EvaluationDomain::new()
.use big integer precompiles, or if we upgrade the sp1 prover to 1.3.0 we have even more field operation precompiles.
The text was updated successfully, but these errors were encountered: