Introduction to the Tohu Network

The Tohu network is a peer-to-peer barter system built on blockchain technology, designed to enable economic sovereignty for marae communities across Aotearoa New Zealand. Rather than relying on traditional centralized financial systems, Tohu creates a decentralized infrastructure where communities can conduct transactions directly with one another, exchanging goods and services according to principles of utu and reciprocal exchange rooted in Māori values.

Blockchain technology underpins Tohu by providing a distributed, immutable ledger that records all transactions across the network. This decentralized approach ensures that no single entity controls the system, allowing participating communities to maintain full sovereignty over their economic activities. The network is owned and operated by the communities themselves through a permissioned validator model where marae representatives can participate in governance and block validation.

Tohu represents a practical implementation of economic self-determination, enabling marae to build interconnected trading relationships while maintaining control over the infrastructure that supports their commerce. By combining peer-to-peer architecture with blockchain’s transparency and security, Tohu creates a foundation for sustainable, community-driven economic systems.

 

 

The Tohu Network Architecture

The Tohu network is built on Hyperledger Besu, a blockchain client that implements the Ethereum Virtual Machine. Validators in the network use the QBFT consensus mechanism, which provides Byzantine fault tolerance suitable for permissioned networks. Communication between validator nodes occurs over a WireGuard virtual private network, ensuring secure and encrypted connections across distributed locations. Each validator node runs as a systemd service, providing automated startup, restart capabilities, and reliable operation. Validator nodes maintain the complete blockchain state and participate in block proposal and validation according to the QBFT protocol.

Sentry nodes operate as non-validator relay nodes within the network architecture. These nodes connect to validator nodes through the same WireGuard infrastructure but do not participate in consensus. Sentry nodes serve to expand network capacity and enable broader community participation without the computational requirements of validation. They relay transactions and blocks across the network, supporting scalability as the Tohu network grows across marae communities.

How Transactions Work

Transactions on the Tohu network represent the transfer of TOHU tokens between users. A user initiates a transaction by specifying a recipient address and the amount of TOHU to send using their Tohu wallet. The transaction is digitally signed using the user’s private key, proving ownership and authorization without revealing the key itself.

Once submitted, transactions enter the network’s mempool where validator nodes collect pending transactions. Validator nodes then bundle these transactions into a new block, which is proposed according to the QBFT consensus mechanism. Other validators verify that all transactions are valid and that the proposer has the right to create a block at that moment in time. Once consensus is reached, the block is added to the blockchain, and all transactions within it become immutable.

The transaction fee structure ensures network sustainability, with a portion of fees supporting validator operations. Transaction finality on Tohu is achieved quickly due to the QBFT consensus model, allowing users to trust that their transactions are permanently recorded within seconds of block inclusion. This speed and certainty make Tohu suitable for real-time peer-to-peer commerce between marae communities.

Token Economics and Minting

The Tohu network uses a native token called TOHU with a fixed maximum supply of one billion tokens. Blocks on the Tohu network are produced at regular intervals through the QBFT consensus mechanism, with each block proposal creating new TOHU tokens through a block reward. Validators earn tokens for each block they successfully propose and validate, incentivizing consistent participation in network security and operation.

The minting rate adjusts dynamically based on the number of active validators in the network, ensuring consistent token issuance across different network states. With current validator configurations, approximately one hundred thousand TOHU tokens are minted per validator node per year. This approach creates predictable long-term tokenomics while allowing the network to scale as additional validators join across marae communities.

Block rewards are distributed equally across all active validators, creating a fair and transparent incentive structure. The network also extends reward eligibility to sentry nodes through a block relay model, allowing relay nodes to earn rewards for their participation in network operations. This design encourages broader network participation beyond core validators, supporting the growth of the network across multiple marae communities. The one billion token supply cap ensures scarcity and long-term value stability, with projections showing the network reaching full token issuance over approximately twenty years as validator count scales to around five hundred nodes.

Wallets and Token Management

Users interact with the Tohu network through decentralized wallets, with Tohu wallet being the primary wallet interface supported by the network. A wallet functions as a secure container for cryptographic keys that prove ownership of TOHU tokens and authorize transactions on the network. When a user creates a wallet, they receive a private key — a secret cryptographic credential that must be kept secure — and a corresponding public address that identifies their account on the Tohu network.

Tohu wallet allows users to manage their TOHU holdings, initiate transactions, and interact with the Tohu network through a simple interface. Users can send TOHU tokens to other participants by specifying a recipient address, with transactions being recorded permanently on the blockchain. The wallet also enables users to view their transaction history and account balance in real time.

Security of the private key is critical, as anyone with access to a user’s private key can control the associated TOHU tokens. MetaMask provides encryption features to protect private keys locally on a user’s device, but users remain responsible for safeguarding their credentials. By maintaining control of their own private keys, users retain full sovereignty over their tokens and transactions, aligning with Tohu’s core principle of community economic control.

Network Security

The Tohu network implements multiple layers of security to protect community assets and maintain network integrity. Validator nodes communicate exclusively through WireGuard, a modern virtual private network protocol that encrypts all inter-node traffic and authenticates connections using cryptographic keys. This ensures that only authorized validator nodes can participate in consensus and block production, preventing unauthorized access to the network core.

User wallets are protected through cryptographic key management, with private keys encrypted locally on user devices through MetaMask’s security features. The permissioned validator model ensures that only marae representatives with approved credentials can operate validator nodes, preventing malicious actors from joining the network and corrupting the consensus process. Validator nodes themselves run under restricted user accounts with minimal system privileges, limiting the impact of potential compromises.

