Private Transactions on DeFi: Confidential Smart Contracts on Ethereum

You will soon be able to get privacy on a public blockchain with Confidential Smart Contracts (CSCs). CSC solves the lack of privacy in traditional smart contracts using Trusted Execution Environments (TEE). This solution can be applied to any public blockchain where privacy is not provided by design. In this blog, we are going to learn some features of Ethereum Smart Contracts that need a redesign, how Confidential Smart Contracts address them in their solution. We are going to learn how Confidential Smart Contracts function and lastly, we are going to examine the advantages of using CSCs.

Features of Smart Contracts

Let's look at some characteristics of smart contract platforms that cause real-world problems:

• Consensus: a public blockchain has a composability feature, which allows to combine of several smart contracts into a new smart contract or to build new solutions on top of existing ones.
• Scalability limitations: consensus introduces low-throughput of submitted transactions into the system because of the way data propagate on the network. Introduction of the sharding concept in Ethereum 2.0 just partially solves the transaction throughput limitation but does not eliminate it completely.
• Blockchain’ lock-in’: in the early stages, smart contracts were comparatively simple and easy to migrate across blockchains. Constructability allowed applications to evolve into complex ecosystems on networks. This increased the complexity of smart contracts and made it very hard to migrate them to other blockchains.
• Data privacy: some public ledgers store data across all nodes on the network.

Confidential Smart Contracts

Confidential Smart Contracts (CSCs) remove the need for consensus as proof of transaction execution. CSCs use Intel SGX hardware and it is the only trusting party also provides attestation – a guarantee of what applications are running on SGX. Confidential Smart Contracts improve security while eliminating transaction throughput limitations of MainNet.

Intel SGX is built inside modern Intel CPUs to provide a secure way of processing data. Intel SGX is a part of an emerging area of Confidential Computing. At a high level, Confidential Computing has three components:

• An enclave — where data is processed securely, this is a trusted party of Intel SGX.
• A host running an enclave on its device. The host doesn’t have access to the data or code inside an enclave.
• A client, who sends their data for processing to the host, which sends data to the enclave.

The host acts as a middleman between the enclave and the client. The client ensures nobody tampers with the code inside the enclave using attestation. Since Intel SGX libraries are relatively low-level, we use Conclave SDK — a high-level library that allows non-specialist engineers to build confidential computing applications easily and fast. Conclave SDK uses GraalVM to build applications.

Components of Confidential Smart Contract

• Management contract — hosted on the blockchain. This is where users deposit their assets from CSC, which are committed to the management contract in a way of a checkpoint.
• Confidential smart contract running on SGX instance. It is responsible for authorizing withdrawals and managing assets deposited on the management contract, according to the code set for a specific deployment.
• Host — manages SGX instances and saves encrypted data. Usually, the host is not malicious. Since it takes transaction fees from users the host has the financial benefits of managing SGX instances. But users should assume the host is malicious and secure their applications.
• Users — mutually-distrusting parties who are not aware of each other. If they were, they would have broken the confidentiality assumption of a confidential contract.

Functionality of Management Contract

Management contracts play a crucial part in Confidential Smart Contract solutions. They:

• Maintain Checkpoints to ensure the SGX instance can access its latest state.
• Protect users’ assets using predetermined policies. Users can install timeouts on withdrawals or instruct hosts to deposit collateral or to stake to secure users’ assets in case of host misconduct.
• Serve as an uncensorable endpoint if a malicious host denies SGX instance from accessing its memory or denies users from accessing SGX instance. Users can use management contracts to queue messages that the SGX instance should have processed. If the host refuses to process messages on the SGX instance, then users can claim the collateral that the host locks.
• Provide metadata that identifies enclaves and hosts — the management contract specifies the host of the SGX instance. Users need attestation to ensure connections to the right SGX instance, to prevent the host from connecting users to a different SGX instance. It also identifies attestations, smart contracts assigned by the key that way attested for on the enclave.
• Management contract APIs that are available to users and hosts:
  • Deposit assets collateral.
  • Dispute messages for SGX instance or open disputes with the host.
  • Call the checkpoint with the data SGX signs to update its state, represented on the ledger. The user has to bear costs for this operation.
  • Reclaim initiates a process that extracts assets that SGX controls back to the users that have deposited them. This function should be used if the host loses all instances of SGX and assets are locked. See Diagram 1.

Deposit Verification

Diagram 2 shows that initially, the user deposits assets on a blockchain and gets a transaction receipt. The user uses the receipt to inform the SGX instance about the deposit. SGX uses its receipt to query trusted nodes to confirm that a transaction has happened and the assets are on the blockchain.

Synchronizing Contract States

When the host creates an initial confidential contract and corresponding management contract, she also creates an initial checkpoint, which is a blank state. A user deposits assets into this state. The underlying state evolves with every trade user makes until there is a withdrawal event that requires a checkpoint that contains a signature from the SGX instance to move assets on the management contract to a provided address. The user receives the checkpoint in the response, then she must synchronize the corresponding state with the management contract by calling the checkpoint function.

Users send requests to the host of the SGX instance. The host forwards this request to the SGX instance. Those requests instruct the Conclave to invoke a specific function on CSC with specific parameters. See Diagram 3.

