​
Overview

SHARP is StarkWare’s proof aggregator, which uses proof recursion and the S-two prover to make proving affordable for everyone, and is used by Starknet to reduce costs and improve efficiency within the network.
Atlantic is a managed ZK Prover service that allows developers to easily integrate with SHARP.
Additional resources

​
What is SHARP?

Being a provable programming language, Cairo allows generating STARK proofs for the validity of its execution, which can then be verified onchain to guarantee their correctness. SHARP (SHARed Prover) is a powerful system designed to generate a unified STARK proof for multiple Cairo programs and verify it on Ethereum. Leveraging the exponential asymmetry of the STARK protocol, this allows applications to share the cost of verifying proofs onchain with other applications, as well as “break down” their computations into several smaller computations without increasing costs. For Starknet, this results in sending only a single proof per multiple blocks to Ethereum, and paying for its onchain verification only with respect to their relatize share in it.

​
How does SHARP work?

​
High-level overview

SHARP’s architecture consists of several services that work together to generate proofs, which include:
  1. The Gateway, through which external Cairo position-independent executions (Cairo PIEs) can be submitted to SHARP
  2. The Job Creator, which processes external Cairo PIEs into jobs and prevents duplications
  3. The Validator, which runs validation checks on each job, ensuring they can be proven successfully
  4. The Scheduler, which determines which Cairo job are to be aggregated together
  5. The Cairo Runner, which executes Cairo jobs and creates their Cairo PIEs
  6. The Prover (either Stone or S-two), which generates STARK proofs of Cairo PIEs
  7. The Dispatcher, which either packages proofs before sending them onchain, or verifies them using the Cairo verifier, creates a corresponding recursive job, and sends it back to the validator
  8. The Blockchain Writer, which is responsible for sending packages from the dispatcher onchain for verification
  9. The Catcher, which monitors onchain transactions to ensure that they have been accepted
The following is a high-level overview of SHARP’s architecture flow:

​
Stone and S-two

SHARP uses StarkWare’s first-gen Stone prover to generate STARK proofs for all proofs it aggregates. Starting from Starknet version 0.14.0, SHARP will use StarkWare’s next-gen S-Two prover for generating all proofs except those of recursive tree roots, which will still to be generated using Stone. Continuing to use Stone for proving recursive tree roots is done to avoid changing SHARP’s onchain verifiers.

​
Proof recursion

Since its inception, SHARP has undergone a handful of efficiency upgrades, with the most powerful being the shift from a linear to a recursive model. In the linear model, SHARP waited for enough programs to “fill up” a proof, and only then started the proving process for the whole bundle of programs. In the recursive model, SHARP proves each statement upon its arrival, and instead of verifying it onchain, it verifies it offchain using a verifier program written in Cairo. Each two such verifications are then aggregated together and sent back to SHARP and the Cairo verifier, restarting the process. This continues recursively, with each new proof being sent to the Cairo verifier until a trigger is reached. At this point, the last proof in the series is sent to the Solidity verifier on Ethereum. At first glance, recursive proofs may seem more complex and time-consuming. However, there are several benefits to this approach:
  1. Parallelization: Recursive proofs enable work parallelization, reducing user latency and improving SHARP efficiency
  2. Cheaper onchain costs: Parallelization enables SHARP to create larger proofs, which in turn result in reduced onchain costs
  3. Lower cloud costs: Since each job is smaller, the required memory for processing is reduced, resulting in lower cloud costs
  4. Cairo support: Recursive proofs only require support in Cairo, without the need to add support to the onchain verifiers

​
Onchain verifier

SHARP’s onchain verifiers is a set of multiple smart contracts responsible for verifying STARK proofs generated by SHARP, the key of which are:
  • GpsStatementVerifier, which serves as the primary verifier contract and relies on smaller verifier contracts that contain specific verification logic.
    For future enhancements or adjustments, a Proxy and CallProxy contracts are used allow seamless updates to the GpsStatementVerifier without compromising its foundational logic.
  • MemoryPageFactRegistry, which maintains hashes of the proven programs’ memory pages, primarily used to register outputs for data availability
  • MerkleStatementContract, which verifies the Merkle paths in the STARK proof
  • FriStatementContract, which is responsible for verifying the FRI layers in the STARK proof
The verification flow consists of the following steps:
  1. The Dispatcher sends:
    • Memory pages (usually many) to the MemoryPageFactRegistry contract
    • Merkle statements (typically between 3 and 5) to the MerkleStatementContract contract
    • Fri statements (generally ranging from 5 to 15) to the FriStatementContract contract
  2. The Dispatcher send the proof to the GpsStatementVerifier contract
  3. Starknet monitors the GpsStatementVerifier contract and updates its state once verification is complete