XMBL Testnet

- XMBL uses a novel "Cubic Ledger Technology" (XCLT) to organize transactions into atomic 3D structures (blocks → faces → cubes → recursive higher-level cubes) for parallel, scalable processing. - Cryptography is MAYO post-quantum signatures (XID) implemented as a WASM wrapper. - Consensus uses a “user-as-validator” model (XPC) with a multi-stage mempool and lightweight leader rotation. - State management is a Verkle-tree based Virtual State Machine (XVSM) with WASM execution. - Storage/compute (XSC) provide sharded P2P erasure-coded storage and WASM compute. - Networking is libp2p + WebTorrent gossip (XN). Simulator (XSIM) stitches modules for E2E testing; CLI and GUI tooling wrap operations. Core architecture and module mapping - Core bootstrap & orchestration: index.js - Public API / module design: api.md Identity & crypto (XID) - Quantum-safe identities and signatures implemented with a WASM wrapper around MAYO C. - Primary API: [`Identity`](xid/src/identity.js) and [`MAYOWasm`](xid/src/wasm-wrapper.js); exported at index.js. - Key manager, batch signing, verification helpers available; integration notes: instructions.md. - Role: sign transactions, validate signatures in consensus and ledger additions. - Evidence: WASM wrapper code and constants (public/private/signature sizes) in wasm-wrapper.js. Networking (XN) - P2P networking and gossip built on libp2p + WebTorrent; responsible for peer discovery, pubsub for transactions/blocks, and shard requests. - Node implementation & APIs: node.js, integration/instructions: instructions.md and readme.md. - Role: propagate transactions and blocks across peers, used by xpc and xclt for dissemination. Cubic Ledger Technology (XCLT) — the geometric ledger - Core exports: index.js. - Key classes and files: - `Ledger` — persistent LevelDB ledger state and event emitter. - `Block` — block creation, fromTransaction, hashing, serialization. - [`Face`](xclt/src/face.js), [`Cube`](xclt/src/cube.js), [`SuperCube`](xclt/src/super-cube.js) — 3×3 face grids, cubes composed of faces, recursive super-cube formation. - Placement & deterministic ordering: placement.js. - Geometric coordinates, vectors, fractal addressing: geometry.js. - Digital root helpers: digital-root.js. - Block lifecycle: 1. Transaction → Block (hashing & ID). 2. Hash/digital root / deterministic placement into face positions (3×3). 3. Faces (9 blocks) complete → form cubes (3 faces per cube, sorted by hash). 4. Cubes form higher-level faces/cubes recursively (parallel cube construction supports conflicts by timestamp). - Coordinates & fractal addressing: - Atomic cube = 3×3×3 = 27 blocks per cube. - Growth is hierarchical: a level-L cube has side length 3^L. For block counts: $$ \text{blocks\_in\_cube}(L)=3^{3L} $$ - Implementation and coordinate APIs are in geometry.js; ledger returns coordinates vectors on add (see tests in xclt/__tests__/ledger.test.js). - Events: block:added, face:complete, cube:complete, supercube:complete (see docs/api.md). Peer Consensus Layer (XPC) - Exports & components: index.js. - Primary logic: [`ConsensusWorkflow`](xpc/src/workflow.js) (multi-stage mempool), [`LeaderElection`](xpc/src/leader-election.js), [`Mempool`](xpc/src/mempool.js), [`ValidationTaskManager`](xpc/src/validation-tasks.js), gossip [`ConsensusGossip`](xpc/src/gossip.js). - Key features: - Five mempool stages: raw_tx → validation_tasks → locked_utxo → processing_tx → tx. - User-as-validator model: transaction users participate in validations; default required validations = 3. - Timestamp averaging across validators determines ordering & conflict resolution when needed; finalization moves tx to ledger. - Integration with XID for signature verification and XN for gossip. State machine and verifiable state (XVSM) - Exports & components: index.js. - Core: `VerkleStateTree` — path-based compressed commitments supporting proofs. - State diffs, WASM execution engine, sharding and assembly components ([xvsm/src/*.js]). - Role: - Process state_diff transactions from ledger. - Maintain scalable/verifiable state using Verkle trees and shard/assembly for parallelization. - Execute WASM code under resource limits using the WASMExecutor. Storage & Compute (XSC) - Purpose: P2P redundant storage with erasure coding and WASM compute runtime. - Key classes described in docs/status: StorageShard, StorageNode, ComputeRuntime; file-level APIs mentioned in instructions.md and status.md. - Features: - Sharding with k data shards + m parity shards (erasure / XOR-like encoding), reconstruction. - LevelDB-backed StorageNode, resource-aware compute via WASM runtime. - Integration with XPC for payments; storage purchases recorded to ledger (xclt). CLI & tooling (XCLI) - CLI wraps all modules for local chain running, chain management, and command automation. - LocalChain runner & commands: chain.js. - CLI docs and behavior: readme.md and status.md. - Role: developer tooling, local chain management, end-to-end tests use CLI. Simulator (XSIM) - Full-system simulator to stitch modules and validate integration sequences. - Main simulator: `SystemSimulator`. - Sim integrates xid, xn, xpc, xclt, xvsm, xsc where available and falls back to simulation otherwise. - Used to stress-test mempool, validation, ledger formation, state assembly, storage/compute flows. Design patterns & integration - Event-driven, modular design: modules communicate via EventEmitter events (docs/api.md, examples in instructions.md). - Persistence: LevelDB used across ledger and mempools. - Testing & CI: Extensive unit, integration and E2E tests—status files show high pass rates (e.g., XCLT: status.md; XPC: status.md; XVSM: status.md). - Simulator as a ground truth: status.md and simulator.js demonstrate module interactions. Consensus vs Finality in XMBL - Consensus workflow enforces validations and finalization via XPC; final inclusion in XCLT ledger occurs after consensus finalization. - Ledger finality in cubic structures is hierarchical: finality strengthens as higher-level cubes form and finalize; encrypted coordinate delivery is planned for private mapping to users (see xclt/instructions.md). Scalability & parallelism - Natural parallelism: 3×3×3 geometry and recursive growth allow parallel face/cube formation and independent processing across cube partitions. - State sharding in XVSM and storage sharding in XSC complement ledger parallelism for end-to-end scaling (targets: 1k+ TPS). - Deterministic placement via hash sorting combined with timestamp tie-breakers supports scalable, parallel block placement. Security and cryptography - Post-quantum signatures (MAYO) by default; WASM-backed and fully tested: instructions.md and wasm-wrapper.js. - Verkle-based state commitments provide compact proofs against state manipulations. Known gaps & next steps (as tracked) - Phase 1 repo maintenance (workspaces, lint, CI) needs completion per status.md. - Additional higher-level cube growth/performance benchmarks; secure encrypted delivery for final coordinates in XSC (not yet implemented). - Continuous performance optimization required for real-world production scale. Representative code & docs to inspect quickly - XCLT ledger core: `Ledger` — ledger.js - XCLT block model: `Block` — block.js - XPC consensus workflow: `ConsensusWorkflow` — workflow.js - XID core: [`Identity`](xid/src/identity.js), [`MAYOWasm`](xid/src/wasm-wrapper.js) — index.js - XVSM Verkle tree: `VerkleStateTree` — verkle-tree.js - Simulator: `SystemSimulator` — simulator.js - Core integration file: index.js - API overview: api.md - Project-wide status and testing summary: status.md Conclusion - The project is modular and well-tested across each core piece (crypto, network, ledger, consensus, state, storage/compute). - The Cubic Ledger offers an explicit design for parallelization that is coherently integrated across modules. - Remaining work focuses on infra (CI, lint), higher-level cube/performance engineering, and some feature completeness (encrypted coordinate delivery). - For implementation deep dives, start with the module entry points linked above (e.g., ledger.js, workflow.js, wasm-wrapper.js, verkle-tree.js).

XMBL Testnet

Demo

About

How it's made