LibraryConsensus2017Design paperCorpus record
The ZILLIQA Technical Whitepaper
Zilliqa. The Zilliqa Team.
A 2017 design for a sharded chain: a directory service that assigns nodes, shards that process transactions in parallel, and a language proposal aimed at safe-by-construction contracts.
Zilliqa splits the network into shards that process transactions in parallel, and it uses a smaller committee to order the shards' results so the pieces form one chain.
The five-minute read
Sharding is the throughput idea
If every node executes every transaction, the network is as slow as one honest node. Shards execute different sets at once. The paper's claim is that this can be done without letting a shard be captured quietly.
Proof of work is for identity, not for every block
A node performs work to join and to be assigned to a shard. That work is a sybil ticket. Day-to-day blocks inside a shard are produced by a classical Byzantine protocol, not by more hashing.
A directory committee coordinates
Someone has to assign nodes to shards, publish the shard results, and handle transactions that touch more than one shard. The paper gives this job to a committee elected from the same identity mechanism.
The smart-contract language is dataflow
Scilla, described around this design, is a language in which effects are explicit so a shard can tell what a call will touch. A general-purpose language that can touch anything does not shard cleanly.
Cross-shard is the bill
Parallelism is easy when transactions do not share state. The paper has to specify what happens when they do. That path, not the in-shard path, is where latency returns.
One action, walked through
- A node solves a proof of work and presents it as a right to join the current epoch's committee structure.
- The directory service assigns the node to a shard, using the work as randomness so the node cannot cheaply choose its neighbours.
- Users send transactions to the shard that holds the relevant state.
- The shard runs a Byzantine agreement on a block of those transactions and submits the result upward.
- The directory committee orders shard blocks into a final chain and processes transactions that the paper marks as cross-shard.
The argument, unpacked
Random assignment is the security argument
A shard of a few hundred nodes is safe only if the attacker cannot choose to sit in it. The proof-of-work identity plus assignment is what makes capture require a large fraction of all identities, not a large fraction of one small group. A shard that people can pick is a small permissioned chain with extra steps.
Classical consensus inside the shard is a choice
Once the set is small and known, a protocol like PBFT can finalise quickly. The paper is a hybrid on purpose. Calling the whole system proof of work because join-tickets use hashes misstates where blocks come from.
Dataflow is how the shard knows what it is allowed to ignore
If a contract can read arbitrary state, every shard needs every state. The language restriction is not a style preference. It is the condition under which parallel execution is correct.
What has to be true
- Enough nodes join that each shard is large enough for its Byzantine assumption.
- The directory committee itself is not captured. It is a shard-sized target with a global job.
- Most transactions are written so their state footprint is visible in advance.
- Cross-shard finality is actually implemented, not left as a future optimisation.
What happened after the paper
Zilliqa launched with this hybrid and later revised its roadmap toward a different architecture. Scilla remained a distinctive artefact. A current status page is not the white paper, and the white paper's sharding math should not be cited as a measurement of today's throughput.
What to check before you use the idea
- Can a node influence which shard it joins?
- How large is a shard, and what fraction of the whole network must an attacker control to capture one?
- Which transactions are allowed to touch more than one shard, and what is their latency?
- Does the contract language make state access explicit?
Terms
- Shard
- A subset of nodes that executes its own transactions and agrees internally.
- Directory service
- The committee that assigns nodes, collects shard results, and handles cross-shard work.
- Join proof of work
- Hashing used to buy an identity for an epoch, not to propose every block.
- Dataflow contract
- A programme whose effects are declared, so a scheduler can see what else it might conflict with.
The problem the paper names
A single committee that re-executes every transaction has a ceiling. Zilliqa's paper treats sharding as the way through that ceiling, and treats the assignment of nodes to shards as the security problem, not a configuration file.
What the design proposes
- Proof-of-work is used to identify nodes and resist Sybils, not as the final ordering of every payment.
- A directory committee coordinates shard membership. Shards run a BFT protocol on their own transaction set.
- Cross-shard effects are the hard part, and the paper's transaction model is shaped to limit them.
How the mechanism is specified
- A node proves it did work to join. The directory then places it so an attacker cannot fill a shard cheaply.
- Finality inside a shard follows the BFT vote, not the heaviest proof-of-work chain.
- The smart-contract section argues for a language that makes certain effects explicit. It is a proposal, not a guarantee about later scilla deployments.
What this page does not treat as proven
- Shard counts and measured throughput in a white paper are not a current benchmark.
- Directory-service security dominates. If that layer is small, the shards do not add the security people infer.
- The paper does not describe Zilliqa's later product history.
Why a venture studio still reads it
Sharding proposals still show up in venture pitches as a multiple on throughput. Zilliqa is the reminder to ask who assigns the shards and what a cross-shard call is allowed to do.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.