Kakarot Cairo 1.0 migration journey

[AbdelStark]

The goal of this discussion is to leverage the Cairo 1.0 migration experience of Kakarot for all Starknet ecosystem.

We will discuss the challenges, the findings, some useful tips for projects that will have to migrate their code to Cairo 1.0.

Once we have gathered enough content and feedback we will write a complete migration guidelines and best practices.

Let's start the great Cairo 1.0 migration adventure together!

🐺 + 🦀 = ❤️

[AbdelStark]

Difficulty related to Cairo 1.0 evolving fast

Description

One of the main difficulty we are currently facing is that Cairo 1.0 is still in alpha version, with a lot of missing features. As a result, you can have breaking changes in your code when you upgrade the Cairo 1.0 version you use.
Also, because it is not yet a stable version, it is possible that you will find bugs during the migration. When it happens please submit them and create issues in the Cairo 1.0 repo.

💡 Tips

We recommend the projects to update frequently the version of Cairo 1.0, both locally and in the continuous integration pipelines.

• 💡You can use a custom version of Cairo 1.0 from the artifacts of the compiler. You can check the list of published artifacts here. Then you can use them is your CI, example here. It will enable you to:
  • catch breaking changes faster
  • benefit from new features and don't wait for published releases

[AbdelStark]

Cairo != Starknet

Description

Cairo is not specific to Starknet, and it can be used as a general purpose programming language. Currently Cairo features are much closer to feature parity with Cairo 0.x than Starknet features are.
It can be tempting for projects to wait feature parity for their Starknet contracts.

However, I think there are some benefits of starting the migration earlier, even with missing Starknet features.

💡Tips

• 💡You can start migrating your business logic as pure Cairo code. The idea is to implement the core logic of your project, without dependencies to Starknet features. This pure Cairo logic can be then integrated later in Starknet contracts. It's a good way to get familiar with the language and start the migration. I think it's a good opportunity to speed up the Cairo 1.0 learning curve of devs, and at the same time start the migration earlier and be ready on time for regenesis.

[AbdelStark]

Use and contribute to community standard library

Description

Quaireaux is a community maintained standard library for Cairo 1.0.

The idea is to have a library with useful primitives, optimised and well tested algorithms that any project can use.

💡Tips

• 💡Before implementing an algorithm, a data structure, or any primitive in Cairo 1.0 check first if it exists already in Quaireaux. If it exists, use it. If it does not, consider submitting a pull request in Quaireaux to implement the feature, if you think it can be useful for other projects. If you are not sure, just create an issue in Quaireaux about your idea.

[AbdelStark]

Consider using AI to help

We are using AI to help during the migration of Kakarot.
Basically Open AI playground + Github copilot labs.

Example prompt to generate boiler plate code with doc functions from Cairo to Cairo 1.

Imagine that you are a developer. You need to migrate a code from a language to another one. When you are given an Input in cairo0 you need to transform it and display the output in cairo1. Below an example:
Input:
```cairo0
    // @notice COINBASE operation.
    // @dev Get the hash of one of the 256 most recent complete blocks.
    // @dev 0 if the block number is not in the valid range.
    // @custom:since Frontier
    // @custom:group Block Information
    // @custom:gas 20
    // @custom:stack_consumed_elements 1
    // @custom:stack_produced_elements 1
    // @param ctx The pointer to the execution context
    // @return ExecutionContext The pointer to the updated execution context.
    func exec_blockhash{
        syscall_ptr: felt*,
        pedersen_ptr: HashBuiltin*,
        range_check_ptr,
        bitwise_ptr: BitwiseBuiltin*,
    }(ctx: model.ExecutionContext*) -> model.ExecutionContext* {

Expected output:

/// BLOCKHASH operation.
/// Get the hash of one of the 256 most recent complete blocks.
/// if the block number is not in the valid range.
/// # Additional informations:
/// - Since:  Frontier
/// - Group: Block Information
/// - Gas: 20
/// - Stack consumed elements: 1
/// - Stack produced elements: 1
/// # Arguments
/// * `ctx` - the execution context
/// # TODO
/// - Implement me.
fn exec_blockhash(ref context: ExecutionContext) {}

Migrate the following cairo0 code to cairo1:
Input:

    // @notice ADDRESS operation.
    // @dev Get address of currently executing account.
    // @custom:since Frontier
    // @custom:group Environmental Information
    // @custom:gas 2
    // @custom:stack_consumed_elements 0
    // @custom:stack_produced_elements 1
    // @param ctx The pointer to the execution context
    // @return ExecutionContext The pointer to the updated execution context.
    func exec_address{
        syscall_ptr: felt*,
        pedersen_ptr: HashBuiltin*,
        range_check_ptr,
        bitwise_ptr: BitwiseBuiltin*,
    }(ctx: model.ExecutionContext*) -> model.ExecutionContext* {