Skip to content

Commit 9312413

Browse files
Merge pull request #11 from raylsnetwork/feat/user-docs
Add mdbook user documentation
2 parents 92c13cf + 24addb8 commit 9312413

22 files changed

Lines changed: 1337 additions & 0 deletions

Makefile

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,7 @@ help:
4040
@echo " fmt - Format code"
4141
@echo " clippy - Run clippy lints"
4242
@echo " clean - Clean build artifacts"
43+
@echo " book - Build the user documentation (mdbook)"
4344
@echo ""
4445
@echo "Environment Variables:"
4546
@echo ""
@@ -329,6 +330,10 @@ clippy:
329330
clean:
330331
$(CARGO) clean
331332

333+
.PHONY: book
334+
book:
335+
mdbook build book
336+
332337
# Dafny commands
333338
dafny-translate:
334339
@echo "Translating Dafny specification to Rust..."

book/book.toml

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
[book]
2+
authors = ["Rayls Network"]
3+
language = "en"
4+
src = "src"
5+
title = "RBFT User Guide"
6+
7+
[build]
8+
build-dir = "../target/book"
9+
10+
[output.html]
11+
git-repository-url = "https://github.com/raylsnetwork/rbft"

book/src/SUMMARY.md

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# Summary
2+
3+
[Introduction](./introduction.md)
4+
5+
# Getting Started
6+
7+
- [Prerequisites](./getting-started/prerequisites.md)
8+
- [Installation](./getting-started/installation.md)
9+
10+
# Running a Chain
11+
12+
- [Local Testnet](./running/local-testnet.md)
13+
- [Follower Nodes](./running/follower-nodes.md)
14+
- [Validator Management](./running/validator-management.md)
15+
- [Docker Deployment](./running/docker.md)
16+
- [Kubernetes Deployment](./running/kubernetes.md)
17+
18+
# Deploying Contracts
19+
20+
- [Using Cast (Foundry)](./contracts/cast.md)
21+
- [QBFTValidatorSet Contract](./contracts/validator-set.md)
22+
- [Deploying Your Own Contracts](./contracts/deploying.md)
23+
24+
# Interacting with the Chain
25+
26+
- [Sending Transactions](./interacting/transactions.md)
27+
- [ERC20 Tokens](./interacting/erc20.md)
28+
- [Load Testing](./interacting/load-testing.md)
29+
30+
# Operations
31+
32+
- [Configuration Reference](./operations/configuration.md)
33+
- [Monitoring and Logs](./operations/monitoring.md)
34+
- [Troubleshooting](./operations/troubleshooting.md)
35+
36+
# Architecture
37+
38+
- [Overview](./architecture/overview.md)
39+
- [QBFT Consensus](./architecture/qbft.md)

book/src/architecture/overview.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
# Architecture Overview
2+
3+
RBFT is built as a layered system on top of Reth, the Rust Ethereum client.
4+
5+
```
6+
┌─────────────────┐
7+
│ RPC Interface │ HTTP JSON-RPC (ports 8545+)
8+
└────────┬────────┘
9+
10+
┌────────▼────────┐
11+
│ Reth Engine │ EVM execution, state management, transaction pool
12+
└────────┬────────┘
13+
14+
┌────────▼────────┐
15+
│ RBFT Consensus │ QBFT protocol, proposer rotation, validator management
16+
└────────┬────────┘
17+
18+
┌────────▼────────┐
19+
│ RLPx Network │ P2P messaging between validators and followers
20+
└─────────────────┘
21+
```
22+
23+
## Crate structure
24+
25+
### `rbft` (core library)
26+
27+
The consensus protocol implementation with no Reth dependencies. Contains:
28+
29+
- QBFT state machine (`NodeState`)
30+
- Message types (Proposal, Prepare, Commit, RoundChange, NewBlock)
31+
- Block validation and proposer election
32+
- Round change and timeout logic
33+
34+
This crate is designed to be testable in isolation using an in-memory
35+
`NodeSwarm` simulation.
36+
37+
### `rbft-node` (binary)
38+
39+
Integrates the core library with Reth:
40+
41+
- Custom consensus engine (`RbftConsensus`)
42+
- RLPx protocol handler for QBFT messages
43+
- Block building and execution via Reth
44+
- P2P connection management
45+
46+
### `rbft-utils` (binary)
47+
48+
Operator tooling:
49+
50+
- Genesis generation (compiles and deploys QBFTValidatorSet contract)
51+
- Testnet orchestration (start/stop/monitor nodes)
52+
- Validator management (add/remove/status via contract calls)
53+
- Log analysis (logjam)
54+
55+
### `rbft-megatx` (binary)
56+
57+
Transaction load generator for stress testing.
58+
59+
### `rbft-validator-inspector` (binary)
60+
61+
Terminal UI for real-time validator monitoring.
62+
63+
## Node types
64+
65+
| Type | Has validator key | Participates in consensus | Produces blocks |
66+
|---|---|---|---|
67+
| Validator (proposer) | Yes | Yes | Yes (when elected) |
68+
| Validator (non-proposer) | Yes | Yes | No |
69+
| Follower | No | No | No |
70+
71+
## Data flow
72+
73+
1. Transactions arrive via JSON-RPC
74+
2. The current proposer builds a block and broadcasts a `Proposal`
75+
3. Validators verify and send `Prepare` messages
76+
4. On quorum of prepares, validators send `Commit` messages
77+
5. On quorum of commits, the block is finalized
78+
6. A `NewBlock` message is broadcast so followers can update
79+
80+
## Fault tolerance
81+
82+
With `n` validators, RBFT tolerates `f = (n-1) / 3` Byzantine faults.
83+
The quorum size is `(2n - 1) / 3 + 1`.
84+
85+
| Validators | Max faults | Quorum |
86+
|---|---|---|
87+
| 4 | 1 | 3 |
88+
| 7 | 2 | 5 |
89+
| 10 | 3 | 7 |

