E2ED: End-to-end decentralization (Part III)

Secure workflows (a.k.a. Smart Contracts)

(This is the third post of a series. First Post. Second Post.)

In the prior two posts of this series we have explained the concept of end-to-end decentralization and have provided a framework for reasoning about decentralization as a property of the computer system’s architecture rather than its social contract. A decentralized system, we posited, is a combination of a secure protection environment which eliminates or reduces the ability by the system’s operator to willy-nilly change the assurances of the system in-flight, and is one which implements some combination of the three orthogonal types of security guarantees: confidentiality, integrity, and availability. In this post we will look at smart contracts and the role they must play in E2ED systems.

A decentralized component receives requests from its user and carries out the action requested, provided the request is valid, and the user has all the necessarily permissions. Importantly, decentralized systems are, by definition, multi-user systems, as it would make no sense to architect private single-user applications in this way. Consequently, we must think of decentralized software as being able to carry out a sequence of requests from a number of users.

Traditionally, the logic of how multiple users interact under the functionality of a single application in the decentralized context is called a smart contract. We prefer to think of this less as a contract, a term implying some financial or legal underpinnings, and more as a workflow, a generic term which can apply to a much broader variety of use cases. We think of these workflows as necessarily secure workflows because in the decentralized context all workflows must operate under the security assurances of the overall system.

To understand this, let’s once again consider an example. We will look at non-custodial cryptocurrency wallets, a critical component of the Web3 stack. An example of such a wallet is Metamask, widely used to interact with the Ethereum blockchain. It might seem counterintuitive to speak of decentralizing Metamask, but in practice, as we will explain shortly, it is not at all wrong.

Metamask, as it stands today, is a component that does not fit our definition of decentralization, as it offers no protection from meddling by its operator (owner, in this case). But why should it, you ask? After all, the wallet holds my keys, why would it impose constraints on my behavior? Am I not the sole owner and operator, when it comes to my own cryptocurrency?

It turns out that even in the case of a wallet, speaking of architecting it in a decentralized way is meaningful. There are two reasons for this. First, if I, the owner, have unlimited access to the wallet and its contents, then so does a hacker or malware that takes control of my computer. This means that being hacked is not a risk I am able to mitigate. Second, my keys are only my keys while I am alive and well, and as long as I am a sovereign fully-functional person. In practice, if a user dies or becomes gravely ill, others (family) must be able to take control of the keys. But there currently is no simple mechanism to enable this.

Furthermore, what do you do in a situation where the key is owned by a group of people, such as a DAO or a fund? Metamask’s “centralized” architecture makes such an arrangement extremely difficult to achieve safely, because, while keys can be cloned across multiple wallets, one cannot control or record the actions different owners carry out, which may be dangerous if they ever become adversarial.

Decentralizing a wallet component, is, consequently, an important goal, albeit this would happen in a very different context to blockchain. Importantly, decentralizing a wallet necessarily requires inclusion of some secure workflow functionality. For example, to prevent malware from exfiltrating your keys, a part of the key must be placed on a secure server that would only release it after an independent confirmation of your identity (say, a second factor check). This imposes the need for a workflow between the two components, client and server, collaborating to sign a blockchain transaction.

To date, all attempts at doing this were focused on placing the smart contract functionality of such a wallet onto the chain itself, because this is the only context in which smart contracts exist. This, for example, is what happens when a group of people launch an Ethereum multisig. Similarly, software like the Argent wallet, which aims to improve the experience of key recovery, also uses Ethereum smart contracts to carry out the desired workflow.

Using on-chain smart contracts to implement front-end-centric secure workflows in the context of a wallet has significant drawbacks. First, different blockchains have distinct smart contract mechanisms, which makes it impossible to reuse smart contract code. Second, some blockchains may not have full-featured smart contracts, making this approach infeasible. Third, confidentiality considerations may dictate that wallet actions leak as little publicly observable data as possible. Consequently, we perceive a strong need to implement secure workflows in non-blockchain decentralized contexts, in this case — wallets. This would further enable the E2ED approach, to which this series of posts is dedicated.

To illustrate the idea of an off-chain smart contract, let’s consider a hybrid-custody version of Metamask, one in which a backend component (key server) keeps part of the key and uses it to allow transaction signing only after checking 1) second factor OTP from the user, and 2) that the transaction does not break OFAC sanctions (as per the stated need for regulatory enforcement). (Footnote: while some readers may cringe at #2, some users may, in fact, want this functionality, to ensure their own safety from interacting with sanctioned wallets by accident)

First, as we consider the secure protection environment of such a backend component, we quickly decide that a well-architected secure enclave process is sufficiently secure for this use case. Even if compromised, it still does not give the attacker enough to drain one’s cryptocurrency holdings. Second, we see that we need a way to implement a secure workflow taking place between the frontend (browser extension, say) and this key server.

I hope this simple example illustrates the key insight of this post — that secure workflows (a.k.a. smart contracts) are an essential part of end-to-end decentralization and that the blockchain environment is not the only environment in which such functionality must be present, but it is in fact relevant to all parts of the decentralized stack.

In the next post we will begin the discussion of the Adapt Framework and what it brings to the table in this context.