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

Overview

huff-rs • ci License Crates.io Discord

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 smart contracts that run on the Ethereum Virtual Machine (EVM). Huff does not hide the inner workings of the EVM. Instead, Huff exposes its programming stack to the developer for manual manipulation.

Rather than having functions, Huff has macros - individual blocks of bytecode that can be rigorously tested and evaluated using the Huff runtime testing suite.

Huff was originally developed by the Aztec Protocol team to write Weierstrudel. Weierstrudel is an on-chain elliptical curve arithmetic library that requires incredibly optimized code that neither Solidity nor Yul could provide.

While EVM experts can use Huff to write highly-efficient smart contracts for use in production, it can also serve as a way for beginners to learn more about the EVM.

To dive deeper into Huff, visit the Official Huff Docs(also available on github).

Installation

Something not working? Send a message in discord.

First run the command below to get huffup, the Huff installer:

curl -L get.huff.sh | bash

To avoid redirecting the script directly into bash, download and run the huffup installation script.

To install the Huff compiler, simply run huffup.

If you have the old huffc (TypeScript version) npm package installed globally, you can remove it with:

sudo yarn global remove huffc

To make sure you are running the rust version, you can run huffc --version and it should respond with huff_cli <version>. If it responds with 2.0.0 that means you are running the Typescript version.

$ huffc --version
huff_cli 0.1.0

Alternatively

Install from source by running:

git clone https://raw.githubusercontent.com/huff-language/huff-rs
cd huff-rs
cargo install --path ./huff_cli --bins --locked --force

OR

cargo install --git https://raw.githubusercontent.com/huff-language/huff-rs --locked huff_cli

How Fast?

Compilation Benchmarks

Compiler Cold (No Cache) Light Cache Deep Cache Full Cache
[huff-language/huff-rs][huff-rs] XXXms XXXms XXXms XXXms
[huff-language/huffc][huffc] XXXms XXXms XXXms XXXms

Note: Compilation benchmarks were performed on huff-examples erc20.

Architecture

Huff Compiler Architecture

Modules

  • huff_core: The core module to huff-rs. Resolves source file paths, executes compilation, and exports artifacts.
  • huff_cli: The command line interface for the Huff compiler.
  • huff_lexer: Takes in the source of a .huff file and generates a vector of Tokens.
  • huff_parser: Crafts a Contract AST from the the vector of Tokens generated by huff_lexer.
  • huff_codegen: EVM Bytecode generation module that accepts an AST generated by huff_parser.
  • huff_utils: Various utilities and types used by all modules.
  • huffup: Update or revert to a specific huff-rs branch with ease. (Forked from foundry)

Contributing

All contributions are welcome! We want to make contributing to this project as easy and transparent as possible, whether it's:

  • Reporting a bug
  • Discussing the current state of the code
  • Submitting a fix
  • Proposing new features
  • Becoming a maintainer

We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!

To run examples, make sure you update git submodules to pull down the huff-examples submodule by running git submodule update.

The branching convention used by huff-rs is a stage branch that is meant to be merged off of and is periodically merged into main. So, when creating a feature, branch off of the stage branch and create a pr from your branch into the stage branch!

i.e: Branching Conventions

To pass github actions, please run:

cargo check --all
cargo test --all --all-features
cargo +nightly fmt -- --check
cargo +nightly clippy --all --all-features -- -D warnings

In order to fix any formatting issues, run:

cargo +nightly fmt --all

Recommended PR Template

Here is an example PR template - not strictly required, but will greatly improve the speed at which your PR is reviewed & merged!

## Overview

<Provide a general overview of what your pr accomplishes, why, and how (including links)>

## Checklist

