E2ED: End-to-end decentralization (Part II)
Defining decentralization
In my previous post I have discussed the need for end-to-end decentralization and the problems that it solves: first, decentralizing the non-blockchain layers of the development stack, and second, creating a suitable mechanism for regulation and enforcement without negating the main benefits of decentralization, such as privacy, interoperability, and open access.
Before diving into the details related to the ADAPT framework, the software suite aimed at enabling E2ED software, we must focus on defining decentralization in a way that suitably informs further discussion. The problem is that in the blockchain and cryptocurrency industry decentralization has acquired a very narrow meaning, specifically referring to the permissionless blockchain networks, such as Bitcoin and Ethereum. Yet, in order to build E2ED we must first understand what decentralization means for those parts of the decentralized applications that are not blockchain.
I propose the following definition of decentralization: a decentralized system is one which delivers important assurances related to the behavior of the system’s operators and users via engineering constraints rather than through legal or social contracts.
Blockchain-style decentralization fits this definition quite well, since blockchain architectures make it impossible for the network’s operators (miners) to deny services or censor transactions. However, this definition is intentionally broad, making it easy to apply to non-blockchain software as well.
To understand this, let’s focus on an example. Consider several e-commerse companies operating in the same market. Imagine that they each have several years of transaction records, which, if combined, can be used to extract valuable market insights. The companies want to run this analysis, but don’t want their competitors to see the line item transactions that contain, among other sensitive data, identity of their customers.
Essentially, the organizations need to combine their datasets and run reports on them in such a way that each must first approve the report’s algorithm to prevent leaking sensitive data, and none of the participants may see the underlying data directly. The question then arises: how can this be done safely? There are multiple answers to this question. First, the organizations may chose the federated computation model, where each receives the algorithm and evaluates it on their respective portion of the data sending results back. This approach has a number of drawbacks, including that some algorithms are not suitable for federated computation, or that the partial results may leak too much information to competition. Second, the organizations may choose a neutral third party to hold the data and generate the reports. In this case, the task is to assure that the third party is honest and will not steal valuable data or insights. Furthermore, the third party will require some kind of financial compensation to carry out the task.
Note that under current — centralized — architectures neither of the companies involved can be trusted to hold the combined dataset. However, if we could build a system which physically limits the ability of its operators to see the data, we could use a much simpler and more universal model of combining the data on the same server, which could reside with one participant, or each could hold a copy. Such a system would be decentralized under the definition above, even though it is entirely unrelated to blockchain.
Importantly, there is a simple tool that enables one to build just such a system. A secure enclave, such as Intel SGX or Amazon Nitro creates strong isolation of a guest software process from intrusions by the operators of the computing hardware that hosts it. It is straightforward (albeit, tedious) to build an enclave-based solution for the use case described above.
Secure enclaves are just one example of an environment protected from operator meddling. There are, currently, many such environments: 1) Cryptographic environments — Fully Homomorphic containers (albeit this technology isn’t fully mature yet); 2) Distributed environments — blockchain; 3) Hybrid cryptographic/distributed — ZKP, SMPC; 4) Software environments — mobile application containers (although the protection they provide is quite weak); and 5) Hardware environments — secure enclaves such as Intel SGX. To bring E2ED to market, one must support all or most environments that deliver the required protections to the software component in question.
One final aspect of decentralization I would like to examine in this post is the type of assurances offered by a decentralized component. This is relevant to considering the suitable protection environment for the software in question, and provides a broader view on the classification of decentralized systems beyond blockchain.
In my view, the assurances relevant to decentralization fall into one of three specific and orthogonal categories: 1) Privacy/confidentiality, an assurance of the operator’s inability to view data; 2) Integrity, an assurance of the operators’s inability to wrongly modify or falsify data; and 3) Availability, an assurance of the operator’s inability to deny services, also sometimes called censorship resistance.
Given these categories, it is now easy to classify decentralized systems and their respective protection environments. For example, blockchain networks are decentralized systems that deliver both integrity and availability assurances, but (as in the case of Ethereum) no confidentiality. Secure enclave software provides assurances of confidentiality and integrity, but not of availability. Federated computation also guarantees confidentiality, but not integrity. And so on.
It is important to recognize that different decentralized systems require a different combination of the kinds of guarantees listed above, and that there is nothing inherently better about blockchain’s assurance of availability versus a federated algorithm’s guarantee of confidentiality. Both are important for their respective use cases. To summarize, in order to build E2ED systems, we must combine a secure environment that offers some protection from meddling by the operators with a set of guarantees relevant to the particular use case.
In order to establish enforcement and regulation methodology, the systems we build must include relevant provisions that enable designated parties to partially control the system, enough to carry out the enforcement duties, but not enough to completely break the system’s guarantees to its users. Regulation by itself does not break the definition of decentralization I have provided earlier. Regulatory compliance assurances can be made part of the promise that the system may put forth from the get go, and as long as such enforcement cannot be extended post-factum to completely break the privacy or integrity guarantees of the system, it is ok. This is the approach we take to soft decentralization.
In the next article we will talk about the relevance of smart contracts (which we term secure workflows) to end-to-end decentralized systems.
