feat(blockifier): add native execution engine #429

varex83 · 2024-08-13T12:31:22Z

This PR bring the boilerplate for the cairo native. It contains some functions that will be used in the future, and put here to parallelize creating of the following PRs.

To test this changes locally you need to set up native dependencies, which are described in cairo native repository:

Setup LLVM-18: mac: brew install llvm-18
Setup ENV variables:

If installed with brew

LIBRARY_PATH=/opt/homebrew/lib
MLIR_SYS_180_PREFIX="$(brew --prefix llvm@18)"
LLVM_SYS_181_PREFIX="$(brew --prefix llvm@18)"
TABLEGEN_180_PREFIX="$(brew --prefix llvm@18)"

export LIBRARY_PATH
export MLIR_SYS_180_PREFIX
export LLVM_SYS_181_PREFIX
export TABLEGEN_180_PREFIX

If installed using Debian / Ubuntu repository

MLIR_SYS_180_PREFIX=/usr/lib/llvm-18
LLVM_SYS_181_PREFIX=/usr/lib/llvm-18
TABLEGEN_180_PREFIX=/usr/lib/llvm-18

export MLIR_SYS_180_PREFIX
export LLVM_SYS_181_PREFIX
export TABLEGEN_180_PREFIX

Compile and specify path to cairo-native-runtime (for future use, you can test this PR without this step):

git clone https://github.com/lambdaclass/cairo_native
cd cairo_native/runtime
cargo build --release
cd .. and export CAIRO_NATIVE_RUNTIME_LIBRARY=$(pwd)/target/release/libcairo_native_runtime.a

NOTE: This PR should be rebased/merge with main after merging the #344

This change is

# Conflicts: # crates/blockifier/src/execution/syscalls/syscalls_test.rs

…-engine # Conflicts: # Cargo.lock

…cution-engine # Conflicts: # Cargo.lock

meship-starkware

Reviewable status: 0 of 36 files reviewed, 1 unresolved discussion (waiting on @varex83)

a discussion (no related file):
Could you please rebase the PR. Some of the changes are already merged

meship-starkware

Reviewable status: 0 of 36 files reviewed, 2 unresolved discussions (waiting on @varex83)

crates/blockifier/src/test_utils/contracts.rs line 221 at r18 (raw file):

                CairoVersion::Cairo0 => ERC20_CAIRO0_CONTRACT_SOURCE_PATH,
                CairoVersion::Cairo1 => ERC20_CAIRO1_CONTRACT_SOURCE_PATH,
            }

There is a new version of this function that might resolve this change. Look at this code:

sequencer/crates/blockifier/src/test_utils/contracts.rs

Line 243 in eb66da4

} else {

meship-starkware

Reviewed 1 of 19 files at r1, 1 of 11 files at r3, 11 of 17 files at r15, 16 of 20 files at r17.
Reviewable status: 28 of 36 files reviewed, 3 unresolved discussions (waiting on @varex83)

crates/blockifier/src/execution/call_info.rs line 27 at r18 (raw file):

}

#[derive(Clone, Debug, Default, Eq, PartialEq, Serialize)]

Why do you need Clone outside of the test scope?

meship-starkware

Reviewed 1 of 20 files at r17, all commit messages.
Reviewable status: 29 of 36 files reviewed, 3 unresolved discussions (waiting on @varex83)

meship-starkware

Reviewable status: 29 of 36 files reviewed, 4 unresolved discussions (waiting on @varex83)

-- commits line 21 at r18:
Why are the commit messages of the already merged PR still in this PR?

noaov1

Reviewed 3 of 17 files at r15, 1 of 20 files at r17, 1 of 1 files at r18.
Reviewable status: 30 of 36 files reviewed, 8 unresolved discussions (waiting on @meship-starkware and @varex83)

crates/blockifier/src/execution/contract_class.rs line 46 at r18 (raw file):

use super::entry_point::EntryPointExecutionResult;
use super::errors::EntryPointExecutionError;

Please avoid using super

Code quote:

use super::entry_point::EntryPointExecutionResult;
use super::errors::EntryPointExecutionError;

