Status: CLOSED
Date: December 2025
Phase 1 delivered the foundational blockchain primitives required for a single-node, manually-driven chain:
- Block and transaction data structures
- Account model with balance and nonce
- Transaction validation and execution
- Persistent storage with RocksDB
- Deterministic serialization (SCALE) and hashing (BLAKE3)
- RPC and REST API endpoints
The execution engine applies transactions to account state in order. For each transaction:
- Validate signature
- Check nonce matches account nonce
- Check balance sufficient for transfer amount
- Apply state transitions atomically
- Increment sender nonce
Transfer transactions move balance from sender to receiver. Stake and ComputeTask types are structurally supported; execution logic is simplified for Phase 1.
Each account is identified by a 32-byte address (Ed25519 public key). State includes:
- balance: Non-negative integer (base units)
- nonce: Monotonically increasing, used for replay protection
Validator accounts may have additional validator_data (stake, active status). Non-validator accounts have validator_data: null.
- Structural: Valid SCALE decode, required fields present
- Signature: Ed25519 verification over signing payload (tx_type, sender, receiver, amount, nonce)
- Nonce: Must equal account nonce
- Balance: Sender balance must be >= amount for transfers
- Replay: Transaction hash must not exist in storage (included at most once)
Invalid transactions are rejected before execution.
- Blocks: Keyed by height and hash. Header and body stored.
- Transactions: Indexed by hash. Links to block height.
- Accounts: Keyed by address. Balance and nonce.
Column families separate blocks, transactions, and accounts. All writes use write_batch for atomicity.
Phase 1 does not include automated block production. A block producer (orchestrator) must:
- Collect transactions from mempool (or direct submission)
- Build block template with valid transactions
- Execute transactions to compute state root
- Sign block header
- Submit via
produce_blockRPC
No consensus protocol. Single producer assumed.
- Serialization: SCALE (parity-scale-codec) for all on-chain data
- Hashing: BLAKE3 for transaction roots, block hashes, state roots
- Signing payload: SCALE-encoded (tx_type, sender, receiver, amount, nonce)
Determinism is required for reproducible state roots and cross-node verification.
All state changes from a block are applied in a single RocksDB WriteBatch. Either all writes succeed or none do. No partial state after a block.
submit_transaction accepts a signed transaction and enqueues it for inclusion. If the same transaction (by hash) is submitted again, it is deduplicated. No double-enqueue. Returns existing tx hash if already present.
RPC (JSON-RPC 2.0 over HTTP POST /rpc):
submit_transaction— Enqueue signed transactionproduce_block— Build and persist block from mempoolget_block_height— Latest finalized heightping— Liveness check
REST:
GET /blocks— List recent blocksGET /blocks/{hash}— Block by hashGET /transactions/{hash}— Transaction by hashGET /accounts/{address}— Account stateGET /validators— Validator set
106 tests across mbongo-core, mbongo-network, mbongo-api, and integration suites.
Phase 1 does not include:
- Consensus protocol (multi-validator agreement)
- P2P block propagation
- Mempool with eviction policy
- Fork choice rules
- Timed block production
- Gas metering
- Smart contracts
Phase 1 is CLOSED.
No further Phase 1 scope changes. The foundation is frozen. Phase 2 development targets tooling, mempool, timed production, and P2P propagation.