Table of contentsSummaryI. INTRODUCTION. MotivationII. STATE OF THE ART. Private data objectsB. EkidenC. The CocoD framework. SCE-TissueIII. EMERGING CONCERNS AND TECHNICAL CHALLENGESIV. COMPARATIVE EVALUATION OF PROPOSED SOLUTIONSSA. Architectural differencesB. Consensus layer dependencyC. Key managementD. ScalabilityE. Performance evaluationsF. Non-deterministic transactionsG. Compromised system componentsH. Individual benefitsI. Use of trusted third partiesJ. SummaryV. CONCLUSION AND PERSPECTIVEREFERENCESSummaryA smart contract is an application that runs on blockchains. It digitally enforces agreements between distrustful parties. Smart contracts inherit the security guarantees of blockchains, but their lack of privacy raises concerns and limits the applicability of smart contracts, while blockchains also pose a performance bottleneck. Combining smart contracts with Trusted Execution Environments (TEEs) is a way to prevent unauthorized access and manipulation through untrusted blockchain nodes, thereby solving privacy concerns. This article reviews four existing frameworks that integrate trusted execution environments into their smart contract systems, examines the different architectures, discusses individual strengths and weaknesses, and performs a detailed comparative evaluation of the four approaches in order to find the right one. combination of characteristics that a Next generation smart contracts should possess. Say no to plagiarism. Get a tailor-made essay on “Why Violent Video Games Should Not Be Banned”? Get the original essay Index Terms: Smart Contracts, Blockchains, TEE, Privacy, ConfidentialityI. INTRODUCTIONDistributed ledgers and in particular blockchains are emerging technologies that have recently attracted a lot of attention, as 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 hand. Smart contracts like Ethereum [2] are programs running on blockchains, 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 various industries, including finance, insurance, identity management, and supply chain management [3]. Typically, even the creator of a smart contract cannot modify its code or reverse its execution. The smart contract code is replicated across all network participants to ensure verifiability, fault tolerance, and availability. But even though such smart contract systems offer a number of advantages, they present several problems that limit their applicability, especially for certain areas of use, because they inherit some undesirable properties of blockchain. MotivationAs noted in [3], the most notable drawback of existing smart contract systems is the lack of privacy, which results from the distributed and publicly accessible nature of blockchain data. In order to verify correct calculation and validate state transitions, contract methods are calculated on each node in the network and the entire contract state is stored publicly, even if a contract processes sensitive data and the Blockchain nodes are owned by untrusted parties. Thisprocedure is a fundamental feature of distributed ledgers, which allows transactions without intermediaries, but at the same time it presents a data privacy problem, since it opens the risk of potential information leaks or privacy threats such as data theft. As a result, privacy concerns create a demand for new approaches in terms of smart contract systems, capable of protecting access to data in one way or another. According to [3] and [4], another problem of conventional smart contracts is limited performance. of most blockchain protocols with respect to computing power, transaction throughput and latency, which are also associated with high processing costs. 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 enterprise applications. Therefore, the goal of new smart contract systems is to improve transaction speed and latency, without imposing privacy trade-offs. Cryptographic protocols like secure multi-party computation, like Enigma [5], or zero-knowledge proof systems like Zerocash. [6] or Hawk [7] promise to provide a privacy-preserving approach to blockchains using cryptographic primitives. However, due to relatively high performance overhead, they incur high costs and do not provide a general-purpose solution, as discussed in [3] and [8]. As an alternative approach, several papers propose the combination of smart contracts with trusted execution environments (TEEs) to attempt to address the privacy, privacy, and performance limitations of smart contracts. This is achieved through the use of reliable hardware that provides fully isolated execution environments, such as Intel Software Guard eXtensions (SGX). Since Intel SGX, a processor-based implementation of TEE, is the predominant TEE technology used in recently proposed TEE-based smart contract solutions, the paper primarily focuses on this trusted computing technology.B. Secure Execution Environments (TEE) Intel SGX provides secure hardware enclaves to run computations with sensitive data, such as private data and confidential contract states, by implementing a memory encryption mechanism that allows space for isolated and therefore sealed addressing. Therefore, the memory space is not accessible to the operating system, the host owner, or other applications and TEEs, as described in [3] and [8]. In order to achieve this property, a key management mechanism is used to generate and manage public and private keys, necessary for encryption and decryption of sensitive data inside an enclave. Before the data leaves the TEE and can be stored in the ledger, it is encrypted with keys that are only known to the processor of the associated hardware enclave. In this way, data integrity is guaranteed and unauthorized access, as well as data manipulation via untrusted blockchain nodes, are corrected. The lack of confidentiality is thus corrected. Another important feature of TEEs is the support of attested execution through 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 duringof execution. An enclave's attestation keys, which are used to generate the digital signature, can be verified using an attestation protocol, such as the Intel Attestation Service (IAS), a certificate of trust provided by the manufacturer, in this case Intel, which guarantees tamper-proof and authenticated certificates by validating the TEE. This procedure promotes verifiable calculations by providing proofs of correctness, even if enclaves run on potentially untrusted nodes. Due to shifting the computation to TEEs, the performance overhead is reduced and thus the transaction speed, throughput and latency are improved, since the computation is simplified through unencrypted data processing [3]. Additionally, other performance optimizations are possible, depending on the particular solution approach. In summary, TEEs can provide secure remote computation of sensitive data and, by hybridizing TEEs and blockchains, smart contract systems can leverage both technologies in order to overcome the issues arising from running smart contracts on blockchains in the clear. As a result, reliable and privacy-preserving smart contract systems with high performance can be enhanced, so that the applicability of smart contracts is extended to applications with strong privacy requirements, e.g. 'insurance. Recently, a number of hybrid TEE smart contract systems have been developed. Existing solutions proposed by disparate research groups have conceptual differences, but generally speaking, 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 following section based on four different smart contract systems based on TEE.II. STATE OF THE ARTCompared to on-chain approaches, where smart contracts are executed within TEEs directly deployed on blockchain nodes, off-chain solutions propose the use of special non-blockchain nodes equipped with reliable hardware [9]. . Thus, the approaches present opposing architectures and concepts, which are described separately in the following by means of two existing off-chain and two on-chain solutions, namely Private Data Objects [10], Ekiden [3], the framework Coco [4 ] and SCE-Fabric [8]. Both smart contract approaches supported by TEE 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,(PDOs) represent Intel's off-chain approach to executing,smart contracts involving private data on a distributed ledger,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 that the parties have agreed upon, and an enclave hosting service providing SGX enclaves. PDOs use an SGX-based enclave hosting service, such as as a cloud provider, enabling off-chain contract execution in Intel SGX enclaves, and relies on Hyperledger Sawtooth as a platform. form of distributed ledger, which offers greater scalability than Hyperledger Fabric, as it is designed to be able to scale to a large number of nodes [10]. Additionally, Hyperledger Sawtooth canensure strict privacy requirements through the use of customizable transaction families, as described below, particularly in combination with trusted computing. Ledger nodes are responsible for verifying and recording transactions, which "allows contracting parties to retrieve and verify data related to contract and enclave instances, as well as serialize and validate transactions." contract status updates” [10]. Therefore, PDOs implement three types of custom transaction families, namely Contract Ledger, Enclave Ledger, and Coordination and Validation Log (CCL). They abstract the layer in such a way that each transaction family defines specific custom operations and rules to modify the state of the ledger. Each transaction submitted to the general ledger must respect the rules of the associated transaction family, otherwise it will be rejected and therefore not annexed to the general ledger. As the name already suggests, the Contract Registry family of transactions defines contract management, such as registering a contract and adding or removing enclaves allowed for the execution of a specific contract, while that the Enclave Registry family of transactions is responsible for transactions regarding enclave management such as registering, updating, or revoking an enclave. On the contrary, the CCL family of transactions allows the construction of a dependency graph composed of dependencies between state transition transactions, which "allow the specification and application of the progress of a contract state conditional on the progress of other contractual states, while allowing maximum competition. between interacting contracts and ledger interactions” [10]. 2) System initialization: Before a smart contract can be executed securely in trusted environments, a PDO instance must be created by registering SGX enclaves and the ledger contract. First, an enclave must be verified by the Intel Attestation Service, to ensure reliable attestations, and then recorded in the ledger by the enclave hosting service as a record transaction. enclave, which includes the audit report produced by the IAS. , the owner of the enclave and the public keys of the enclave. Such a transaction must follow the rules of the Enclave Registry family of transactions. Rather, contract registration is initiated by the contract owner and divided into several phases. First, the contract is entered into the general ledger as a contract registration operation, which must comply with the rules defined by the Contract Registry family of operations and is followed by an execution authorization of the contract. When authorizing execution, the contract holder submits a request for the provision of keys to the provisioning services in order to be able to supply the registered enclaves with cryptographic material as part of the subsequent phase of provision of the contract enclaves. The provisioned enclaves are then able to encrypt and decrypt the contract state using the keys provided by the provisioning services. This procedure allows the contract state encryption to be independent of the enclave and also of the enclave service. During these phases, the contract owner acts as an intermediary between the ledger, the provisioning services and the enclave hosting services, so there is no direct interaction between the ledger and TEEs. As a final step, the contract holder provides proof of supply, signed by the enclave, to the ledger, which completesthe contract registration and execution authorization process, resulting in the disclosure of a set of procurement services, together with a list. of enclaves authorized and provisioned for a specific contract on the ledger. 3) Transaction workflow: As soon as the contract and associated enclaves are registered on the distributed ledger, an authorized user can trigger smart contract method invocations, which are carried out by the contractual interpreter of an enclave. Initially, when the first smart contract method is invoked by the user, the contract interpreter initializes an empty state. Subsequent method calls can then lead to state updates. Figure 3 shows a contract method invocation sequence 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 either by enclaves or by a contract, depending on predefined policies. Then it must retrieve the latest state of the contract in the ledger. After the corresponding contract code is executed on the trusted hardware, the user receives the result of the enclave calculation and can then submit a transaction including the resulting state transition to the ledger, which is verified and recorded by the ledger nodes in terms of correct attestation before acceptance. 4) Security aspects: As shown in Figure 3, a user acts as a communication channel between the distributed ledger and the SGX enclave, which executes the contract code clever. The channel concept requires the user to generate a new public/private key pair for each method invocation. By including the user's signature and public key in the method invocation and validation of the resulting transaction, ledger nodes can verify whether the transaction signature belongs to the user who signed it. submitted. This way it is guaranteed that a transaction resulting from a specific method call is only committed by the user who actually invoked the method. Additionally, this mechanism guarantees 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. Both private keys are stored in the enclave's sealed memory, but their public counterparts are needed for attestation, so these keys are recorded and can thus be retrieved from the ledger. The verification public key is used to validate the enclave's signature, while the encryption public key is needed to provide confidential contract status to the enclave. The state of a contract “indicates the (private) data that an AOP associates with a specific contract” [10] and is available in plain text inside the enclave. Before a state leaves the TEE, it is encrypted by the enclave via the contract-specific encryption key and, analogously, the enclave decrypts the state it receives from the user for the purpose of calculation.B. EkidenThe second off-chain execution approach to combining blockchains with TEEs 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 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 generates minimal performance overhead due to off-chain computation of smart contract data. From thisIn this way, Ekiden is able to efficiently support large-scale applications with strong privacy requirements, while preserving availability and integrity as fundamental characteristics of the blockchain. Its working prototype is built on Tendermint as a consensus layer, but the architectural design facilitates its compatibility with different blockchain systems, with permissioned (private) or permissionless (public) consensus layer mechanisms, since the only prerequisite for blockchain nodes is the capacity. of attestation validation.1) System architecture: Ekiden provides an architecture composed of three different types of entities, namely clients, compute nodes and consensus nodes. Compute nodes can run smart contracts processing confidential data within SGX enclaves, but are also responsible for key management. Therefore, each compute node is capable of inducing various TEE instances, either Contract TEEs or Key Manager TEEs. Contract TEEs are used to execute the smart contract code and generate attestations as proof of correct calculation, while all key management is delegated to special key manager TEEs, which together form a management committee keys (KMC) and are synchronized via the blockchain. Thus, key manager TEEs are responsible for generating random and unbiased keys, as well as providing them to contracted TEEs via secure channels for data encryption and decryption. Rather, consensus nodes maintain the blockchain and thus ensure consensus between ledger nodes. . The underlying blockchain system is characterized by an append-only distributed general ledger that maintains encrypted and persistent contract states, as well as attestations issued by compute nodes to verify state transitions. Finally, clients represent the end users capable of creating new smart contracts or executing existing contracts. 2) System initialization: a client must initiate the creation of a contract by sending a piece of smart contract code to a node of calculation, where the contract is initialized in a contract TEE. The contract TEE generates a new contract ID, acquires a new contract-specific public/private key pair for encryption and decryption of client input, and a symmetric secret state key for encryption and decryption of the state to one of the key manager's TEEs. Then it generates a new initial state of the encrypted contract and a remote attestation as proof of the correctness of the initialization. Subsequently, the compute node retrieves a verification attestation from the Intel Attestation Service and sends the contract code, the public key associated with the contract identifier, the encrypted initial state and the two attestations to the consensus nodes, which verify the generated attestations and then store the remaining information received from the compute node on the blockchain if accepted. 3) Transaction workflow: From here, a client can request execution of the contract code by acquiring the contract-specific public key from the blockchain, encrypting its own input data using the retrieved key, then sending the encrypted input with the contract ID to a compute node. In the next step, the TEE contract from the compute node obtains the contract code and the encrypted previous state from the blockchain. With the secret state key and private key for encryption/decryption of inputs provided by the TEE key manager, the client's state and input are loaded into the TEE contract. Once customer input and statusdecrypted with the two provided keys, the contract code is executed, producing a resulting output and updated state. The final steps in this sequence include transmitting the new encrypted state and attestation to the consensus nodes, as well as outputting to the client. These messages must be delivered atomically, so the output is only sent to the client if the consensus nodes accept the state transition as valid by verifying the signature of the TEE. The updated and encrypted state is then stored on the blockchain.C. The Coco frameworkIn order to overcome the limitations of public networks like Bitcoin and Ethereum, the Blockchain Confidential Consortium (Coco) framework was developed by Microsoft. According to [4], it is an on-chain execution in which there is a network of trusted nodes that forms the distributed ledger. The consortium identified that existing public networks do not meet important requirements, including “acceptable transaction throughput and latency, privacy, effective governance, and IT efficiency” [4]. The TEEs used by Coco Framework are the main Intel SGX and the "Windows Virtual Secure Mode (VSM)" [4]. 1) System architecture: a system based on the Coco framework is composed of a distributed network of "network nodes". trust validation (VN). )” [4]. The trust enclave is contained in a VN and the VNs together run the framework as well as the blockchain protocol. Therefore, VNs accept transactions and participate in the network consensus algorithm. A VN can be hosted by a network actor. Depending on the objective and policies of a consortium, a network actor can be a member or a participant. Members collectively decide which actors can transact on the network and can be considered “governing bodies of a consortium” [4]. Participants, on the other hand, have no control over the governance or operation of the network. They transact on the network if members allow it. Depending on the consensus algorithm chosen, one or more VNs process transactions and execute the smart contract code. It is mentioned in [4] that VNs are capable of verifying the identity of other VNs, which is why they are considered to be completely trustworthy. This is not the case in public blockchain networks. Figure 6 illustrates the architecture of the framework. To enable identity-less authorized end-users to interact with the network, network members and participants provide front-end systems.2) System Initialization: According to [4], certain policies govern the framework. These include the Membership and VN List, Code Manifesto, TEE Manifesto, and Voting Policies. In order to initialize the system, one of the members must bootstrap the first VN and upload a genesis constitution to the network. Before that, a virtual machine with a TEE, for example Intel SGX, must be configured by the member. Next, it installs a supporting operating system and the Confidential Consortium Blockchain Framework along with the desired blockchain protocol. Once the network constitution has been downloaded, a communication channel is established between the VN and each front-end application. Finally, the member puts their “private/public key shares” [4] online, essential to guarantee the integrity and confidentiality of the data. Once the network is established, a member can make proposals for change such as the inclusion or elimination of 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 earlier, transactions on the network can be carried out by members andparticipants determined by the members. The Coco framework defines two types of transactions authorized on the network, namely “administrative transactions” and “application transactions” [4]. Administrative transactions are the transactions that take place for network governance, for example adding or removing members, while application transactions are the regular business transactions that are submitted by end users to members' front-end systems and participants via the secure communication channel. .4) Consensus: Regardless of the type of transaction, in order to implement 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, an algorithm from Microsoft Research” [4].5) Secure communication: for To ensure that network transactions can only be performed by valid VNs and to limit the visibility of transactions on 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 to the VN.D enclave. SCE-FabricThis section presents an on-chain solution for Secure Chaincode Execution for Hyperledger Fabric (SCE-Fabric) and its corresponding prototype enabling the execution of smart contracts in Intel SGX enclaves, as proposed by [8]. Fabric represents an open source blockchain platform and is one of the Hyperledger [12] projects of the Linux Foundation. By following a “new execute-command-commit 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 the execution of smart contract code happens on many nodes, it gives the impression of being executed on a single globally distributed blockchain computer. 1) System architecture: the SCE prototype -Fabric adopts a modular architecture. As expected of a TEE-based blockchain system, the execution of the smart contract code takes place inside the trust enclave, thus separating it from the peer. Describes the main components of the system, including: a Chaincode enclave, a Ledger enclave, an Enclave ledger, and an Enclave transaction validator. Chaincode enclave. It is inside the chaincode enclave that the execution of the chaincode takes place according to 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 most recent state of the blockchain. When a new block arrives, it generates a cryptographic hash of each key-value pair in the blockchain state and stores the hash inside the enclave. Integrity specific metadata is accessed through the enclave interface and in this way the correctness of the retrieved data is verified. Enclave Registry. Operating outside of the SGX enclave, it is responsible for maintaining the list of all chaincode enclaves present in the network and performing attestation with the chaincode enclave.Enclave transaction validator. It is responsible for verifying the validity of signatures on the transaction and ensuring that it is issued by a registered enclave. It sends valid transactions to the ledger enclave, wherethe decision is verified before the transaction is finally validated in the ledger.2) Initialization of the system: It is with the genesis block, containing the expected hash, that the ledger enclave is initialized. The ledger enclave initializes only if the actual hash obtained by the peer matches the expected value. It then generates a private/public key pair so that the ledger enclave can be uniquely identified. The ledger enclave also receives public keys from peers, clients and the “ordering service” [8], which are used for authentication of 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 in the form of transaction blocks to all peers in the network” [8]. 3) Transaction workflow: execution The chaincode is triggered when a client first proposes a transaction and sends it to the peer. The peer receives it and sends it to the chaincode enclave. Once the chain code is executed, a response is sent to the peer, which forwards it to the client. The client then extracts the results of the performed execution and sends the transaction to the ordering service. Transactions accepted by the ordering service are assigned to blocks and broadcast to all peers present in the blockchain network. Peers must validate transactions so that the transaction process can be finalized. In order to validate transactions and confirm the chaincode enclave that created the transaction, a peer uses a “validation system chaincode (VSCC)” [8]. Figure 9 graphically explains the validation process. Once the enclave's transaction validator declares the transaction to be valid, the peer's local ledger and blockchain state must be updated.III. EMERGING CONCERNS AND TECHNICAL CHALLENGESSo far, the design, system architecture, initialization and key transaction flow 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, the four prototypes discussed above aim to secure blockchains to keep transaction data secret. They offer several advantages, but running smart contracts within a TEE also presents several challenges. For example, since TEEs are generally stateless and therefore susceptible to rollback attacks as described below, this could lead to a loss of privacy [8]. In this section, we will examine 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 not yet been addressed and which are not fully resolved by existing frameworks. As mentioned previously, support for attested execution via a remote attestation mechanism is a key feature of TEEs. Attestation allows clients to verify that the correct smart contract is loaded and executed in a real TEE, which is crucial for establishing trust in a smart contract within a TEE on a potentially untrusted node. However, attestation is expensive because it usually requires an interactive protocol [9]. The Intel SGX attestation protocol involves consulting a third party, the IAS, for each attestation. The four solutions presented previously avoid this by only performing the attestation initially and storing the attestation result in the ledger. According to [9], attestation is currently only supportedby a subset of TEEs available like Intel SGX. To avoid TEE vendor lock-in and ensure interoperability, it is necessary for the industry 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 on Bitcoin [1] is that they do not reach a definitive consensus. “Their consensus mechanism is based on a randomized protocol, in which for each epoch (or “block height”) a node selected according to a probabilistic scheme that is difficult to bias (like a “proof of work”) broadcasts a block of transactions. to add to the blockchain”[8]. These blocks are propagated to all nodes in the network using an efficient peer-to-peer gossip protocol. However, strict consistency is still not guaranteed. When a node receives a block as a candidate for extending the current chain, the node must validate the contents of the block and ensure that all transactions inside the block are correct. In terms of Bitcoin, the validation step is only to verify that the state of a coin has not been spent earlier, but for blockchains like Ethereum, validation includes the execution of all transactions and the calculation of corresponding state updates. If the block is valid, the node adds it to the local chain and updates the state. However, even if it subsequently receives other valid blocks, there is always a possibility that a node will roll back previously received transactions and, therefore, there can never be definitive consensus. A node is obliged to continue participating in the consensus protocol indefinitely in order to guarantee 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 blockchains based on non-final consensus. “Blockchains with consensus without a final decision, such as proof of work in Bitcoin or Ethereum, are inherently incapable of benefiting 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 via specific mechanisms, for example by ensuring that the state entered by the enclave for contract execution always matches the state entered by the enclave for contract execution. he state of the blockchain which is validated by all peers, as shown in [8]. Deterministic transactions, incorporating randomness into their calculation, pose another challenge for TEE-backed smart contract systems. Theoretically, this problem can be solved by executing transactions in 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 since enclaves can be compromised. and therefore the integrity of the calculation is no longer assured. It is therefore difficult to differentiate between a non-deterministic transaction and a compromised enclave, which requires appropriate mechanisms, but such mechanisms still need to be developed in order to overcome this problem. It is now clear that TEEs are intended to protect privacy. However, side-channel attacks on smart contract systems could lead to data leaks, as discussed in [3]. Since there is currently no general approach to protect such a smart contract system against side-channel attacks, all solutions presented above do not introduce protective measures. “Key management is fundamental to availabilityof a TEE-blockchain system” [3], but the question arises as to how the encryption keys can be preserved. Replicating keys across multiple TEEs poses a risk of key exfiltration, such as in the case of privacy breaches via side-channel attacks. There is therefore a trade-off between the availability of replicated keys and the risk of exposure, because "a higher replication factor means not only better resilience to state loss, but also a larger attack surface" [ 3]. While several other concerns regarding the execution of smart contracts within TEEs have been mentioned in [3], [4], [8] and [10], one of the main arguments against the use of 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 during a power cycle. Malicious hosts can also manipulate the scheduling or I/O of a TEE, as well as arbitrarily delete messages. Availability outages can lead to the risk of having conflicting states or even losing state [3]. As proposed by [9], a possible solution to limit this risk is the execution of the same contract code on multiple nodes, but this approach, in turn, imposes other technical challenges. Besides side-channel attacks and availability outages, timer outages can also occur because a fully reliable timer is not guaranteed in SGX enclaves. Malicious hosts are capable of delaying the clock reading, which can lead to an outdated view of the blockchain inside the TEE or a calculation with outdated input states [3]. In general, the proposed solutions should provide ways to identify compromised TEEs and tolerate or rather eliminate such enclaves. Additionally, the impacts of TEE failures should be mitigated as much as possible. From the above discussion, we can infer that several pitfalls arise when harmonizing TEEs and blockchains. While some of them can serve as a basis for designing prototypes, others nevertheless present serious risks and must be taken into account by the new generation of smart contract protocols.IV. COMPARATIVE EVALUATION OF PROPOSED SOLUTIONSThe choice of smart contract system has many implications, as they all have different properties, even though they are based on the same idea, namely combining smart contract execution with trust computing via TEEs. Each of the proposed solutions mentioned above can bring benefits, but also has certain shortcomings, which are identified and evaluated below.A. Architectural Differences Although all four solutions have in common that they are built on Intel SGX and therefore support runtime proof-of-correctness attestations, their individual designs and implementations have notable differences. As noted above, the categorization into on-chain and off-chain smart contract execution directly affects the architecture of these systems, but nevertheless, the specific solutions to different types of approaches also differ in their architectural composition regarding the entities involved, their particularities. roles and how they interact with each other. While both off-chain approaches, Ekiden and PDO, only encapsulate the execution of smart contract code in SGX enclaves by means of special TEE nodes and persistently store the current contract state on the ledger in an encrypted manner [3], Coco and SCEFabric on-chain approaches use blockchain nodes equipped with TEE [9]. THECoco framework implements almost all of its functionality in an enclave on a blockchain node as shown in [4] and [9], so the local ledger as well as state management is maintained inside 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 by two enclaves, namely a chaincode enclave and a ledger enclave [8], as described above. This way, SCE-Fabric entrusts only 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 compared to Coco and thus decreases the surface area. attack [8]. 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 result in mechanisms complex [9]. Coco and SCE-Fabric create a network likely to consist of known, trusted and therefore trusted peers [4], [10], while PDOs are also designed for private and permissioned settings. Ekiden, on the contrary water, can be used in licensed or unauthorized settings [3].B. Consensus Layer Dependency Since on-chain approaches aim to provide ledger nodes with TEEs, enclaves need to be properly integrated into blockchain nodes, which is why SCE-Fabric, as the name suggests indicates, depends on Hyperledger Fabric as a distributed ledger technology [8 ]. The goal of the Coco framework is to support multiple consensus protocols via pluggable consensus algorithms [4], but its initial prototype is built on Ethereum. In contrast, off-chain solutions use a ledger abstraction that typically allows them to operate across different blockchain systems [9]. The Ekiden prototype implements Tendermint as a consensus layer [3] and the PDO project relies on Hyperledger Sawtooth [10].C. Key managementAnother distinguishing property is the key management mechanism used by each of the solutions. In this sense, Ekiden maintains key manager TEEs that together form a key management committee, share a secret key for each contract with each other, and provide contract TEEs with public/private key pairs [3]. In contrast, PDOs use key provisioning services that provide enclaves with cryptographic hardware for encryption and decryption [10], so the availability risk of TEEs is limited. Coco outsources key management to an on-premises or cloud-based key management system, for example a hardware security module (HSM) [4], where generated private keys persist, while members' corresponding public keys or consortium participants are stored on the blockchain. Finally, SCE-Fabric offers either client-based encryption for state encryption, where key management is done by the client, or chaincode encryption, where the administrator must provide security code enclaves. string a key specific to the chaincode during the bootstrap phase. 8].D. ScalabilityRegarding the scalability of the smart contract system, the proposed approaches have different capabilities. Although the PDO system places more emphasis on scalability than Ekiden [10], in general, both systems are relatively easy to scale, since the number of TEE-based computing nodes and the number of Blockchain nodes can be increased independently of each other. 3]. According to the white paper published by Microsoft, Coco provides a large-scale framework that "approaches the performance and scalability of a traditional database andcentralized” [4]. Compared to Hyperledger Sawtooth, Hyperledger Fabric is not as scalable [10], so SCE-Fabric systems do not necessarily have as high scalability capabilities as PDO.E. Performance EvaluationsIn terms of project and implementation status, Ekiden and SCE-Fabric provided prototypes and evaluation reports on different metrics like throughput or latency, performed for specific applications. The Ekiden prototype, for example, “achieves 600x higher throughput performance and 400x lower latency at 1,000x lower cost than the Ethereum mainnet” [3] for the ERC20 token standard. Conversely, the SCE-Fabric prototype “achieves 0.80x-0.95x of the throughput achieved by native execution” [8], with native execution referring to using the Hyperledger Fabric implementation without enclaves SGX. At the same time, it has a 10-20% overhead for a sealed-bid application caused by encapsulating the smart contract execution in a TEE [8]. Coco, meanwhile, describes two demos made with a working prototype of the framework, based on Ethereum, with an emphasis on scalability and privacy. The result of the demonstrations shows that “transaction rates were approximately 100 times faster than for a non-framework-based protocol” [4]. On the contrary, the PDO document does not mention any evaluation, but emphasizes that it is an open source project from Hyperledger Labs, which lays the foundation for further development and demonstration [10]. Since the measurements were only performed for certain applications that differ among the approaches, no general conclusions can be drawn from the results as to which of the solutions has the best overall performance. However, so far, Ekiden's results seem more promising and its performance exceeds that of the other three.F. Nondeterministic TransactionsAs discussed in the previous section, the combination of smart contracts and TEE poses several challenges. The proposed solutions attempt to solve some of them, but there is no approach that can solve them all. For example, to our knowledge, only the Coco framework allows the execution of non-deterministic transactions [4]. Similar to SCE-Fabric, which states that transactions are by default deterministic [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 solution approach. Since a compromised enclave can potentially affect the entire network by exposing confidential data or performing incorrect transactions, it is essential to attempt to minimize the potential attack surface. Additionally, key design goals should include detecting malicious components, minimizing their impact and the damage they could cause to the system, and eliminating these components. In this sense, PDOs distinguish between data confidentiality violations and integrity violations. A privacy violation means that an enclave is compromised and thus private data can be exposed, while maintaining execution correctness. In the case of an integrity violation, the correctness of the calculations could also be compromised [10]. PDOs provide protection mechanisms against both attacks. For example, in order to maintain confidentiality, methods implemented include the useof enclaves from reputable enclave hosting services and reducing the number of enclaves provisioned per contract, but this approach involves a trusted third party to provision the enclaves. Even if confidentiality is not guaranteed at all times, execution integrity can still be preserved by verifying the calculation result of an enclave by re-executing the same method on one or more other enclaves. This way, integrity is guaranteed and misbehaving enclaves can be identified and revoked. Ekiden attempts to mitigate the impacts of integrity risks and data leaks by designing critical components "according to a strong adversarial model, allowing an attacker to break the confidentiality of a small fraction of TEE" [3], but restricting access to 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 management node is compromised, but it does not cover measures to circumvent contract-level data leaks via side channels or software bugs . The Coco framework differentiates between compromised validator nodes and compromised enclaves. One of the mechanisms implemented by Coco is that a VN needs partial decryptions from other nodes in order to decrypt the data, so a single malicious VN is not capable of fully decrypting confidential data by himself [4]. Like PDOs, Coco offers to synchronously execute transactions across multiple nodes for rapid verification and detection of compromises. Measures to mitigate the risks of malicious components, such as software fault 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 into the system. enclaves with spurious inputs, but it “cannot access or alter the code and data residing in an enclave” [8], so the correctness of the execution itself is still ensured. To avoid wrong execution order, SCE-Fabric implements an execution order validation architecture, which forces a peer to execute a transaction before the transaction order is decided by consensus. Therefore, SCE-Fabric uses a reliable order service that cannot be canceled and is accessed for every transaction submitted by a customer, ensuring state continuity. However, SCE-Fabric does not prevent denial-of-service attacks or side-channel leaks [8].H. Individual advantages In addition to the properties mentioned above, each of the existing solutions has advantages that are not present in the other approaches. For example, Ekiden offers several performance optimizations for their system, which contribute to the remarkable performance improvement compared to the Ethereum mainnet when evaluating their prototype in [3]. PDOs focus on smart contracts that involve 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 contract executions is also possible [10], for example in case of TEE deletions or outages. The Coco framework is the most generic solution, since it supports pluggable blockchain protocols “such as Ethereum, Quorum, Corda or Hyperledger Sawtooth” [4]. One of the main design goals of SCE-Fabric, besides/