book/src/architecture/qbft.md

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
# QBFT Consensus
2+
3+
RBFT implements the QBFT (Quorum Byzantine Fault Tolerant) consensus protocol,
4+
a practical BFT algorithm designed for permissioned blockchain networks.
5+
6+
## References
7+
8+
- [The Istanbul BFT Consensus Algorithm (IBFT paper)](https://arxiv.org/abs/2002.03613)
9+
- [QBFT Formal Specification (ConsenSys)](https://github.com/ConsenSys/qbft-formal-spec-and-verification)
10+
11+
## Protocol overview
12+
13+
QBFT operates in rounds within each block height. Each round has a designated
14+
proposer determined by round-robin rotation.
15+
16+
### Normal case (round 0)
17+
18+
1. **Block timeout** — the proposer waits for the block interval, then
19+
broadcasts a `Proposal` containing the new block.
20+
2. **Prepare** — validators verify the proposal and broadcast a `Prepare`
21+
message.
22+
3. **Commit** — once a validator receives a quorum of prepares, it broadcasts
23+
a `Commit` message with a commit seal.
24+
4. **Finalize** — once a quorum of commits is collected, the block is added
25+
to the chain with the commit seals embedded in the header.
26+
5. **NewBlock** — the committed block is broadcast so all nodes (including
27+
followers) can update their chains.
28+
29+
### Round change
30+
31+
If the proposer fails to propose within the timeout, validators trigger a
32+
round change:
33+
34+
1. Each validator sends a `RoundChange` message for the next round.
35+
2. When a quorum of round changes is collected, the new round's proposer
36+
creates a proposal with a justification (the round change messages).
37+
3. The protocol continues from step 2 (prepare phase).
38+
39+
### Timeout schedule
40+
41+
Round timeouts grow exponentially to avoid thrashing:
42+
43+
```
44+
timeout(r) = first_interval * growth_factor^r
45+
```
46+
47+
Default values:
48+
49+
| Parameter | Default |
50+
|---|---|
51+
| `first_interval` | 1.0 s |
52+
| `growth_factor` | 2.0 |
53+
| `max_round` | 10 |
54+
55+
## Proposer election
56+
57+
The proposer for round 0 at a given height is the validator after the previous
58+
block's proposer (wrapping around). For subsequent rounds, the index advances
59+
by the round number:
60+
61+
```
62+
round_zero_index = index_of(previous_proposer) + 1
63+
proposer_index = (round_zero_index + round) % num_validators
64+
```
65+
66+
At height 1, the first validator (index 0) proposes.
67+
68+
## Quorum and fault tolerance
69+
70+
For `n` validators:
71+
72+
- Maximum Byzantine faults tolerated: `f = (n-1) / 3`
73+
- Quorum size: `q = (2n - 1) / 3 + 1`
74+
75+
The protocol guarantees safety (no conflicting blocks are finalized) as long as
76+
at most `f` validators are faulty. It guarantees liveness as long as at least
77+
`q` validators are honest and connected.
78+
79+
## Validator sets and epochs
80+
81+
The validator set can change dynamically through the QBFTValidatorSet contract.
82+
Changes take effect at epoch boundaries (every `epochLength` blocks) to ensure
83+
all validators agree on the set for a given block range.

book/src/contracts/cast.md

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
# Using Cast (Foundry)
2+
3+
[Cast](https://book.getfoundry.sh/cast/) is a CLI tool from Foundry for
4+
interacting with EVM-compatible chains. It is the recommended way to send
5+
transactions and query state on an RBFT network.
6+
7+
## Installation
8+
9+
```bash
10+
curl -L https://foundry.paradigm.xyz | bash
11+
foundryup
12+
```
13+
14+
Verify:
15+
16+
```bash
17+
cast --version
18+
```
19+
20+
## Common operations
21+
22+
All examples assume the default testnet RPC at `http://localhost:8545`.
23+
24+
### Check block height
25+
26+
```bash
27+
cast bn
28+
```
29+
30+
### Query an account balance
31+
32+
```bash
33+
cast balance 0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf
34+
```
35+
36+
### Send ETH
37+
38+
```bash
39+
cast send 0x1234567890123456789012345678901234567890 \
40+
--value 1ether \
41+
--private-key 0x<YOUR_KEY> \
42+
--rpc-url http://localhost:8545
43+
```
44+
45+
### Derive an address from a private key
46+
47+
```bash
48+
cast wallet address --private-key 0x<YOUR_KEY>
49+
```
50+
51+
### Call a contract (read-only)
52+
53+
```bash
54+
cast call 0x0000000000000000000000000000000000001001 \
55+
"getValidators()(address[])" \
56+
--rpc-url http://localhost:8545
57+
```
58+
59+
### Send a contract transaction
60+
61+
```bash
62+
cast send 0x0000000000000000000000000000000000001001 \
63+
"addValidator(address,string)" \
64+
0xABCD... "enode://..." \
65+
--private-key 0x<ADMIN_KEY> \
66+
--rpc-url http://localhost:8545
67+
```

book/src/contracts/deploying.md

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
# Deploying Your Own Contracts
2+
3+
RBFT chains are fully EVM-compatible. Any contract that works on Ethereum can be
4+
deployed to an RBFT network using standard tools.
5+
6+
## Using Foundry (forge)
7+
8+
Create a project and deploy:
9+
10+
```bash
11+
forge init my-contract
12+
cd my-contract
13+
14+
# Edit src/Counter.sol, then deploy:
15+
forge create src/Counter.sol:Counter \
16+
--rpc-url http://localhost:8545 \
17+
--private-key 0x<YOUR_KEY>
18+
```
19+
20+
## Using cast with raw bytecode
21+
22+
```bash
23+
cast send --create <BYTECODE> \
24+
--private-key 0x<YOUR_KEY> \
25+
--rpc-url http://localhost:8545
26+
```
27+
28+
## Using Hardhat
29+
30+
In `hardhat.config.js`:
31+
32+
```javascript
33+
module.exports = {
34+
networks: {
35+
rbft: {
36+
url: "http://localhost:8545",
37+
accounts: ["0x<YOUR_PRIVATE_KEY>"]
38+
}
39+
}
40+
};
41+
```
42+
43+
Deploy:
44+
45+
```bash
46+
npx hardhat run scripts/deploy.js --network rbft
47+
```
48+
49+
## Getting test funds
50+
51+
On a default local testnet, the admin account
52+
(`0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf`, derived from key `0x000...0001`)
53+
is pre-funded with ETH. Transfer from it to fund your deployment account:
54+
55+
```bash
56+
cast send 0x<YOUR_ADDRESS> \
57+
--value 100ether \
58+
--private-key 0x0000000000000000000000000000000000000000000000000000000000000001 \
59+
--rpc-url http://localhost:8545
60+
```
61+
62+
## Chain ID
63+
64+
The chain ID is set in `genesis.json`. Check it with:
65+
66+
```bash
67+
cast chain-id --rpc-url http://localhost:8545
68+
```

0 commit comments

Comments
 (0)