Confidential Smart Contracts in the Wild

Confidential smart contracts are still a relatively new concept and can primarily be found under well controlled conditions in laboratories or under conceptualized form in research papers. The maturity of this enhanced technology is still questionable and many problems remain to be resolved, which makes confidential smart contracts rare to find in the wild. This makes Microsoft Azure‘s announcement of a preview of their Azure Confidential Ledger (ACL) earlier this year all the more interesting. ACL is Microsoft’s implementation of confidential smart contracts using their Confidential Consortium Framework (CCF, formerly known as Coco framework) to exploit the confidentiality and security guarantees of trusted execution environments (TEE). In this article, I will be taking a closer look at the ACL platform and compare it to existing solutions for Hyperledger Fabric, namely Hyperledger Fabric Private Chaincode (HFPC) and the prototype developed at the complex systems research group of the University of Neuchâtel, TZ4Fabric. For an overview on confidential smart contracts, HFPC, and TZ4Fabric, please read my previous blog entry on “Confidential Smart Contracts for the Industry 4.0“.

CCF is Microsoft’s research attempt to propose an open source blockchain framework leveraging TEE technology to execute smart contracts shielded from attackers and compromised systems. Hyperledger Fabric, contrary to CCF, is a modular and extensible open source system which does not provide support for confidential smart contracts out of the box. It is the HFPC, respectively TZ4Fabric, extension which provides the necessary support for confidential smart contracts. Like HFPC, CCF provides support for the Intel SGX[fn:8], a TEE commercially available in desktops and laptops or in cloud data centers. TZ4Fabric provides support for ARM TrustZone, a TEE targeting primarily IoT and mobile devices with ambitions for cloud data centers.  In order to make use of TEEs, consensus protocols with finality guarantee have to be used to avoid certain types of malicious attacks. Therefore, CCF, HFPC, and TZ4Fabric establish a permissioned blockchain network to have a bounded number of participating and trusted nodes. Different approaches are taken by the frameworks to achieve consensus with finality guarantee.

On the one hand CCF achieves consensus with finality by requiring transactions to be committed in its consensus protocol and proposes a quorum as governance rule. Furthermore, to prevent malicious attacks, the entire node (i.e., consensus protocol, ledger, smart contract and more) are being executed inside the TEE. This is problematic because a large code base needs to be trusted and secured. On the other hand, HFPC and TZ4Fabric separate conceptually the smart contract execution from the node into the TEE and rely on a trusted ordering service resulting in a much smaller trusted computing base (trusted code executed inside a TEE). The main difference between HFPC/TZ4Fabric and CCF are their architectures. CCF uses a classical order-execute architecture while HFPC/TZ4Fabric use an execute-order-validate architecture. In the classical order-execute architecture, participating nodes in the blockchain network agree first on the order of blocks before executing the smart contract and changing the state of the blockchain. For HFPC/TZ4Fabric, this means that transactions are executed in a speculatively similar way to modern microprocessors to improve performance. However, speculative execution has a couple of pitfalls programmer of smart contracts need to be aware of (remember the speculative execution vulnerabilities Meltdown and Spectre from 2019 which have drastically changed the microprocessor ecosystem). For this reason, HFPC/TZ4Fabric make use of a barrier in confidential smart contracts, which ensures that the blockchain state is only evaluated after the barrier. Imagine, for example, an auction. As soon as all participants have placed their bets, the confidential smart contract will issue a barrier to close the auction before evaluating the bets. Without this barrier, a malicious attacker could craft transactions to extract confidential information from the blockchain state due to the speculative execution. It should be noticed that placing a barrier after each transaction would essentially transform the execute-order-validate architecture into an order-execute architecture.

HFPC and TZ4Fabric make use of the membership service provider that maps members to their organization in order to issue credentials, authenticate members and authorize access to the blockchain network. Such a service is currently not available in CCF, but a consortium concept is being established to allow collaboration of multiple parties. However, in CCF, members have the ability to verify at any time the integrity of nodes, blocks, and transactions using receipts. HFPC has a similar capability named “remote attestation”, which leverages functionalities already available on the SGX platform. TZ4Fabric currently does not provide remote attestation, but in our research group we have ongoing work for a different prototype to provide remote attestation in ARM TrustZone within the European project VEDLIoT.

Microsoft’s ACL has set a foot into the wild, but ACL as well as HFPC and TZ4Fabric still have to take a major leap to provide a complete set of functionalities for operating blockchain networks with confidential smart contracts. Off-the-shelf blockchain networks with support for confidential smart contracts are not yet available and remain for the moment a do-it-yourself undertaking. ACL by itself is a proprietary ledger available as preview that runs inside a TEE of Microsoft’s Azure cloud and must be coupled with CCF in order to form a complete blockchain network capable to run confidential smart contracts. Furthermore, confidential smart contract programmers must be aware of the many pitfalls that hide behind the architecture of the underlying blockchain network. For example, smart contracts and other elements of the framework need to be ported into the TEE. Another issue of the frameworks is the introduction of additional restrictions, such as barriers and governance rules. Maybe it will be possible in the future to integrate them into the framework and hide them from unexperienced programmers. Nevertheless, in their current state, programmers that are new to or unaware of these issues with confidential smart contracts are likely to fall into the trap. A lot of research and work remains to be done to lower the entry level to confidential smart contracts and make them more easily accessible to a wider audience.