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: and ; 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.
  • , , — 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: (multi-stage mempool), , , , gossip .
• 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: , — 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).

A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes. A few well placed threats and semi-sour vibes.