Special thanks to the Enclave team for helping me compile a large corpus of the information on this writeup, and a special thanks to Victor Costan and Srinivas Devadas for writing their excellent detailed paper on the inner workings of Intel’s SGX.

Disclaimer: The content hereafter is for educational purposes only, without representation, warranty or guarantee of any kind. None of this is as an endorsement by the Enclave Markets Inc., or any of its respective subsidiaries or affiliates and does not constitute any form of investment advice.

Building the Next Generation of Exchanges

Crypto exchanges have recently been plagued with startling instances of misbehavior from insiders. The collateral damage from these bad actors has set off a domino effect of bankruptcies, loss of client assets, and – most damaging to the industry – a loss of confidence in critical infrastructure. In the wake of these issues, one raises the question: in the future, can we have safe and secure alternatives that, through code, take away the control of user funds and trade execution from the exchange itself, making it impossible for insiders to game it?

Recently, Buterin et al. shared thoughts in the article “Having a safe CEX: proof of solvency and beyond”, where the authors outline several key steps centralized exchanges have initiated in the past to walk down the spectrum of “trust”. The bulk of the article focuses on various methods for “proofs of funds”. While these are reasonable starting points, they are inconclusive. First, there are questions around the performance and practicality of these solutions, especially those using expensive cryptographic circuits. Second, some key features are missing, including important properties around execution integrity. This is deeply problematic for both of the latest iterations of centralized and decentralized exchanges, the latter of which suffer greatly from MEV. Finally, and maybe most importantly, upon further inspection it is not clear that the solutions actually work.

If we are to envision a next-gen exchange, one that can’t be evil, it helps to run ourselves through a Gedankenexperiment, and to envision an idealized exchange that is operated by a magical computer. The magical computer has a few key properties:

• First, it allows anyone to remotely check the exchange code. In other words, anyone can verify that there are no backdoors or special privileges for certain traders. It also prevents anyone from modifying the code without the world knowing about it. In other words, tampering with the integrity of the exchange is not possible.
• Second, all requests enter and exit as ciphertexts, i.e. fully encrypted, such that nobody in the world can frontrun any orders. Trade history is revealed to the world only after the order is actually executed, ensuring market fairness.
• Third, and maybe most importantly, if somehow the magical computer was broken by an all-powerful wizard (or a hack), the exchange would not totally break down in guarantees, but instead would simply materialize the same trust assumptions as a standard centralized exchange.

With these properties, we would be able to build an exchange that guarantees a) integrity of all orders, b) confidentiality, and c) reasonable robustness under circumstances that break the security of the system. Said differently, it would be impossible for the developers of the codebase to create backdoors, run away with user funds, or provide special privileged access to certain traders. For all intents and purposes, we’d have a “perfect” exchange, free from malfeasance.

As it turns out, the technology to make this happen is rapidly materializing, and it comes from something known as a “secure enclave”. Said simply, the latest generation of chips inside most high-end computers come with a special piece of hardware which effectively functions as an “encrypted black-box CPU within the main CPU”. Early iterations of secure enclaves has experienced huge growing pains from a multitude of vulnerabilities, but the latest generations have rapidly closed the gap from “experimental” to “practical”. As Matthew Green eloquently put it:

So how can one build this idealized exchange, also known as a FEX (fully encrypted exchange) using secure enclaves? We discuss this in the next section, using the implementation of Enclave Markets, whose spot market is set to arrive sometime this year. In the meantime, it is helpful to mentally think of the trust model in exchanges as a spectrum in the following quadrant below. Note, that while this quadrant doesn’t represent all the niceties that a FEX would provide (include attestation), it provides a generally good breakdown. Furthermore note that a properly designed FEX must have strong robustness in the face of zero-day hardware exploits. In other words, even if an enclave hack were to be found, the FEX must simply roll down to a CEX, and no further.

The Basics of a Fully Encrypted Exchange (FEX)

A FEX’s architecture (such as that of Enclave Markets) can be broken into two major components that, when combined, decentralize custody of client funds, ensure exchange integrity, and ensure confidentiality of trades. These two components are: the Intel Software Guard Extension (SGX) Application (although other secure enclaves, such as Apple’s could be used) and the third-party Attestor Network.

Intel SGX Application

Enclave Markets uses Intel SGX, which consists of a trusted, walled-off codebase that runs within a secure enclave, and an untrusted codebase that runs externally. Assuming correctness as guaranteed by the manufacturer, the secure enclave provides hardware-based memory encryption that protects the system from tampering, access from other processes, and the operating system. A good representation of this can be seen below in Figure 2 by Costan et al. (note, not the same a proper FEX model):

The key difference in the model above and in Enclave’s model is that the key operational components of both the software provider and the infrastructure owner are decentralized through multiple parties using the Attestor Network. A FEX ensures confidentiality by running key architectural components within the secure enclave, specifically: the exchange monolith, the exchange wallet system, blockchain node support, balance transfer engine, user orders, and many other utilities. The secure enclave environment is an important improvement from existing exchange infrastructure, where information leakage enables preferential treatment and advantages for insiders. Within the FEX architecture, the secure enclave ensures that market structure integrity is upheld.

The untrusted code outside the enclave is responsible for initializing and starting the enclave as well as running the remote attestation server. While the untrusted system is built on top of the secure enclave it cannot fundamentally alter the output or services run within the enclave; this ensures that nobody can leverage data from the secure enclave to front run or otherwise knowingly trade against their user’s data.

