feat: use verifying key directly from guest builder

[prajwolrg]

Description

Before merging this PR, please run it locally to verify that it works as expected. While it runs successfully on my machine with everything set up, I want to double-check to ensure consistency across different environments.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 56.04%. Comparing base (9a5db7c) to head (7d659a6).
Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
bin/datatool/src/main.rs	0.00%	1 Missing ⚠️

@@            Coverage Diff             @@
##             main     #363      +/-   ##
==========================================
- Coverage   56.04%   56.04%   -0.01%     
==========================================
  Files         250      250              
  Lines       26495    26489       -6     
==========================================
- Hits        14850    14846       -4     
+ Misses      11645    11643       -2     

Files with missing lines	Coverage Δ
bin/datatool/src/main.rs	0.00% <0.00%> (ø)

... and 4 files with indirect coverage changes

[delbonis]

I'm a little confused this approach. This bakes in the rollup vk into the binary right? I can see the strength with this approach in that it makes it so that it's impossible to use the wrong vk. But to me it would make more sense to have the datatool instead be in charge of building all the proofs. It makes it harder to misuse, as we could bake in the --release args instead of hoping the user reads the readme.

Can you elaborate on how the proof structure is able to use the correct consensus settings if we're not constructing it until we run the program? Do we check the proofs on this from the outside? I never had a good doc explaining the proof structure.

[prajwolrg]

I'm a little confused this approach. This bakes in the rollup vk into the binary right? I can see the strength with this approach in that it makes it so that it's impossible to use the wrong vk. But to me it would make more sense to have the datatool instead be in charge of building all the proofs. It makes it harder to misuse, as we could bake in the --release args instead of hoping the user reads the readme.

Can you elaborate on how the proof structure is able to use the correct consensus settings if we're not constructing it until we run the program? Do we check the proofs on this from the outside? I never had a good doc explaining the proof structure.

Yes, this approach does indeed bake the rollup vk into the datatool binary. To make the datatool responsible for building the proofs, we would need to update and migrate the build.rs script from strata-sp1-guest-builder.

Currently, the rollup parameters are passed to ZkVM as an input.

Ideally, it might make sense to have RollupParams::DEVNET as a constant, similar to bitcoin::params::MAINNET, and use that directly in the guest code. However, since the current RollupParams includes the verifying key, this would create a cyclic dependency. To solve this, we could remove the verifying key from RollupParams, create a separate RollupParamsWithVk struct, or set the verifying key to a placeholder like 0x00 in the guest code and update it later when the correct vk is available.

[delbonis]

@prajwolrg

That's interesting, the latter comment about having multiple layers to the rollup params it kinda lines up with some thoughts I had earlier where we have some inner params type for each component that gets constructed early and used when building the proofs, then we can package it together into a "holistic" params that includes all the components and vks and whatnot.

I'm not sure how having a RollupParams::DEVNET would help us here though. Or would it be set with like an env! just while building it?

Currently, the rollup parameters are passed to ZkVM as an input.

I think this is fine and maybe an ideal way to do it, if it means it lets us shift things upwards in the stack.

[prajwolrg]

@delbonis it works for now, but deriving tx_filter_rules each time is very costly for the prover. More info here: #371 (review)

We can make the tx filter rules as a public params (for now).

[delbonis]

That feels pretty crappy but it doesn't matter at this stage.

[delbonis]

Let's do whatever we have to to get this over the line.