Sparse Merkle Tree
Ayrıca şöyle anılır SMT, Jellyfish Merkle Tree
What it is. A plain Merkle tree (see that entry) only has leaves for the data you actually put in it. A Sparse Merkle Tree instead reserves a leaf position for every possible key, for a 256-bit key space, that's 2^256 positions, and the overwhelming majority of them hold a defined "empty" value rather than nothing. This sounds wasteful, but it isn't built that way in practice: the empty subtrees all hash to the same well-known values, so they never need to be stored, only referenced.
What that buys you is non-membership proofs. With a plain Merkle tree you can prove "X is in this set," but proving "Y is not in this set" requires seeing the whole set. With a Sparse Merkle Tree, "Y is not in this set" is just another inclusion proof: you're proving that Y's reserved position holds the empty value, using exactly the same short proof shape as a membership proof. That property matters for anything that needs fast, cheap "is this revoked / does this exist / is this key taken" answers, which is most of what a blockchain's account and identity state actually needs.
Who built it. The general sparse-tree idea had been used in certificate-transparency and academic cryptography for a while before it was popularized in production systems. The specific compact, height-optimized variant most current chains use, often called a "Jellyfish Merkle Tree", was designed and published by Meta's Diem (formerly Libra) blockchain project, and continued afterward by Aptos Labs when that team spun out. Solidus runs this open design; it did not design the data structure itself.
How Solidus uses it. This is testnet-grade and unaudited. Solidus's whole chain state, accounts, DIDs, credentials, validators, lives in one Jellyfish-style Sparse Merkle Tree over 256-bit BLAKE3 hashes, namespaced into four logical sub-trees under a single global root that gets embedded in every block header. That's not a design sketch, it's what the running testnet actually stores today. What is not live yet is the sharded version some architecture documents describe (splitting the tree across 32 independent shards for parallel writes): that remains roadmap work.
Check it yourself. The tree implementation lives in the public repository, crates/solidus-state at github.com/solidusnetwork/protocol, read the code rather than a diagram to confirm which version is actually running.
Nereden geliyor
Bunu başkası belirtti. Solidus bir araya getiriyor.
A Sparse Merkle Tree (SMT) generalizes the plain Merkle tree (see that entry) to cover an entire fixed key space, for a 256-bit hash, that's 2^256 possible keys, nearly all of them empty by default. That lets it prove non-membership ("this key does not exist") as cheaply as membership. The general SMT idea circulated in cryptography and certificate-transparency circles for years; the specific compact, proof-efficient variant Solidus runs, a "Jellyfish"-style SMT, was designed and published by Meta's Diem/Libra project and carried forward by Aptos Labs. Solidus's contribution is choosing this open design and implementing it in Rust, not inventing it.
Bunu nasıl doğrularsınız
Test ağında çalışıyor. Ana ağda değil.
Read the state crate directly in the public github.com/solidusnetwork/protocol repository (crates/solidus-state). The single global SMT, namespaced into account/DID/credential/validator sub-trees under one root embedded in every block header, is there in the code, not just in a diagram.