Ethereum Virtual Machine implementation

Last update: Dec 9, 2022

Related tags

Overview

evmodin

Fast EVM implementation with full async support. Port of evmone to Rust.

Usage

use evmodin::{*, host::*, util::*, tracing::*};
use ethereum_types::*;
use hex_literal::hex;

let my_code = Bytecode::new()
    .mstore8_value(0, b'h')
    .mstore8_value(1, b'e')
    .mstore8_value(2, b'l')
    .mstore8_value(3, b'l')
    .mstore8_value(4, b'o')
    .ret(0, 5)
    .build();

let message = Message {
    kind: CallKind::Call,
    is_static: true,
    depth: 0,
    gas: 200,
    destination: Address::zero(),
    sender: Address::zero(),
    input_data: vec![].into(),
    value: U256::zero(),
};

assert_eq!(
    AnalyzedCode::analyze(my_code)
        .execute(&mut DummyHost, &mut NoopTracer, message, Revision::London)
        .await,
    Output {
        status_code: StatusCode::Success,
        gas_left: 146,
        output_data: b"hello".to_vec().into(),
        create_address: None,
    }
)

License: Apache-2.0

LC3 Virtual Machine written in Rust 🦀

LC3 - Emulator LC3-rust is a virtual machine for the Little Computer 3 architecture, written using the Rust programming language. The VM has been writ

2 Oct 25, 2022

little computer 3 (lc3) virtual machine written in Rust

Little Computer 3 (LC3) Virtual Machine (by @lowlevelers) What is Little Computer 3? Little Computer 3, or LC-3, is a type of computer educational pro

3 Oct 25, 2023

RailCar: Rust implementation of the Open Containers Initiative oci-runtime

railcar - rust implementation of the oci-runtime spec What is railcar? railcar is a rust implementation of the opencontainers initiative's runtime spe

1.1k Dec 21, 2022

Rocker is a minimal docker implementation for educational purposes.

Rocker is a minimal docker implementation for educational purposes inspired by gocker. Rocker uses linux kernel features (namespace, cgroup, chroot etc.) to isolate container processes and limit available resourses.

16 Feb 14, 2022

A toy Cairo VM implementation in Rust

oriac A toy Cairo VM implementation in Rust This is a toy implementation of the Cairo VM I'm building for learning purposes. There's no guarantee on w

57 Nov 23, 2022

Ethereum Virtual Machine implementation

Fast EVM implementation with full async support. Port of evmone to Rust.

147 Dec 9, 2022

DeFiChain octopus is a codename research & development for DFIP 2111-B: VOC: Ethereum Virtual Machine (EVM) Support.

DeFiCh/octopus DeFiChain octopus is a codename research & development for DFIP 2111-B: VOC: Ethereum Virtual Machine (EVM) Support . Proposed as a DFI

6 Apr 18, 2022

DFIP 2111-B: VOC: Ethereum Virtual Machine (EVM) Support

DeFiCh/metachain is a codename research & development for DFIP 2111-B: VOC: Ethereum Virtual Machine (EVM) Support . Proposed as a DFIP on Nov 2021; D

19 Dec 6, 2022

A low-level assembly language for the Ethereum Virtual Machine built in blazing-fast pure rust.

huff-rs • huff-rs is a Huff compiler built in rust. What is a Huff? Huff is a low-level programming language designed for developing highly optimized

276 Dec 31, 2022

A Rust implementation of the Lox programming language. Based on clox, the bytecode virtual machine.

23 Dec 26, 2022

Substreams development kit for Ethereum chains, contains Firehose Block model and helpers as well as utilities for Ethereum ABI encoding/decoding.

Substreams Ethereum Substreams development kit for Ethereum chains, contains Rust Firehose Block model and helpers as well as utilities for Ethereum A

15 Oct 25, 2022

Comments

Fixes a compilation error for wasm targets.

Without this fix, the build fails when targetting wasm. Repro steps:

$ wasm-pack build --target web
[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
   Compiling getrandom v0.2.3
error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
   --> /*******/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.3/src/lib.rs:219:9
    |
219 | /         compile_error!("the wasm32-unknown-unknown target is not supported by \
220 | |                         default, you may need to enable the \"js\" feature. \
221 | |                         For more information see: \
222 | |                         https://docs.rs/getrandom/#webassembly-support");
    | |_________________________________________________________________________^

error[E0433]: failed to resolve: use of undeclared crate or module `imp`
   --> /********/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.3/src/lib.rs:246:5
    |
246 |     imp::getrandom_inner(dest)
    |     ^^^ use of undeclared crate or module `imp`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `getrandom` due to 2 previous errors
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

After applying this fix the compilation succeeds:

$ wasm-pack build --target web
[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
    Finished release [optimized] target(s) in 0.13s
[INFO]: ⬇️  Installing wasm-bindgen...
[INFO]: Optimizing wasm binaries with `wasm-opt`...
[INFO]: Optional fields missing from Cargo.toml: 'description', 'repository'. These are not necessary, but recommended
[INFO]: ✨   Done in 0.71s
[INFO]: 📦   Your wasm pkg is ready to publish at /*****/evmodin/pkg.

opened by karim-agha 4

Adding String to Enum conversion for hardfork names.

I needed to translate hardfork names from string to a typed enum multiple times so far when reading config, exposing JS api through N-API, etc. I think that if we keep this here, we can guarantee that this conversion will always be in sync with new hardforks that become supported by evmodin.

opened by karim-agha 0
Adding String to Enum conversion for hardfork names.

I needed to translate hardfork names from string to a typed enum multiple times so far when reading config, exposing JS api through N-API, etc. I think that if we keep this here, we can guarantee that this conversion will always be in sync with new hardforks that become supported by evmodin.

opened by karim-agha 0