Recall that delta is a network of domains, each of which can host one or more services and applications. For the network to be seamless it is necessary that these domains comply with certain standards. On the other hand, a network which is very opinionated about the exact properties its participants are allowed to possess will by its nature restrict their expressivity and thereby lead to homogeneity, like the bouncer at Berghain. This article will take a look at the computing environment enabled by delta.
At the core of the design philosophy underlying delta lies a strong delineation between global and local features of the network. As mentioned in the previous article, for example, user accounts are global. This means that every user on every domain can access and interact with any other user or any other domain within delta, as these are all globally known (i.e. also to the domain the user currently finds itself on). Moreover, network features such as data propagation and settlement need to be global, as they transmit information about the users.
On the other hand, execution is local—each domain continuously collects user transactions, periodically orders them into lists which they then execute to produce a state diff list (SDL), and submits this SDL to the base layer.
With execution taking place locally on a domain, only the operator of that domain needs to process its user transactions.
This is secure thanks to a class of cryptographic proofs called SNARKs (Succinct Non-Interactive Argument of Knowledge). In simple terms, a SNARK consists of two algorithms: a prover and a verifier. The domain prover takes in an ordered list of transactions 𝜔; and a list of state diffs, SDL, and outputs a proof 𝝅. The delta verifier is global, unlike the prover, meaning that it lives as part of the validators. It takes in SDL and 𝝅, returning true if and only if (with overwhelming probability) SDL was the result of correctly executing the list of transactions 𝜔. Note in particular that the verifier does not require access to the transaction data 𝜔 in order to verify its validity.
SNARKs enable us to prove the validity of a transaction or of a list of transactions, but what does it mean for a transaction to be valid? Within the context of delta, this does not refer to the entire execution path being proven, i.e. running the execution in some zkVM or custom program.
On the contrary, domains have an immense level of flexibility in choosing their programming environments. Rather than locking them all in to one and the same execution model, delta merely defines a set of global laws that need to be proven for every transaction on any domain.
This set is minimal and the associated proofs are extremely lightweight compared to full execution proofs. Its sole purpose is to provide a baseline of security guarantees and maximum flexibility for domains to build on top of. Examples include:
Moreover, assets themselves are global in the same way that end users are and can therefore define more granular rules which are also to be followed for any transaction on any domain which includes that asset type.
The global laws allow for the permissionless deployment of new domains without putting existing domains at risk of being harmed by a malicious domain: they make it impossible to double-spend, mint arbitrary tokens, or steal assets from a user. Therefore, the global laws form the minimal trust basis required for safe interoperability between domains.
In addition to the minimal set of global laws to be followed by everyone, domains can declare and commit to local laws, which then also have to be complied with by that domain. As an example, any domain that wants to run a zkEVM can add the corresponding proof verifier to its (globally viewable) state, such that its SDLs will not be accepted by the network unless the proof of the full EVM execution returns true. Similarly, a domain can add the verifier for a custom program or a set of custom programs, thereby guaranteeing to the user that it follows a publicly known execution path.
With the analogy of the global laws forming a bedrock, each domain can build on top of this solid foundation using their own construction techniques and materials. The goal is to maximize each domain’s expressivity and let these design choices serve as an axis of competition. For delta as a whole, this is equivalent to maximizing the heterogeneity of the network, enabling the highest degree of market-driven innovation.
While strong local laws offer the user cryptographically enforced security guarantees, a well-known company might instead rely on its reputation and/or legal prerogatives, such that users do not mind trusting it. Ultimately, the existence or absence of additional local validity laws for each domain is all transparent information. There is no uninformed, blind trust on the side of the end users.
We have seen that global laws exist to respect the delta state model, assets, and accounts, and make it cryptographically impossible for domains to break the system. On the other hand, local laws are chosen by the domains in order to give their users certain assurances.
What about censorship resistance (CR)? In delta, CR is a global feature: domains are free to gatekeep based on NFT holders, citizenship, or vibes. Users therefore do not have local CR. The global CR of users derives from two system features:
In this way, delta preserves CR and global openness, while still allowing for domains to be opinionated in near-arbitrary ways.
Similarly, liveness cannot be guaranteed locally, but is preserved by the system as a whole.
