Investigate Cairo 1 runner

[cicr99]

There should be a few differences between cairo zero runner and the one for cairo 1. These will dictate whether we can reuse some of our current code. There are two important things we need to check:

• [ ] Check instructions. Check whether there are differences in the way to decode the instructions or how a specific instruction is supposed to change the state
• [ ] Check pipeline. I'm interested here in checking the initialization of all the segments, if there are any particular constraints we need to follow, execution of builtins and hints. Take a look at function run_function_with_starknet_context here which is called from here.

Write a comment in this issue outlining all the info you gather about each of this, so we can then create specific tasks to work on.

[Sh0g0-1758]

Cairo One Runner Write Up

To start off, I found some new builtins in Cairo one.

• [x] Output
• [x] Pedersen
• [x] Range Check
• [x] ECDSA
• [x] Bitwise
• [x] EC OP
• [x] Keccak
• [x] Poseidon
• [ ] Range Check96
• [ ] AddMod
• [ ] MulMod
• [ ] Segment Arena
• [ ] Gas
• [ ] System

We will also have to add support for sierra in the VM. The cairo one runner's struct have these extra variables :

    /// The sierra program.
    sierra_program: cairo_lang_sierra::program::Program,
    /// Metadata for the Sierra program.
    metadata: Metadata,
    /// Program registry for the Sierra program.
    sierra_program_registry: ProgramRegistry<CoreType, CoreLibfunc>,
    /// Program registry for the Sierra program.
    type_sizes: TypeSizeMap,
    /// The casm program matching the Sierra code.
    casm_program: CairoProgram,
    /// Mapping from class_hash to contract info.
    starknet_contracts_info: OrderedHashMap<Felt252, ContractInfo>,

In the runner, we will have to introduce some new functions :

1. get_initial_available_gas : Returns the initial value for the gas counter. In case there are not any costs - it means no gas equations were solved (and we are in the case of no gas checking enabled) - so the gas builtin is irrelevant, and we can return any value.
2. create_entry_code and create_code_footer : Returns the instructions to add to the beginning of the code to successfully call the main function, as well as the builtins required to execute the program.
3. assemble_ex : Creates an assembled representation of the program preceded by header and followed by footer.
4. There is also a separate HintProcessor which is required to run through the hints before the vm executes it. This is preceded by a build_hints_dict function which register hint with string for the hint processor. Its struct is :

pub struct CairoHintProcessor<'a> {
    /// The Cairo runner.
    pub runner: Option<&'a SierraCasmRunner>,
    /// A mapping from a string that represents a hint to the hint object.
    pub string_to_hint: HashMap<String, Hint>,
    /// The starknet state.
    pub starknet_state: StarknetState,
    /// Maintains the resources of the run.
    pub run_resources: RunResources,
    /// Resources used during syscalls - does not include resources used during the current VM run.
    /// At the end of the run - adding both would result in the actual expected resource usage.
    pub syscalls_used_resources: StarknetExecutionResources,
}

5. run_function : Runs the vm starting from a function with custom hint processor. Function may have implicits, but no other ref params. The cost of the function is deducted from available_gas before the execution begins.
6. After we initialize the vm, we add a builtin_cost segment but I am not really sure about what that means / do.

Cairo one VM changes :

Most of the code for the VM can be reused. There are a few changes required :

1. Support for the missing builtins that I mentioned above.
2. There is a new relocation rule in the rust vm :

Will return an error if any of the following conditions are not met:
- Source address's segment must be negative (temporary).
- Source address's offset must be zero.
- There shouldn't already be relocation at the source segment.