nethermindeth / blockifier

Blockifier is a Rust implementation for the transaction-executing component in the StarkNet sequencer, in charge of creating state diffs and blocks.

Blockifier

Report a Bug · Request a Feature · Ask a Question

Table of Contents

• About
• Roadmap
• Support
• Security
• License

---

About

Blockifier is a Rust implementation of the component in the Starknet sequencer that executes transactions, and is in charge of creating state diffs and blocks.

Roadmap

The Blockifier is a step towards a decentralized sequencer client for Starknet, allowing anyone to run one. We'll add more milestones to this table once we finish the first one, where we blockify transactions sequentially, including all existing functionality.

name	status
Add the ability to execute a block and output a state diff.	✅
Integrate with the existing Starknet Sequencer by replacing its current transaction-blockifying component, which is written in Python.	⏳
Implement optimistic concurrency of transaction execution.
Extend the Blockifier into a full Starknet sequencer, written in Rust, replacing the one currently in use.

Support

Reach out to the maintainer at one of the following places:

• GitHub Discussions
• Contact options listed on this GitHub profile

Security

Blockifier follows good security practices, but 100% security cannot be assured. Blockifier is provided "as is" without any warranty. Use at your own risk.

For more information and to report security issues, please refer to our security documentation.

License

This project is licensed under the Apache 2.0 license.

See LICENSE for more information.

blockifier's Issues

Moving Native Compilation outside of the Blockifier

General Idea

The Native Blockifier is capable of executing Starknet Contracts compiled ahead of time using the Cairo Native compiler. The way it works currently is:

1. The Blockifier receives a Starknet Contract in Sierra.
2. It compiles it down to Machine Code.
3. Executes it.
4. Returns the Execution Trace.

This setup, although initially good enough for testing, won't be good in Production. The main reason is that it creates a bottleneck during execution where it will stop just to compile a file something that could have already been done by this point. It also raises other issue such as what to do with the compile file, store it somewhere (and how long) or delete it.

This two problems are not for the Blockifier to take care of but by the Sequencer/Nodes. We need to update the workflow, removing the compilation step, to:

1. The Blockifier receives a Starknet Contract compiled with Cairo Native.
2. Executes it.
3. Returns the transaction trace

More technical

We currently have a SierraContractClass representing a Contract Definition written in Sierra. We should swap it for a NativeContractClass representing a Contract Definition compiled with Native.

This will break the general flow of the program since everything is based on getting this Sierra and compiling it. Also, I don't know how difficult it could be to represent a Natively Compiled Contract as a Rust object (maybe it's very easy).

Finally, you should take into account testing. Testing uses Sierra files which are compiled with Native during the test execution. Since now we won't have anymore compilation, those should be compiled (by having them pre-compiled) or compiling them directly in execution. We can discuss the best solution for this.

Juno

The problem of solving this issue alone is that we are going to end up with something un-usable since there isn't any Node prepared to work with the Native compiler.

The solution for this is that we are going to prep Juno in a patchy way to perform the compilation on it's side. Juno communicates with the Blockifier using CGo (an FFI). This communication layer is written partly in Go and partly in Rust.

The Patchy solution comes when the Juno sends the Sierra to the Blockifier, being able to "capture" it in the Rust side of the translation, compiling it with Native, and sending that instead. Maybe we can improve over this idea.

Now, this won't fix any of the problems mentioned, but for the scope of our tests we don't care about them. We only care about Native Blockifier performing the same as Base Blockifier.
What this will do is to make our current Native Blockifier prototype achieve its final form, making it ready (or almost-ready) for production.

Splitting Syscall Tests into multiple sub modules

The Syscall Test has gotten big and hard to traverse. We should split it and have all tests grouped by the functionality they are testing.

Find & Fix Mismatch in in Get Execution Info result

Executing get_execution_info returns a TxInfo as parts of its result. There is a missmatch between the account_contract_address returned by the syscall and the one expected.

The syscall is returning the correct one but it seems that Native is reading the value where it shouldn't (perhaps because it is boxed).

To solve the issue we need to (i) learn what is causing this error, (ii) fix it by either updating the code or our dependencies

Share secp256 implementation between native and non-native.

In #102 native's secp256 syscall calls were simplified by inlining and making the operation stateless. These simplifications can be ported back to the non-native secp256 syscall handler such that the native and non-native syscall handler can share parts of the implementation.

Native resources should match the VMs

Gas handling for Native is still not implemented. When real testing this cause for transactions that should fail for insufficient founds are actually being executed, possibly affecting transactions later on.

We need to implement a mechanisms for Native transactions to match the resources used by the VM.