crates/blockifier/src/execution/contract_class.rs line 636 at r18 (raw file):

        entry_point_type: EntryPointType,
        entrypoint_selector: EntryPointSelector,
    ) -> EntryPointExecutionResult<&FunctionId> {

WDYT?

Suggestion:

    pub fn get_entrypoint(
        &self,
        call: &CallEntryPoint,
    ) -> EntryPointExecutionResult<&FunctionId> {

crates/blockifier/src/execution/contract_class.rs line 637 at r18 (raw file):

        entrypoint_selector: EntryPointSelector,
    ) -> EntryPointExecutionResult<&FunctionId> {
        let entrypoints = &self.entry_points_by_type[entry_point_type];

I saw that in the casm we verify that if the entry point type is constructor than the entry point selector must be equal to "constructor". Don't we need it here as well?

crates/blockifier/src/execution/contract_class.rs line 641 at r18 (raw file):

        entrypoints
            .iter()
            .find(|entrypoint| entrypoint.selector == entrypoint_selector)

What if there is more than one matching entry point? We want to return an error in this case

Code quote:

            .find(|entrypoint| entrypoint.selector == entrypoint_selector)

…cution-engine # Conflicts: # Cargo.lock # crates/blockifier/src/execution/contract_class.rs

varex83

Reviewable status: 28 of 36 files reviewed, 8 unresolved discussions (waiting on @meship-starkware and @noaov1)

-- commits line 21 at r18:

Previously, meship-starkware (Meshi Peled) wrote…

Why are the commit messages of the already merged PR still in this PR?

If we re-make the PR it will show only new commits, I tried to do something with that, without any results

crates/blockifier/src/execution/call_info.rs line 27 at r18 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

Why do you need Clone outside of the test scope?

Because in the execute_inner_call function, we need to return call_info and add it to the vector, so Clone is necessary here

Code snippet:

 pub fn execute_inner_call(
        &mut self,
        entry_point: CallEntryPoint,
        remaining_gas: &mut u128,
    ) -> SyscallResult<CallInfo> {
        let call_info = entry_point
            .execute(self.state, self.execution_resources, self.execution_context)
            .map_err(|e| encode_str_as_felts(&e.to_string()))?;
        let retdata = call_info.execution.retdata.0.clone();

        if call_info.execution.failed {
            // In VM it's wrapped into `SyscallExecutionError::SyscallError`.
            return Err(retdata);
        }

        self.update_remaining_gas(remaining_gas, &call_info);

        self.inner_calls.push(call_info.clone());

        Ok(call_info)
    }

crates/blockifier/src/execution/contract_class.rs line 636 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

WDYT?

Good catch!

crates/blockifier/src/execution/contract_class.rs line 637 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

I saw that in the casm we verify that if the entry point type is constructor than the entry point selector must be equal to "constructor". Don't we need it here as well?

Refactored

crates/blockifier/src/execution/contract_class.rs line 641 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

What if there is more than one matching entry point? We want to return an error in this case

Refactored

meship-starkware

Reviewed 2 of 3 files at r21, 5 of 6 files at r22, 1 of 1 files at r23, 2 of 8 files at r24, 1 of 1 files at r25, all commit messages.
Reviewable status: 34 of 42 files reviewed, 6 unresolved discussions (waiting on @noaov1 and @varex83)

meship-starkware

Reviewed 6 of 8 files at r24.
Reviewable status: 40 of 42 files reviewed, 6 unresolved discussions (waiting on @noaov1 and @varex83)

meship-starkware

Reviewable status: 40 of 42 files reviewed, 7 unresolved discussions (waiting on @noaov1 and @varex83)

crates/blockifier/src/execution/contract_class.rs line 681 at r25 (raw file):

        // function name is what is used by Cairo Native to lookup the function.
        // Therefore it's not enough to know the function index and we need enrich the contract
        // entry point with FunctionIds from SierraProgram.

    // Therefore, it's not enough to know the function index, and we need to enrich the contract
    // entry point with FunctionIds from SierraProgram.

Code quote:

        // Therefore it's not enough to know the function index and we need enrich the contract
        // entry point with FunctionIds from SierraProgram.

meship-starkware

Reviewable status: 40 of 42 files reviewed, 10 unresolved discussions (waiting on @noaov1 and @varex83)

crates/blockifier/src/execution/contract_class.rs line 676 at r25 (raw file):

        let sierra_program =
            sierra_contract_class.extract_sierra_program().expect("can't extract sierra program");
        // Note [Cairo Native ABI]

What do the squared brackets mean? Is it the name of the note or files it is related to?
I am not familiar with this notion.

crates/blockifier/src/execution/contract_class.rs line 684 at r25 (raw file):

        let lookup_fid: HashMap<usize, &FunctionId> =
            HashMap::from_iter(sierra_program.funcs.iter().map(|fid| {
                // This exception should never occur as the id is also in [SierraContractClass]

I am not sure I understand this comment, we expect here only if the id cannot be turned into a usize.
Do you mean that we have already defined it as a usize in the SierraContractClass?

crates/blockifier/src/execution/contract_class.rs line 762 at r25 (raw file):

#[derive(Debug, PartialEq)]
/// Provides a relation between a function in a contract and a compiled contract.

Is it supposed to provide a relation between any contract and any compiled contract, or is it supposed to provide a relation between a contract and its compiled contract? If it is the latter, please consider the following change
/// Provides a relation between a function in a contract and its compiled contract.

meship-starkware

Reviewed 1 of 3 files at r21.
Reviewable status: 41 of 42 files reviewed, 10 unresolved discussions (waiting on @noaov1 and @varex83)

noaov1

Can you please update according to the new content?

Reviewed 1 of 3 files at r21, 1 of 1 files at r25.
Reviewable status: 41 of 42 files reviewed, 12 unresolved discussions (waiting on @meship-starkware and @varex83)

crates/blockifier/src/execution/call_info.rs line 27 at r18 (raw file):

Previously, varex83 (Bohdan Ohorodnii) wrote…

Because in the execute_inner_call function, we need to return call_info and add it to the vector, so Clone is necessary here

Why do you need to return the callinfo?

crates/blockifier/src/execution/contract_class.rs line 599 at r25 (raw file):

    #[error("FunctionId {0} not found")]
    FunctionIdNotFound(usize),
}

Can you please move it to the file: crates/blockifier/src/execution/errors.rs?

Code quote:

#[derive(Debug, thiserror::Error)]
pub enum NativeEntryPointError {
    #[error("FunctionId {0} not found")]
    FunctionIdNotFound(usize),
}

crates/blockifier/src/execution/contract_class.rs line 603 at r25 (raw file):

impl NativeContractClassV1 {
    fn constructor_selector(&self) -> Option<EntryPointSelector> {
        self.entry_points_by_type.constructor.first().map(|ep| ep.selector)

Suggestion:

        self.entry_points_by_type.constructor.first()?.selector

crates/blockifier/src/execution/contract_class.rs line 628 at r25 (raw file):

            abi: None,
            sierra_program_debug_info: None,
            contract_class_version: String::default(),

Why?

Code quote:

            contract_class_version: String::default(),

crates/blockifier/src/execution/contract_class.rs line 631 at r25 (raw file):

        };

        CasmContractClass::from_contract_class(sierra_contract_class, false, usize::MAX)

Can you please use the compile method of the CairoLangSierraToCasmCompiler?

Code quote:

        CasmContractClass::from_contract_class(sierra_contract_class, false, usize::MAX)

crates/blockifier/src/execution/contract_class.rs line 635 at r25 (raw file):

    /// Returns an entry point into the natively compiled contract.
    pub fn get_entry_point(&self, call: &CallEntryPoint) -> Result<&FunctionId, PreExecutionError> {

Consider sharing code with get_entry_point of ContractClassV1 struct.

Code quote:

 pub fn get_entry_point(&self, call: &CallEntryPoint) -> Result<&FunctionId, PreExecutionError> {

crates/blockifier/src/execution/contract_class.rs line 664 at r25 (raw file):

    entry_points_by_type: NativeContractEntryPoints,
    // Storing the raw sierra program and entry points to be able to fallback to the vm
    sierra_program_raw: Vec<BigUintAsHex>,

WDYT?

Suggestion:

    sierra_program: Vec<BigUintAsHex>,

crates/blockifier/src/execution/contract_class.rs line 749 at r25 (raw file):

}

impl Index<EntryPointType> for NativeContractEntryPoints {

Nice!

Code quote:

impl Index<EntryPointType> for NativeContractEntryPoints {

noaov1

Reviewable status: 41 of 42 files reviewed, 21 unresolved discussions (waiting on @meship-starkware and @varex83)

crates/blockifier/src/execution/contract_class.rs line 651 at r18 (raw file):

#[derive(Debug)]
pub struct NativeContractClassV1Inner {
    pub executor: AotNativeExecutor,

Why not storing the output of the native compiler and create the executor before running the entry point? 🤔

Suggestion:

    pub native: NativeModule,

crates/blockifier/src/execution/contract_class.rs line 676 at r18 (raw file):

                // This exception should never occur as the id is also in [SierraContractClass]
                let id: usize = fid.id.id.try_into().expect("function id exceeds usize");
                (id, &fid.id)

What is the difference between the two fields?

Code quote:

                (id, &fid.id)

crates/blockifier/src/execution/contract_class.rs line 684 at r18 (raw file):

                &lookup_fid,
                &sierra_contract_class.entry_points_by_type,
            )?,

Can it be extracted from the compilation output?

Code quote:

            entry_points_by_type: NativeContractEntryPoints::try_from(
                &lookup_fid,
                &sierra_contract_class.entry_points_by_type,
            )?,

crates/blockifier/src/execution/contract_class.rs line 716 at r18 (raw file):

    /// On failure returns the first FunctionId that it couldn't find.
    fn try_from(
        lookup: &HashMap<usize, &FunctionId>,

Consider defining a type.

Code quote:

        lookup: &HashMap<usize, &FunctionId>,

crates/blockifier/src/execution/contract_class.rs line 717 at r18 (raw file):

    fn try_from(
        lookup: &HashMap<usize, &FunctionId>,
        sep: &SierraContractEntryPoints,

Suggestion:

        sierra_ep: &SierraContractEntryPoints,

crates/blockifier/src/execution/contract_class.rs line 763 at r18 (raw file):

    fn try_from(
        lookup: &HashMap<usize, &FunctionId>,
        cep: &ContractEntryPoint,

Suggestion:

        contract_ep: &ContractEntryPoint,

crates/blockifier/src/execution/contract_class.rs line 631 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Can you please use the compile method of the CairoLangSierraToCasmCompiler?

I see that the compile method adds pythonic hints which are not needed in this case. Consider adding it as a parameter.

crates/blockifier/src/execution/contract_class.rs line 663 at r25 (raw file):

    pub executor: AotNativeExecutor,
    entry_points_by_type: NativeContractEntryPoints,
    // Storing the raw sierra program and entry points to be able to fallback to the vm

Why?
Can we extract it from the state?

Code quote:

    // Storing the raw sierra program and entry points to be able to fallback to the vm

crates/blockifier/src/execution/native/utils.rs line 38 at r18 (raw file):

) -> EntryPointSelector {
    let selector_felt = Felt::from_bytes_be_slice(&entrypoint.selector.to_be_bytes());
    EntryPointSelector(selector_felt)

Consider using the From<&BigUint> for Felt method.
I see that the method uses little endian. Does it matter or it just need to be consistent?

Code quote:

    let selector_felt = Felt::from_bytes_be_slice(&entrypoint.selector.to_be_bytes());
    EntryPointSelector(selector_felt)

meship-starkware

Reviewed 1 of 20 files at r17.
Reviewable status: 41 of 42 files reviewed, 21 unresolved discussions (waiting on @varex83)

meship-starkware

Reviewed 1 of 20 files at r17.
Reviewable status: all files reviewed, 21 unresolved discussions (waiting on @varex83)

meship-starkware

Reviewed 1 of 20 files at r17.
Reviewable status: all files reviewed, 20 unresolved discussions (waiting on @varex83)

xrvdg · 2024-08-27T06:07:00Z

crates/blockifier/src/execution/contract_class.rs line 651 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Why not storing the output of the native compiler and create the executor before running the entry point? 🤔

BecauseNativeModule is not fully compiled yet. It's Sierra compiled into MLIR and lowered to LLVM, but it still needs to be compiled to machine code, linked into a library, and loaded into memory. AotNativeExecutor contains the pointer to the library in memory and the metadata to translate functions in the contract into functions within the library.

xrvdg · 2024-08-27T06:13:01Z

crates/blockifier/src/execution/contract_class.rs line 676 at r25 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

What do the squared brackets mean? Is it the name of the note or files it is related to?
I am not familiar with this notion.

It indicates that the comment is referenced from multiple places. In this case the comment is also relevant for struct NativeContractEntryPoint.

xrvdg · 2024-08-27T07:20:36Z

crates/blockifier/src/execution/contract_class.rs line 684 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Can it be extracted from the compilation output?

This information is available during the compilation phase so it could be stored alongside with the rest of the metadata we would like to store, but as of now it's not part of the compilation output.

xrvdg · 2024-08-27T07:23:51Z

crates/blockifier/src/execution/contract_class.rs line 676 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

What is the difference between the two fields?

A FunctionId is a combination of a function index and a debug name. What we do here is to create a lookup from function index -> function index + debug_name.

To execute a function in a contract we need to go from a selector to a function name in the compiled contract / shared object. We get there by selector -> function index -> function index + debug name -> function name. This is one of the friction points that I mentioned during the meeting, ideally the translation from function index -> function index + debug name is pushed down into cairo native. Together with the suggestion below it would mean that the sierra program doesn't have to be passed around anymore.

xrvdg · 2024-08-27T07:37:03Z

crates/blockifier/src/execution/contract_class.rs line 684 at r25 (raw file):

Previously, meship-starkware (Meshi Peled) wrote…

I am not sure I understand this comment, we expect here only if the id cannot be turned into a usize.
Do you mean that we have already defined it as a usize in the SierraContractClass?

ContractEntryPoint (in SierraContractClass) and FunctionId don't agree over the type of a function_idx, the former uses usize the latter u64. When the execution get to this point in the program it was already successful in constructing the ContractEntryPoint thus the function index fits in a usize therefore the panic of except should never occur.

varex83

Reviewable status: 39 of 42 files reviewed, 15 unresolved discussions (waiting on @meship-starkware and @noaov1)

crates/blockifier/src/execution/call_info.rs line 27 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Why do you need to return the callinfo?

We will reuse it in the future in the syscall's implementations. Is adding "Clone" causing some problems?

crates/blockifier/src/execution/contract_class.rs line 717 at r18 (raw file):

    fn try_from(
        lookup: &HashMap<usize, &FunctionId>,
        sep: &SierraContractEntryPoints,

Done.

crates/blockifier/src/execution/contract_class.rs line 599 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Can you please move it to the file: crates/blockifier/src/execution/errors.rs?

Done.

crates/blockifier/src/execution/contract_class.rs line 603 at r25 (raw file):

impl NativeContractClassV1 {
    fn constructor_selector(&self) -> Option<EntryPointSelector> {
        self.entry_points_by_type.constructor.first().map(|ep| ep.selector)

In this case, we need to wrap it into Some(..), so I would like to leave it as it is

crates/blockifier/src/execution/contract_class.rs line 664 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

WDYT?

Done.

crates/blockifier/src/execution/native/utils.rs line 38 at r18 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Consider using the From<&BigUint> for Felt method.
I see that the method uses little endian. Does it matter or it just need to be consistent?

Done.

rodrigo-pino

Reviewable status: 39 of 42 files reviewed, 12 unresolved discussions (waiting on @meship-starkware, @noaov1, and @varex83)

crates/blockifier/src/execution/call_info.rs line 27 at r18 (raw file):

Why do you need to return the callinfo?

We use the retdata from the call info. We can modify it to just return that. Personally, it makes sense to return the call info, but we can specialize it.

crates/blockifier/src/execution/contract_class.rs line 628 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Why?

This is only used for the Fallback, I'll publish a commit removing this

crates/blockifier/src/execution/contract_class.rs line 631 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

I see that the compile method adds pythonic hints which are not needed in this case. Consider adding it as a parameter.

Will be deleted as well.

crates/blockifier/src/execution/contract_class.rs line 663 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Why?
Can we extract it from the state?

Remember from our past conversation, specifically asking for CASM would require a change in the State API. Nonetheless, we will be remove this accordingly since it is specifically for the Fallback

varex83

Reviewable status: 39 of 42 files reviewed, 10 unresolved discussions (waiting on @meship-starkware and @noaov1)

crates/blockifier/src/execution/contract_class.rs line 635 at r25 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Consider sharing code with get_entry_point of ContractClassV1 struct.

I see your point, but these methods work with different types, so that will be challenging to make it more generic (e.g. implementing shared traits, etc. )

rodrigo-pino · 2024-10-07T22:32:40Z

Solved in #620

varex83 added 18 commits August 6, 2024 19:00

refactor: split syscalls into separate files

ef8318b

fix: apply cargo-fmt

956639e

fix: address review comments

47f3557

Merge remote-tracking branch 'origin/main' into native/split-syscalls

2d1a082

# Conflicts: # crates/blockifier/src/execution/syscalls/syscalls_test.rs

fix: conflicts after merge

47e6969

fix: clippy warnings

86df83b

feat: add ability of native execution

e70684e

fix: make comments capitalized

379a9d9

fix: apply fmt

1a5d04e

fix: small fixes in comments and matching

584dc88

fix: bring back old .toml formatting

71c8757

fix: remove unused yet utility functions

5a1bcc2

Merge remote-tracking branch 'origin/main' into native/split-syscalls

83d1e2d

feat: add syscall failure format

32c4400

Merge branch 'native/split-syscalls' into native/add-native-execution…

07d3d2f

…-engine # Conflicts: # Cargo.lock

chore: update Cargo.lock

a2ba95b

Merge remote-tracking branch 'origin/main' into native/add-native-exe…

ef1331a

…cution-engine # Conflicts: # Cargo.lock

feat: update Cargo.lock

938c552

meship-starkware requested changes Aug 19, 2024

View reviewed changes

meship-starkware reviewed Aug 19, 2024

View reviewed changes

meship-starkware reviewed Aug 20, 2024

View reviewed changes

noaov1 requested changes Aug 20, 2024

View reviewed changes

varex83 added 3 commits August 20, 2024 19:40

fix: address review

f236548

refactor: address get_entry_point review requests

00d5ca7

Merge remote-tracking branch 'origin/main' into native/add-native-exe…

9b7a80a

…cution-engine # Conflicts: # Cargo.lock # crates/blockifier/src/execution/contract_class.rs

varex83 commented Aug 20, 2024

View reviewed changes

varex83 added 2 commits August 20, 2024 20:11

refactor: move out methods that won't be reviewed in this PR

bb23d4a

fix: rust fmt

3403746

fix: apply some of the CI fixes

79a2872

varex83 mentioned this pull request Aug 21, 2024

feat(blockifier): add NativeSyscallHandler #549

Closed

fix: comment in Cargo.toml

20db622

meship-starkware reviewed Aug 21, 2024

View reviewed changes

meship-starkware reviewed Aug 22, 2024

View reviewed changes

noaov1 requested changes Aug 25, 2024

View reviewed changes

meship-starkware reviewed Aug 26, 2024

View reviewed changes

meship-starkware requested a review from noaov1 August 27, 2024 07:00

fix: address some of the review comments

b73639a

varex83 commented Aug 27, 2024

View reviewed changes

varex83 mentioned this pull request Aug 27, 2024

feat(blockifier): add native execution engine #620

Merged

rodrigo-pino reviewed Sep 3, 2024

View reviewed changes

varex83 commented Sep 13, 2024

View reviewed changes

rodrigo-pino added the native integration Related with the integration of Cairo Native into the Blockifier label Sep 23, 2024

rodrigo-pino closed this Oct 7, 2024

github-actions bot locked and limited conversation to collaborators Oct 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(blockifier): add native execution engine #429

feat(blockifier): add native execution engine #429

varex83 commented Aug 13, 2024 •

edited by alon-dotan-starkware

Loading

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

noaov1 left a comment

varex83 left a comment

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

noaov1 left a comment

noaov1 left a comment

meship-starkware left a comment

meship-starkware left a comment

meship-starkware left a comment

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

varex83 left a comment

rodrigo-pino left a comment

varex83 left a comment

rodrigo-pino commented Oct 7, 2024

feat(blockifier): add native execution engine #429

feat(blockifier): add native execution engine #429

Conversation

varex83 commented Aug 13, 2024 • edited by alon-dotan-starkware Loading

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

noaov1 left a comment

Choose a reason for hiding this comment

varex83 left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

noaov1 left a comment

Choose a reason for hiding this comment

noaov1 left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

meship-starkware left a comment

Choose a reason for hiding this comment

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

xrvdg commented Aug 27, 2024

varex83 left a comment

Choose a reason for hiding this comment

rodrigo-pino left a comment

Choose a reason for hiding this comment

varex83 left a comment

Choose a reason for hiding this comment

rodrigo-pino commented Oct 7, 2024

varex83 commented Aug 13, 2024 •

edited by alon-dotan-starkware

Loading