In order to verify the enclave integrity, which includes the exchange codebase, the Attestors (explained in detail below) take part in Remote Attestation, by which a third party can attest to a remote entity that the codebase is trusted and can establish an authenticated communication channel with that entity. As part of attestation, the enclave proves the following:

• Secure enclave’s identity
• Source code hasn’t been tampered
• Software is running on a genuine SGX enabled platform with the latest security updates

When the Attestor Network is in steady state, each Attestor will perform attestation upon startup and post the report to a public JSON file. The enclave communicates directly with the Attestors to learn about on-chain events and send signed transactions. The transmission of messages for attestation in an SGX box is represented in Figure 3 from Costan et al. below:

The attestation process also applies to all upgrades of Enclave Markets’ codebase. Any updates to the exchange software must be reviewed by the attestor network, and an independent majority must agree to any intended changes after auditing it. Without an audit and explicit confirmation of the attestors, the exchange cannot be updated.

Ultimately, remote attestation ensures that codebase integrity is upheld and that the running software hasn’t been tampered or compromised by exchange operators, insiders, or bad actors.

Attestor Network

Naturally, as we saw above, the reader will note that certain key components are centralized. To solve for this, a proper FEX will distribute key management entirely such that even code upgrades are managed without a single point of failure. This is done through Attestors, which are independent third parties that provide special key distribution functionalities. In particular, they provide additional verification to confirm that neither the exchange operator, nor anyone, is able to unilaterally control customer funds or alter the codebase.

How does this work? The Attestors each run independent nodes, with similar overhead to running full nodes for a blockchain. We’ll take the example of a FEX that uses both Ethereum and Avalanche for asset settlement. Each instance consists of three main components, a server used to index Ethereum and Avalanche (or any blockchain!) transactions and communicate with the enclave, an Ethereum Geth node, and an AvalancheGo node. The Attestors’ responsibilities are broken down below:

• Verify codebase: Through remote attestation, each Attestor is able to verify the hash of the enclave’s binary code. The Attestors have access to the full codebase and are able to check this hash against each code change. Each time the enclave code is updated, the Attestor partners must explicitly approve the new hash and add it to a local configuration file on the Attestor server. If the codebase has been compromised, it will fail the attestor network challenge.

• Storing secret shares: Each Attestor receives a single secret share from the enclave when the enclave first initializes. A set threshold of these shares is sufficient to regenerate the enclave’s “master secret”. If the enclave ever restarts, it will query the Attestors to get their secret shares and recompute its master secret value. All keys used by the enclave are deterministically derived from the master secret.

• Indexing supported blockchains: The enclave needs to be able to query the Attestors for transactions sent to a specific address on each blockchain network. Geth nodes do not have the database indices necessary to support this API. Instead each Attestor builds this index in its own database by querying Geth and AvalancheGo nodes for each block and iterating through the transactions.

• Processing transactions and tracking which requests have been processed: The Attestors are responsible for tracking deposits and withdrawals that have been processed by the enclave. Once the enclave receives a Attestor consensus on an eligible transaction, it kicks off a two-phase commit process. The first commit sends an encrypted signed transaction to each Attestor to store in its database as a backup. Once the enclave receives confirmation that the encrypted transaction has been successfully stored, the enclave then sends the unencrypted transaction to each Attestor for processing. Upon receiving the signed transaction, the Attestor broadcasts it to its Avalanche or Ethereum node. On either confirmation of the transaction or being notified that the transaction’s nonce has already been included, the Attestor marks that the transaction has been processed successfully.

• Host public information: Information such as fees, minimum transfer requirements, and which ERC20s are supported will be configured and maintained in the enclave. As the enclave is not publicly accessible, the Attestors publicly host that information. In addition, the Attestors are responsible for hosting an attestation report for public consumption. Each Attestor posts this information to a publicly accessible S3 file, which can be used for independent verification.

The Attestor network serves as a critical layer of security. Critically, these independent Attestors remove single-points-of-failure which have plagued centralized entities in each crypto cycle. To illustrate, if there was ever any change within just one of the attestor nodes due to a malware attack, the Attestor would be unable to verify its SGX enclave’s integrity, and would be excluded from submitting or approving code changes. As a result, malware or man-in-the-middle attacks would be unable to gain critical access.

Traditional CEXs demand faith that their codebase is secure, that bad actors don’t have access or preferential treatment, and that client funds are protected. With a FEX, the exchange codebase is independently reviewed and cryptographically verified to ensure a neutral and fair exchange. Furthermore, client funds are held in decentralized custody – the exchange operator cannot unilaterally move client funds without majority alignment from the Attestors, which forms a critical safeguard to protect client assets.

Conclusions

Currently there are two types of mainstream crypto exchanges: CEXes and DEXes. CEXes, while highly performant and efficient, push control and management of both funds and execution down to a single party, therefore are susceptible to malfeasance from bad actors. On the other hand, DEXes, which aim to remove the fund control away from a single party, suffer from low performance, high costs, and – ultimately – are still susceptible to manipulation from on-chain MEV.

The third generation of exchanges, FEXes, aims to solve all these issues. They prevent insiders from manipulating the codebase and injecting backdoors, prevent frontrunning and other forms of malfeasance, ensure client confidentiality from even the exchange system admins, and prevent custody from single parties. The biggest issue to overcome for FEXes is still the quality of the hardware implementation. While Intel is one of the earliest implementations for secure enclaves, there are other offerings, such as those from Apple, which promise a much smaller attack vector.