Address naming of `starkfelt_to_felt` & `felt_to_starkfelt` AND `stark_felt_to_felt` & `felt_to_stark_felt`

It turns out we have very similar names for utilites that do very similar things. We should address this.

Fix Library Calls for VM

Execution Failure when the VM. Probable cause is gas but should investigate

Update Blockifier to 2.6.0-rc1

Update Blockifier and Native to the latest posible version

Fix Native Keccak

Keccak is failing. It is producing the wrong hash value.

    #[external(v0)]
    fn test_keccak(ref self: ContractState) {
        let mut input: Array::<u256> = Default::default();
        input.append(u256 { low: 1, high: 0 });

        let res = keccak::keccak_u256s_le_inputs(input.span());
        assert(res.low == 0x587f7cc3722e9654ea3963d5fe8c0748, 'Wrong hash value');
        assert(res.high == 0xa5963aa610cb75ba273817bce5f8c48f, 'Wrong hash value');
    }

Test Get Execution V1

Currently, get_execution_info_v1 is missing tests due to compilers defaulting to version v2 when compiling.

Nonetheless, is still possible to find versions v1 when executing transactions. We should find a way to add tests for this as seamlessly as possible.

Investigate the reason Get Execution Info Txs are failing

All transactions which handle getting execution info are failing. This issue is to investigate (and not necessarily to solve) the reasons behind it.

Create syscall counter for NativeSyscallHandler

Make fallback system

The Blockifier will be using two systems to execute transactions:

1. The battle-tested VM
2. The new and faster but still unreliable Cairo Native

It will default to the Cairo Native one but a system must be put in place when the this fails to start execution using the first one.

Points are failures can occur twice:

• During Compilation
• During Execution

We will asume that Naive will return their errors wrapped in a result.

Event emitting should fail when maximum size is breached

Currently event emitting in Native doesn't fail when the amount of data encoded exceeds upper limit.

Find & Fix the reason secp256k1 is Failing

Implement Unit-tests

Fix get_block_hash for the VM

Currently, when executingtest_get_block_hash there is a faulire during validation for the VM.

Update to the latest cairo-native

rev: 8b49c84318c23a33bd9081c99b7bd312631abf03

Implement secp256r1

secp256r1 needs to be implemented

Update test_get_execution_info to use the updated testing framework.

When executing test_get_execution_info it keeps the old test designs, where both Cairo1 and Cairo0 contracts are initialized and an input flag is_legacy determines which one to execute. This can be re-structured to remove the flag and set the input directly to Cairo0 test contract in the right places.

Investigate how events work on cairo-native side

Investigate how events work on cairo-native side in order to solve issues with events emitting

Assure that all VM tests are working fine

Assure that VM tests are working when using Cairo Native in the simillar way without changing any logic

Creating a Native Utils file

Adding a Native Utils file such that all native specific utilities can be found there

Split Event Emitting Syscall Test

Event emitting test consist of four different test cases. Divide the test into 4 minor tests accordingly.

This will let us see with a more granularity where Native is failing and the VM is not.

Improve the cli tooling for Cairo Native

Overallocation of points when using secp256 operations on native.

Whenever an secp256 addition or multiplication is performed the arguments are unnecessarily allocated.

Integrate Deploy Syscall Test with Blockifier

Modify the deploy syscall test to work with both Native and the VM

Detect & Fix Slow times using Native

AMM tests

Add AMM test using cairo-native

• link: https://github.com/lambdaclass/yet-another-swap

Tests covered:

• Faucet
• Factory
• Pool
• Router
• ?ERC20

Implement secp256k1

It should be implemented in the Native Syscall Handler. Also, make sure the test is available for Native as well

Add unit tests to Sierra Utils

We have a couple of core functionality in Sierra Utils. Most of this functionality is untested which makes it vulnerable to changes that could affect their behaviour.

We should add unit tests for each of them

Point free secp256 on native

Native doesn't need to keep track of points when executing secp256 operations. Rewrite the instructions in terms of Affine<Curve> instead of the old syscall handler.

Update to latest Blockifier version with Cairo 2.7.0

Make `test_replace_class` work with Native

test_replace_class is working with only the VM. The test should be updated to work with Native and the VM

Investigate struct ordening `u256` in Cairo and Native/Blockifier

Accessing the high part of a U256 from within Rust gives the same result as accessing the low part of u256 from within Cairo. This seems to point to the order of the struct getting mixed up. We currently workaround this in both keccak and secp in the native starknet sycall handler.

Investigate Nested Library Calls Test Failure for Native

It seems Native is not executing no inner Calls (test_nested_library_call), or at least it is not reporting them. We should investigate and determine if the fix is on our side or on the Native side