Rust Ethereum 2.0 Client

Related tags

Cryptography casper ethereum sharding serenity proof-of-stake eth2 shasper
Overview

Lighthouse: Ethereum 2.0

An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime.

Build Status Book Status Chat Badge

Documentation

Banner

Overview

Lighthouse is:

  • Ready for use on Eth2 mainnet.
  • Fully open-source, licensed under Apache 2.0.
  • Security-focused. Fuzzing techniques have been continuously applied and several external security reviews have been performed.
  • Built in Rust, a modern language providing unique safety guarantees and excellent performance (comparable to C++).
  • Funded by various organisations, including Sigma Prime, the Ethereum Foundation, ConsenSys, the Decentralization Foundation and private individuals.
  • Actively involved in the specification and security analysis of the Ethereum 2.0 specification.

Eth2 Deposit Contract

The Lighthouse team acknowledges 0x00000000219ab540356cBB839Cbe05303d7705Fa as the canonical Eth2 deposit contract address.

Documentation

The Lighthouse Book contains information for users and developers.

The Lighthouse team maintains a blog at lighthouse.sigmaprime.io which contains periodical progress updates, roadmap insights and interesting findings.

Branches

Lighthouse maintains two permanent branches:

  • stable: Always points to the latest stable release.
    • This is ideal for most users.
  • unstable: Used for development, contains the latest PRs.
    • Developers should base thier PRs on this branch.

Contributing

Lighthouse welcomes contributors.

If you are looking to contribute, please head to the Contributing section of the Lighthouse book.

Contact

The best place for discussion is the Lighthouse Discord server. Alternatively, you may use the sigp/lighthouse gitter.

Sign up to the Lighthouse Development Updates mailing list for email notifications about releases, network status and other important information.

Encrypt sensitive messages using our PGP key.

Donations

Lighthouse is an open-source project and a public good. Funding public goods is hard and we're grateful for the donations we receive from the community via:

  • Gitcoin Grants.
  • Ethereum address: 0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b (donation.sigmaprime.eth).
