Prover service trait, SHARP client, fact checker, Stone stubs #6
Conversation
WalkthroughThis update integrates new dependencies and restructures various modules across Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
unstark
changed the title
unstark
force-pushed
the
feat/prover-traits
branch
from
7fd2b50 to
82fb16c
Compare
src/provers/stone/mod.rs
Outdated
| } | ||
|
|
||
| #[async_trait] | ||
| impl<R: StoneProofRegistry> ProverService for StoneProverService<R> { |
There was a problem hiding this comment.
so I was thinking that the prover api will talk to the orchestrator to register the proofs on the L1. even though the proof registration code is in the orchestrator, the normal sequencer and job flow isn't aware of it, the job creator and watcher will be the prover api. the orchestrator will just use the prover service to know when the proof is complete (which means its also registered on the L1). what do you think about this design?
if we're on the same page here, then my question was do we need the StoneProverService to depend on a StoneProofRegistry? I agree the prover service should have some context of where the proof will be registered so it can pass it to the prover api, but will the prover service need to call register_proof? If not, should we move it another job altogether which will be handled by the prover api
There was a problem hiding this comment.
Sure, that would work!
However we are then back to determining what is the generic proof output (that will be returned by ProverService, consumed by prover job, and submitted to verifier job) and how to handle "e2e" proving services in this paradigm.
Current design is mostly driven by the intention to put SHARP-like "monolith" and "modular" prover services under the same interface to simplify the orchestrator job
There was a problem hiding this comment.
we are then back to determining what is the generic proof output
Hmm, but do we need the proof output anymore if we are assuming the prover service is going to take the responsibility of verifying it on the L1? Maybe I don't have the exact picture of the flow in your mind, happy to jump on a call :)
src/provers/sharp/config.rs
Outdated
|
|
||
| impl Default for SharpConfig { | ||
| fn default() -> Self { | ||
| unimplemented!("No defaults for SHARP config") |
There was a problem hiding this comment.
this causes the code to panic right now because we use the DefaultSettingsProvider and sharp/mod.rs calls settings.get_settings(SHARP_SETTINGS_NAME).unwrap()
src/fact_checker/mod.rs
Outdated
|
|
||
| impl FactChecker { | ||
| pub fn new(rpc_node_url: Url, verifier_address: Address) -> Self { | ||
| let provider = ProviderBuilder::new().on_http(rpc_node_url); |
There was a problem hiding this comment.
should we store the provider in the global config and pass it here? it might be used in other places as well
There was a problem hiding this comment.
This case is rather specific (read only access), typically we will need a more involved provider (in Alloy it is now a much more complicated abstraction)
There was a problem hiding this comment.
Oh interesting. But won't providers by default be read only and you need to attach them to an account to get write access?
src/fact_checker/fact_info.rs
Outdated
| Ok(FactInfo { program_output, fact_topology, fact }) | ||
| } | ||
|
|
||
| pub fn get_program_output(cairo_pie: &CairoPie) -> Result<Vec<Felt252>, FactCheckerError> { |
There was a problem hiding this comment.
we should ideally have test cases for this, what do you think is the best approach to test this? can we utilise mainnet data somehow? we can do it in a new PR
There was a problem hiding this comment.
I planned to take/generate test vectors using cairo-lang.
Separate PR would be best I think (though current one might contain bugs) since it will unblock other tasks
There was a problem hiding this comment.
Awesome, let's do a separate PR. Can you create an issue if possible?
unstark
force-pushed
the
feat/prover-traits
branch
from
82fb16c to
8283718
Compare
unstark
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.lockmigrations/.DS_Storeis excluded by!**/.DS_Store
Files selected for processing (43)
- Cargo.toml (2 hunks)
- crates/da_clients/ethereum/Cargo.toml (1 hunks)
- crates/da_clients/ethereum/src/lib.rs (2 hunks)
- crates/orchestrator/Cargo.toml (1 hunks)
- crates/orchestrator/src/config.rs (5 hunks)
- crates/orchestrator/src/controllers/jobs_controller.rs (1 hunks)
- crates/orchestrator/src/database/mod.rs (1 hunks)
- crates/orchestrator/src/database/mongodb/config.rs (1 hunks)
- crates/orchestrator/src/database/mongodb/mod.rs (3 hunks)
- crates/orchestrator/src/jobs/da_job/mod.rs (2 hunks)
- crates/orchestrator/src/jobs/mod.rs (4 hunks)
- crates/orchestrator/src/jobs/prover_job/mod.rs (1 hunks)
- crates/orchestrator/src/jobs/types.rs (2 hunks)
- crates/orchestrator/src/main.rs (1 hunks)
- crates/orchestrator/src/queue/job_queue.rs (1 hunks)
- crates/orchestrator/src/queue/mod.rs (1 hunks)
- crates/orchestrator/src/queue/sqs/mod.rs (1 hunks)
- crates/orchestrator/src/routes.rs (1 hunks)
- crates/prover_services/gps_fact_checker/Cargo.toml (1 hunks)
- crates/prover_services/gps_fact_checker/src/artifacts/FactRegistry.json (1 hunks)
- crates/prover_services/gps_fact_checker/src/error.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_info.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_node.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_topology.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/lib.rs (1 hunks)
- crates/prover_services/prover_service/Cargo.toml (1 hunks)
- crates/prover_services/prover_service/src/lib.rs (1 hunks)
- crates/prover_services/sharp_service/Cargo.toml (1 hunks)
- crates/prover_services/sharp_service/src/client.rs (1 hunks)
- crates/prover_services/sharp_service/src/config.rs (1 hunks)
- crates/prover_services/sharp_service/src/error.rs (1 hunks)
- crates/prover_services/sharp_service/src/lib.rs (1 hunks)
- crates/prover_services/stone_service/Cargo.toml (1 hunks)
- crates/prover_services/stone_service/src/error.rs (1 hunks)
- crates/prover_services/stone_service/src/gps.rs (1 hunks)
- crates/prover_services/stone_service/src/integrity.rs (1 hunks)
- crates/prover_services/stone_service/src/lib.rs (1 hunks)
- crates/prover_services/stone_service/src/registry.rs (1 hunks)
- crates/prover_services/stone_service/src/sovereign.rs (1 hunks)
- crates/utils/Cargo.toml (1 hunks)
- crates/utils/src/lib.rs (1 hunks)
- crates/utils/src/settings/default.rs (1 hunks)
- crates/utils/src/settings/mod.rs (1 hunks)
Files skipped from review due to trivial changes (14)
- crates/orchestrator/Cargo.toml
- crates/orchestrator/src/controllers/jobs_controller.rs
- crates/orchestrator/src/database/mod.rs
- crates/orchestrator/src/main.rs
- crates/orchestrator/src/queue/mod.rs
- crates/orchestrator/src/queue/sqs/mod.rs
- crates/orchestrator/src/routes.rs
- crates/prover_services/gps_fact_checker/Cargo.toml
- crates/prover_services/prover_service/Cargo.toml
- crates/prover_services/sharp_service/Cargo.toml
- crates/prover_services/sharp_service/src/config.rs
- crates/prover_services/stone_service/Cargo.toml
- crates/utils/Cargo.toml
- crates/utils/src/lib.rs
Additional comments not posted (26)
crates/prover_services/stone_service/src/error.rs (1)
6-9: The implementation ofFrom<StoneProverError> for ProverServiceErroris correctly done, ensuring thatStoneProverErrorcan be seamlessly converted intoProverServiceError.crates/utils/src/settings/default.rs (1)
3-12: The implementation ofDefaultSettingsProviderwith the methodget_settingsreturning default values is clear and adheres to the expected behavior of a default settings provider.crates/utils/src/settings/mod.rs (2)
5-9: TheSettingsProviderErrorenum is well-defined, with anInternalvariant that appropriately encapsulates internal errors, allowing for detailed error reporting.
11-13: TheSettingsProvidertrait is correctly implemented, providing a clear interface for fetching settings based on a section name.crates/da_clients/ethereum/Cargo.toml (1)
7-11: The modifications to thealloydependency to use the workspace version and includereqwestin its features are appropriate, ensuring consistency and enhanced functionality across the workspace.crates/prover_services/stone_service/src/registry.rs (1)
7-15: TheStoneProofRegistrytrait is well-designed, supporting settings injection and asynchronous proof registration. This design is suitable for services that interact with blockchain technologies.crates/prover_services/sharp_service/src/error.rs (2)
5-19: The error handling withthiserroris well implemented and covers a comprehensive range of SHARP service-related errors.
21-24: The implementation of the conversion fromSharpErrortoProverServiceErroris correctly done, using a boxed error to maintain compatibility across error types.crates/da_clients/ethereum/src/lib.rs (1)
35-35: The replacement ofreqwest::Clientwithalloy::transports::http::Clientis consistent with the project's direction to integrate with thealloylibrary. Ensure that all interactions with the Ethereum network are tested to confirm that the new client integrates smoothly.Verification successful
The integration of
alloy::transports::http::ClientwithRpcClientappears to be correctly set up in the codebase. TheHttp<Client>type is defined and used appropriately as a transport layer forRpcClient.
RpcClientis imported fromalloy::rpc::client::RpcClient.- The
provideris defined asRpcClient<Http<Client>>incrates/da_clients/ethereum/src/lib.rs.Ensure that all interactions with the Ethereum network are tested to confirm that the new client integrates smoothly.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of alloy's HTTP client with Ethereum network interactions. # Test: Search for usage of `alloy::transports::http::Client` and ensure it's correctly configured. rg --type rust $'alloy::transports::http::Client'Length of output: 48
Script:
#!/bin/bash # Description: Verify the integration of alloy's HTTP client with Ethereum network interactions. # Test: Search for usage of `RpcClient::builder()` to ensure it's correctly configured with alloy's HTTP client. rg --type rust 'RpcClient::builder()'Length of output: 121
Script:
#!/bin/bash # Description: Extract the relevant lines around the usage of `RpcClient::builder()` in `crates/da_clients/ethereum/src/lib.rs`. # Extract 10 lines before and after the usage of `RpcClient::builder()`. rg --type rust 'RpcClient::builder()' -A 10 -B 10 crates/da_clients/ethereum/src/lib.rsLength of output: 528
Script:
#!/bin/bash # Description: Verify the definition and implementation of `RpcClient` and its `.http` method. # Search for the definition of `RpcClient`. rg --type rust 'struct RpcClient' # Search for the implementation of the `.http` method. rg --type rust 'fn http'Length of output: 62
Script:
#!/bin/bash # Description: Verify if `RpcClient` is imported from an external crate and check for references to external crates. # Search for `RpcClient` imports. rg --type rust 'RpcClient' crates/da_clients/ethereum/src/lib.rs # Search for external crate references. rg --type rust 'extern crate' crates/da_clients/ethereum/src/lib.rsLength of output: 252
Script:
#!/bin/bash # Description: Verify the definition and configuration of `Http<Client>`. # Search for the definition of `Http<Client>`. rg --type rust 'Http<Client>' # Search for the configuration of `Http<Client>`. rg --type rust 'Http<Client>' -A 10 -B 10Length of output: 3310
crates/prover_services/gps_fact_checker/src/lib.rs (1)
21-39: TheFactCheckerstruct and itsis_validmethod are well implemented, using thealloylibrary for network interactions and providing robust error handling. Ensure that the integration with the Ethereum network and the fact registry is thoroughly tested.Verification successful
The
FactCheckerstruct and itsis_validmethod are well implemented and correctly integrated with the Ethereum network and fact registry. Theis_validmethod is used to validate facts and handle task statuses appropriately in theSharpProverService.
crates/prover_services/sharp_service/src/lib.rs: Theis_validmethod is called within theONCHAINbranch of a match statement, and its result determines the task status.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `FactChecker` with the Ethereum network and fact registry. # Test: Search for usage of `FactChecker` and ensure it's correctly interacting with the network. rg --type rust $'FactChecker'Length of output: 5476
Script:
#!/bin/bash # Extract relevant code from crates/prover_services/sharp_service/src/lib.rs to review the instantiation and usage of FactChecker. rg --type rust -A 10 'FactChecker' crates/prover_services/sharp_service/src/lib.rsLength of output: 1385
Script:
#!/bin/bash # Search for calls to the `is_valid` method within crates/prover_services/sharp_service/src/lib.rs. rg --type rust 'is_valid' crates/prover_services/sharp_service/src/lib.rsLength of output: 135
Script:
#!/bin/bash # Extract more lines around the `is_valid` call in crates/prover_services/sharp_service/src/lib.rs to understand its context. rg --type rust -A 10 -B 10 'is_valid' crates/prover_services/sharp_service/src/lib.rsLength of output: 1094
crates/prover_services/sharp_service/src/client.rs (1)
10-40: TheSharpClientstruct and its methods for adding jobs and checking job status are well implemented, usingreqwestfor network requests and handling errors robustly. Ensure that the error handling paths are thoroughly tested, especially the custom error types.crates/prover_services/prover_service/src/lib.rs (1)
4-44: TheProverServicetrait and related types are well defined, providing a clear abstraction for proof services. The error handling is comprehensive and well structured, covering a wide range of potential issues.Cargo.toml (2)
7-10: Added new workspace members for prover services.Ensure that the directory structure and module initialization in Rust are correctly set up for these new crates.
22-64: Dependencies for various services and utilities have been added.Verify that all added dependencies are used in the project and are compatible with each other to avoid conflicts.
crates/prover_services/gps_fact_checker/src/error.rs (1)
1-51: Comprehensive error handling for the GPS fact checker.Ensure that all potential error cases are handled in the calling functions to maintain robustness.
crates/prover_services/gps_fact_checker/src/fact_info.rs (1)
1-72: Implementation of fact information retrieval and processing.Review the usage of
unwrapand ensure proper error handling is in place to avoid panics in production.crates/orchestrator/src/queue/job_queue.rs (1)
12-13: Integration of job processing and verification functions.Ensure that the job processing functions are thoroughly tested, especially with different types of jobs and error scenarios.
crates/prover_services/sharp_service/src/lib.rs (1)
22-71: Implementation of theSharpProverServicefor interacting with the SHARP API.Ensure that error handling is robust, especially in network communication and data parsing scenarios.
crates/orchestrator/src/jobs/types.rs (1)
74-77: Updated job type definitions to reflect new functionalities.Ensure that all parts of the system that use these job types are updated to handle the new definitions correctly.
crates/orchestrator/src/database/mongodb/mod.rs (1)
Line range hint
24-43: Optimistic locking implemented for job updates in MongoDB.Verify that the versioning mechanism is correctly implemented in all parts of the system that modify job data to prevent update conflicts.
crates/orchestrator/src/config.rs (1)
Line range hint
88-122: Configuration setup for various services in the orchestrator.Ensure that the configuration is flexible and can be easily modified to accommodate changes in the underlying services or infrastructure.
crates/prover_services/gps_fact_checker/src/fact_node.rs (1)
31-41: FactNode structure is well-defined and appropriate for its use case.crates/orchestrator/src/jobs/da_job/mod.rs (1)
11-14: Ensure proper error handling in DaJob methods.While the methods seem to handle errors, ensure that all potential error cases are covered, especially in asynchronous operations. Consider adding more comprehensive error logging and recovery mechanisms.
crates/orchestrator/src/jobs/mod.rs (2)
17-17: Job trait is well-defined and covers essential methods needed for job handling.
103-103: Ensure robust error handling inverify_job.While the function handles different verification statuses, ensure that all error cases are thoroughly handled, especially in asynchronous operations. Consider adding more detailed error logging and recovery mechanisms.
crates/prover_services/gps_fact_checker/src/artifacts/FactRegistry.json (1)
1-1: ABI definitions forhasRegisteredFactandisValidare correctly structured.
There was a problem hiding this comment.
Actionable comments posted: 0
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
Files selected for processing (5)
- crates/prover_services/gps_fact_checker/Cargo.toml (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_info.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_node.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_topology.rs (1 hunks)
- crates/utils/src/lib.rs (1 hunks)
Files skipped from review as they are similar to previous changes (5)
- crates/prover_services/gps_fact_checker/Cargo.toml
- crates/prover_services/gps_fact_checker/src/fact_info.rs
- crates/prover_services/gps_fact_checker/src/fact_node.rs
- crates/prover_services/gps_fact_checker/src/fact_topology.rs
- crates/utils/src/lib.rs
There was a problem hiding this comment.
Actionable comments posted: 2
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (4)
- crates/prover_services/prover_service/src/lib.rs (1 hunks)
- crates/prover_services/sharp_service/src/error.rs (1 hunks)
- crates/prover_services/sharp_service/src/lib.rs (1 hunks)
- crates/prover_services/stone_service/src/lib.rs (1 hunks)
Files skipped from review as they are similar to previous changes (2)
- crates/prover_services/prover_service/src/lib.rs
- crates/prover_services/sharp_service/src/error.rs
Additional comments not posted (4)
crates/prover_services/stone_service/src/lib.rs (1)
41-44: Constructor implementation looks good.The constructor
with_settingscorrectly uses dependency injection to initialize theregistry. This is a good practice for maintainability and testability.crates/prover_services/sharp_service/src/lib.rs (3)
21-25: Struct definition is appropriate.The
SharpProverServicestruct is well-defined with fields forsharp_clientandfact_checker, which are essential for its functionality.
27-65: Method implementations are comprehensive and handle various scenarios.The methods
submit_taskandget_task_statusinSharpProverServiceare well-implemented, covering various scenarios and incorporating error handling effectively.
81-92: Utility functions for task ID manipulation are correctly implemented.The functions
combine_task_idandsplit_task_idare correctly implemented using standard libraries and include appropriate error handling.
There was a problem hiding this comment.
Actionable comments posted: 3
Out of diff range and nitpick comments (3)
crates/prover_services/gps_fact_checker/src/artifacts/README.md (3)
9-9: Consider rephrasing to enhance clarity.Instead of "In order to generate zip compressed Cairo PIEs follow the instructions at", consider "To generate zip-compressed Cairo PIEs, follow the instructions at".
17-17: Ensure fenced code blocks are properly formatted.Add blank lines before and after the fenced code blocks for proper markdown formatting.
Also applies to: 28-28
12-12: Improve list formatting.Add blank lines before and after the list for better markdown formatting.
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
crates/prover_services/gps_fact_checker/src/artifacts/fibonacci.zipis excluded by!**/*.zip
Files selected for processing (5)
- crates/prover_services/gps_fact_checker/src/artifacts/README.md (1 hunks)
- crates/prover_services/gps_fact_checker/src/artifacts/get_fact.py (1 hunks)
- crates/prover_services/gps_fact_checker/src/error.rs (1 hunks)
- crates/prover_services/gps_fact_checker/src/fact_info.rs (1 hunks)
- crates/prover_services/sharp_service/src/config.rs (1 hunks)
Files skipped from review due to trivial changes (1)
- crates/prover_services/gps_fact_checker/src/artifacts/get_fact.py
Files skipped from review as they are similar to previous changes (3)
- crates/prover_services/gps_fact_checker/src/error.rs
- crates/prover_services/gps_fact_checker/src/fact_info.rs
- crates/prover_services/sharp_service/src/config.rs
Additional Context Used
LanguageTool (2)
crates/prover_services/gps_fact_checker/src/artifacts/README.md (2)
Near line 8: Consider a shorter alternative to avoid wordiness.
Context: ...the repo using Foundry. ## Cairo PIEs In order to generate zip compressed Cairo PIEs foll...
Near line 23: Possible missing comma found.
Context: ...facts To create test vectors for SHARP facts you would need to install the Cairo0 to...
crates/prover_services/gps_fact_checker/src/artifacts/README.md
Outdated
Show resolved
Hide resolved
crates/prover_services/gps_fact_checker/src/artifacts/README.md
Outdated
Show resolved
Hide resolved
crates/prover_services/gps_fact_checker/src/artifacts/README.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (3)
Cargo.lockis excluded by!**/*.lockcrates/prover_services/sharp_service/src/artifacts/fibonacci.zipis excluded by!**/*.zipcrates/prover_services/sharp_service/src/artifacts/print.zipis excluded by!**/*.zip
Files selected for processing (6)
- Cargo.toml (2 hunks)
- crates/prover_services/sharp_service/Cargo.toml (1 hunks)
- crates/prover_services/sharp_service/src/client.rs (1 hunks)
- crates/prover_services/sharp_service/src/config.rs (1 hunks)
- crates/prover_services/sharp_service/src/error.rs (1 hunks)
- crates/prover_services/sharp_service/src/lib.rs (1 hunks)
Files skipped from review as they are similar to previous changes (6)
- Cargo.toml
- crates/prover_services/sharp_service/Cargo.toml
- crates/prover_services/sharp_service/src/client.rs
- crates/prover_services/sharp_service/src/config.rs
- crates/prover_services/sharp_service/src/error.rs
- crates/prover_services/sharp_service/src/lib.rs
There was a problem hiding this comment.
Actionable comments posted: 0
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
Files selected for processing (2)
- crates/orchestrator/Cargo.toml (1 hunks)
- crates/orchestrator/src/jobs/prover_job/mod.rs (1 hunks)
Files skipped from review as they are similar to previous changes (2)
- crates/orchestrator/Cargo.toml
- crates/orchestrator/src/jobs/prover_job/mod.rs
unstark
force-pushed
the
feat/prover-traits
branch
2 times, most recently
from
081b35b to
cd95f27
Compare
crates/orchestrator/src/jobs/prover_job/artifacts/fibonacci.zip
Outdated
Show resolved
Hide resolved
crates/prover_services/gps_fact_checker/src/artifacts/FactRegistry.json
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| pub enum Task { | ||
| CairoPie(CairoPie), |
There was a problem hiding this comment.
what sort of other tasks do you think we will have in the future for the prover service?
There was a problem hiding this comment.
Can be encoded PIE to avoid deserialization/serialization when reading from DB -> sending to the prover service. The problem with SHARP is that you still have to decode in order to calculate fact, but this is not a problem with e.g. Madara prover API
| snos::sharp::pie::encode_pie_mem(cairo_pie).map_err(ProverServiceError::PieEncoding)?; | ||
| let res = self.sharp_client.add_job(&encoded_pie).await?; | ||
| if let Some(job_key) = res.cairo_job_key { | ||
| Ok(combine_task_id(&job_key, &fact_info.fact)) |
There was a problem hiding this comment.
do we need to combine it if we're anyways going to split and use the job_key only later on? if the purpose is to store the fact so that it can be reused, then we can do that by storing it inside the metadata as well. wdyt?
There was a problem hiding this comment.
The thing is that it is know by the sharp service only, i.e. the Task type is completely opaque. Generally I don't think we will need fact on the top level, and if so it would be better to introduce a separate method for calculating the fact or modify the submit_task signature
unstark
force-pushed
the
feat/prover-traits
branch
7 times, most recently
from
1f35cf1 to
07db0af
Compare
unstark
force-pushed
the
feat/prover-traits
branch
from
07db0af to
cdafcd4
Compare
* Prover service trait and SHARP client implementation * _ to - in crates * fix taplo * fix taplo again --------- Co-authored-by: apoorvsadana <95699312+apoorvsadana@users.noreply.github.com>
This WIP PR introduces prover traits and implementation stubs.
ProverServiceis the top-level abstraction, responsible for generating proofs given Cairo runner output and registering that proof onchain. Prover service is agnostic to the proving system (stark, cstark, halo2, etc) and base layer (Ethereum, Starknet, other EVM, Aligned Layer, etc).StoneProverServiceis an implementation of theProverServicetrait that combines Madara prover API (Stone + RPC) and one of the supported fact registries (Solidity StarkEx contracts, Cairo Integrity, Sovereign -- DA layer).Other
ProverServiceimplementations:Summary by CodeRabbit
New Features
ProverJobstruct with methods for job creation, processing, and verification.FactCheckerstruct for checking the validity of facts using aFactRegistry.SharpClientfor interacting with the SHARP API.Enhancements
JobTypefor better clarity.Bug Fixes
Documentation
Chores
Cargo.tomlfiles to reflect new and updated dependencies.