Solidity verifier
This topic previously appeared in the Starknet Book. |
Before exploring this topic, review the Starknet architecture: Overview for foundational knowledge. Familiarity with concepts such as sequencers, provers, SHARP, and SHARP jobs is assumed.
Starknet’s Solidity verifier plays a pivotal role in the rollup landscape, ensuring the truth of transactions and smart contracts.
Quick review: SHARP and SHARP jobs
For a more detailed explanation of SHARP and SHARP jobs, see Provers. This is a brief review. |
In Starknet, the Shared Prover, SHARP, aggregates various Cairo programs from distinct users. These programs, each with unique logic, run together, producing a common proof for all, optimizing cost and efficiency.
Furthermore, SHARP supports combining multiple proofs into one, enhancing its efficiency by allowing parallel proof processing and verification.
SHARP verifies numerous Starknet transactions, like transfers, trades, and state updates. It also confirms smart contract executions.
To illustrate SHARP: Think of commuting by bus. The bus driver, the prover, transports passengers, the Cairo programs. The driver checks only the tickets of passengers alighting at the upcoming stop, much like SHARP. The prover forms a single proof for all Cairo programs in a batch, but verifies only the proofs of programs executing in the succeeding block.
SHARP jobs enable multiple users to present their Cairo programs for combined execution, distributing the proof generation cost. This shared approach makes Starknet more economical for users, enabling them to join ongoing jobs and leverage economies of scale.
Solidity verifiers
A Solidity verifier is an L1 smart contract, crafted in Solidity, designed to validate STARK proofs from SHARP.
Previous architecture: Monolithic verifier
Historically, the Solidity verifier was a monolithic contract, both initiated and executed by the same contract. For illustration, the operator would invoke the update state
function on the main contract, providing the state to be modified and confirming its validity. Subsequently, the main contract would present the proof to both the verifier and the data availability committee. Once they validated the proof, the state would be updated in the main contract.
![Previous architecture](../_images/prehistoric-architecture.png)
However, this architecture faced several constraints:
-
Batching transactions frequently surpassed the original Geth 32 KB transaction size limit, later adjusted to 128 KB, due to accumulating excessive transactions.
-
The gas required often outstripped the block size (e.g., 8 Mgas), as the block couldn’t accommodate a complete batch of proof.
-
A prospective constraint was that the verifier wouldn’t support proof bundling, which is fundamental for SHARP.
Current architecture: Multiple smart contracts
The current verifier uses multiple smart contracts rather than being a singular, monolithic structure.
Here are some key smart contracts associated with the verifier:
-
GpsStatementVerifier
: This is the primary contract of the SHARP verifier. It verifies a proof and then registers the related facts usingverifyProofAndRegister
. It acts as an umbrella for various layouts, each namedCpuFrilessVerifier
. Every layout has a unique combination of built-in resources.Figure 2. Verifier layoutsThe system routes each proof to its relevant layout.
-
MemoryPageFactRegistry
: This registry maintains facts for memory pages, primarily used to register outputs for data availability in rollup mode. The Fact Registry is a separate smart contract ensuring the verification and validity of attestations or facts. The verifier function is separated from the main contract to ensure each segment works optimally within its limits. The main proof segment relies on other parts, but these parts operate independently. -
MerkleStatementContract
: This contract verifies Merkle paths. -
FriStatementContract
: It focuses on verifying the FRI layers.
SHARP verifier contract map
The SHARP verifier contract map contains roughly 40 contracts, detailing various components of the Solidity verifier. The images below display the contracts and their Ethereum Mainnet addresses.
These are currently the entire stack of contracts that comprise the SHARP verifier, with their Ethereum Mainnet addresses.
Proxy |
0x47312450B3Ac8b5b8e247a6bB6d523e7605bDb60 |
CallProxy |
0xD4C4044ACa68ebBcB81B13cC2699e1Bca2d3F458 |
GpsStatementVerifier |
0x47312450b3ac8b5b8e247a6bb6d523e7605bdb60 |
MemoryPageFactRegistry |
0xfd14567eaf9ba941cb8c8a94eec14831ca7fd1b4 |
MerkleStatementContract |
0x3e6118da317f7a433031f03bb71ab870d87dd2dd |
FriStatementContract |
0x3e6118da317f7a433031f03bb71ab870d87dd2dd |
CairoBootloaderProgram |
0x5d07afFAfc8721Ef3dEe4D11A2D1484CBf6A9dDf |
PedersenHashPointsXColumn |
0xc4f21318937017B8aBe5fDc0D48f58dBc1d18940 |
PedersenHashPointsYColumn |
0x519DA5F74503dA351EbBED889111377d33096002 |
EcdsaHashPointsXColumn
EcdsaHashPointsYColumn |
0xcA59f6FD499ffF50c78Ffb420a9bcd0d273abf29 |
CpuFrilessVerifier0
CpuOods0 CpuConstraintPoly0 CpuFrilessVerifier1 CpuOods1 CpuConstraintPoly1 CpuFrilessVerifier2 CpuOods2 CpuConstraintPoly2 CpuFrilessVerifier3 CpuOods3 CpuConstraintPoly3 CpuFrilessVerifier4 CpuOods4 CpuConstraintPoly4 CpuFrilessVerifier5 CpuOods5 CpuConstraintPoly5 CpuFrilessVerifier6 CpuOods6 CpuConstraintPoly6 PoseidonPoseidonFullRoundKey0Column6 PoseidonPoseidonFullRoundKey1Column6 PoseidonPoseidonFullRoundKey2Column6 PoseidonPoseidonPartialRoundKey0Column6 ם9999999999999999999ן CpuFrilessVerifier7 CpuOods7 CpuConstraintPoly7 |
.SHARP verifier contract map image::sharp-contract-map-1.png[SHARP verifier contract map] |
![SHARP verifier contract map](../_images/sharp-contract-map-2.png)
These contracts function as follows:
-
Proxy: This contract facilitates upgradability. It interacts with the
GpsStatementVerifier
contract using thedelegate_call
method. Notably, the state resides in theGpsStatementVerifier
contract, not in the proxy. -
CallProxy: Positioned between the
Proxy
and theGpsStatementVerifier
contracts, it functions like a typical proxy. However, it avoids thedelegate_call
method and calls the function in the implementation contract directly. -
CairoBootloaderProgram: Comprising numerical Cairo programs, it validates the Cairo program of a statement. The bootloader manages the logic executing Cairo programs to generate proof and program hash.
-
PedersenHashPoints (X & Y Column): These lookup tables store vast amounts of data. Validation functions consult them to compute the Pedersen hash.
-
EcdsaPoints (X & Y Column): Similar to the Pedersen hash, these tables assist in calculating the elliptic curve.
-
CpuFrilessVerifier/CpuOods/CpuConstantPoly (0 - 7): These verifier contracts vary in layout as shown in the
GpsStatementVerifier
layout image. Each layout encompasses resources, built-ins, constraints, and more, designed for a specific task. Each has unique parameters for its constructor. -
PoseidonPoseidon: These contracts back the new Poseidon built-in and contain Poseidon-specific lookup tables.
Constructor parameters of key contracts
When constructing the primary verifier contracts, specific parameters are employed to facilitate functionality. These parameters reference other auxiliary contracts, decentralizing the logic and ensuring the main contract remains under the 24kb deployment limit.
Below is a visual representation of these parameters in relation to key contracts CpuFrilessVerifiers
and GpsStatementVerifier
:
![Constructor Parameters](../_images/constructor-params.png)
CpuFrilessVerifier constructor parameters
CpuFrilessVerifiers
is designed to handle a diverse range of tasks. Its parameters encompass:
-
Auxiliary Polynomial Contracts: These include
CpuConstraintPoly
,PedersenHashPointsxColumn
,PedersenHashPointsYColumn
,EcdsaPointsXColumn
, andEcdsaPointsYColumn
. -
Poseidon-Related Contracts: Several
PoseidonPoseidonFullRoundKey
andPoseidonPoseidonPartialRoundKey
contracts. -
Sampling and Memory: The contract uses
CpuOods
for out-of-domain sampling andMemoryPageFactRegistry
for memory-related tasks. -
Verification: It integrates with
MerkleStatementContract
for Merkle verification andFriStatementContract
for Fri-related tasks. -
Security: The
num_security_bits
andmin_proof_of_work_bits
contracts ensure secure operation.
For instances like |
GpsStatementVerifier constructor parameters
The GpsStatementVerifier
functions as the hub of verifier operations, necessitating various parameters for effective functioning:
-
Bootloader: It references the
CairoBootloaderProgram
to initiate the system. -
Memory Operations: This is facilitated by the
MemoryPageFactRegistry
contract. -
Sub-Verifiers: It integrates a series of sub-verifiers (
CpuFrilessVerifier0
throughCpuFrilessVerifier7
) to decentralize tasks. -
Verification: The hashes,
hashed_supported_cairo_verifiers
andsimple_bootloader_program_hash
, are essential for validation processes.
Interconnection of contracts
The GpsStatementVerifier
serves as the primary verifier contract, optimized for minimal logic to fit within deployment size constraints. To function effectively:
-
It relies on smaller verifier contracts, which are already deployed and contain varied verification logic.
-
These smaller contracts, in turn, depend on other contracts, established during their construction.
In essence, while the diverse functionalities reside in separate contracts for clarity and size efficiency, they are all interlinked within the GpsStatementVerifier
.
For future enhancements or adjustments, the proxy and callproxy contracts facilitate upgradability, allowing seamless updates to the GpsStatementVerifier
without compromising its foundational logic.
SHARP verification flow
![SHARP verification flow](../_images/new-sharp-flow.png)
-
The SHARP dispatcher transmits all essential transactions for verification, including: a.
MemoryPages
(usually many). b.MerkleStatements
(typically between 3 and 5). c.FriStatements
(generally ranging from 5 to 15). -
The SHARP dispatcher then forwards the proof using
verifyProofAndRegister
. -
Applications, such as the Starknet monitor, validate the status. Once verification completes, they send an
updateState
transaction.