---
# System prepended metadata

title: 'Proposal: Migration and Enhancement of Cairo Verifier'

---

# Cairo 1.0 Migration Proposal: Upgrading the Cairo 0 Verifier

## Background

With the evolution of the Cairo language and the advent of Cairo 1.0, there is an imminent need to transition our legacy tools. A prime example is the Cairo 0 verifier which should be updated to be compatible with the latest standard.

**Reference**: [cairo_verifier.cairo in starkware-libs repository](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/cairo/cairo_verifier.cairo)

## Goals

1. Transition from Cairo 0 to Cairo 1.0.
2. Integrate a fact registry system.
3. Design a hookable interface (events) to initiate on-chain operations in StarkNet upon proof verification based on state changes.

## Proposed Framework

1. **Cairo Verifier**
    - A function that accepts a proof and verifies its validity.

2. **Fact Registry**: 
    - A function designed to accept proof and respond with `true` or `false`.
    - If affirmed, the fact (a hash combining the program and its output) is incorporated into a mapping, which can be referred to later.


## Implementation Path

1. **Core Code Development**:
    - Refer to the central codebase at [cairo_verifier.cairo in starkware-libs repository](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/cairo/cairo_verifier/layouts/all_cairo/cairo_verifier.cairo).
    - The pivotal function is `verify_cairo_proof` with the signature:
      ```cairo
      fn verify_cairo_proof(proof: StarkProof) -> CairoVerifierOutput
      ```
    - Modules to port from [stark verifier](https://github.com/starkware-libs/cairo-lang/tree/master/src/starkware/cairo/stark_verifier) 
        - [air](https://github.com/starkware-libs/cairo-lang/tree/master/src/starkware/cairo/stark_verifier/air)
            - verify
            - global_values
            - public_verify
            - public_input
            - public_memory
        - [core](https://github.com/starkware-libs/cairo-lang/tree/master/src/starkware/cairo/stark_verifier/core)
            - air_interface
            - channel
            - config
            - fri
            - queries
            - table_commitment
            - traces
            - vector_commitment
        - [crypto](https://github.com/starkware-libs/cairo-lang/tree/master/src/starkware/crypto/signature)
            - fast_pedersen_hash (research if we can use poseidon?)

2. **Fact Registry**:
    - **Registering Fact Interface**:
      - Construct the function: 
        ```cairo
        trait FactRegistry {
            fn verify_proof_and_register(proof: StarkProof);
            fn is_valid(fact: felt252) -> bool;
        }
        ```
      - This interface should mirror the [solidity_verifier](https://book.starknet.io/chapter_3/solidity_verifier.html), with contract details accessible on [Etherscan](https://etherscan.io/address/0x6cb3ee90c50a38a0e4662bb7e7e6e40b91361bf6#code).
      
    - **Fact Validation Interface**:
      - Adopt the validation interface as depicted [here](https://etherscan.io/address/0x6cb3ee90c50a38a0e4662bb7e7e6e40b91361bf6#code#F7#L1).
      - The fact should be a unique signature of the executed program. Potentially constructed as (akin to Solidity's fact creation for SHARP): 
        ```
        bytes32 fact = keccak256(
            abi.encodePacked(cairoProgramHash, outputHash)
        );
        ```
        ```cairo
        fn generate_fact(cairo_program_hash: felt252, output_hash: felt252) -> felt252;
        ```
        ensuring the exclusive identification of the program's operation.
        We should be able to achieve similar behaviour [example contract](https://github.com/visoftsolutions/cairo-presentation/blob/master/contracts/Treasury.sol#L38-L60)

4. **Testing & Integration**:
    - Implement the Cairo 1.0 verifier.
    - Rigorously test the entire setup using a prototype dApp, particularly emphasizing the seamless flow involving the L2 claim function.
