# 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:

      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:

        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)
        );

        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.