Asylo and its Place Next To The Blockchain

Privacy is well understood to be a problem in the blockchain ecosystem, where, by default, everything is available on-chain for all the world to see. Many different projects are attempting to address this problem, using a wide variety of techniques. But, I would like to focus on one particular approach: Secure Enclave hardware. More specifically, Project Asylo, an open and flexible framework from Google for building portable applications that run on Secure Enclave hardware.

What Is Secure Enclave Hardware?

Before we dive into things, it is helpful to understand a little bit about Secure Enclave hardware. I will not aim to cover everything in detail — there are much better places to learn about the details — but I will cover the high-level capabilities.

In short, Secure Enclave hardware allows you to run general-purpose applications in a secure environment where both the data, and the application itself, cannot be compromised by anyone. Not even you. Why would I want to compromise my own application, you ask? Well, in the blockchain world, no one can be trusted. You might *claim* to be running a certain kind of software, and you might *claim* not to be accessing its data, but how can others feel confident that this is true? In the blockchain space, you almost definitely have something to gain by tricking people into thinking that you are an honest actor when in reality, you are not.

Secure Enclave hardware can cryptographically attest to its correctness (with cloud providers like Google Cloud taking this a step further with shielded virtual machines). This allows people to verify that you *really are* running a specific binary in a secure hardware environment that will not allow you to make alterations and will not give you access to any encrypted data.

Why Asylo?

This is where Asylo is of particular interest. Asylo abstracts away the specifics of Secure Enclave hardware, making it trivial to port an application from one type of hardware to the next. This makes it possible for application developers to support Intel implementations, AMD implementations, and any others that appear in the future. But this also means that application developers can easily support different cloud providers that offer secure computing environments, such as Google Cloud’s Confidential Computing or Azure’s Confidential Compute.

But why is this important? Well, in the world of decentralization — and the world of security — **diversity is everything.**

By supporting different Secure Enclave hardware options, users are free to choose the implementation that they want. If a hardware vulnerability is discovered, it’s unlikely that the vulnerability will affect the entire network. If a hardware provider is compromised, it’s also unlikely that this will affect the entire network. If a cloud provider changes its platform or its policies, it is unlikely that this will affect the entire network.

Asylo is Powered By Kubernetes

Asylo also has many features out-of-the-box that make it incredibly easy to work with:

• It offers a POSIX interface, allowing all of the major features of a full-blown Operating System without needing to leave the security of the enclave.
• It supports connections between remote enclaves using gRPC without leaving the security of the enclave. This allows remote machines to authenticate with each other and securely and correctly exchange data.
• It comes with an easy-to-use Docker image, which allows for quick migration of applications and easy testing.

This is all possible, essentially for free, because Project Asylo is built on top of Kubernetes. Kubernetes is the de-facto standard for managing large clusters of virtual machines, consuming vast resources, and running lots of heterogeneous software. This makes it a perfect candidate for managing an array of different blockchain nodes across various hosting providers.

Possible Applications

Bringing privacy to the blockchain space opens a world of possible applications, but I will highlight some of the ones that are particularly interesting to me.

MPC

The first — and least surprising — is multi-party computation networks like RenVM. In a multi-party computation network, data is broken down into *shares* that — by themselves — reveal nothing about the data. The multi-party computation network can run computations over these shares as if it was running computations over the data, but without revealing the data to anyone. In the case of RenVM, this allows it to generate and use ECDSA encryption without ever revealing the private keys, opening the way for decentralized custodianship of assets. By extension, the moving of assets from one blockchain to another.

But, there is a problem. If enough peers in a multi-party computation reveal their shares to each other, those players can reveal the secret data. This is an unavoidable reality and one that people are struggling to solve using economic incentives and game-theory.

With Asylo, a multi-party computation network can be built where peers cannot access their own shares. Furthermore, peers can cryptographically attest to each other that (a) they really are running their software in a Secure Enclave, and (b) they really are running the correct software. Peers’ machines can connect securely, cryptographically authenticating their identities and their binaries, all without leaving the safety of the Secure Enclave hardware. This makes it impossible for peers to reveal their shares to each other, even if they’re incentivized to compromise the network.

Asylo makes it trivial for peers to be using different Secure Enclaves implementations and different cloud providers (including local machines) because the hardware is abstracted away with Kubernetes, upon which Asylo is built. This way, even if a vulnerability is discovered, it will not affect enough peers for a multi-party computation to be affected (note, this is only the case for robust MPC algorithms such as the RZL MPC algorithm.

Secure Blockchain APIs

With blockchains becoming more and more connected and an emerging class of applications that require data from multiple chains (e.g., Synthetix), the problem of managing API access to blockchains is becoming more pressing. To maintain the trust-less nature of the blockchain, people typically need to run their own nodes. However, with both Bitcoin and Ethereum consuming hundreds of Gigabytes of storage (and growing), this is quickly becoming less feasible. This is just one example of how to make any external data and computing resources available on-chain and how to solve the oracle problem and discussed in greater detail related to cloud computing here.

Building on the Google Confidential Computing (GCC) and Google Kubernetes Engine (GKE) allows developers to deploy clusters that run lots of different nodes for accessing different blockchains without necessarily needing to trust the person/people/team that is operating the cluster.

At Ren, we’re beginning to use Asylo and migrate our blockchain API infrastructure to use GCC and GKE because it enables our developers and community to deploy exclusively onto machines that use Secure Enclave hardware with minimal effort. It also removes the need for our users and third-party developers to trust that we are running the right node software on secure hardware. They’ll soon be able to verify that cryptographically.

Dark Pools

Another interesting application is dark pools. In a normal exchange, the order book is visible to everyone. You can see what assets are being bought and sold, at what price, and in what quantities. You can also see what orders have not been filled yet. These are orders waiting on the book, showing traders' intent to buy/sell at different prices and quantities. In a dark pool, all of these details are kept hidden. You cannot see what orders people are placing, what orders are on the book, or what assets are being bought and sold, at what price, or at what quantity.

In the traditional financial world, dark pool operators are trusted intermediaries. Traders simply trust that the operator will respect their privacy, not reveal their information to others, and not use the information themselves. It should hardly be surprising that there is no shortage of examples where dark pool operators have blatantly violated this responsibility. In doing so, dark pool operators are giving an unfair advantage to some traders, allowing them to see the information that others cannot, even allowing them to front-run other traders (where you buy an asset someone else is about to buy so that you can sell it back to them at a slightly higher price).

Exchanges are big in the blockchain world. But so is not trusting intermediaries. Asylo gives developers an option to build a dark pool that runs entirely within a Secure Enclave. This gives users confidence that even if the dark pool operator wanted to access trade information, it would not be possible. This also gives users confidence that the dark pool operator is not favoring one trader over another. Of course, there are other theoretical ways to implement dark pools, but when performance matters, Asylo appears to be the only practical option for building a dark pool today. Believe me, we have thought long and hard about this problem.

The maturation of Asylo will usher in an era of innovation around privacy technology and is particularly suited for the blockchain space. At Ren, we are excited about the possibilities that this opens for improving the safety of RenVM without compromising decentralization. The ability to force nodes onto Secure Enclave hardware without forcing node operators to use a specific hardware or cloud provider will allow RenVM to scale well beyond what would otherwise be possible.