Building on cryptographic primitives such as zero-knowledge proofs, a state model based on conflict-resistant, commutative data structures, and a new approach to permissionless consensus, the goal of delta is not merely to provide scalable decentralized computation, but to make possible entirely new classes of applications.
This series will consist of eight articles, each exploring some part of the tech underlying the Delta network.
In this very first article, we will provide a very high-level overview to the individual technical components and how they all fit together.
delta consists of a set of domains which are connected through a validator set. The validators maintain shared state, including assets and accounts on all domains. The domains make up the delta execution environment, and the vast majority of end users only interact with domains, not with the validators directly. Deploying a domain is permissionless. The combination of shared state and permissionlessness provides self-custodying users with censorship resistance:
Therefore, any user on any domain can move to a given domain without requiring permission from the operator of their current domain.
The validators receive the state changes computed by the domains, disseminate them among each other, and apply the changes upon verifying their corresponding proofs (more on this later).
Core to the design of delta is the asymmetry between spending and receiving, or crediting and debiting accounts. An account can only be debited by its associated domain, i.e. it can only spend its assets through that domain. Accounts can switch domains without bridging, and even without going through its current domain. An account can, however, receive assets from any other domain.
After receiving, ordering, and executing a set of user transactions, domains submit a list of these state changes to validators on the base layer. We refer to these as State Diff Lists, or SDLs, and they consist of three columns:
The SDL reaches settlement upon verification of its associated proof.
Another important consideration around the design of delta and all of its components regards what data and which rules ought to be global (valid for all domains) as opposed to local (valid within a given domain).
As we have seen, accounts are global, and this enables the frictionless movement of users and assets across domains. Moreover, assets themselves are global: there will be a single USDC implementation across domains; assets and liquidity are in this sense unified across all domains.
Additionally, all execution on all domains needs to adhere to a set of global laws. One such law is, as mentioned above, that only accounts associated to a given domain can spend through that domain. Many global laws are asset-specific — since assets are global, their rules hold identically across all domains. These laws allow for the network to be permissionless for both users and domains, without enabling potentially malicious participants to do any harm to the network. For every SDL a given domain submits, it must also provide a zero-knowledge proof that the SDL does not contradict the global laws.
Execution is local, as enabled by zero-knowledge proofs. These allow a single node to compute the result (SDL) of some ordered list of transactions (and a proof) and simply send this result to the validators, the latter verifying the validity of the result based on the corresponding proof.
The purpose of the global laws is not to ensure the full security of the user — this would be possible only if they proved the validity of some deterministic execution path, which would again limit the base layer’s ability to support any execution model. Since the network only requires execution to adhere to a relative few global laws, the set of execution models permitted by the network is close to unbounded.
A domain which wants to give users additional guarantees about transaction execution does so by (globally) stating additional local laws, which it therefore must adhere to. The strongest such law would be proving the full execution path, e.g. a zk-EVM or zk-MoveVM. In this case, the domain’s SDLs need to be accompanied by an additional proof corresponding to the local laws, otherwise settlement will not be achieved.
In short, the minimality of the global laws allows for a multitude of trust models, ranging from the maximally trustless (relying on cryptography alone) to the trusted, where the execution node is not constrained at all with respect to how it spends the funds which the user has given it permission to spend — this latter version is more similar to Tradfi or Web2, where legal and reputational factors form the basis of the user’s willingness to engage with products. Note that even in the latter case, each user has custody over their own assets and can freely move to other domains, and so their downside is bounded.
Validators can verify the correctness of an SDL only in the presence of a corresponding proof. Therefore, unless the domain submits the proof at the same time as the SDL, settlement and finality take place some time after submission of the SDL to the network. We have not yet decided whether to enforce the simultaneous submission of SDL and proof — this will be dependent on the prover time. With the current trend we’re seeing of latency decreasing rapidly, we will likely enforce same-time proving.
We refer to our settlement approach as zk settlement, and it’s a key enabler of delta’s heterogenous execution environments within the global state machine. With zk settlement, validators do not need access to the domains’ execution models, as they simply verify proofs of the global laws (and local laws if provided by domain).
SDLs contain information about the state they executed their transaction list against. Specifically, they refer to all local state changes applied from incoming SDLs of other domains since the last SDL they output (SDLs from the same domain are naturally ordered by the domain). We recall that the domain’s accounts can only be credited by SDLs from other domains, and so applying these SDLs only enables transactions which would otherwise not be possible on that domain; they cannot invalidate otherwise valid transactions.
Once submitted to a validator by the domain, an SDL gets disseminated through the validator set efficiently using Byzantine Reliable Broadcast (similar to Narwhal). Validators then produce a quorum certificate confirming the network’s acceptance of the SDL.
We recall from the previous section that there is an asymmetry between spending and receiving, and as it turns out, this property implies that no total ordering of SDLs is necessary, i.e. the validators do not need to reach classical Byzantine agreement on the SDLs. The SDLs themselves contain all necessary ordering data. The protocol disseminating them can therefore run in parallel for each SDL, with no need of sequentializing (read: bottlenecking) the data passing through the network. In short, they do not need to be organized into blocks and go through traditional consensus.
Periodically, the validators run a weaker synchronization protocol to reconfigure the validator set, which explicitly mainly looks like reaching agreement on epoch boundary points, at which the synchronization takes place. Since this protocol also does not involve ordering, the communication overhead on the validators is a mere fraction a traditional consensus protocol's overhead.
For the reasons laid out above, delta’s subprotocols are fully leaderless. This makes the network very robust to malicious nodes, and also drastically simplifies the protocol by removing edge cases. Finally, technically speaking, delta does not have consensus at all — in neither of the protocols laid out above do the participants order any data, whereby they are essentially little more than slightly fancy broadcast protocols.
We have here provided a high-level introduction to the delta protocol. In the coming weeks, we will dive deeper into the protocol and its individual components.
