English | 简体中文

• 00 | Overview
• 01 | Architecture
• 02 | Initialization: Pre-commit Hooks & Github Action
• 03 | Defining Data Structure & API
• 04 | Wallet: Sign & Verify
• 05 | Command Line & Config File
• 06 | Thinking in Libp2p
• 07 | Tinyp2p: A CSP Concurrency Model
• 08 | Network Layer
• 09 | Biz Layer: How to Do Read/Write Separation?
• 10 | Data Layer & Demo

This project aims to demonstrate the basic principles of blockchain through a distributed ledger. The main features include:

• HTTP JSON API provides users with interfaces such as transfer and some query apis;
• P2P Protocol is used for interaction between nodes, and data is serialized/deserialized by protobuf. The functions include peer discovery, transaction broadcast, block broadcast, and block synchronization;
• PoW is used as the consensus mechanism;
• Sled, an embedded key-value database, is used as the storage backend;
• For the convenience of demonstration, there is a wallet in each node that stores the users' private keys, so that the node can sign the transaction on behalf of users.

See 01 | Architecture for details.

From a holistic perspective, this project is a workspace, consisting of three crates: tinychain, tinyp2p, and wallet.

• tinychain: core business.
• tinyp2p: a tinychain-specific p2p protocol based on rust-libp2p.
• wallet: user private key management.

See 01 | Architecture for details.

In tinychain, it is divided into three layers according to responsibilities:

• Network Layer: responsible for interacting with the outside world, including processing HTTP requests and interacting with other peers.
• ⭐Biz Layer: based on the principle of Dependency Inversion, it defines the behavior (traits) of the network and data layers, getting rid of the dependency on them.
  • trait PeerClient: the network needs to implement this trait to send data to other nodes.
  • trait State: the data needs to implement this trait to save the local state.
• Data Layer: responsible for saving the state.

See 09 | Biz Layer: How to Do Read/Write Separation? for details.

The biz layer achieves lock-free programming through read/write separation. That is to say, any thread can "read", but only one thread can "write". In this project, there are two main write operations: (1) Adding user transfer data to the transaction pool; (2) Adding blocks to the database. From the above figure, only the Miner thread has write permission. When other threads need to write, they send the data to the Miner to write via the channel.

See 07 | tinyp2p: A CSP Concurrency Model for details.

• p2p_client is used to process user requests. In p2p_client, the request is converted to cmd and sent to the channel.
• A background thread exclusively owns mut p2p_server, and gets cmd from the channel one by one to execute.
• Users can register event_handlers in p2p_server. When data is received from a remote node, event_handlers are called to process the data.

See 10 | Data Layer & Demo for details.

1. View the commands: RUST_LOG=info ./target/debug/tinychain：

   

2. Create an account: RUST_LOG=info ./target/debug/tinychain new-account：

   

3. Query account balance and block information