The ZILLIQA Technical Whitepaper

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.