The previous article introduced the delta execution model, which in short maximizes the customizability of domains. We have not yet touched on the movement or interaction across domains, and we will here explore that topic.
We recall that both assets and users are global, meaning that they are visible to and can interact with any network participant, also outside of their current domain. The most direct consequence is that both assets and users can move between domains fully within the confines of the delta protocol, i.e. there is no dependency on an external third party (e.g. a bridge).
Importantly, the fungibility of assets across domains prevents unnecessary fragmentation. On the user side, their accounts can be used on any domain (even if they can only spend through a single domain at a time) — the account is a singular access point and a unified identity across the entirety of the network.
We touched on censorship resistance in the previous article, and here expand on it in the context of free movement of users between domains.
Each domain is free to choose how it processes its transactions, be that via some consensus-based network, a rotating set of nodes, or a single server in an AWS datacenter. A crucial aspect of permissionless networks such as delta is the true self-custody of each end user. If the domain is running a centralized executing node, can it not simply censor a user and thereby effectively freeze its funds? Yes and no.
Indeed, each domain is free to choose which transactions to process, and can censor users. However, this does not impact the user’s freedom to move to a different domain with all of its assets intact. Thanks to the global nature of user accounts and token balances, a user can talk to the base layer directly in order to move to a different domain, via a forced migration transaction. The validators receiving this transaction can independently verify its validity and accept the migration of the censored user’s account and associated token balances. Moreover, since domains can be spun up by anyone permissionlessly, the global censorship resistance of each user is secure. The exact mechanism that enables this without making possible double-spends is slightly complicated and beyond the scope of this article.
In short, delta does not make any guarantees with respect to local censorship resistance. And from the perspective of the developer/operator, the ability to censor can be viewed as one of the benefits of running a domain. That being said, a delta user will always remain globally free to access and move its funds.
Recall that a user transaction is final only when the SDL in which it was included has a corresponding proof which is successfully verified. In fact, if the proven SDL depends on another domain’s not-yet-proven SDL, e.g. it builds on a state resulting from incoming transfer transactions which have not yet been proven, it cannot yet be considered final. A domain which bases its state on unproven SDLs is at risk of its SDLs being reverted if those dependencies are not proven in time. A domain which wants zero reliance on other domains would therefore only apply their external SDL updates (e.g. inbound transfers) to its internal state once they have been fully proven, which naturally adds latency and limits the level of interoperability between this and other domains.
A domain can nevertheless choose to build on unproven SDLs from specific domains, allowing for near-instant composability between the domains. This would likely be the case for domains which have a formal collaboration, for example, where they have reason to trust each other.
Atomic composability refers to the case where two or more domains act as one, and a single transaction spends from multiple different domains. From the perspective of the delta protocol, this will be made possible by having SDLs which are signed and originate from all the affected domains, whereby they have all agreed on the input and output states. We note that while atomic composability is on the delta roadmap, it will likely not be a feature at the time of launch.
The properties we have described in this article define what we refer to as an opt-in empire: Any domain can be centrally run, and users are always free to opt out — to vote with their feet, as it were. Domains are better viewed as highly opinionated actors than as autonomous machines, which is a strong distinction between delta and smart contract-based systems. We do of course note that domains can be less opinionated, as they can choose to run generalized smart contract VMs and/or operate with a decentralized node set. Fitting with the actor model, domains can decide which other domains to rely on and integrate with, with the base case allowing them to be unaffected by any mistakes made by other domains.
The opt-in empires model and the delta execution environment as laid out in the previous article, provide the domain with the freedom to design and run its business exactly as it wants to, whilst retaining the user’s freedom to choose.
