E2ED: end-to-end decentralization (Part IV)
Introducing the ADAPT Framework
This is Part 4 of the series of posts (Post I, Post II, Post III) that introduce end-to-end decentralization. In prior posts we have examined the concept of E2ED and described the need for secure workflows (smart contracts) in the context of non-blockchain components of the software stack. This post introduces ADAPT Framework as a secure workflow and data management platform that enables E2ED architectures and builds on these insights.
ADAPT is a framework built on the concept of programmable secure data containers. A data container is a singular node that exposes a request-response API of transactions. Each container, in other words, is a host for some data and a set of secure workflow endpoints that establish the process of observing and modifying the data. The assumption is that the containers will be placed in some form of a secure environment that prevent circumventing the container endpoints, establishing each container as a decentralized component by our definition.
Containers can communicate with each other. In response to a request, a container may send subsequent requests to others. This process allows developers to build cohesive networks of data containers that jointly perform the function necessary for the given use case.
As part of the communication protocol between containers, each reports the information identifying the environment in which it operates. For example, a container running within a secure enclave will attach the enclave’s attestation document to the handshake message, allowing the recipient of the request to independently confirm the degree of its security for the purpose of deciding whether it is safe to respond.
Let’s contextualize this architecture with an example. Consider the architecture of a decentralized non-custodial wallet, in which the individual blockchain key is broken up between the user’s frontend and a backend secure enclave component which performs additional checks on the request and the transaction in order to a) verify additional authentication factors; and b) to confirm the transaction as safe against a list of actions that could be dangerous (phishing) or forbidden by regulators (sanctioned). This is depicted in Figure 1.
So what makes ADAPT special? First, the platform radically decouples workflow logic from the environment which hosts the container. It ensures that code can be reused between environments without the context-dependent fragility of, say, Javascript. Second, it establishes standard and easy-to-use protocols to use available secure environments and confirm the necessary security information to other nodes in the network. So, in this example, the verification of the enclave’s attestation document is performed by the framework, which sharply reduces the cognitive burden on developers. Third, containers establish a process to upgrade their code, ensuring that decentralized software may evolve as appropriate over its lifetime.
The example of a hybrid wallet application illustrates how ADAPT can be used for any decentralized application that hosts critical data on behalf of users. A similar architecture can be used in authentication applications as well as to store identity, KYC, or medical data. The second example in this post pertains to an even simpler use case, which further illustrates the need for decentralization even in the context of single-component architectures.
Consider an implementation of a centralized cryptocurrency exchange built using Web2 (SaaS) tools. Somewhere inside the exchange’s backend service lives a database that contains the entire list of keys for hot wallets controlled by the exchange. Access to a hot wallet by the exchange’s backend typically works like this: 1) the backend requests one of the keys from the database; 2) the database checks the provided credential and returns the key; 3) the backend uses the key to sign and send a transaction to the corresponding blockchain network.
This interaction takes place within the exchange’s enterprise perimeter, which is relied upon for the security of the entire process. The problem arises in a situation when the perimeter is compromised. The current state of Web2 software is such that it is often impossible to assure complete safety from intrusions for honeypots such as cryptocurrency exchanges, especially considering insider threats. It would therefore be safer if the system could provide additional internal protection. ADAPT can be used to do this as follows.
A secure enclave-based ADAPT container is used as the key manager database, and, furthermore, using ADAPT’s programmability features, it is programmed to never release the key, but rather to sign transaction upon request. In other words, the web backend of the exchange can send a request to the container to sign a given transaction with a specified key, and the container will respond with the signed transaction.
The logic inside the container can be used to provide additional protection. It can parse the transaction and establish the amount of funds being transferred. It can then place limits on how much funds are allowed to be transferred within a given time period, say 1 hour. It can then notify the exchange’s security team if the limit is being exceeded, and stop signing transactions until the member of the team confirms that the situation is ok, using their own specialize frontend.
This creates an additional (and high) barrier to the hackers attempting to steal tokens from the exchange, because in addition to breaking into the company’s perimeter, they must now circumvent the protections provided by the secure enclave. While enclaves can potentially be broken, this is only within reach of high-powered organizations, such as nation states and well-resources hacking teams. Consequently, this additional protection is meaningful to the exchanges overall security.
This example demonstrates that building additional decentralization assurances is meaningful to the application’s security even when the application is otherwise fully centralized. This insight is key to understanding the ADAPT framework.
For more on the software stack for decentralization and the smart contract layer see the next post.