- [x] <Ex: Added a `new` method to the Huff Lexer [here](./huff_lexer/src/lib.rs#50)>
- [x] <Ex: Fully tested the `new` method [here](./huff_lexer/tests/new.rs)>
- [ ] <Ex: Wrote documentation for the `new` method [here](./huff_lexer/README.md#20)>

When the PR checklist isn't complete, it is highly recommended to make it a draft PR. NOTE: if your PR is not complete, it will likely be changed to a draft by one of the repository admins.

For breaking changes: make sure to edit the excalidraw asset and export the file to ./assets/huffc.excalidraw along with an image to ./assets/huffc.png.

Safety

Warning

This is experimental software and is provided on an "as is" and "as available" basis. Expect rapid iteration and use at your own risk.

This code is not designed for safety.

  • There are untested invariants in the code that may break.
  • You can easily shoot yourself in the foot if you're not careful.
  • You should thoroughly read the documentation and examples.

We do not give any warranties and will not be liable for any loss incurred through any use of this codebase.

Acknowledgements

The original Huff Language compiler: huffc.

An exemplary, minimal rust compiler: ripc.

Foundry, for the many scripts, documentation, devops, and code on which huff-rs is based on.

All huff-rs contributors, users, advocates, and enthusiasts!

Comments
  • feat: constructor bootstrap code overrides

    feat: constructor bootstrap code overrides

    I think it could be useful if we allowed the user to override the normal bootstrap code with something custom. This could be used in multiple niche cases, such as metamorphic contracts. Additionally, since Huff is often used for education purposes, some may want to write the bootstrap code themselves to better understand the contract deployment process.

    I see two main ways of accomplishing this:

    1. If a constructor contains the RETURN opcode in it, automatically omit the bootstrap code.
    2. Add a command line flag to omit the bootstrap code.

    I'd be happy to implement either of these myself, but want to make sure that the change would be well received first.

    opened by ncitron 3
  • feat: Interface Output Location Override

    feat: Interface Output Location Override

    Overview

    Currently the huff_cli -g flag tells the compiler to generate a solidity interface file at the same location as the source with an I prefix.

    We should allow the -g flag to accept an optional string location of where to generate the output interfaces (with it by default being in the same location as each source file).

    cli med-priority 
    opened by abigger87 3
  • add checks for evm types as arg names

    add checks for evm types as arg names

    Overview

    Attempts a fix for #196

    Checklist

    • [x] 1.1 Naming parameters as native solidity datatypes should lead to an error #define function balanceOf(address uint256) view returns (uint256 balance) => now errors with: carbon(2)

    • [x] 1.2 A lack of a comma in a function definition should not lead to following datatypes affecting the function signature

      • This will not compile now as of 1.1
    • [x] 2. You should be allowed to give a parameter a name that starts with "int" / "uint" / "bytes"

      • This was due to a bug in the PrimitiveEVMType that optimistically unwrapped on parsing the remaining bit of a string as a usize.
    • [x] 3. You should be able to name dynamic parameters (string, bytes, <type>[], etc.)

    parser med-priority bug 
    opened by abigger87 2
  • feat(huff_tests): Cheatcodes

    feat(huff_tests): Cheatcodes

    Overview

    Adds a new inspector to the test runner to detect calls to a cheatcode address. Cheatcodes can be invoked by sending a staticcall to 0x00000000000000000000000000000000bEefbabe with the following calldata layout:

    ╔═════════╦═══════════════╗
    ║ Offset  ║     Value     ║
    ╠═════════╬═══════════════╣
    ║ 0x00    ║ cheatcode_key ║
    ║ 0x20    ║ current_pc    ║
    ║ 0x40... ║ args          ║
    ╚═════════╩═══════════════╝
    

    The first cheatcode is LOG, which allows logging stack items within Huff tests. Screen Shot 2022-08-16 at 2 23 09 AM

    Will need to add a Huff tests cheatcode contract to Huffmate tomorrow:

    #define macro LOG() = takes (1) {
        // Input stack:   [log_item]
        pc             // [pc, log_item]
        0x01           // [log_cheatcode, pc, log_item]
        0x00 mstore    // [pc, log_item]
        0x20 mstore    // [log_item]
        0x40 mstore    // []
        0x00 dup1      // [0x00, 0x00]
        0x60 dup2      // [0x00, 0x60, 0x00, 0x00]
        0x00000000000000000000000000000000bEefbabe
        gas            // [gas, beef_babe, 0x00, 0x60, 0x00, 0x00]
        staticcall pop // []
    }
    
    huff tests 
    opened by clabby 2
  • feat: Huff tests

    feat: Huff tests

    Overview

    Adds a stripped down test suite to huff-rs, mainly for gas profiling and creating assertions. Peek 2022-08-07 00-56

    Usage

    CLI: huffc <contract_path> -t [-f <list|table|json>] [-m <TEST_NAME>]

    Test syntax:

    #[calldata("0x0000000000000000000000000000000000000000000000000000000000000020"), value(0x01)]
    #define test MY_TEST() = takes (0) returns (0) {
        // test code
    }
    
    #define test MY_TEST_2() = takes (0) returns (0) {
        // test code
    }
    
    #define macro MY_MACRO() = takes (0) returns (0) {
        MY_TEST() // Tests cannot be invoked- this will throw an error.
    }
    

    Checklist

    • [x] Create a test runner that utilizes revm
      • [x] Tests for the runner
      • [x] Configurable test environment (gas limit, chain id, hardfork, call value, etc.)
      • [ ] Simple input fuzzer (? - not necessarily needed, might be nice for fuzzed gas profiling.)
    • [x] Implement test macros into the lexer / parser
      • [x] Restrict regular macros / functions from invoking test macros
    • [x] Add a subcommand / flag to the CLI to run the test suite
    • [x] Clean up
      • [x] Proper errors
      • [x] README
    cli 
    opened by clabby 2
  • docs: add steps to remove old version of huffc

    docs: add steps to remove old version of huffc

    Overview

    Please provide a short description here and review the requirements below.

    I was having probs removing the old huffc npm package and didnt even realize it at first because it seemed to take when i ran yarn global remove huffc and also i didnt know what version we were on or that the --help files look different now. Finally after some headbanging I realized i was still running the old version and went back and tried removing it again but with sudo this time, and that worked.

    Thought I'd add something in the docs here to help others in case they have a similar experience.

    opened by devtooligan 2
  • feat(huff_parser): expand macros

    feat(huff_parser): expand macros

    Overview

    When parsing, we need to expand macros to make code generation as easy as possible.

    Macro expansion refers to the process of taking an invocation, and expanding to its relevant opcodes, with the arguments substituted. This is a crucial part of eventually compiling Huff code, whether we include it in parsing or not.

    An example of macro expansion:

    #define macro EXPAND_ME() = takes(0) returns(0) {
        0x02 0x01 add
    }
    
    #define macro MAIN() = takes(0) returns(0) {
       0x01 0x02 sub
       EXPAND_ME()
    }
    

    Once the compiler has turned the code into tokens, the macro expansion and parsing will begin. The parser will begin parsing the macros, and notice there is an invocation to the EXPAND_ME macro. It will 'expand,' or substitute, the necessary opcodes into the main macro. If we represent the newly parsed code in Huff, it would look like below.

    #define macro MAIN() = takes(0) returns(0) {
       0x01 0x02 sub
       0x02 0x01 add
    }
    

    The alternative to doing this is in code generation. Instead of parsing the expansions, we can look for invocations in code generation.

    Expanding the macros at the parsing stage is somewhat better than doing it add the code generation stage as it means we do not have to track the invocations in vectors, and have ambiguity regarding ordering.

    parser med-priority 
    opened by sudovirtual 2
  • feat(huff_utils): Add `codemap-diagnostic` for fancy errors

    feat(huff_utils): Add `codemap-diagnostic` for fancy errors

    Overview

    Currently, we're returning errors that don't give the developer enough information. #33 added slightly more specific error messages for development purposes, but codemap-diagnostic (suggested by @sudovirtual) provides much more verbose feedback.

    We should create an error handling function or struct in huff_utils/error.rs to make it as easy as possible to create diagnostic messages and emit them throughout the codebase.

    med-priority 
    opened by clabby 2
  • fix(parser): Function definition and test

    fix(parser): Function definition and test

    Overview

    Previously, the function definition in the AST allowed a function to have multiple types.

    It was changed to only allow one single type, as multiple don't make sense.

    A function definition not having a return type should be an invalid syntax.

    parser 
    opened by exp-table 2
  • fix(huff_lexer): Bytes are being incorrectly lexed

    fix(huff_lexer): Bytes are being incorrectly lexed

    Overview

    Right now (master @ 5fd1e325625612a931ef10e428bf07197399b840), the huff_lexer incorrectly parses bytes / hex number tokens.

    Failing Test

    #[test]
    fn parses_bytes() {
        let source = "0xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF";
        let mut lexer = Lexer::new(source);
        assert_eq!(lexer.source, source);
    
        // Try to parse the bytes token (assuming that it is a single token)
        let tok = lexer.next();
        let unwrapped = tok.unwrap().unwrap();
        let bytes_span = Span::new(0..source.len());
        assert_eq!(unwrapped, Token::new(TokenKind::Ident(source), bytes_span));
        assert_eq!(lexer.span, bytes_span);
    
        // We covered the whole source
        assert_eq!(lexer.span.end, source.len());
        assert!(lexer.eof);
        assert!(lexer.next().is_none());
    }
    

    Expected Result

    tok = Token { kind: Ident("0xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF"), span: Span { start: 0, end: 66 } }

    Or a dedicated TokenKind variant for bytes / hex tokens.

    Actual Result

    tok = Token { kind: Num(0), span: Span { start: 0, end: 1 } }

    Suspected Reason for Issue

    The lexer dyn_consumes all valid ascii digits when it comes across what it thinks is a TokenKind::Num. When dyn_consume hits the second character of a bytes / hex number token, x, it completes, splitting the bytes / hex number token into two parts: The TokenKind::Num(0) and the TokenKind::Ident("xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF"). Some extra logic needs to be added to this match arm in order to correctly lex these tokens.

    lexer 
    opened by clabby 2
  • feat(huff_core): Remapping Import Resolution

    feat(huff_core): Remapping Import Resolution

    Overview

    Tackles #187

    Adds remapping support for import resolutions. So a remapping in a foundry.toml can be supported when compiling huff contracts. For example, a remapping for huffmate like huffmate/=lib/huffmate/src/ located in a foundry.toml file can be successfully parsed by the huff compiler. This allows you to import huffmate contracts inside a huff contract using foundry.toml remappings (WLOG)

    Note: This PR rips out file path validation logic in the parser since files are validated and fully flattened at the compiler top-level.

    parser med-priority 
    opened by abigger87 1
  • feat(huff_assert) Stack traces

    feat(huff_assert) Stack traces

    Overview

    This PR aims to implement stack assertions. See https://github.com/huff-language/huff-rs/issues/132 When writing huff code, it's frequent to have a revert and is sometimes hard to debug. These assertions should makes us more confident on how the stack looks like at each line, and makes debugging easier.

    After annotating the assertions, this is what SAFE_ADD from SafeMath would look like:

    #define macro SAFE_ADD() = takes (2) returns (1) {
        dup2                    $ [num2, num1, num2]
        add                     $ [result, num2]
        dup1                    $ [result, result, num2]
        swap2                   $ [num2, result, result]
        gt                      $ [is_overflow, result]
        iszero                  $ [is_not_overflow, result]
        is_not_overflow jumpi   $ [result]
            0x00 0x00 revert
        is_not_overflow:        $ [result]
    }
    

    Running:

    huffc --check-assert src/SafeMath.huff
    

    shouldn't return anything.

    Now what happens if assertions are wrong ?

    #define macro SAFE_ADD() = takes (2) returns (1) {
        dup2                    $ [num2, num1, num2, nope]
        add                     $ [result, num2]
        dup1                    $ [result, result, num2, definitely_not]
        swap2                   $ [num2, result, result]
        gt                      $ [is_overflow, result]
        iszero                  $ [is_not_overflow, result]
        is_not_overflow jumpi   $ [result]
            0x00 0x00 revert
        is_not_overflow:        $ [result]
    }
    

    it's gonna give image

    Some things left to-do:

    • Custom stack & calldata At the moment, there is no calldata in the call that is done to the macro, and stack is pushed with "0" bytes considering the takes parameter. Because of this, assertion checks are failing in some cases:
      • MAIN macro has no revert case if no function selector is matched
      • Pushing 0 could make the macro revert if dividing by 0 in the SAFE_DIV or SAFE_MOD macro

    Not sure if we should do it in the command, like:

    huffc --check-assert src/SafeMath.huff <MACRO> <CALLDATA> <STACK>
    

    and maybe make check-assert a subcommand then

    Checklist

    • [x] add --check-assert command
    • [x] Support input stacks and custom calldata
    • [x] Support comments in assertions
    • [x] Enforce returns count
    • [x] Support variable instanciation
    • [x] Display error lines
    • [x] Write tests
    opened by iFrostizz 1
  • bug: __FUNC_SIG computes wrong selector of custom errors

    bug: __FUNC_SIG computes wrong selector of custom errors

    Version: Result of huffc -V => huffc 0.3.0

    Description

    The huff compiler computes the wrong selector for custom errors when using __FUNC_SIG.

    Steps to Recreate

    1. Define custom error in huff contract #define error NotOwner()
    2. Add __FUNC_SIG(NotOwner) to macro
    3. Compile using huffc MyContract.huff -b

    Expected Result: __FUNC_SIG(NotOwner) gets compiled to 6330cd7471 (PUSH4 0x30cd7471) Actual Result: __FUNC_SIG(NotOwner) gets compiled to 632a4cb61e (PUSH4 0x2a4cb61e)

    Other Details

    Upon some investigation it looks like __FUNC_SIG only hashes the name of errors instead of hashing the entire name according to the ABI spec: bytes4(keccak256("NotOwner")) => 0x2a4cb61e

    opened by Philogy 0
  • Compiler crashes when __codesize(CONSTRUCTOR) is used inside of the CONSTRUCTOR macro

    Compiler crashes when __codesize(CONSTRUCTOR) is used inside of the CONSTRUCTOR macro

    The only way currently in huff to either know the code size without the constructor arguments or the constructor arguments size, is to add the codesize of the MAIN and CONSTRUCTOR macros (+ fn) using the __codesize() builtin.

    Expected Behavior

    #define macro CONSTRUCTOR() = takes(0) returns(0) {
        __codesize(MAIN)
        __codesize(CONSTRUCTOR)
        add
        codesize
        sub                                        // [argumentsSize]
        // do something
    }
    
    #define macro MAIN() = takes(0) returns(0) {
        0x00 0x00 revert
    }
    

    The huff file should compile and __codesize(CONSTRUCTOR) should return the constructor macro size.

    Currently observed behavior

    __codesize(CONSTRUCTOR) creates a loop and huffc crashes with stack overflow error.

    ...
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    DEBUG ast: Deriving Storage Pointrs: Found builtin function Codesize
    
    thread 'main' has overflowed its stack
    fatal runtime error: stack overflow
    
    opened by The-Wary-One 0
  • automate stack comments

    automate stack comments

    We would like a way for the stack comments to be automatically generated.

    by stack comments we are referring to inline comments to the right representing the current known state of the stack:

    0x20 // [length]
    0x0  //  [offset, length]
    

    One way we discussed was creating a new huff-fmt command that would got through Huff files and add stack annotations. Maybe someday it would be nice to have a editor extension that can add the comments.

    As part of this work, we need to figure out how to assign labels or aliases for items on the stack.

    For incoming/outgoing stack items, it has been suggest that maybe we define the aliases along with the takes(x) returns(x) at the macro(fn) definition level, so perhaps takes(2, [owner, spender]) returns (1, [returnValue]).

    Alternatively, aliases could be defined in a comment at the beginning of the macro so:

    #define macro MY_MACRO() = takes(2) returns(1) {
      // takes: [owner, spender]
      // returns: [returnValue]
      ...
    }
    

    It would also be great to be able to alias intermediate stack items so one idea is:

     0x04
     CALLDATALOAD // alias: Spender
    

    would elicit:

     0x04                     // 0x04
     CALLDATALOAD // [Spender, 0x04]
    

    For values with left padded zero's, one idea is to exclude the zeros so:

     0x123
    

    would elicit:

     0x123   // [0x123]
    

    It has also been suggested that the stack generating logic would work with constants so:

      0x123
      [SOME_SLOT]
    

    would elicit:

      0x123                     // [0x123]
      [SOME_SLOT]      // [SOME_SLOT, 0x123]
    
    opened by devtooligan 0
  • Support 1-byte jump label value

    Support 1-byte jump label value

    A jump label value is calculated using 2 bytes and the PUSH2 opcode is used, but when the value can be reduced to 1 byte, it is more gas efficient to use the PUSH1 opcode. (200 gas per byte)

    https://github.com/huff-language/huff-rs/blob/a4f820a7154c44d1f982e5921d8c24afa4fb0a7c/huff_codegen/src/lib.rs#L374

    ~An alternative is to support the jumpdst opcode.~

    • EDIT: I found that this alternative is not necessary because even if labels were not used, a jumpdst could still be obtained by labeling it.

    (When I was implementing https://github.com/minaminao/huff-eip1167, I wanted the jump using PUSH1)

    opened by minaminao 0
  • Compiler incorrectly interprets parameter names

    Compiler incorrectly interprets parameter names

    Expected behavior

    1.1 Naming parameters as native solidity datatypes should lead to an error 1.2 A lack of a comma in a function definition should not lead to following datatypes affecting the function signature 2. You should be allowed to give a parameter a name that starts with "int" / "uint" / "bytes" 3. You should be able to name dynamic parameters (string, bytes, <type>[], etc.)

    Currently observed behavior

    Version: 0.3.0 (Note issues also observed under 0.2.0)

    1.1 #define function balanceOf(address uint256) view returns (uint256 balance) => no error 1.2 #define function balanceOf(address uint256) view returns (uint256 balance) //; ... __FUNC_SIG(balanceOf) => returns signature for "balanceOf(address,uint256)" 2. #define function supportsInterface(bytes4 interfaceId) view returns (bool) => produces compiler error:

    ⠋ Compiling...thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', huff_utils/src/types.rs:47:49
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    [1]    122499 IOT instruction (core dumped)  huffc src/ERC721H.huff -b
    
    1. #define function transferMany(uint256[] memory tokens) view returns () => produces compiler error:
    ⠙ Compiling...
    
    Error: Invalid Argument Type: "tokens"
    -> src/ERC721H.huff:858-864
           |
      > 16 | #define function transferMany(uint256[] memory tokens) view returns ()
           |
    
    
    opened by Philogy 0
Owner
Huff
Huff is a low level assembly language for the Ethereum Virtual Machine
Huff
Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.

foundry Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust. Foundry consists of: Forge: Ethe

Georgios Konstantopoulos 4.3k Sep 24, 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

StreamingFast 10 Sep 13, 2022
Zero-Knowledge Assembly language and compiler

zkAsm A Zero-Knowledge circuit assembly language, designed to represent Zero-Knowledge circuits in a compressed format, to be stored on blockchains. I

null 1 Dec 30, 2021
A blazing fast, type-safe template engine for Rust.

markup.rs A blazing fast, type-safe template engine for Rust. markup.rs is a template engine for Rust powered by procedural macros which parses the te

Utkarsh Kukreti 194 Sep 18, 2022
The fast, light, and robust client for the Ethereum mainnet.

OpenEthereum Fast and feature-rich multi-network Ethereum client. » Download the latest release « Table of Contents Description Technical Overview Bui

OpenEthereum 1.6k Sep 21, 2022
The fast, light, and robust client for Ethereum-like networks.

The Fastest and most Advanced Ethereum Client. » Download the latest release « Table of Contents Description Technical Overview Building 3.1 Building

OpenEthereum 6.7k Sep 20, 2022
Emerging smart contract language for the Ethereum blockchain.

Emerging smart contract language for the Ethereum blockchain.

null 1.2k Sep 20, 2022
Extremely low-latency chain data to Stackers, with a dose of mild humour on the side

Ronin Hello there! Ronin is a ultra-speed Stacks API server. It's super lightweight, but scales easily. Why are we making this? Because we don't like

Syvita Guild 11 Mar 29, 2022
Custom Ethereum vanity address generator made in Rust

ethaddrgen Custom Ethereum address generator Get a shiny ethereum address and stand out from the crowd! Disclaimer: Do not use the private key shown i

Jakub Hlusička 144 Sep 5, 2022
Rust Ethereum 2.0 Client

Lighthouse: Ethereum 2.0 An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime. Documentation Overview Lighthouse is: Read

Sigma Prime 2k Sep 22, 2022
Rust client to Opensea's APIs and Ethereum smart contracts

opensea.rs Rust bindings & CLI to the Opensea API and Contracts CLI Usage Run cargo r -- --help to get the top level help menu: opensea-cli 0.1.0 Choo

Georgios Konstantopoulos 213 Sep 25, 2022
A library to help you sew up your Ethereum project with Rust and just like develop in a common backend

SewUp Secondstate EWasm Utility Program, a library helps you sew up your Ethereum project with Rust and just like development in a common backend. The

Second State 44 Aug 29, 2022
Complete Ethereum and Celo wallet implementation and utilities in Rust

ethers.rs Complete Ethereum and Celo wallet implementation and utilities in Rust Documentation Extensive documentation and examples are available here

Georgios Konstantopoulos 1.2k Sep 23, 2022
Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture.

?? Martinez ?? Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture. Why run Martinez? Look at

Arthur·Thomas 23 Jul 3, 2022
Ethereum JSON-RPC multi-transport client. Rust implementation of web3 library

Ethereum JSON-RPC multi-transport client. Rust implementation of web3 library. ENS address: rust-web3.eth

Tomasz Drwięga 1.1k Sep 22, 2022
Parity-Bridge — Bridge between any two ethereum-based networks

Deprecated Bridges This repo is deprecated. Originally it contained the ETH <> ETH-PoA bridge (see tumski tag). Later it was repurposed for ETH-PoA <>

Parity Technologies 314 Sep 12, 2022
An Ethereum 2.0 Emulator for Local Testing of Eth2 Applications

Mousse is an Ethereum 2.0 emulator for local testing of Eth2 applications (mainly Rollups). HTTP Server The REST API definition can be found in the ht

Mousse 46 Sep 10, 2022
C++ `std::unique_ptr` that represents each object as an NFT on the Ethereum blockchain

C++ `std::unique_ptr` that represents each object as an NFT on the Ethereum blockchain

null 1.9k Sep 18, 2022
Ethereum Improvement Proposal Validator

EIP validator An engine which ensures Ethereum Improvement Proposals meet certain requirements. Getting Started To install eipv and validate the EIPs

null 4 Dec 6, 2021