Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

with a focus on low resource utilization, modularity and security

nakamoto

.

The vision for the project is to build a set of libraries targeting light client functionality, that are easy to embed in any program and on any platform, be it mobile or desktop. The project's small cpu, memory and code footprint is made possible by its efficient runtime and minimal set of dependencies. The implementation language, Rust, opens up the possibility for programs written in other languages (eg. Swift, Python, Java), to bind directly to it via a foreign function interface (FFI).


[dependencies]
nakamoto = "0.2.0"

Requires rustc 1.53 or greater.

Design

Nakamoto is split into several crates, each handling a different aspect of the light-client protocol. Although these crates are designed to be used in tandem, swapping implementations is trivial, due to the explicit boundaries between them, and the use of traits. From a high-level, we have:

  • nakamoto-client: the core light-client library
  • nakamoto-p2p: the protocol state-machine implementation
  • nakamoto-chain: the block store and fork selection logic
  • nakamoto-net-poll: the default poll-based networking library
  • nakamoto-common: common functionality used by all crates
  • nakamoto-node: a standalone light-client daemon
  • nakamoto-wallet: a very basic watch-only wallet built on the above crates

For an overview of the above, see the architecture diagram in the docs folder.

Status

While the project is still in its infancy, the base functionality has been implemented. Nakamoto is able to discover peers, download and verify the longest chain and handle forks, while implementing the full header verification protocol.

Client side block filtering (BIP 157/158) is implemented and working. See nakamoto-wallet for an example of how to use it.

Once peer-to-peer layer encryption (BIP 151) lands in Core, it will also be implemented in Nakamoto.

Finally, a C FFI will be implemented, to make it easy to embed the client in mobile applications.

Though wallet functionality will slowly be added, it isn't the primary focus of this project, which sits one level below wallets.

Projects goals

  • High assurance: the library should be thoroughly tested using modern techniques such as property and model-based testing as well as discrete event simulation and fuzzing. These approaches benefit from a clean separation between I/O and protocol logic and have been shown to catch more bugs than unit testing.

  • Security: as a library that may find its way into wallet implementations, a primary goal is security and auditability. For this reason, we try to minimize the total dependency footprint, keep the code easy to read and forbid any unsafe code.

  • Efficiency: blockchain synchronization should be done as efficiently as possible, with low memory, disk and bandwidth overhead. We target resource-constrained environments, such as mobile.

  • Privacy: when possible, privacy-preserving techniques should be employed. Client Side Block Filtering (BIP 157/158) should be used over bloom filters (BIP 37) to ensure user privacy and provide censorship resistance.

Running the tests

cargo test --all

Running the daemon

cargo run --release -p nakamoto-node -- --testnet

Contributing

If you'd like to contribute to the development of Nakamoto, please get in touch! Otherwise, do read the contribution guidelines.

Donations

To help fund the project and ensure its ongoing development and maintenance, your support in Bitcoin is appreciated at the following address:

bc1qa47tl4vmz8j82wdsdkmxex30r23c9ljs84fxah

Motivation

Looking at ecosystems that aren't light-client friendly—Ethereum for example—we see that the vast majority of users are forced into trusting third parties when transacting on the network. This is completely counter to the idea and raison d'être of blockchains, and poses a giant security and privacy risk. Unfortunately, this is due to the lackluster support for light-clients, both at the protocol level, and in terms of the available implementations. Light-clients are necessary for the average user to be able to securely interface with a network like Ethereum or Bitcoin.

For this purpose, Nakamoto was conceived as a client that can efficiently run on any mobile device, with the highest standards of privacy and security achievable given the constraints.

License

Licensed under the MIT license. © 2020 Alexis Sellier (https://cloudhead.io)

Issues

Collection of the latest Issues

cloudhead

cloudhead

help wanted
0

To have a higher chance to connect to peers with NODE_COMPACT_FILTERS support, we could use the service bit filtering functionality of DNS seeds.

This is not a very well documented feature, but there is some information here: https://bitcoin.stackexchange.com/questions/60373/dns-seeder-options

The filter we'd be interested in is NODE_NETWORK | NODE_COMPACT_FILTERS, so 1 << 0 | 1 << 6 = 65.

Since not all seeds support this functionality, we should fall back on a regular DNS query if we're unable to retrieve addresses from the seeds.

metaclips

metaclips

enhancement
1

When client.run fails, users have to create a new client, reload blocks and peers before sync can be started. We should ensure client doesn't panic or is easily restartable.

cloudhead

cloudhead

help wanted
3

Currently, the client API is channel based, via crossbeam-channel. It would be worth exploring what a futures-based API might look like around Client and client::Handle.

cloudhead

cloudhead

help wanted
0

Starting thinking about how a C FFI would look, as the API stabilizes. For now, this FFI should only be around the nakamoto-client crate.

cloudhead

cloudhead

0

Currently, peer latency is measured in the PingManager, but not used.

  • We should keep track of latencies, persist them (either in the client::peer::Cache or some where else.
  • Use it to decide which peers to connect to
  • Use it to decide which peers to download headers/blocks from

Some notes:

  • We should generally not compromise geo-diveristy when looking for low-latency peers, but having a few low-latency peers is desired
  • Low-latency peer selection can either be via AddressManager::sample being biased towards low-latency peers, or by simply calling sample 2-3 times and picking the peer with the lowest latency.
cloudhead

cloudhead

help wanted
0

Initial block (header) download can be made faster by syncing from multiple peers. To do this, we can use the hard-coded checkpoints to request multiple block ranges.

cloudhead

cloudhead

good first issue
0

We should keep track of how much data is read and written to the network. This can be done through the Reactor.

cloudhead

cloudhead

help wanted
2

Peers that misbehave or shouldn't be connected to / retry-ed for a while should be banned. We're mainly interested in saving time and bandwidth by doing this.

The banned peers should be stored in the client::peer::Cache with the ban duration and start time.

It probably makes sense to create a BanManager for this alongside the other sub-protocols in p2p/src/protocol/.

Information - Updated Jun 06, 2022

Stars: 208
Forks: 31
Issues: 14

Solana blockchain repo and docs

Please make sure you are always using the latest stable rust version as this is a crypto library and require safe code

Solana blockchain repo and docs

Wagyu Etherum blockchain ledger and wallet in Rust

Cross platform ether wallet generator that makes automated creation of crypto wallets easy

Wagyu Etherum blockchain ledger and wallet in Rust

Blockchain Commons torgap-sig

torgap-sig is a fork of spdx:BSD-2-Clause Plus Patent License

Blockchain Commons torgap-sig

Blockchain Commons torgap-sig-cli-rust

torgap-sig-cli-rust is a fork of Minisign, with support for

Blockchain Commons torgap-sig-cli-rust

Phala Blockchain

pRuntime (Phala Network Secure Enclave Runtime) is a runtime to execute confidential smart contracts, based on confidential computing

Phala Blockchain

A Blockchain implementation in Rust

MIT (c) Doublify Technologies

A Blockchain implementation in Rust

Simple Blockchain

cargo run para ejecutar la app, cargo build para crear un ejecutable

Simple Blockchain

A Blockchain implementation in pure Rust

Below find an example usage of the library:

A Blockchain implementation in pure Rust

rusted-blockchain

Wanted a better understanding of blockchain, and practice more rust

rusted-blockchain

Rust API client for cryptoapis

0 is a complex and innovative infrastructure layer that radically simplifies the development of any Blockchain and Crypto related applications

Rust API client for cryptoapis
Facebook Instagram Twitter GitHub Dribbble
Privacy