Transaction validation on the blockchain provides immutability and tamper resistance — once a transaction is recorded in a block, it cannot be altered or removed without redoing all subsequent blocks, making historical attacks computationally infeasible. The QBFT consensus mechanism protects against Byzantine failures, tolerating malicious or faulty validators up to a defined threshold while maintaining network agreement. By combining permissioned access, encryption, and Byzantine fault tolerance, Tohu creates a secure foundation for community economic transactions.

How QBFT Consensus Works with Your 40 Nodes

The Core Concept

QBFT (Quorum Byzantine Fault Tolerant) consensus is built on the idea that if you have enough honest nodes agreeing on a block, even if some are lying or offline, you can still reach consensus with absolute finality — no rollbacks, no forks.

With 40 validators on Tohu, you need 30 nodes to agree on each block (that’s ⌊2n/3⌋ + 1). This means up to 10 Byzantine nodes can fail, crash, or try to fork the chain without breaking the network.


The Four Phases in Detail

Phase 1: Propose
The designated leader (which rotates through the 40 nodes each round) creates a new block from pending transactions in the mempool and sends it to all 39 other nodes. Each node:

  • Validates the transactions (nonce, signature, gas, state consistency)
  • Computes a block digest (a hash representing the block’s unique identity)
  • Records “I’ve seen this block and it’s valid”

Phase 2: Prepare
All 40 nodes broadcast a PREPARE message containing their block digest. This is a cryptographically signed vote saying “I’m ready to commit this block.”

  • Threshold: 30 PREPARE votes needed to move to the commit phase
  • If fewer than 30 nodes vote in time (nodes crash, network delays), a view change happens — the leader rotates and we start over
  • This prevents any single leader from committing an invalid block

Phase 3: Commit
Once a node sees 30 PREPARE votes, it broadcasts a COMMIT message — “I’m locking in this block.”

  • Threshold: 30 COMMIT votes needed to finalize
  • A block that reaches 30 COMMITs is final and irreversible — it goes on-chain permanently
  • No amount of Byzantine nodes can undo it because they would need 30 votes to propose an alternative block, but 30 honest nodes already committed the original

Phase 4: Finalize
Once a node sees 30 COMMITs, the block is finalized. The chain advances, you mine TOHU rewards, and the next round begins with a new leader.


Why 30 Out of 40 Is Magic

The math: n = 40, f = ⌊n/4⌋ = 10 maximum faults

To guarantee consensus even with 10 Byzantine nodes:

  • Quorum = ⌊2n/3⌋ + 1 = 26 + 1 = 27 minimum
  • But Hyperledger Besu uses 30 for a safety margin, which is ⌊3n/4⌋ (99.9% confidence)
  • This means even if 10 nodes lie or crash, the remaining 30 honest nodes can finalize any block without them

The attack impossibility:

  • Attacker needs 30 votes to commit block A
  • Attacker needs 30 votes to commit conflicting block B (from a different leader)
  • Total required: 60 votes
  • Total available: 40
  • Impossible. Even a sophisticated Byzantine attacker with 10 nodes can’t create a fork because they’d need honest nodes to vote for two different blocks, and honest nodes won’t.

View Changes (What Happens If the Leader Fails)

If the leader doesn’t propose a block in time (crashed, network partition, or intentionally stalling):

  1. Timeout expires (typically 1–3 seconds, tunable in Besu config)
  2. All 40 nodes increment the view number (0 → 1 → 2 → 3…)
  3. New leader elected — typically via leader = nodeID mod (currentView + 1), so the rotation is deterministic but Byzantine nodes can’t predict it far ahead
  4. New leader proposes — starting Phase 1 again
  5. Repeat until someone commits a block

With 10 faulty nodes trying to stall forever, you might cycle through leaders a few times, but eventually you hit an honest one and consensus happens.


Practical TOHU Network Numbers

Your current setup: 2 validators (Node 1 and 2) running on Raspberry Pi with WireGuard VPN.

Scaling to 40 validators:

  • Each validator runs Hyperledger Besu 25.10.0 with QBFT
  • Each broadcasts 3 messages per round (PROPOSE, PREPARE, COMMIT)
  • At a block every 6 seconds (typical), that’s ~40 × 3 = 120 messages/sec across the network
  • Over WireGuard on a 1Gbps VPS link, this is negligible (~960 kbps max, usually 10–50 kbps)

Per-node CPU load:

  • Block validation: cryptographic checks (ECDSA signatures, Merkle tree proofs) — ~50–100ms per block
  • QBFT voting: ~10ms per round
  • Disk writes: ~10 MB/sec to /opt/besu/data on your Samsung T7 SSD — fine, no bottleneck

Security advantage of 40 nodes:

  • Decentralisation: No single marae controls the network
  • Regulatory clarity: 40 independent operators across iwi communities makes it harder for a regulator to claim it’s one entity
  • Availability: Even if 10 marae nodes go offline, consensus continues
  • Sovereignty: If RBNZ ever tried to force a “trusted partner” to run a node and force chain reorg, they’d need 30 nodes cooperating — extremely unlikely if validators span 40 different communities

Finality vs Liveness Trade-off

QBFT prioritises finality over liveness:

  • Finality: Once 30 nodes commit, that block is locked forever ✓
  • Liveness: If fewer than 30 nodes are online or responsive, the chain pauses (no new blocks) until a leader produces one that 30 nodes see

This is opposite to longest-chain consensus (Nakamoto PoW/PoS), where blocks are probabilistically final and the chain never stops.

For Tohu:

  • Good: You’ll never have to deal with rollbacks or chain reorgs
  • Good: Community treasuries on Tohu are final and irreversible
  • Trade-off: If more than 10 marae nodes go offline at once (network partition, natural disaster), the chain stalls. Plan for geographic and network redundancy.