CSC archives cost reduction because not all operations are checkpointed. The user receives worker state in the form of cryptographic commitment. When a checkpoint is uploaded to the management contract, the user uses cryptographic commitment to identify functions that had changed the state before the checkpoint was generated to ensure that the host hasn’t tampered with her state. The user can perform a dispute function and claim her collateral if a cryptographic commitment hasn’t been called when the next checkpoint was uploaded.

Processing Withdrawals

Diagram 4 below shows that to withdraw assets, a user calls a function in CSC instructing it to move funds to an address. The user receives a crypto key to the command, which instructs the management contract to disburse funds to that address. Then the user can unlock the management contract with the crypto key to receive the assets. The:

1. User invokes the withdraw function. The SGX instance processes the code and generates a response that returns a commitment and automatically generated a checkpoint.
2. User generates a transaction containing SGX-signed instructions.
3. User sends the transaction to the ledger. The ledger verifies that the specific SGX instance signed the instructions, which is bound to a particular management contract. If the ledger verifies the SGX instance, it processes the instructions.

Staking as a Defense Mechanism

If the host refuses to grant users access to SGX, the user can open a dispute on the blockchain which results in a loss of transaction fees. In Diagram 5 below, users contact the host, who should contact the CSC on Conclave. If the host denies access to the SGX instance and the assets on it, than the user contacts MainNet directly, which forces a host to comply to avoid losing transaction fees.

Benefits of using Confidential Computing:

• No Consensus – A trusted party removes the need for consensus of all nodes on the network; only one party, an Intel SGX instance needs to have consensus with itself.
• Network with nearly full privacy – with the only trusted party being Intel SGX. Since even the Intel SGX instance host has no access to the data, it is fully secured. Applications are not in any way engineered to reveal the data.

Benefits of using Conclave:

• Cloud acceleration – The cloud-based Key Derivation Service makes it possible to deploy CSC that are not tied to any particular machine unlocking high-availability architectures. Read more here.
• Language support (Java, Kotlin, JavaScript) — in general, any new language that Conclave SDK will support will be supported by CSC. There is experimental support for Python in Conclave 1.2. Confidential smart contracts also support any new language that is added to Conclave SDX.
• Cost Reduction — to execute transactions on MainNet, the user needs to broadcast them to the whole public network. Using CSC, you can execute her transaction on a handful of machines where SGX instances are running.

Benefits of Confidential Smart Contracts

Let’s compare the cost, speed, and security of trade on three systems: traditional centralized, MainNet (Ethereum), and Confidential Smart Contract on L2 Ethereum.

The table above shows the cost of executing a transaction on the MainNet is the most expensive out of the three systems. Initially, Ethereum designers wanted to make transaction executions more affordable on Ethereum than on traditional centralized systems. The cost of MainNet also includes a network congestion charge. In Contrast, Confidential Smart Contracts are on average 1000x cheaper to run than MainNet.

If you compare the speed of transactions, executing a trade on traditional centralized systems is still the fastest solution overall. CSC has a performance penalty of decrypting/encrypting data into and out of an enclave. Therefore, it runs on average 30% slower. Security has its performance costs. Comparing CSC with Ethereum, CSC is considerably faster because there is no data propagation that exists on MainNet.

Lastly, comparing confidentiality across three systems, only CSC provides true data security. With centralized systems, users can not be sure their data hasn’t been revealed to third parties. MainNet doesn’t provide privacy.

Other Benefits of CSCs

• Reduced complexity and improved security. CSC uses Conclave SDK software, which is the easiest and simplest way to write smart contracts than any other L2 protocol.
• Ability to retrofit functionality on existing blockchains where smart contracts are not available. Let’s take Bitcoin as an example, which doesn’t have smart contracts. Because SGX is a Trusted Execution Environment, it allows users to generate private-public key pairs, which can act as a Bitcoin address to send assets. Bitcoin users can send assets to another address. If that address is an SGX instance with a key pair and deployed Confidential Smart Contract, Bitcoin users can run a fully functional confidential smart contract on the Bitcoin network.
• Potential for Solidity support without re-writing contracts. Users can deploy any smart contract on Conclave, for example, a Solidity smart contract. If the SDX instance is bound to a different blockchain then the user moves its smart contracts across networks.

Drawbacks of CSC

SGX is unable to remember. The Intel processor desktop families that use Intel SGX technology have a monotonic counter, which lets it keep states. An SGX server doesn’t. The solution is to store a state on the ledger. That way, users can make sure the state is synchronized, and the host can't tamper with it.

What if SGX is Compromised?

In the real world, anything is technically hackable, and no system is truly fully secure. Some possible risks:

• Overengineering. This increases the likelihood of security mechanisms being compromised.
• Malicious users can still require funds, even if there are backup security policies are in place. Confidential Smart Contracts solved it by having a challenge mechanism with incentives on top of the decentralized consensus protocol of the MainNet.

This blog is based on the research by Stefan Iliev, an R&D software engineer at R3. You can watch his presentation on CSCs here.

Confidential Smart Contracts have been in the center of obscu.ro protocol. Read more about Obscuro in their white paper. Join Obscuro on Telegram and Discord.

Join our developer community at our Developer Platform and check out our Developer Community Forum.