E2ED: End-to-end Decentralization, Part V

The Technology Stack from First Principles

This is the next post in a series. Please see part I, part II, part III, part IV for further background.

The reason why web3 in it’s current form fails to achieve or even support end-to-end decentralization is, in part, a consequence of the fact that blockchain places the consensus model (global eventually-consistent Byzantine-proof data synchronization) lower in the stack than the smart contract layer.

Bitcoin and all subsequent layer 1 systems provide an implicit answer to the question of what is the most important aspect of decentralization. Their answer is “global consensus”. You observe this repeatedly when reading initial white papers for systems such as Avalanche and Algorand, as those papers leave out the question of the smart contracts almost entirely out of scope, focusing instead on the mechanism for Byzantine fault tolerance, as if the innovation in how that mechanism works provides the very reason for the system’s need to exist. If the smart contract question is considered at all at the early stages of system design, it is without detail and is generally seen as a secondary aspect of the architecture.

The question of relative importance of the smart contract mechanism versus the consensus algorithm is a nuanced one. What we are really asking is whether the smart contract layer builds upon the consensus layer or, conversely, whether the consensus layer builds upon the smart contract layer, or, are they entirely independent and completely orthogonal to each other. So far, in existing layer one ecosystems, the answer is obviously “smart contract layer builds upon the consensus layer”, so the consensus layer is seen as primary, while the smart contract layer is seen as secondary. We see this in the way that a single consensus layer in multi-network ecosystems such as Cosmos and PolkaDot can host multiple different smart contract systems.

We believe that this discussion is of paramount importance, and that we must re-examine this question from first principles urgently. The key problem with the current answer is that if a smart contract layer may assume the existence of a consensus layer, then this limits the programmability of the decentralized system to the very back of the application’s backend, because that is the part of the system that requires and relies on global consensus. The smart contract layer, is, in other words, relegated to the database layer of the three-layered frontend-backend-database architecture of the web application.

But this is far from the only area in which smart contracts are important! We have already shown in the prior posts that smart contracts are equally as important on the front-end as they are on the back-end of the system. As an example of this, lacking a front-end smart contract mechanism, multi-device wallets such as Argent and Gnosis Safe are forced to rely on the back-end-level smart contracts, making them costly to port to other chains.

But wallets are not the only example where this matters. In a non-financial decentralized application, such as in a self-custody document sharing system (KeyBase has some such features, for example), there still is a valid need for smart contracts. For document sharing it is very easy to imagine a number of workflows they would implement, for example: 1) revoke access to this document in 5 days; 2) permit further sharing with up to 5 people; 3) User X gets access to document A from user Y if and only if user Y gets access to document B from user X; and so on.

The ADAPT framework takes this exact approach, flipping the technology stack to make the smart contract model the core part of the system, and then stacking the specific decentralization mechanism on top of that. If the decentralization mechanism is global consensus, then you get a blockchain just as before, but if the decentralization and remote trust is achieved through other means, for example, by using TEEs or Zero-Knowledge proofs, that’s fine too. This way we enable decentralization at all layers of the technology stack and lay the groundwork for interoperability not only within a specific decentralized network, such as Ethereum, but also between different networks, even if they use different approaches to security.