Comments
  • BooleanBitfield needs to be made sane

    BooleanBitfield needs to be made sane

    There is an implementation of a Boolean Bitfield here:

    https://github.com/sigp/lighthouse/tree/master/boolean-bitfield

    It (kinda) does the job for now, but it really needs some work done. If you spend some time looking at it I think you'll soon find out what I mean. As an example;

    • There is a possibility of overflows: we return the number of bits as a usize, however there can theoretically be usize number of bytes meaning we can have 8 * usize bits.
    • It keeps track of the number of true bits as you flip bits on and off. I don't think this is ideal as most cases where we want to know the number of true bits, we'll be receiving some serialized bytes from somewhere else (e.g., p2p nodes) and will need to calculate it manually.

    On top of these two points, there's likely many chances for optimization.

    Required Functionality

    Get

    get(n: usize) -> Result<bool, Error>

    Get value at index n.

    Error if bit out-of-bounds (OOB) of underlying bytes.

    Set

    set(n: usize, val: bool) -> Result<(bool, Error>

    Set bit at index n. Returns the previous value if successful.

    Error if bit is OOB of underlying bytes.

    Highest Set Bit

    highest_set_bit() -> Option<usize>

    Returns the index of the highest set bit. Some(n) if a bit set set, None otherwise.

    Note: this is useful because we need to reject messages if an unnecessary bit is set (e.g. if there are 10 voters and the 11th bit is set

    Number of Underlying Bytes

    num_bytes() -> usize

    Returns the length of the underlying bytes.

    _Note: useful to reject bitfields that are larger than required (e.g., if there are eight voters and two bytes -- only one byte is necessary). _

    Number of Set Bits

    num_set_bits() -> usize

    Returns the total number of set bits (i.e., how many peeps voted).

    Note: I'm not 100% sure we'll use this but I suspect we will.

    help wanted good first issue good for bounty 
    opened by paulhauner 38
  • Beacon Node: Unable to recover from network fragmentation

    Beacon Node: Unable to recover from network fragmentation

    Description

    Given is a custom beacon-chain testnet with nodes in physical distinct network locations [A, B]. The nodes have both an ENR supplied in a testnet directory specified as boot-enr.yaml and (due to inability to sufficiently network through ENR) a multi-address command line flag.

    The ENR file looks like this: gist/d6eea3ea3356e41bde81864143284ce9#file-4-boot_enr-yaml

    The multi-address look like this:

    --libp2p-addresses /ip4/51.158.190.99/tcp/9000,/ip4/87.180.203.227/tcp/9000

    Version

    ~/.opt/lighthouse master*
❯ git log -n1
commit f6a6de2c5d9e6fe83b6ded24bad93615f98e2163 (HEAD -> master, origin/master, origin/HEAD)
Author: Sacha Saint-Leger <[email protected]>
Date:   Mon Mar 23 09:21:53 2020 +0100

    Become a Validator guides: update (#928)

~/.opt/lighthouse master*
❯ rustc --version
rustc 1.42.0 (b8cedc004 2020-03-09)

    Present Behaviour

    In case there is a network fragmentation between A and B, the nodes do not attempt to reconnect to each other. Both nodes know about each other both from the ENR and the multi-address format.

    Furthermore, if both A and B are validators, there happens a chain split with two different head slots.

    It's possible to reconnect the nodes by restarting the beacon chain nodes manually, however, the chains of A and B are now unable to reorganize to the best head and the peers ban each other.

    Mar 23 10:53:27.534 ERRO Disconnecting and banning peer          timeout: 30s, peer_id: PeerId("16Uiu2HAkxE6kBjfoGtSfhSJAE8oib6h3gM972pAj9brmthTHuuP2"), service: network
Mar 23 10:53:27.612 ERRO Disconnecting and banning peer          timeout: 30s, peer_id: PeerId("16Uiu2HAmPz5xFwZfY4CYN6fxf3Yz6LQaDfzCUrA5qwCoTHoCSiNR"), service: network
Mar 23 10:53:38.000 WARN Low peer count                          peer_count: 1, service: slot_notifier

    In this case, deleting either A's or B's beacon chain and temporarily stopping the validators is the only way to recover from this issue.

    Expected Behaviour

    The beacon chain node should aggressively try to maintain connections. It should keep trying to resolve ENR and multi-addresses even after a disconnect.

    I don't know how it's designed, but I imagine:

    1. having higher timeouts to prevent disconnects in case of short network fragmentation
    2. having repeated connection attempts even if previous attempts failed in case of longer or more severe network fragmentation

    I have not enough understanding of consensus to have a suggestion for how to handle the reorganization, but having a more stable network would certainly help here.

    Steps to resolve

    Manual restart including reset of the beacon chain data directory.

    opened by q9f 31
  • Add cache for selection proof signatures

    Add cache for selection proof signatures

    Issue Addressed

    #3216

    Proposed Changes

    Add a cache to each VC for selection proofs that have recently been computed. This ensures that duplicate selection proofs are processed quickly.

    Additional Info

    Maximum cache size is 64 signatures, at which point the oldest signature (or rather the signature referencing the oldest message) is removed to make room for the next signature.

    WIP: Still need to remove pre-computation selection proofs if these are no longer desired.

    work-in-progress 
    opened by macladson 28
  • [Merged by Bors] - [Altair] Sync committee pools

    [Merged by Bors] - [Altair] Sync committee pools

    Add pools supporting sync committees:

    • naive sync aggregation pool
    • observed sync contributions pool
    • observed sync contributors pool
    • observed sync aggregators pool

    Add SSZ types and tests related to sync committee signatures.

    ready-for-bors 
    opened by realbigsean 27
  • Lighthouse re-licensing: GPL 2.0 -> Apache 2.0

    Lighthouse re-licensing: GPL 2.0 -> Apache 2.0

    Sigma Prime core contributors (@paulhauner , @AgeManning , @spble , @kirk-baird, @michaelsproul and others) have recently been discussing licensing for Lighthouse. We would like to change the licensing on Lighthouse to a more permissive, less restrictive license: Apache 2.0 (presently GPL 2.0).

    We would like to request our contributors to provide their approval for this change. If you approve this re-licensing, please comment in this issue with the sentence "I agree with re-licensing my work on this project to Apache 2.0" or similar.

    If you disagree with this change and would like to discuss further, please feel free to do so here or reach out to us on Gitter.

    Thank you all for helping make Lighthouse an even more open project!

    opened by zedt3ster 25
  • Implement tree hashing function

    Implement tree hashing function

    Description

    Implement the function described here: https://github.com/ethereum/eth2.0-specs/issues/54

    Present Behaviour

    Function doesn't exist.

    Expected Behaviour

    Function should exist.

    Steps to resolve

    AFAIK, the function is still experimental so be on the lookout for bugs and optimisations.

    At this stage, I think we should implement it as a separate crate.

    work-started 
    opened by paulhauner 25
  • [Merged by Bors] - Enable proposer boost re-orging

    [Merged by Bors] - Enable proposer boost re-orging

    Proposed Changes

    With proposer boosting implemented (#2822) we have an opportunity to re-org out late blocks.

    This PR adds three flags to the BN to control this behaviour:

    • --disable-proposer-reorgs: turn aggressive re-orging off (it's on by default).
    • --proposer-reorg-threshold N: attempt to orphan blocks with less than N% of the committee vote. If this parameter isn't set then N defaults to 20% when the feature is enabled.
    • --proposer-reorg-epochs-since-finalization N: only attempt to re-org late blocks when the number of epochs since finalization is less than or equal to N. The default is 2 epochs, meaning re-orgs will only be attempted when the chain is finalizing optimally.

    For safety Lighthouse will only attempt a re-org under very specific conditions:

    1. The block being proposed is 1 slot after the canonical head, and the canonical head is 1 slot after its parent. i.e. at slot n + 1 rather than building on the block from slot n we build on the block from slot n - 1.
    2. The current canonical head received less than N% of the committee vote. N should be set depending on the proposer boost fraction itself, the fraction of the network that is believed to be applying it, and the size of the largest entity that could be hoarding votes.
    3. The current canonical head arrived after the attestation deadline from our perspective. This condition was only added to support suppression of forkchoiceUpdated messages, but makes intuitive sense.
    4. The block is being proposed in the first 2 seconds of the slot. This gives it time to propagate and receive the proposer boost.

    Additional Info

    For the initial idea and background, see: https://github.com/ethereum/consensus-specs/pull/2353#issuecomment-950238004

    There is also a specification for this feature here: https://github.com/ethereum/consensus-specs/pull/3034

    ready-for-bors v3.4.0 
    opened by michaelsproul 24
  • [Merged by Bors] - Use the forwards iterator more often

    [Merged by Bors] - Use the forwards iterator more often

    Issue Addressed

    NA

    Primary Change

    When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.

    After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the BeaconChain::block_root_at_slot to use the forwards iterator, instead of the reverse one.

    I also noticed that the networking stack is using BeaconChain::root_at_slot to check if a peer is relevant (check_peer_relevance). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.

    Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).

    Additional Changes

    In the process I also noticed that we have two functions for getting block roots:

    • BeaconChain::block_root_at_slot: returns None for a skip slot.
    • BeaconChain::root_at_slot: returns the previous root for a skip slot.

    I unified these two functions into block_root_at_slot and added the WhenSlotSkipped enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.

    Additionally, I replaced vec![] with Vec::with_capacity in store::chunked_vector::range_query. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.

    Also, BeaconChain::get_ancestor_block_root is unused, so I got rid of it :wastebasket:.

    Additional Info

    I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.

    Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the check_peer_relevance call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.

    ready-for-bors 
    opened by paulhauner 22
  • [Merged by Bors] - Added LightClientBootstrap V1

    [Merged by Bors] - Added LightClientBootstrap V1

    Issue Addressed

    Partially addresses #3651

    Proposed Changes

    Adds server-side support for light_client_bootstrap_v1 topic

    Additional Info

    This PR, creates each time a bootstrap without using cache, I do not know how necessary a cache is in this case as this topic is not supposed to be called frequently and IMHO we can just prevent abuse by using the limiter, but let me know what you think or if there is any caveat to this, or if it is necessary only for the sake of good practice.

    ready-for-bors v3.4.0 
    opened by Giulio2002 21
  • [Merged by Bors] - Use async code when interacting with EL

    [Merged by Bors] - Use async code when interacting with EL

    Overview

    This rather extensive PR achieves two primary goals:

    1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
    2. Refactors fork choice, block production and block processing to async functions.

    Additionally, it achieves:

    • Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
    • Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
    • Concurrent per-block-processing and execution payload verification during block processing.
    • The Arc-ification of SignedBeaconBlock during block processing (it's never mutated, so why not?):
      • I had to do this to deal with sending blocks into spawned tasks.
      • Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper Arc clones.
      • We were also Box-ing and un-Box-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
      • Avoids cloning all the blocks in every chain segment during sync.
      • It also has the potential to clean up our code where we need to pass an owned block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
    • The BeaconChain::HeadSafetyStatus struct was removed. It was an old relic from prior merge specs.

    For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273

    Changes to canonical_head and fork_choice

    Previously, the BeaconChain had two separate fields:

    canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>

    Now, we have grouped these values under a single struct:

    canonical_head: CanonicalHead {
  cached_head: RwLock<Arc<Snapshot>>,
  fork_choice: RwLock<BeaconForkChoice>
}

    Apart from ergonomics, the only actual change here is wrapping the canonical head snapshot in an Arc. This means that we no longer need to hold the cached_head (canonical_head, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the cached_head and fork_choice locks simultaneously.

    Breaking Changes

    The state (root) field in the finalized_checkpoint SSE event

    Consider the scenario where epoch n is just finalized, but start_slot(n) is skipped. There are two state roots we might in the finalized_checkpoint SSE event:

    1. The state root of the finalized block, which is get_block(finalized_checkpoint.root).state_root.
    2. The state root at slot of start_slot(n), which would be the state from (1), but "skipped forward" through any skip slots.

    Previously, Lighthouse would choose (2). However, we can see that when Teku generates that event it uses getStateRootFromBlockRoot which uses (1).

    I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.

    Notes for Reviewers

    I've renamed BeaconChain::fork_choice to BeaconChain::recompute_head. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the ForkChoice struct.

    I've changed the ordering of SSE events when a block is received. It used to be [block, finalized, head] and now it's [block, head, finalized]. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".

    I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to get_head. Ensuring get_head has been run at least once means that the cached values doesn't need to wrapped in an Option. This was fairly simple, it just involved passing a slot to the constructor so it knows when it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the slot that was saved in the fork_choice_store. That seems like it would be a faithful representation of the slot when we saved it.

    I added the genesis_time: u64 to the BeaconChain. It's small, constant and nice to have around.

    Since we're using FC for the fin/just checkpoints, we no longer get the 0x00..00 roots at genesis. You can see I had to remove a work-around in ef-tests here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the network expected the 0x00..00 alias and patched it here: 3f26ac3e2.

    You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:

    • Changing tests to be tokio::async tests.
    • Adding .await to fork choice, block processing and block production functions.
    • Refactor of the canonical_head "API" provided by the BeaconChain. E.g., chain.canonical_head.cached_head() instead of chain.canonical_head.read().
    • Wrapping SignedBeaconBlock in an Arc.
    • In the beacon_chain/tests/block_verification, we can't use the lazy_static CHAIN_SEGMENT variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.

    I had to disable rayon concurrent tests in the fork_choice tests. This is because the use of rayon and block_on was causing a panic.

    ready-for-bors backwards-incompat bellatrix 
    opened by paulhauner 21
  • FailedToInsertDeposit

    FailedToInsertDeposit

    Description

    I receive this error in my logs, over and over:

    {
  "msg": "Failed to update eth1 cache",
  "level": "ERRO",
  "ts": "2020-05-27T09:02:20.147080658-05:00",
  "service": "eth1_rpc",
  "error": "Failed to update eth1 cache: FailedToInsertDeposit(NonConsecutive { log_index: 52, expected: 51 })",
  "retry_millis": "7000"
}

    I run lighthouse with the following command: /home/lighthouse/.cargo/bin/lighthouse --logfile /data/lighthouse/logs/beacon.log beacon_node --eth1 --http --ws --datadir /data/lighthouse --http-address 0.0.0.0 --ws-address 0.0.0.0

    I run a Nethermind eth1 client, archive sync to Goerli, version 1.8.40

    I will say that this is as far as I got, I'm not running a validator yet. I wanted the beacon node to be up and running and in sync before I moved on to the next steps...

    Version

    Lighthouse 0.1.2

    Present Behaviour

    It's not clear to me what this log means, I searched for it but I couldn't find it.

    Expected Behaviour

    Unknown

    opened by MysticRyuujin 21
  • Support LightClientFinalityUpdate and LightClientOptimisticUpdate rpcs

    Support LightClientFinalityUpdate and LightClientOptimisticUpdate rpcs

    Issue Addressed

    #3651 partially addresses

    Proposed Changes

    Support LightClientFinalityUpdate https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md#getlightclientfinalityupdate

    Support LightClientOptimisticUpdate https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md#getlightclientoptimisticupdate

    Additional Info

    I didn't name it GetLightClientFinalityUpdate to follow the LightClientBootstrap PR that has been merged already #3711. I'll make another PR to support LightClientUpdatesByRange as it's a bit more involved.

    opened by GeemoCandama 0
  • Don't write empty blobs to db

    Don't write empty blobs to db

    Issue Addressed

    Don't write empty blobs to db

    Proposed Changes

    Blob verification doesn't appear to happen on blobs loaded from db, so verification will occur where it is supposed to (i.e. where this is called https://github.com/sigp/lighthouse/blob/786d9834f572fdf546604ebf5612ce2c3dd2e1c9/beacon_node/beacon_chain/src/kzg_utils.rs#L14).

    Imo it's fine to return an error to a request for an empty blob https://github.com/sigp/lighthouse/blob/786d9834f572fdf546604ebf5612ce2c3dd2e1c9/beacon_node/network/src/beacon_processor/worker/rpc_methods.rs#L249-L262.

    ready-for-review eip-4844 
    opened by emhane 0
  • Capella cleanup

    Capella cleanup

    Issue Addressed

    Proposed Changes

    • remove unused methods
    • fix potential panic in type conversion
    • error handling in default_at_fork
    • remove web3signer blobs code
    • remove post blobs from bn api client
    • log instead of panic in p2p
    • fix lcli payload decoding

    Additional Info

    ready-for-review capella 
    opened by realbigsean 0
  • implementation CLI request on 4844

    implementation CLI request on 4844

    please allow for a CLI parameter to let lighthouse to use a different data directory for the 4844 data.

    eg

    ./lighthouse bn --4844-data-dir /path/to/4844storage

    Reason: The 4844 data structure is designed to not be processed and rather just be temporarily stored. Further this data should have a low disk read write access requirement so another non-SSD media could be used.

    @realbigsean

    opened by mrabino1 2
  • Add CLI flag to specify the format of logs written to the logfile

    Add CLI flag to specify the format of logs written to the logfile

    Proposed Changes

    Decouple the stdout and logfile formats by adding the --logfile-format CLI flag. This behaves identically to the existing --log-format flag, but instead will only affect the logs written to the logfile. The --log-format flag will no longer have any effect on the contents of the logfile.

    Additional Info

    This is technically a breaking change, as users who were previously relying on being able to write JSON formatted logs to the logfile will now have to use --logfile-format JSON instead of --log-format JSON.

    ready-for-review UX-and-logs backwards-incompat 
    opened by macladson 0
Releases(v3.3.0)
Owner
Sigma Prime
Blockchain & Information Security Services
Sigma Prime
GitHub
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 2.1k Jan 6, 2023
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 226 Dec 27, 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.2k Jan 8, 2023
Rust client to Seaport's APIs and Ethereum smart contracts(WIP)

Seaport-rs WIP - WORK IN PROGRESS. REFER TO https://github.com/Alcibiades-Capital/quay FOR PRODUCTION READY CODE I'm new to Rust and seek to be legend

Perelyn 21 Nov 29, 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 Dec 28, 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 Dec 24, 2022
The Fastest and most Advanced Ethereum Client

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

Jay Lee 6 Feb 17, 2022
A crate for working with Ethereum beacon chain light client protocol messages. `no_std` friendly!

eth-lightclient-rs A crate for working with Ethereum beacon chain light client protocol messages. no_std friendly! !! For hacking and experimentation

Willem Olding 12 Jan 6, 2023
An experimental fork of a16z's Helios Ethereum client which can run its network traffic over the Nym mixnet

Helios (Nym mixnet fork) Helios is a fully trustless, efficient, and portable Ethereum light client written in Rust. This fork of Helios includes nasc

Nym 4 Mar 3, 2023
Rust project for working with ETH - Ethereum transactions with Rust on Ganache and also deploy smart contracts :)

Just a test project to work with Ethereum but using Rust. I'm using plain Rust here, not Foundry. In future we will use Foundry. Hope you're already f

Akhil Sharma 2 Dec 20, 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 153 Dec 27, 2022
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 5.1k Jan 9, 2023
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 48 Dec 18, 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.5k Jan 8, 2023
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

Huff 276 Dec 31, 2022
Ethereum key tool - Lightweight CLI tool to deal with ETH keys written in rust

ekt - Etherum Key Tool ekt is a lightweight tool to generate ethereum keys and addresses. Installation Either clone it and run it with cargo or instal

null 5 May 8, 2023
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 Nov 25, 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