IndexAbstractI. INTRODUCTION. MotivationII. STATE OF THE ART. Private data objectsB. Ekiden C. The CocoD painting. SCEIII fabric. EMERGING CONCERNS AND TECHNICAL CHALLENGESIV. COMPARATIVE EVALUATION OF THE PROPOSED SOLUTIONS. Architectural differencesB. Dependence on the level of consensusC. Key ManagementD. ScalabilityE. Performance EvaluationsF. Non-deterministic transactionsG. Compromised system componentsH. Individual benefitsI. Use of trusted third partiesJ. SummaryV. CONCLUSIONS AND REFERENCES PERSPECTIVEAbstractA smart contract is an application that runs on blockchain. Digitally enforce agreements between wary parties. Smart contracts inherit the security guarantees of blockchains, but their lack of privacy and confidentiality raises concerns and limits the applicability of smart contracts, while blockchains also constitute a performance bottleneck. Combining smart contracts with Trusted Execution Environments (TEE) is a way to prevent unauthorized access and manipulation through untrusted blockchain nodes, thus solving privacy and confidentiality issues. This article reviews four existing frameworks that incorporate Trusted Execution Environments into their smart contract systems, examines the different architectures, discusses individual strengths and shortcomings, and performs a detailed comparative evaluation of the four approaches in order to find the right combination of features that a new generation smart contract should possess. Say no to plagiarism. Get a tailor-made essay on "Why Violent Video Games Shouldn't Be Banned"? Get an original essayIndex Terms: smart contracts, blockchain, TEE, privacy, confidentialityI. INTRODUCTIONDistributed ledgers and especially blockchains are emerging technologies that have recently attracted a lot of attention, since they constitute a new decentralized computing paradigm, which on the one hand allows payments with cryptocurrencies such as Bitcoin [1], but also serves as the basis for smart contracts on the other part. Smart contracts like Ethereum [2] are programs running on blockchain, which define and enforce agreements between two or more parties, based on pre-agreed policies to access and update contract-specific data. Smart contracts have been proposed to improve applications in a wide range of industries, including finance, insurance, identity management, and supply chain management [3]. Typically, even the creator of a smart contract cannot modify its code or subvert its execution. Smart contract code is replicated across all participants within the network to ensure auditability, fault tolerance, and availability. But while such smart contract systems offer a number of benefits, they present several issues that limit their applicability, especially for some use case domains, as they inherit some undesirable blockchain properties. Motivation As stated in [3], the most notable disadvantage of existing smart contract systems is the lack of privacy and confidentiality, which arises from the distributed and publicly available nature of blockchain data. To verify correct computation and validate state transitions, contract methods are computed on every node in the network and the entire state of the contract is stored publicly, even if a contract deals with sensitive data and blockchain nodes are owned by untrusted parties . This procedure is a key feature of distributed ledgers, which allows transactions without intermediaries, but at the same time presents a data privacy problem, since it opens the risk of potential information leaks orprivacy threats such as data theft. As a result, privacy concerns create a demand for new approaches in terms of smart contract systems, which are capable of safeguarding access to data in some way. According to [3] and [4], another problem of conventional smart contracts is the limited performance of most blockchain protocols regarding computing power, transaction throughput and latency, which is also associated with processing costs high. Due to these issues, existing smart contract systems may fail to meet key requirements, such as reasonable performance, as required by various use cases or business applications. Therefore, the aim of new smart contract systems is to improve the speed and latency of transactions, without imposing compromises in terms of privacy and confidentiality. Cryptographic protocols such as secure multiparty computation, such as Enigma [5], or zero-knowledge proof systems such as Zerocash [6] or Hawk [7] promise to provide a privacy-preserving approach for blockchains using cryptographic primitives. However, due to relatively high performance costs, they incur high costs and do not provide a general solution, as stated in [3] and [8]. As an alternative approach, several articles propose combining smart contracts with Trusted Execution Environments (TEE) as an attempt to address the limitations of smart contracts in terms of privacy, confidentiality, and performance. This is achieved by using reliable hardware that provides fully isolated execution environments, such as Intel Software Guard eXtensions (SGX). Since Intel SGX, a CPU-based TEE implementation, is the predominant TEE technology used in recently proposed TEE-supported smart contract solutions, the focus of the paper is primarily on this reliable computing technology.B. Trusted Execution Environments (TEEs) Intel SGX provides secure hardware enclaves for performing computations with sensitive data, such as private data and sensitive contract states, by implementing a memory encryption mechanism that enables an isolated and therefore sealed address space . Therefore, the memory space is not accessible to the operating system, host owner, or other applications and TEEs, as described in [3] and [8]. To realize this property, a key management mechanism is used to generate and manage public and private keys, which are required to encrypt and decrypt sensitive data within an enclave. Before the data leaves the TEE and can be stored in the registry, it is encrypted with keys known only to the CPU of the associated hardware enclave. This ensures data integrity and prevents unauthorized access, as well as data manipulation through untrusted blockchain nodes, thus remedying the lack of privacy and confidentiality. Another important feature of TEEs is the support for attested execution thanks to a remote attestation mechanism, as mentioned by the authors of [3] and [8]. Remote attestations are digital cryptographic signatures proving the correct execution of a program within a TEE, which can be issued by an enclave during runtime. An enclave's attestation keys, used to generate the digital signature, can be verified using an attestation protocol, such as the Intel Attestation Service (IAS), a certificate of approval provided by the manufacturer, in this case Intel, which guarantees non-falsifiable and authenticated certifications through the validation of TEEs. This procedure favors verifiable calculations by dispensing proof of correctness, even if the enclavesthey run on potentially untrusted nodes. As a result of moving computation to TEEs, performance overhead is reduced and thus transaction speed, throughput and latency are improved, as computation is simplified due to unencrypted data processing [3]. Furthermore, further performance optimizations are conceivable, depending on the particular solution approach. In summary, TEEs can provide secure remote computation of sensitive data and by hybridizing TEEs and blockchain, smart contract systems can take advantage of both technologies to overcome problems arising from executing smart contracts on plaintext blockchains. As a result, reliable and privacy-preserving smart contract systems with reasonable pricesPerformance can be built, so the applicability of smart contracts is extended to applications with strong privacy requirements, for example in the field of insurance companies. Recently, numerous smart contract systems hybridized with TEE have been developed. Existing solutions proposed by different research groups show conceptual differences, but in general they can be divided into two categories, namely those with on-chain execution and those with off-chain execution of smart contracts. Both concepts are analyzed in the next section based on four different TEE.II-based smart contract systems. STATE OF THE ART Compared to on-chain approaches, in which smart contracts are executed within TEEs distributed directly on blockchain nodes, off-chain solutions propose the use of special non-blockchain nodes equipped with reliable hardware [9] . Therefore, the approaches show opposite architectures and concepts, which are described separately below by means of two existing off-chain and two on-chain solutions, namely Private Data Objects [10], Ekiden [3], the Coco framework [ 4 ] and SCE-Fabric [8]. Both TEE-supported smart contract approaches imply advantages, but also disadvantages compared to their counterparts, which are identified and evaluated in the following sections.A. Private Data Objects As introduced by [10], Hyperledger Private Data Objects (PDO) represent an off-chain approach from Intel to execute smart contracts involving private data on a distributed ledger by leveraging TEEs. 1) System Architecture: The architectural concept behind smart contract execution within PDO-based systems. It shows the main entities involved during the execution of the smart contract, namely a distributed ledger, multiple users, a contract agreed between the parties and an enclave hosting service providing SGX enclaves. PDOs use an SGX-based enclave hosting service, as a cloud service provider, enabling off-chain execution of contracts in Intel SGX enclaves, and rely on Hyperledger Sawtooth as a distributed ledger platform, which provides greater scalability compared to Hyperledger Fabric, as it is designed to be able to scale to a large number of nodes [10]. Additionally, Hyperledger Sawtooth can ensure high privacy and confidentiality requirements through the use of customizable transaction families, as described below, especially in combination with Trusted Computing. Registry nodes are responsible for verifying and logging transactions which “enables contracting parties to retrieve and audit contract and enclave instance data, as well as serialize and confirm contract state updates” [10] . Therefore, PDOs implement three types of custom transaction families, namely Contract Registry, Enclave Registry, and Coordination and Commit Log(CCL). They abstract the layer such that each transaction family defines specific custom operations and rules to change the state of the ledger. Each transaction sent to the ledger must comply with the rules of the associated transaction family, otherwise it will be rejected and therefore not added to the ledger. As the name already suggests, the Contract Registry transaction family defines contract management, such as registering a contract and adding or removing authorized enclaves for the execution of a specific contract, while the Enclave Registry transaction family is responsible for transactions regarding enclave management such as registering, updating, or revoking an enclave. In contrast, the CCL transaction family allows the construction of a dependency graph consisting of dependencies between state transition transactions, which “enable the specification and enforcement of the progression of one contract state conditional on the progression of other contract states, allowing at the same time maximum competition between interacting contracts and ledger interactions” [10].2) System Initialization: Before a smart contract can be securely executed in trusted environments, a PDO instance must be created by registering the SGX enclaves and the contract in the register. First, an enclave must be verified by the Intel Attestation Service, to ensure reliable attestations, and then registered by the enclave hosting service as an enclave registration transaction, which includes the verification report produced by the IAS, the owner of the enclave and the public keys of the enclave. Such a transaction must comply with the Enclave Registry transaction family rules. In contrast, contract registration is initiated by the contract owner and divided into several stages. First, the contract is registered in the register as a contract registration transaction, which must comply with the rules defined by the Contract Registry transaction family and is followed by an authorization to execute the contract. During execution authorization, the contract owner submits a key provisioning request to the so-called provisioning services in order to be able to provide the registered enclaves with cryptographic material as part of the subsequent contractual enclave provisioning phase. The provided enclaves are then able to encrypt and decrypt the contract state using the keys provided by the provisioning services. This procedure allows contract state encryption to be enclave independent and also enclave service independent. During these phases, the contract owner acts as an intermediary between the registry, provisioning services and enclave hosting services, so there is no direct interaction between the registry and the TEEs. As a final step, the contract holder provides a proof of supply, signed by the enclave, to the registry, which completes the contract registration and execution authorization process, resulting in disclosure of a set of supply services, as well as a list of enclaves authorized and provided for a specific contract on the ledger.3) Transaction workflow: As soon as both the contract and its associated enclaves are registered on the distributed ledger, an authorized user is able to trigger contract method invocations intelligent, which are carried out by the contract interpreter of an enclave. Initially, when the user invokes the first method of the smart contract, the contract interpreter initializes an empty state. Subsequent method calls could then lead to state updates. Fig. 3shows a sequence of contract method invocations within PDOs. Before a method can be invoked via a request sent by the user to the SGXhosting enclave service, the user must be authenticated via enclave or contract, depending on the default policies. Next, it needs to retrieve the latest contract status from the registry. After the corresponding contract code is executed on the trusted hardware, the user receives the computation result from the enclave and can then send a transaction including the resulting state transition to the ledger, which is verified and recorded by the ledger nodes in terms of proper attestation before acceptance.4) Security Aspects: As outlined in Fig. 3, a user serves as a communication channel between the distributed ledger and the SGX enclave, which executes the smart contract code. The channel concept forces the user to generate a new public/private key pair for each method invocation. By including the user's signature and their public key in the method invocation and subsequent commit of the transaction, registry nodes can verify whether the signature of the transaction belongs to the user who submitted it. This ensures that a transaction resulting from the invocation of a specific method is only confirmed by the user who actually invoked the method. Furthermore, this mechanism ensures the privacy of a user, since different transactions cannot be correlated with a specific user. In general, each enclave generates two public/private key pairs. The two private keys are stored in the enclave's sealed storage, but their public counterparts are needed for attestation, so these keys are recorded and can then be retrieved from the registry. The verification public key is used to validate the enclave's signature, while the encryption public key is needed to provide the enclave with confidential contract status. The status of a contract “indicates the (private) data that a PDO associates with a specific contract” [10] and is available in plain text within the enclave. Before a state leaves the TEE, it is encrypted by the enclave using the contract-specific encryption key, and similarly, the enclave decrypts the state it receives from the user for computation purposes.B. Ekiden The second off-chain execution approach to combining blockchain with TEE is called Ekiden. It represents an efficient and privacy-preserving smart contract system and was proposed in [3]. Ekiden is based on Intel SGX as trusted hardware and features an architecture that separates contract execution from consensus, which opens up the possibility of scaling the nodes used for computing the contract code independently of those maintaining the blockchain and vice versa . According to [3 ], using the platform produces minimal performance overhead through off-chain computation of smart contract data. In this way, Ekiden is able to efficiently support large-scale applications with strong privacy needs, preserving availability and integrity as fundamental characteristics of the blockchain. Its functional prototype is built on Tendermint as a consensus layer, but the architectural design facilitates its compatibility with different blockchain systems, both with permissioned (private) and permissionless (public) consensus layer mechanisms, as the only prerequisite for blockchain nodes is the ability to validate the attestation.1) System architecture: Ekiden provides an architecture composed of three different types of entities, namely Clients, Compute Nodes and Consensus Nodes. Compute nodes can execute smart contracts that deal with sensitive datawithin SGX enclaves, but are also responsible for key management. Therefore, each computing node is able to introduce various TEE instances, both contractual TEEs and Key Manager TEEs. Contract TEEs are used to execute smart contract code and generate attestations as proof of correct calculation, while the entire key management is delegated to special TEE key managers, who together form a key management committee (KMC) and are synchronized via blockchain. Therefore, key manager TEEs are responsible for generating random and impartial keys, as well as providing them to contractual TEEs through secure channels for data encryption and decryption. In contrast, consensus nodes maintain the blockchain and thus ensure consensus between ledger nodes. The underlying blockchain system features a general purpose append-only distributed ledger that maintains encrypted and persistent contract states, as well as attestations issued by compute nodes to verify state transitions. Finally, clients represent end users who are able to create new smart contracts or execute existing ones.2) System Initialization: A client needs to initiate the creation of a contract by sending a piece of smart contract code to a compute node , where the contract is initialized within a TEE contract. The contract TEE generates a new contract ID, acquires a new contract-specific public/private key pair for encrypting and decrypting client input, as well as a symmetric secret state key for encrypting and decrypting state from one of the key manager TEEs. It then generates a new encrypted initial contract state and remote attestation as proof of correct initialization. Next, the compute node retrieves a verification attestation from the Intel attestation service and sends the contract code, the public key associated with the contract ID, the encrypted initial state, and both attestations to the consensus nodes, which verify the generated attestations and then store the remaining information received from the computing node on the blockchain in case of acceptance. 3) Transaction Workflow: From then on, a customer can request contract code execution by acquiring the contract-specific public key from the blockchain, encrypting their input data using the retrieved key, and then sending the encrypted input along with the contract ID to a compute node. In the next step, the contract TEE of the compute node obtains the contract code and previous state encrypted by the blockchain. Together with the secret state key and private key for input encryption/decryption provided by the TEE key manager, the client's state and input are loaded into the TEE contract. After the client input and state are decrypted with the two provided keys, the contract code is executed, producing a resulting output and updated state. The last steps in this sequence include transmitting the new encrypted state and an attestation to the consensus nodes, as well as outputting it to the client. These messages must be delivered atomically, so the output is sent to the client only if the consensus nodes accept the state transition as valid by verifying the TEE signature. The updated and encrypted state is then stored on the blockchain.C. The Coco FrameworkTo overcome the limitations of public networks such as Bitcoin and Ethereum, Microsoft developed the Confidential Consortium (Coco) Blockchain Framework. According to [4], it is an on-chain execution where a network existsreliable network of nodes that form the distributed ledger. The consortium identified that existing public networks fail to meet important requirements including “acceptable transaction speed and latency, confidentiality, effective governance and computational efficiency” [4]. The TEEs used by the Coco framework are Intel SGX primary and “Windows Virtual Secure Mode (VSM)” [4].1) System architecture: A system based on the Coco framework is composed of a distributed network of “trusted validator nodes (VNs) ) )” [4].The trusted enclave is contained within a VN and the VNs together run the blockchain framework and protocol. Therefore, the VNs accept transactions and participate in the consensus algorithm of the network be managed by a network actor. Depending on the purpose and policies of a consortium, a network actor can be a member or a participant of a consortium” [4]. Participants, however, have no control over the governance or operation of the network. They execute transactions on the network if permitted by the members. Depending on the consensus algorithm chosen, one or several VNs process the transactions and execute the smart contract code. In [4] it is mentioned that VNs are capable of verifying the identity of other VNs, which is why they are considered completely trustworthy. This is not the case with public blockchain networks. Fig. 6 illustrates the architecture of the framework. To allow authorized end users without identities to interact with the network, network members and participants provide front-end systems. 2) System Initialization: According to [4], there are some policies that govern the framework. These include the Member List and VN, Code Manifesto, TEE Manifesto and Voting Policies. To initialize the system, one of the members must start the first VN and upload a genesis constitution to the network. Before that, the member needs to setup a virtual machine with a TEE, for example Intel SGX. Then install a supporting operating system and the Confidential Consortium Blockchain Framework along with the desired blockchain protocol. Once the network constitution is uploaded, a communication channel is established between the VN and each front-end application. Finally, the member uploads its “private/public key shares” [4], which are essential for ensuring data integrity and confidentiality. Once the network is established, a member can make proposed changes such as including or eliminating members, participants, and VNs, among others. All existing members are required to vote for the proposed changes to be implemented. 3) Transaction Workflow: As mentioned above, transactions on the network can be performed by members and participants determined by the members. The Coco framework defines two types of transactions allowed on the network, namely “administrative transactions” and “application transactions” [4]. Administrative transactions are transactions that take place for network governance, such as adding or removing members, while application transactions are normal business transactions that are sent from end users to member and participant front-end systems via the secure communication channel .4) Consensus: Regardless of the type of transaction, to implement a change in the network, it is essential to achieve consensus. “The Confidential Consortium Blockchain Framework is designed to support pluggable consensus algorithms with plans to integrate Paxos-like consensus algorithms and Ceasar consensus, a Microsoft Research algorithm” [4].5) Secure communication: to ensure that network transactions can only be performed by VNvalid and to limit the visibility of transactions to them, the Coco Framework enforces secure “application-to-node and node-to-node” communication channels [4]. Transport Layer Security connections and network-wide data encryption limit data accessibility within the VN.D enclave. SCE-FabricThis section introduces an on-chain solution for secure chain code execution for Hyperledger Fabric (SCE-Fabric) and its corresponding prototype that enables the execution of smart contracts within Intel SGX enclaves, as proposed from [8]. Fabric represents an open source blockchain platform and is one of the Linux Foundation's Hyperledger [12] projects. Following a “new execution-order-validation paradigm” [8] for executing smart contract code, this solution attempts to maximize the flexibility, scalability, resilience, and privacy of the blockchain network. Although in Fabric, smart contract code execution occurs on many nodes, it gives the impression of execution on a single globally distributed blockchain computer.1) System Architecture: The SCE-Fabric prototype adopts a modular architecture. As expected from a TEE-based blockchain system, the execution of the smart contract code occurs within the trusted enclave, thus separating it from the peer. It outlines the main components of the system which include: a Chaincode Enclave, a Ledger Enclave, an Enclave Registry, and an Enclave Transaction Validator. Chain code enclave. It is within the chaincode enclave where the chaincode execution takes place following the specifications of the smart contract. The enclave also contains the chaincode library, which extends the Fabric interface with “additional support for state encryption, attestation, and secure access to blockchain state” [8].Ledger enclave. It maintains the ledger as integrity-specific metadata, which represents the latest blockchain state. When a new block arrives, it generates a cryptographic hash of each key-value pair in the blockchain state and stores the hash within the enclave. Integrity-specific metadata can be accessed via the enclave interface, and in this way the correctness of the retrieved data is verified. Enclave registry. Operating outside the SGX enclave, it is responsible for maintaining the list of all chaincode enclaves within the network and performing attestation with the enclave.Enclave chaincode transaction validator. It is responsible for verifying the validity of signatures on the transaction and ensuring that it is issued by a registered enclave. Send valid transactions to the ledger enclave, where the decision is verified before the transaction is finally inserted into the ledger.2) System initialization: it is with the genesis block, containing the expected hash, that the ledger enclave is initialized . The registry enclave proceeds with initialization only if the actual hash obtained from the peer matches the expected value. It then generates a private/public key pair so that the registry enclave can be uniquely identified. The registry enclave also receives the public keys of peers, clients and the “ordering service” [8], which are used to authenticate the transactions it will receive. The ordering service is a component of the Fabric network that "establishes the total order of all transactions and broadcasts them as blocks of transactions to all peers in the network" [8].3) Transaction workflow: execution of the chaincode is activated when a client first proposes a transaction and sends it to the peer. The peer receives it and sends it to the chaincode enclave. After chaincode execution, a response is sent to the peer, which forwards it to theclient. The client then extracts the results of the executed execution and sends the transaction to the ordering service. Transactions accepted by the ordering service are assigned to blocks and transmitted to all peers in the blockchain network. Peers are required to validate transactions so that the transaction process can be finalized. To validate transactions and confirm the chaincode enclave that created the transaction, a peer uses a “validation system chaincode (VSCC)” [8]. Fig. 9 explains the validation process graphically. Once the enclave transaction validator declares the transaction to be valid, accordingly, the peer's local ledger and blockchain state must be updated.III. EMERGING CONCERNS AND TECHNICAL CHALLENGES So far, the design, system architecture, initialization, and key transaction workflow aspects of four different solutions, where smart contracts are executed within TEEs, have been described. While there are notable differences between on-chain and off-chain approaches, all four prototypes discussed above aim to secure blockchains to keep transaction data secret. They offer numerous benefits, however, running smart contracts within a TEE also introduces several challenges. For example, since TEEs are generally stateless and therefore susceptible to rollback attacks as described below, this could lead to loss of confidentiality [8]. In this section, we will look at some of the technical obstacles associated with running smart contracts within TEEs, how existing solutions attempt to overcome them, as well as other emerging concerns that have yet to be addressed and not fully resolved by existing frameworks . As mentioned above, support for attested execution through a remote attestation mechanism is a key feature of TEEs. Attestation allows customers to verify that the correct smart contract is loaded and executed in an authentic TEE, which is critical to establishing trust in a smart contract within a TEE on a potentially untrusted node. However, attestation is expensive as it usually requires an interactive protocol [9]. The Intel SGX attestation protocol involves consulting a third party, IAS, for each attestation. The four solutions introduced above avoid this problem by performing the attestation only initially and storing the attestation result in the registry. According to [9], attestation is currently supported only by a subset of available TEEs such as Intel SGX. To prevent TEE vendor lock-in and ensure interoperability, the industry needs to adopt a common set of security features including attestation, as also suggested by the Keystone-enclave project [13]. Another problem faced by most public blockchains modeled after Bitcoin [1], is that they do not reach a definitive consensus. “Their consensus mechanism is based on a randomized protocol, where for each epoch (or “block height”) a node selected through a hard-to-influence probabilistic scheme (like a “proof of work”) spreads a block of transactions to add to the blockchain” [8]. These blocks are propagated to all nodes in the network following an efficient peer-to-peer gossip protocol. However, strict consistency is not yet guaranteed. When a node receives a block as a candidate to extend the current chain, the node must validate the contents of the block and ensure that all transactions within the block are correct. In Bitcoin terms, the validation phase just means verifying that the status of thecoin has not been spent previously, but for blockchains like Ethereum, validation includes executing all transactions and calculating corresponding state updates. If the block is valid, consequently, the node appends it to the local chain and updates its status. However, despite subsequently receiving other valid blocks, there is still the possibility that a node cancels previously received transactions and therefore there can never be a definitive consensus. A node is forced to continue participating in the consensus protocol indefinitely to ensure the validity of its blockchain state. From this discussion and the analysis carried out by [8], it is clear that TEEs cannot be used in the case of non-final consensus-based blockchains. “Consensus blockchains that have no final decisions, such as proof of work in Bitcoin or Ethereum, are inherently unable to benefit from TEEs to maintain confidentiality” [8]. By allowing only final transactions to be executed on the TEE, attempting to restore its state would lead to an attack. A common way to prevent rollback attacks is to ensure state continuity through specific mechanisms, for example by enforcing that the enclave's state input for contract execution always matches the blockchain state committed by all peers, as stated in [8]. Support for non-deterministic transactions, which incorporate randomness into their calculation, constitute another challenge for TEE-supported smart contract systems. Theoretically, this problem can be solved by performing transactions within a single TEE and applying the resulting state on all ledger nodes, but as mentioned in [9], it is practically impossible to verify whether the calculation is correct, especially because the enclaves can be compromised and therefore the integrity of the calculation is no longer guaranteed. This makes it difficult to distinguish between a non-deterministic transaction and a compromised enclave, so the need for appropriate mechanisms arises, but such mechanisms still need to be developed to overcome this problem. It is now clear that TEEs aim to protect confidentiality. However, side-channel attacks on smart contract systems could lead to data loss, as stated in [3]. Since there is currently no general approach to safeguarding a smart contract system from collateral attacks, protection measures are not introduced by all the solutions presented above. “Key management is critical to the availability of a TEE-blockchain system” [3], but the question arises of how to make encryption keys persistent. Replicating keys across multiple TEEs carries the risk of key exfiltration, such as in the case of privacy breaches through side-channel attacks. There is therefore a trade-off between the availability of replicated keys and the risk of exposure, since “a higher replication factor means not only better resilience to state loss, but also a larger attack surface” [3]. executing smart contracts within TEEs have been mentioned in [3], [4], [8] and [10], one of the biggest arguments against using TEEs is that they do not guarantee availability. In the case of SGX, a malicious host can terminate enclaves, and even an honest host could lose enclaves in a shutdown cycle. Malicious hosts could also manipulate the scheduling or I/O of a TEE, as well as arbitrarily drop messages. Non-availability can lead to the risk of having conflicting states or even losing the state [3]. As proposed by [9], a possible solution to limit this risk is to execute the same contract code on multiple nodes, but this approach, in turn, imposes additionaltechnical challenges. In addition to side channel attacks and availability failures, timer failures can also occur as a fully reliable timer is not guaranteed within SGX enclaves. Malicious hosts are capable of delaying the clock readout, which can lead to an outdated view of the blockchain within the TEE or computation with outdated input states [3]. Overall, the proposed solutions should provide means to identify compromised TEEs and tolerate or better eliminate such enclaves. Furthermore, the impacts of TEE failures should be contained as much as possible. From the discussion above, we can deduce that several pitfalls arise when harmonizing TEE and blockchain. While some of these can serve as building blocks for the conceptual design of prototypes, others still pose serious risks and need to be addressed by the new generation of smart contract protocols.IV. COMPARATIVE EVALUATION OF THE PROPOSED SOLUTIONS The choice of smart contract system has many implications, since they all have different properties, even if they are based on the same idea, that is, combining smart contract execution with trust computing via TEE. Each of the proposed solutions mentioned above can bring benefits, but also presents some shortcomings, which are identified and evaluated below.A. Architectural DifferencesAlthough all four solutions have in common that they are based on Intel SGX and therefore support attestations for proof of execution, their individual designs and implementations show notable differences. As stated previously, the categorization into on-chain and off-chain smart contract execution directly affects the architecture of such systems, but nevertheless, specific solutions for different types of approaches also differ in their architectural composition regarding the entities involved , their particular roles and how they interact with each other. While both offchain approaches, Ekiden and PDO, only encapsulate the execution of the smart contract code in SGX enclaves via special TEE nodes and persistently store the current state of the contract on the ledger in an encrypted manner [3], Coco and SCEFabric as on-chain approaches make use of blockchain nodes equipped with TEEs [9]. The Coco framework implements almost all of its functionality within an enclave on a blockchain node as stated in [4] and [9], so the local ledger and also state management are maintained within the TEE. As a result, the size of the Trusted Computing Base (TCB) is relatively large. SCEFabric, on the other hand, extends a Hyperledger Fabric peer via two enclaves, namely a chaincode enclave and a ledger enclave [8], as described above. In this way, SCE-Fabric only entrusts a fraction of the blockchain node's responsibilities to a TEE and leaves the rest in an untrusted environment, which leads to a smaller TCB size than Coco and thus decreases the attack surface [8 The architecture The choices also imply that on-chain TEEs have direct access to the local ledger, while the state of a contract must be retrieved from the blockchain when using off-chain enclaves, which can involve complex mechanisms [9] . Coco and SCE-Fabric create a network that is likely to be composed of known, approved and therefore trusted peers [4], [10], while PDOs are also designed for private and permissioned environments. Ekiden, on the other hand, can be used in both authorized and unauthorized settings [3].B. Consensus level dependence Since on-chain approaches aim to provide ledger nodes with TEE, enclaves must be properly integrated into blockchain nodes, which is why SCE-Fabric, as it suggeststhe name, depends on Hyperledger Fabric as a distributed ledger technology [8 ]. The goal of the Coco framework is to support multiple consensus protocols through pluggable consensus algorithms [4], but its initial prototype is based on Ethereum. In contrast, off-chain solutions make use of a ledger abstraction that generally allows them to run on different blockchain systems [9]. The Ekiden prototype implements Tendermint as the consensus layer [3] and the PDO project is based on Hyperledger Sawtooth [10].C. Key Management Another property that allows for the distinction is the key management mechanism used by each of the solutions. In this sense, Ekiden maintains the TEEs of the key managers who together form a key management committee, share a secret key for each contract with each other, and provide the contract TEEs with public/private key pairs [3]. On the contrary, PDOs make use of key-provisioning services that provide enclaves with cryptographic material for encryption and decryption [10], so the risk of TEE availability is limited. Coco outsources key management to an on-premise or cloud-based key management system, such as a hardware security module (HSM) [4], where the generated private keys persist, while the corresponding public keys of the members of the consortium or participants are stored on the blockchain. Finally, SCE-Fabric offers client-based encryption for state encryption, where key management is performed by the client, or encryption for chaincode, where the administrator must provide chaincode enclaves with a chaincode-specific key during the bootstrap phase [8].D. Scalability Regarding the scalability of the smart contract system, the proposed approaches show different capabilities. Although the PDO system shows a greater focus on scalability than Ekiden [10], in general, both systems are relatively easy to scale, as the number of TEE-supported compute nodes and the number of blockchain nodes can be increased independently l 'from each other [ 3]. According to the whitepaper published by Microsoft, Coco provides a large-scale framework that “approaches the performance and scalability of a traditional centralized database” [4]. Compared to Hyperledger Sawtooth, Hyperledger Fabric is not as scalable [10], so SCE-Fabric systems do not necessarily show as high scalability capabilities as PDOs. Performance EvaluationsIn terms of design and implementation status, Ekiden and SCE-Fabric have provided prototypes and evaluation reports on different measurements such as throughput or latency, performed for specific applications. The Ekiden prototype “achieves sample performance of 600x more throughput and 400x less latency at 1000x lower cost than the Ethereum mainnet” [3] for the ERC20 token standard. In contrast, the SCE-Fabric prototype “achieves 0.80x-0.95x the throughput achieved by native execution” [8], whereby native execution refers to using the Hyperledger Fabric implementation without SGX enclaves. At the same time, it shows an overhead of 10-20% for a sealed-bid application caused by encapsulating the smart contract execution in a TEE [8]. Coco, however, describes two demos performed with a functional prototype of the framework, based on Ethereum, focusing on scalability and confidentiality. The result of the demos shows that “transaction rates were approximately 100 times faster than a non-framework-based protocol” [4]. In contrast, the PDO document does not mention any evaluation, but emphasizes that it is an open source Hyperledger Labs project, which lays the foundation for further development and demonstrations [10]. So long asthe measurements were carried out only for some applications which differ between the approaches, from the results it is not possible to draw a general conclusion on which of the solutions has the best overall performance. However, so far, Ekiden's results look more promising and its performance surpasses that of the other three.F. Non-deterministic transactions As stated in the previous section, there are several challenges that arise from combining smart contracts with TEEs. The proposed solutions attempt to address some of them, but there is no one approach that solves them all. For example, to the best of our knowledge, only the Coco framework allows the execution of non-deterministic transactions [4]. Similar to SCE-Fabric, which states that transactions are deterministic by default [8], Ekiden simply defines a smart contract as “a program with deterministic state” [3] and therefore contract methods must also be deterministic. The PDO document [10] does not mention any support for executing non-deterministic transactions.G. Compromised System ComponentsCompromised system components have different impacts depending on the resolution approach. Since a compromised enclave could affect the entire network by exposing sensitive data or committing erroneous transactions, it is essential to aim to minimize the potential attack surface. Additionally, primary design goals should include detecting harmful components, minimizing their impact and the damage they may cause to the system, and eliminating those components. In this sense, PDOs distinguish between data confidentiality violations and integrity violations. A breach of confidentiality means that an enclave is compromised and thus private data can be exposed, while ensuring correct execution. In the case of an integrity violation, the correctness of the calculation may also be compromised [10]. PDOs provide mechanisms to protect against both attacks, for example, to maintain confidentiality, methods implemented include using enclaves from trusted enclave hosting services and reducing the number of enclaves provided per contract, but this approach involves a trusted third party to provide the enclaves. While confidentiality may not be guaranteed at all times, execution integrity can still be preserved by verifying the calculation result of an enclave by rerunning the same method on one or more other enclaves. In this way, integrity is guaranteed and misbehaving enclaves can be identified and revoked. Ekiden seeks to mitigate the impact of integrity risks and data leakage by designing critical components “against a strong adversarial model, allowing an attacker to break the confidentiality of a small fraction of TEE” [3], but limiting the access critical components from other system components. If the confidentiality of a computing node is threatened, a secrecy and isolation mechanism is used. Additionally, Ekiden implements proactive key rotation in case a key manager node becomes compromised, but does not cover measures to circumvent contract-level data leakage through side channels or software bugs. The Coco framework distinguishes between compromised validation nodes and compromised enclaves. One of the mechanisms implemented by Coco is that a VN needs partial decryptions from other nodes to decrypt data, so a single malicious VN is unable to fully decrypt sensitive data on its own [4]. Similar to PDOs, Coco proposes to execute transactions synchronously across multiple nodes for verification and rapid compromise detection. Measures to mitigate the risks of harmful components, such assoftware error isolation techniques are also introduced by the Coco framework [4]. Finally, SCE-Fabric states that a malicious peer could interfere with the invocation order of contract operations or feed the enclave system with spurious input, but “cannot access or tamper with the code and data residing in an enclave” [8 ], therefore the correctness of the execution itself is guaranteed in any case. In order to avoid incorrect execution order, SCE-Fabric implements an execution order validation architecture, which forces a peer to execute a transaction before the transaction order is decided via consensus. Therefore, SCE-Fabric uses a reliable ordering service that cannot be canceled and is consulted for every transaction sent by a customer, thus ensuring continuity of status. However, SCE-Fabric does not prevent denial-of-service attacks or side-channel leaks [8].H. Individual advantagesIn addition to the properties mentioned above, each of the existing solutions has advantages that are not present in the other approaches. For example, Ekiden provides several performance optimizations for their system, which contribute to the notable performance improvement over the Ethereum mainnet when evaluating their prototype in [3]. PDOs focus on smart contracts involving mutually distrusting parties, where contract owners have freedom of choice regarding the selection of enclaves used for contract execution from different enclave hosting services and migration of enclaves is also possible contract performances [10], e.g. in the event of removal or failure of the TEEs. The Coco framework is the most generic solution, as it supports pluggable blockchain protocols “such as Ethereum, Quorum, Corda or Hyperledger Sawtooth” [4]. One of the main design goals of SCE-Fabric, in addition to the general goal of ensuring privacy and confidentiality, is to minimize the size of the trusted computing base, as this represents an "important cybersecurity principle" [8] in order to decrease the potential attack surface. This is achieved by identifying trusted and untrusted components of applications and limiting the amount of code executed within an enclave as much as possible in order to reduce the potential attack surface.I. Using Trusted Third Parties All proposed solutions depend on a trusted third party for verification of SGX enclaves, namely the Intel Attestation Service. The IAS, created by hardware manufacturer Intel, must be consulted for each SGX enclave to ensure non-falsifiable and authenticated attestations issued by the enclaves [11] and therefore must be trusted by all entities. This procedure directly contradicts blockchain's core concept of eliminating third-party involvement in distributed ledger systems. Furthermore, PDOs rely on enclave hosting services [10], which own platforms to provide SXG enclaves to PDOs, so there may be even more third parties participating in the smart contract system.J. Summary In summary, the choice of solution approach depends on the actual use case to which it should be applied and the needs required by the application, such as privacy or performance requirements [9]. They all show different benefits, but also weaknesses due to architectural design, so solution-specific tradeoffs must be considered and weighted before selecting an approach in order to identify the best solution for each application or use case. So far no fully satisfactory general solution has been proposed to solve the problem of/