Storage
Node
Interface
Protocol
Three-Layer Design
The chain acts strictly as the cryptographic source of truth. No actual file data touches the blockchain.
On-Chain State
L1 State TrieL1 Bridge
JSON-RPC InterfaceOff-Chain Mesh
P2P Storage NetworkClient to Network
From raw bytes to replicated, verifiable, content-addressed storage across a decentralized mesh.
Private files encrypted locally via XChaCha20-Poly1305. The key never leaves the client.
XChaCha20-Poly1305 AEADSplit into uniform 1 MB blocks. Each block hashed with BLAKE3 to create leaf nodes.
CHUNK_SIZE = 1_048_576 bytesBuild the binary Merkle tree. The resulting merkle_root becomes the file's absolute network identity.
blake3(left_32 || right_32)Broadcast TxPayload::AllocateStorage to Validators with merkle_root, access_list, and storage_fee_pool.
TxPayload variant index 18Push actual chunks to Storage Nodes via /sum/storage/v1 libp2p protocol with 3x combinatorial replication.
REPLICATION_FACTOR = 3Storage nodes use gossipsub to announce which chunks they have successfully acquired.
topic: /sum/storage/announceRust Internals
Four crates. Zero Python. 100% native Rust — compiled directly into the SUM Chain node binary.
sum-types
Core DefinitionsShared types compiled into the SUM Chain node binary. These are the off-chain counterparts to the L1's StorageMetadata.
Core storage primitives matching the L1 constants
Global configuration structs
JSON-RPC response deserialization types
Node capability advertisement
Proof of Retrievability
Every N blocks, validators challenge storage nodes. Pass = rewards from the fee pool. Fail = stake slashed. No exceptions.
verify_merkle_proof(chunk_hash, index, sibling_path, root)Mission Roadmap
Built ground-up by a core Rust blockchain engineering team without breaking consensus.
Phase 1: Cryptography & State Foundation
COMPLETEDWeeks 1-3- +NodeRegistry and StorageMetadata state types
- +BLAKE3 Merkle builder CLI/SDK (chunk, hash, tree)
- +TxPayload::AllocateStorage + RegisterStorageNode
- +Ed25519 L1 identity -> libp2p PeerId bridge
Phase 2: L1 RPC Bridge, ACL & PoR Responder
IN PROGRESSWeeks 4-8- >JSON-RPC client to L1 (reqwest) — 7 endpoints
- >Persistent ManifestIndex (merkle_root -> DataManifest)
- >bincode v1 mirror types for transaction signing
- >Background PoR challenge poll, proof gen, TX submit
- >ACL interceptor: PeerId -> L1 Address -> access_list check
- >PeerId-to-Address via libp2p identify protocol
Phase 3: Combinatorial P2P Mesh
COMPLETEDWeeks 9-12- +REPLICATION_FACTOR = 3 (L1 + off-chain)
- +blake3(root ++ chunk_index ++ replica) assignment with linear probing
- +L1 generate_challenge() targets assigned nodes only
- +storage_getActiveNodes() RPC endpoint
- +CBOR manifest exchange via serve.rs
- +MarketSyncWorker: poll L1, compute assignment, fetch missing
Phase 4: Scale-Out Upgrade
UPCOMINGFuture- -Reed-Solomon Erasure Coding replaces pure replication
- -Hash shards (data + parity) instead of raw chunks
- -On-chain metadata, ACL, and PoR unchanged
- -60-80% reduction in network storage overhead