Rust Ethereum 2.0 Client

Related tags

Cryptocurrencies 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
  • 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
  • Return HTTP 404 rather than 405

    Return HTTP 404 rather than 405

    Issue Addressed

    Issue 3112

    Proposed Changes

    Add Filter::recover to the GET chain to handle rejections specifically as 404 NOT FOUND

    Additional Info

    Making a request to http://localhost:5052/not_real now returns the following:

    {
    "code": 404,
    "message": "NOT_FOUND",
    "stacktraces": []
}
    opened by santiagomed 1
  • Make validator-dir global

    Make validator-dir global

    Issue Addressed

    https://github.com/sigp/lighthouse/issues/3768

    Proposed Changes

    Make certain flags as global

    Additional Info

    Please provide any additional information. For example, future considerations or information useful for reviewers.

    opened by 0xbentang 1
Releases(v3.3.0)
Owner
Sigma Prime
Blockchain & Information Security Services
Sigma Prime
GitHub
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
Martinez is vNext Ethereum implementation written in pure Rust with Erigon architecture as design.

?? 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
Coinbase pro client for Rust

Coinbase pro client for Rust Supports SYNC/ASYNC/Websocket-feed data support Features private and public API sync and async support websocket-feed sup

null 126 Dec 30, 2022
rust client libraries to deal with the current cardano mainnet (byron / cardano-sl)

Rust implementation of Cardano primitives, helpers, and related applications Cardano Rust is a modular toolbox of Cardano’s cryptographic primitives,

Input Output 275 Oct 9, 2022
Reference client for NEAR Protocol

Reference implementation of NEAR Protocol About NEAR NEAR's purpose is to enable community-driven innovation to benefit people around the world. To ac

NEAR 2k Dec 29, 2022
The Parity Bitcoin client

The Parity Bitcoin client. Gitter Installing from source Installing the snap Running tests Going online Importing bitcoind database Command line inter

Parity Technologies 714 Dec 21, 2022
A Rust library for working with Bitcoin SV

Rust-SV A library to build Bitcoin SV applications in Rust. Documentation Features P2P protocol messages (construction and serialization) Address enco

Brenton Gunning 51 Oct 13, 2022
The new, performant, and simplified version of Holochain on Rust (sometimes called Holochain RSM for Refactored State Model)

Holochain License: This repository contains the core Holochain libraries and binaries. This is the most recent and well maintained version of Holochai

Holochain 737 Dec 28, 2022
DEPRECATED. The Holochain framework implemented in rust with a redux style internal state-model.

Holochain-rust Travis: Circle CI: Codecov: License: This code is loosely based on the previous Golang prototype. Code Status: This Rust version is alp

Holochain 1k Jan 3, 2023
IBC modules and relayer - Formal specifications and Rust implementation

ibc-rs Rust implementation of the Inter-Blockchain Communication (IBC) protocol. This project comprises primarily four crates: The ibc crate defines t

Informal Systems 296 Jan 4, 2023
A Rust implementation of BIP-0039

bip39-rs A Rust implementation of BIP0039 Changes See the changelog file, or the Github releases for specific tags. Documentation Add bip39 to your Ca

Infincia LLC 49 Dec 9, 2022
Official Rust implementation of the Nimiq protocol

Nimiq Core implementation in Rust (core-rs) Rust implementation of the Nimiq Blockchain Core Nimiq is a frictionless payment protocol for the web. Thi

Nimiq 72 Sep 23, 2022
Rust implementation of Zcash protocol

The Parity Zcash client. Gitter Blog: Parity teams up with Zcash Foundation for Parity Zcash client Installing from source Installing the snap Running

Parity Technologies 183 Sep 8, 2022
Tendermint in Rust!

tendermint.rs Tendermint in Rust with TLA+ specifications. Tendermint is a high-performance blockchain consensus engine for Byzantine fault tolerant a

Informal Systems 439 Jan 1, 2023
A Rust library for generating cryptocurrency wallets

Table of Contents 1. Overview 2. Build Guide 2.1 Install Rust 2.2a Build from Homebrew 2.2b Build from Crates.io 2.2c Build from Source Code 3. Usage

Aleo 554 Dec 31, 2022
Rust port of the Terry Davis' (RIP) "god says" program

RIP Terry A. Davis 1969-2018 god says Rust port of the programmer Terry Davis' "god says" (AKA GodSpeaks) program. Terrence Andrew Davis (December 15,

Orhun Parmaksız 54 Dec 26, 2022
Implementation of the Kademlia DHT protocol in Rust

kademlia-dht Simple implementation of the Kademlia DHT protocol in Rust with state dumping features for educational purposes (not production-ready). T

Leonardo Folgoni 18 Sep 24, 2022
Collection of Key Derivation Functions written in pure Rust

RustCrypto: Key Derivation Functions Collection of Key Derivation Functions (KDF) written in pure Rust. Supported Algorithms Algorithm Crate Crates.io

Rust Crypto 44 Dec 25, 2022
Cryptocurrencies trend-following trading bot sandbox written in Rust.

Trend trading bot Experiments repo about (crypto) trend trading. By "trend" I mean trading following the trend using technical indicators (vs other ki

Julien 6 Oct 2, 2022