TSP-0002 BLAKE3

Proposal Number: TSP-0002
Proposal Name: Tondi Adoption of BLAKE3 for Performance and Concurrency Enhancements
Proposal Status: Implemented
Author: Tondi Foundation Development Team
Creation Date: 2025-05-05
Target Version: Tondi Genesis (v2025b)
Protocol Scope: Consensus layer, transaction structure, block header, UTXO indexing, contract hash references, RGB anchoring

---

🔍 Overview

This proposal specifies that the Tondi blockchain will adopt BLAKE3 as its universal hashing algorithm across all protocol layers, replacing traditional algorithms such as BLAKE2b and SHA-256. The scope includes:

• Block header hashing (consensus path)
• Transaction IDs
• Merkle root construction
• Script and contract hash references
• All client-side contract state hashing and RGB anchoring (ensuring consistency across layers)

As a key optimization for a high-performance DAG-based blockchain, this proposal works in tandem with Taproot-only architecture (TSP-0001) to establish a minimalistic and efficient stack for Tondi.

---

🎯 Goals

• Establish a single high-performance hashing primitive across the protocol stack;
• Leverage BLAKE3’s SIMD parallelism and 128-bit security strength to maximize throughput;
• Reduce CPU overhead for full nodes and light clients, enabling mobile participation in validation;
• Provide strong guarantees for future smart contract state hashing and RGB anchor consistency.

---

🔧 Technical Details

1. Replacement Scope

BLAKE3 will be mandated across all protocol-critical hashing points, specifically:

• Block headers: consensus-critical block identifiers must use blake3(header_bytes);
• Transaction IDs: transaction identifiers (txid) are derived via blake3(tx_bytes);
• Merkle trees: all transaction and UTXO set commitments use BLAKE3 for internal node concatenation;
• Script references: script commitments, program code references, and contract IDs must adopt BLAKE3;
• RGB anchoring: client-side contract commitments and proofs must unify under BLAKE3 to guarantee cross-client consistency.

2. Parameter Specification

• Output length: 256 bits (default, truncated from BLAKE3’s extendable output function).

• Algorithm version: BLAKE3 v1.3 (aligned with the reference Rust implementation).

• Domain separation: all BLAKE3 calls must apply context-specific keys to prevent collision reuse. Example:

  blake3::derive_key("tondi.block.hash", header_bytes)
  blake3::derive_key("tondi.txid", tx_bytes)
  blake3::derive_key("tondi.contract.state", state_bytes)
  

---

⚠️ Security Analysis

• Security level: Although BLAKE3 targets a 128-bit preimage resistance level, its internal Merkle-tree structure and wide adoption in systems programming environments make it robust against all known attacks.
• Collision resistance: Adequate for all consensus and anchoring use cases; collision attacks are computationally infeasible under current cryptanalysis.
• Parallelism advantage: The Merkle-tree parallel construction allows multi-core systems (including GPU/SIMD acceleration) to compute block and state hashes significantly faster than SHA-256 or BLAKE2b.
• Rationale for exclusion of SHA-256: SHA-256, while battle-tested, lacks the throughput and parallelism required for a DAG high-frequency block environment.
• Fallback considerations: In the unlikely event of a cryptographic break, a new hash function may be introduced via soft fork with dual-hash transitional commitments (BLAKE3 + fallback).

---

📈 Performance Impact

• CPU efficiency: Benchmarks show BLAKE3 achieves ~3–5× the throughput of BLAKE2b/SHA-256 on modern CPUs.
• Verification cost: Transaction verification pipelines (including Merkle root computation and txid lookup) are expected to reduce CPU cycles per validation by ~50–70%.
• Client performance: Mobile and embedded devices benefit disproportionately due to SIMD optimization, lowering energy consumption for light validation.
• Network effects: Uniform hash adoption avoids multi-hash compatibility overhead and simplifies consensus-critical codebases.

---

📅 Implementation Plan

1. Genesis Activation:

   • BLAKE3 is defined as the only valid hash function at chain genesis (v0.1.0).
   • No compatibility with SHA-256 or BLAKE2b is provided.

2. Reference Implementation:

   • Rust reference library (blake3 crate, v1.3) adopted as canonical implementation.
   • C and Go bindings distributed for ecosystem developers.

3. Tooling Upgrade:

   • Wallet SDKs, block explorers, and node APIs must replace SHA-256/BLAKE2b with BLAKE3 before mainnet launch.
   • RPC endpoints must expose transaction IDs and block hashes strictly in BLAKE3 format.

4. Testing & Audit:

   • Formal verification of Merkle root consistency under BLAKE3.
   • Testnet migration path with enforced BLAKE3-only rule.
   • Security audit of domain separation usage to avoid cross-context collisions.

---

📝 Additional Notes

• Smart contracts (including RGB, Lexum, AMM, DAO) must use BLAKE3 for all state hashing.
• Wallets and explorers: must ensure users see BLAKE3-based txids and block hashes exclusively.
• RGB anchor proofs: validation must require BLAKE3 roots exclusively to prevent ambiguity.
• Cross-chain compatibility: If bridging to SHA-256-based chains (e.g., Bitcoin), translation layers must explicitly document that BLAKE3 → SHA-256 is a lossy mapping, not reversible.

---

If approved, TSP-0002 shall become part of the Tondi Genesis Protocol, alongside TSP-0001, establishing a Taproot-only, BLAKE3-based blockchain foundation.

---