Verifiable Computing Applications in Blockchain

From weak clients outsourcing computational tasks to more powerful machines, to distributed blockchain nodes needing to agree on the state of the ledger in the presence of adversarial nodes, there is a growing need to efficiently verify the results of computations delegated to untrusted third parties. Verifiable computing is a new and interesting research area that addresses this problem. Recently, new applications of verifiable computing techniques have emerged in blockchain technology for secure key management, sybil-resistance and distributed consensus, and smart contracts, while providing desired performance and privacy guarantees. In this paper, we provide an overview of common methods for verifying computation and present how they are applied to blockchain technology. We group the presented verifiable computing applications into five main application areas, i.e., multiparty approval for secure key management, sybil-resistance and consensus, smart contracts and oracles, scalability, and privacy. The main contribution of this survey is to answer two research questions: 1) what are the main application areas of verifiable computing in blockchain technology, and 2) how are verifiable computing techniques used in major blockchain projects today.


I. INTRODUCTION
Verifiable computing (or verifiable computation) allows a client to delegate computation to possibly untrusted clients while retaining the ability to verify the results. This solves the problem of dishonest clients returning false results without actually performing the assigned work. Verifiable computing is not only about getting the correct result, but also about verifying that result with significantly less computational effort than was required to compute the result itself. There are several methods that can be used for verifiable computing [1], such as interactive proofs (IP) [2], zero-knowledge proofs (ZKP) [3], multiparty computation (MPC) [4], trusted execution environment (TEE) [5] and others. These concepts found their application in cloud computing, volunteer computing projects, and blockchain technology. For example, the Enigma [6] project, a decentralized computing platform with guaranteed privacy, uses MPC to jointly work on data while maintaining privacy. The Folding@home project [7], a distributed computing platform that aims to develop new treatments for a variety of diseases by simulating protein dynamics, uses a simple technique of verification by replication to check the correctness of results. The use of verifiable computing and blockchain enables new mechanisms for privacy preservation, for example of patient healthcare data in an e-Healthcare system [8] or for a secure and efficient management of data during a federated learning process [9]. Particularly interesting application areas of verifiable computing can be found in blockchain technology and its applications, which have motivated and challenged research in this field in recent years. In this paper, we provide an overview of verifiable computing techniques, focusing on their use in the decentralised setting of blockchain technology. The main research questions we address are: 1) what are the main application areas of verifiable computing in blockchain technology, and 2) how are verifiable computing techniques used in major blockchain projects today.
Consider a public blockchain. It is a distributed, decentralized, and shared ledger that requires no central authority and eliminates the need for third-party verification [10]. It was first introduced for the Bitcoin cryptocurrency [10] as a public ledger to record all transactions. It provides trust when the parties involved do not trust each other. Instead of trusting an authority or intermediary, trust is transferred to a computer code. This code runs on computers called nodes that are connected in a peer-to-peer (P2P) network. The need for an intermediary is avoided by using a distributed, cryptographically secured ledger that everyone agrees to. The ledger can only be updated by consensus between all parties involved, i.e., all nodes. The data that is written to the blockchain is mathematically encrypted and digitally signed. It is grouped into blocks that are appended and cryptographically linked to a previous block, creating a chain of blocks, a growing ledger of historical records. Once the data is written and accepted by the nodes, no deletions or changes are possible, making the blockchain practically immutable. In order to participate in consensus, where identities can be anonymous, and in the presence of malicious nodes that do not follow the rules, a sybil-resistance mechanism must be in place. One such mechanism is Proof-of-Work (PoW) [10], [11], where participants must perform some computational work to validate new data with all other participants before it can be appended to the chain of blocks [12]. In PoW, network participants typically perform cryptographic computations to solve puzzles (see subsection III-B1 for more details). The high energy consumption of the PoW consensus protocol and limited transaction throughput motivated the development of alternative mechanisms such as Proof-of-Useful-Work (PoUW) [13], which focuses on solving practical problems instead of cryptographic puzzles, and Proof-of-Stake (PoS) [14], which uses stake in the blockchain, i.e. cryptocurrency supporting the blockchain network, as voting power. All of the above consensus mechanisms use some form of verifiable computing.
Some blockchains are also capable of running smart contracts, which further enrich the functionality of the blockchain. A smart contract is a program that runs on the blockchain and whose methods, when invoked, perform actions that execute logic and change the state of the blockchain. To confirm correct execution, each participant in the network must re-execute the same method with the same input, which is a waste of compute cycles and requires that all nodes have access to the same input data, which can be a problem with data outside the blockchain. Verifiable computing methods can circumvent both problems, i.e., they can reduce the need to re-execute the same computations and guarantee that the execution is done with the same data even in a distributed environment.
In the following, we provide an overview of common concepts and technologies for verifying computation. Then we present how they are being used today with blockchain technology in some notable projects that use these methods. Finally, we conclude with a discussion and summary of the work presented.

II. VERIFIABLE COMPUTING
In the blockchain context, where the parties involved in a computation cannot be implicitly trusted, verification of a computation may generally involve verification of the participants, the program executed to perform the computation, the data and results of the computation, and any messages exchanged between the participants during the process. In this chapter, we describe selected methods and concepts related to verifiable computing currently used in the blockchain implementations under consideration, with a focus on performance and privacy. First, digital signatures are discussed as the primary scheme for verifying the authenticity and integrity of a message, document, or transaction, as well as ensuring non-repudiation and accountability of participants in the blockchain system. In the next two subsections, we present various methods for verifying that the computation was performed correctly and that the results are as claimed. We then present techniques and schemes that allow multiple parties to perform the computation jointly, even when unknown adversarial participants are present. We present methods for verifiable generation of random numbers, which are an essential tool in many security protocols and especially in blockchain applications. Finally, we describe how specially designed hardware can facilitate the task of verifying computations.

A. DIGITAL SIGNATURE SCHEMES
A digital signature scheme typically consists of a triplet of efficient algorithms (G, S, V ) [15]. A generation algorithm G takes no input and generates a key pair (sk, pk) where sk is the private key selected uniformly at random from a set of all possible private keys and pk is the corresponding public key. A signing algorithm S(sk, m) returns a signature σ when given the sk and a message m as input. A verification algorithm V (pk, m, σ), given the message m, public key pk and signature σ, outputs true if the signature is valid and f alse otherwise. The private key sk is therefore used as the signing key and the public key pk is used as the verification key. For any practical signature scheme it must be computationally infeasible to generate a valid signature t without knowing the private key sk.
Digital signatures are widely used in certificates and public key infrastructure (PKI). In any blockchain, they are used to verify the integrity and authenticity of digital messages and ensure non-repudiation [16]. Every transaction on a blockchain is digitally signed and every node must verify all transactions. Therefore, signature verification should be as fast as possible. Other desirable properties of signature schemes include small signature size, the ability to aggregate multiple signatures to save both space and time, and speed of the signing process. The following three digital signature schemes are commonly used in blockchain implementations: a: ECDSA signatures ECDSA stands for Elliptic Curve Digital Signature Algorithm and is the signature scheme currently used in Bitcoin [10]. It is based on the discrete logarithm problem and uses elliptic curves over finite fields. The generated keys are shorter than keys in RSA signatures, which are often used in certificates and PKI. A public key pk is generated as a point on an elliptic curve (the curve used by Bitcoin is secp256k1 as standardized by the National Institute of Standards and Technology (NIST) [17]) by using the private key sk as a scalar.
b: Schnorr signatures Similar to ECDSA, the Schnorr signature scheme is based on the discrete logarithm problem and uses elliptic curves, but the signature is computed differently [18]. Also, with Schnorr signatures, it is possible to aggregate all signatures and public keys in the transaction into a single key and signature. Signature verification can be performed only once. This makes Schnorr multisignature transactions (MultiSig) indistinguishable from regular signatures, which has a positive impact on privacy and transaction size. The disadvantage of the Schnorr signature scheme is that it requires a random number generator for signature aggregation and an additional round of communication between each signer and the aggregator, due to the interactivity between signers. This is not practical for blockchain applications like MultiSig with cold wallets [19]. Also, t − of − n multisig schemes become complex for large t and n [19] and it is not possible to combine all signatures in the block into a single signature. c: BLS signatures BLS (Boneh-Lynn-Shacham) signature scheme [20] uses the properties of bilinear pairing of elliptic curves and is based on the computational hardness assumption over the Diffie-Hellman problem [21]. It has the unique property that all BLS primitives (secret keys, public keys, signatures) are aggregable and can be combined in any order to form a single primitive of the same type, with no practical limit on the number of aggregated primitives. BLS primitives that correlate with each other still correlate with each other when the same arithmetic operations are performed on each of them. For example, if two signatures are aggregated that were created using the two previously aggregated secret keys and the same message hash, the new signature will also be validated against the aggregated public key. Also, unlike ECDSA, where the use of randomness within the signature results in multiple possible signatures for the same public key and message, BLS signatures are unique and deterministic. For any given combination of public key and message, there can be only one valid signature. These properties are especially relevant for various blockchain implementations [22], [23]. The disadvantage of BLS signatures is that signature verification is an order of magnitude slower than ECDSA or Schnorr signatures. However, if selected optimization techniques are implemented, the signature verification time can be significantly reduced [23].

B. VERIFICATION BY REPLICATION
The easiest way to verify a computation is to simply repeat the computation. Given a computation method C and an input I, the prover can compute the result R = C(I) and send it to the verifier. Assuming that the verifier also has access to C and I, acquired either publicly or privately, he can then compute R = C(I) and evaluate R ? = R. In an untrusted environment, with multiple participants, n verifiers can be randomly chosen to perform the verification. Assuming that the majority of participants are honest, there is usually a threshold t that marks the minimum quorum (often t ≥ 2) of verifiers that must agree on the result R. If this condition is met, the verifiers can then confidently assume that the result R is correct.
The advantage of this approach is its simplicity and the technical implementation is straightforward compared to other approaches. However, this comes at the cost of a major weakness -the waste of energy caused by the repeated computation itself.
Replication can be done always or only under certain conditions. A system that needs a quick decision on whether the computation was performed correctly usually has the recomputation performed immediately by a certain number of verifiers. Other types of systems, based on game-theoretic principles [24], require recomputation only when one participant disagrees with the solution submitted by another participant. In these systems, the computation is performed only once unless the result is disputed. In case of a dispute, an application-specific dispute resolution protocol is started, which can be a kind of interactive game between a prover and a verifier. To prevent participants in these systems from making false claims, they must put down a deposit, which they lose along with their reputation if they are found to have acted maliciously.
The world's largest volunteer computing project, Fold-ing@home [7], and many others [25], [26], use this approach. The architecture of such projects usually involves a client and many workers [27]. The client sends identical units of work from (C, I) to multiple workers W = {w 1 , ..., w n }, which then compute the results R W = {R w1 , ..., R wn }. Once the quorum is reached with a certain threshold for R W , the result is marked as final. It is also important that these projects have some kind of reputation system to discourage dishonest actors and prevent them from submitting false results. The reputation metric can be a combination of the time taken to complete the work and the correctness of the results returned [28].

C. VERIFICATION BY PROOFS
An alternative to recomputation to verify the result of the computation is to use a proof which asserts that the computation was performed and that the result is correct. Generally, the prover has a proving method P which runs a computation method C on input I and produces (R, π) = P (C, I), where R is the result and π is the proof of the computation. Given a computation method C, an input I, a result R, a proof of VOLUME 4, 2016  = true. In some cases π = R holds, where the result R can serve as a proof π and its validity proves that the computation has been performed. Consider an example of searching for an occurrence of a substring that matches a regular expression in a large string. The prover can compute the result R = (i, j) using the computation method C on a string S and a regular expression re, where i and j are starting and ending positions of an occurrence. Given the result (i, j) the verifier can run a separate verification method V (S, re, i, j) to quickly check whether the substring in that range matches a regular expression without having to perform the entire computation C again. If privacy is a concern and the data being worked on must remain private, the proof of the computation can be constructed in a zero-knowledge way (subsection II-C0b). In this case, the verifier does not need to know the input I and can simply check V (C, R, π). In the next subsections, we present common methods that rely on proving rather than recomputing to verify a computation.

a: Interactive proof
An interactive proof (IP) system is an abstract machine where computation is modeled as an exchange of messages between the prover P and the verifier V [2]. The prover has unlimited computational power and cannot be trusted, while the verifier has limited computation power and is always honest. Messages are exchanged between the verifier and the prover until the verifier is convinced by the prover that a statement is true, resulting in the verifier accepting the statement. If the prover failed to convince the verifier that a statement is true, the verifier rejects the statement. Interactive proof systems must satisfy the following two requirements [29]: • Completeness -If the statement is true, the honest verifier will be convinced that the statement is true by an untrusted prover. • Soundness -If the statement is false, no cheating prover can convince the honest verifier that the statement is true, except with some small probability.
An interactive proof can also be a proof of knowledge by which the prover can convince the verifier that he knows something [30]. Most frequently used interactive ways to prove knowledge are the Schnorr protocol [18] and the Σprotocol [31]. Proofs of knowledge are also used in signature schemes, such as group signatures [32] and Schnorr signatures [18]. b: Zero-knowledge proof A zero-knowledge proof (ZKP) is a method by which the prover can prove to the verifier that some statement is true without revealing any information other than the fact that the statement is true [33]. Assume the prover wants to prove to the verifier that he knows the value x. The challenge is to prove the knowledge of x without revealing the x itself. Besides the requirements of interactive proof systems completeness and soundness, any ZKP must also satisfy the requirement of zero-knowledge -if the statement is true, no verifier learns anything other than the fact that the statement is true.
There are two types of ZKP: interactive and noninteractive. In an interactive ZKP, the prover performs series of actions to convince the verifier that a particular statement is true, with some probability p. The more rounds of interaction there are, the higher the probability p will be. A noninteractive zero-knowledge proof (NIZKP) does not require any interaction between the prover and the verifier, which provides greater flexibility since the verifier can verify the proof itself at any time. It is also possible to transform some interactive ZKPs to NIZKPs using a Fiat-Shamir heuristic, which is a way of creating a signature based on an interactive proof of knowledge [34], [35].
One of the NIZKP is zk-SNARK [3], [36]- [38], which stands for "Zero-Knowledge Succinct Non-Interactive Argument of Knowledge". Succinct means that the proof is just a few hundreds bytes in size, even for statements about computations that are very large, and that it can be verified quickly, usually within a few milliseconds. Every zk-SNARK consists of three algorithms [39]: generator G, prover P , and verifier V . Generator G takes as an input a secret parameter λ and a program (computation) C, from which it derives proving key pk and verification key vk. This is a one time process for any program C, and the keys are made public. The prover P takes as an input proving key pk, a public input x and a private input w, also known as a witness. The proving algorithm then generates a proof π = P (pk, x, w) which asserts that the prover knows a witness w which satisfies the program. The verifier V can then use verifying key vk, public input x and a proof π to compute V (vk, x, π) which returns true if the prover knows a witness that satisfies C(x, w) = true. Downside and common criticism of zk-SNARK protocol is the need for a trusted setup. A secret parameter λ is required during generation phase, which if unveiled, could allow a cheating prover to generate fake proofs without knowing a witness w. To prevent this from happening it is not unusual to use MPC (subsection II-D) during generation of the public parameters [40], [41], which is secure as long as one of the participants is honest.
This drawback in zk-SNARKs has led to the development of other NIZKPs that do not require trusted setup, such as zk-STARKs [42] and Bulletproofs [43]. While zk-STARKs are faster than zk-SNARKs during proving phase, they are slower during verification phase [44]. Bulletproofs are smaller in size than zk-STARKs, however, they are much larger than zk-SNARKs [44]. Different protocols have different limitations in terms of proof size, proving time and verification time. These are the properties that need to be considered when deciding which NIZKP to use, as also shown in Table 2 [45]-[47].

D. MULTIPARTY COMPUTATION
Multiparty computation (MPC) is a method by which multiple parties P = {p 1 , ..., p n } can jointly compute a function F of their individual inputs X = {x 1 , ..., x n }, without any party revealing their inputs to the other parties [4], [48]. The generated output Y = F (x 1 , ..., x n ) is public and can be viewed by all parties. For example, in the blockchain context the parties are often nodes and it is assumed that some of the nodes may be potentially adversarial [49]. The nodes wish to perform a joint computation of a function while preserving basic security properties such as correctness and privacy. The privacy requirement states that nothing beyond what is absolutely necessary may be learned; more specifically, the parties may learn only the intended output and nothing else. The requirement of correctness states that each party should produce its correct output. Therefore, the adversary must not be able to cause the result of the computation to be different from the function that the parties intended to compute.
Most MPC protocols use secret sharing. Secret sharing allows a secret to be shared among multiple parties, with each party receiving a portion of the secret [50]. No single party owns the entire secret, minimizing the risk that the secret will be revealed if one party is compromised. Besides some trivial secret-sharing schemes where all shares are necessary to recover the secret, the most common schemes are those where t of n secrets are shared and where a certain threshold of adversaries can be tolerated [51]. A notable secure and efficient threshold sharing scheme based on the Lagrange interpolation polynomial is Shamir Secret Sharing (SSS) [52]. SSS is based on the premise that the dealer and the parties are honest. It is not possible to verify that (i) a dealer is sending correct shares to some or all participants and (ii) participants are not submitting fake shares during the reconstruction process [53]. Verifiable secret sharing (VSS) includes auxiliary information that allows parties to verify their shares as consistent, even if the dealer is malicious [53]. A commonly used example of a simple VSS scheme is the Feldman scheme for non-interactive VSS [54]. Publicly Verifiable Secret Sharing (PVSS) [55] explicitly requires that not only the parties involved in the scheme, but anyone can verify that the parties have received correct shares. The original secret sharing schemes [52], [56] required a dealer to generate and distribute shares of a secret to the participants. To initialize the cryptosystem securely without requiring a dealer, a Distributed Key Generation protocol (DKG) [57], [58] can be used. A group of n participants can jointly generate a secret whose shares are distributed among the participants such that any subset larger than t can use the secret. No trusted party is required.

E. VERIFIABLE RANDOMNESS
Many applications require random values that cannot be predicted in advance and must be published. The source of the randomness may be from the system itself or from a trusted third party. However, when participants do not trust either the system or a third party, a provably fair and publicly verifiable method is needed. We describe common methods that can be used to generate randomness and publicly verify its fairness.

a: Verifiable random function
A verifiable random function (VRF) is a pseudo-random function that provides a verifiable proof of its correctness [59]. For a given input x, used as a seed for random number generation, a party with private key P r and public key P u can compute the result y = F P r (x) and the proof π P r (x). The result is a random number that other parties can verify by computing the verification function with the known seed x, the proof π P r and the public key P u. The result of the verification is true if the random number was generated correctly, false otherwise. In other words, evaluating the output of the VRF function for a given input does not allow the adversary to distinguish the output of VRF from a random source. Moreover, given the output of the VRF function and a prover's public key, the verifier can be non-interactively convinced that the output was correctly generated using the prover's secret key. The prover cannot say for arbitrary random looking number that for that input and his private key the same number will be generated.
VRF can be used to provide deterministic precommitments that will be revealed at a later time [60]. For example low entropy inputs (e.g., "John Doe") can be mapped to a random number and committed in advance on a public blockchain. A notable use case for VRFs is the Internet draft for NSEC5 [61] which proposes a scheme that uses VRFs to prevent offline DNSSEC zone brute-force enumeration and guarantee the integrity of zone contents even if an attacker compromises the authoritative nameserver responsible for responding to DNS queries for the zone. Some traditional applications of VRFs are resettable zero-knowledge proofs [62], micropayment systems [63], and privacy-preserving transaction escrow schemes [64]. Some prominent blockchain applications of VRFs are described in the next chapter.

b: Verifiable delay function
A verifiable delay function (VDF) is a function that takes a prescribed minimum time to compute a unique output that can be efficiently verified in a public setting [65], [66]. VOLUME   More precisely, for an input x ∈ X and a VDF function y = F (x), anyone can compute F (x) in t sequential steps, but no adversary, even with a parallel computer with many processors, can compute the output of F (x) in substantially fewer steps. Given the output y, any observer can quickly verify that y = F (x). Moreover, every input x ∈ X must have a unique valid output y ∈ Y . VDFs were introduced as a way to prevent malicious actors from influencing an output by predicting future values.

F. TRUSTED EXECUTION ENVIRONMENT
A trusted execution environment (TEE) is a secure area on the main processor that is separate from the main operating system. It is an execution environment that provides features such as isolated execution of programs, integrity of computations, and confidentiality of data [5].
An application using TEE generally consists of two components. An untrusted component, a host, runs on the untrusted operating system, while a trusted component, an enclave, runs inside an isolated TEE container. TEE enables the storage of secret data that cannot be accessed by attackers, ensuring confidentiality. To ensure security and integrity, TEE only executes code authorized by other authorized code. To prove its trusted state, TEE is able to generate a signed proof, called an attestation, which can be used later for verification. This makes it impossible for other applications to alter the state or tamper with the code executed within TEE. As such, TEE provides features that can help verify computations.
Two notable hardware technologies that support TEE are ARM TrustZone [67] and Intel SGX [68]. TEEs are usually shipped with a unique private key from the manufacturer, which is then used to generate attestations. This means that in the case of a malicious or hacked manufacturer, we can no longer trust the TEE. In addition, numerous vulnerabilities have been discovered in TEEs in recent years [69]- [73]. Some of these risks can be mitigated by distributing the work among multiple workers and using threshold cryptography for secrets. TEE can be used to store encryption keys to verify the integrity of the operating system, user data for biometric authentication, and other forms of sensitive data [5]. TEE can also provide a hardware-protected random number generator with special instructions [74].

III. BLOCKCHAIN APPLICATIONS
In this chapter, we provide an overview of the main applications of verifiable computing in blockchain systems. We describe how the selected verifiable computing methods are used, what functionality they enable, and for what purpose.
Where possible, we also list examples of practical implementations of blockchain systems that use these methods. For better readability and structure, we group the applications of verifiable computing into five thematic blockchain areas: key management, consensus mechanisms, smart contracts, scalability, and privacy.
The verifiable computing methods and their applications are summarised in Tables 3 and 4. Table 3 maps the desired goal/functionality to one or more specific verifiable computing techniques used to achieve that goal, while Table 4 provides an overview of current blockchain applications that rely on verifiable computing techniques, with notable system examples for each application.

A. SECURE KEY MANAGEMENT
Blockchain protocols are based on public-key cryptography where pairs of a public key and a private key are used to perform different tasks. Any person with the private key is able to sign transactions and there is no way to recover it if it is lost. It is therefore of utmost importance to protect the private key and keep it secret.

1) Multiparty approval schemes
To reduce the risk of an adversary gaining access to the private key, multiparty approval schemes are often used where there is no single point of failure.
A traditional solution for multiparty approval is to use a multisignature transaction (MultiSig) [101]. To be considered valid, a multisignature transaction must be signed by multiple private keys from different participants.
A different approach with several important advantages over MultiSig is the use of verifiable computing techniques in secure multiparty approval schemes. By using a Threshold Signature Scheme (TSS) [102]- [104] it is possible to define a (t, n)-threshold signature scheme, where at least t parties of n are required to create a signature. To sign a transaction, multiple parties participate in a secure offline protocol where each party uses its secret to generate a partial signature. When enough partial signatures have been collected, the transaction can be signed. Anyone with a public key can then verify that the transaction is valid, i.e., that it was signed with the corresponding private key. However, the signature is the result of an MPC computation and the private key is never generated. It can therefore not be stolen, destroyed or used to sign another transaction. Once the offline signature process is complete, the threshold signature appears as a single standard signature regardless of the number of approvers. This is an advantage over MultiSig because no meta-information about   public key shares or signers needs to be stored when sending to a t − of − n address or spending it's output. No additional software modification is required by a particular blockchain implementation to support TSS approval schemes and privacy is also improved as the address is indistinguishable from a normal address. In addition, TSS provides additional privacy and security as individual approvers can be removed, changed, or added at any time without changing the resulting signature. In contrast, MultiSig records the signature of each approver on the public blockchain for successful transactions.

2) Secret shares management
One of the common security practices in key management is key updating, where the user is required to change the private keys regularly to reduce the risk of exposure. The same practice can be used in multiparty approval schemes where shares of the secret are held by n different parties. It should be possible for each party to replace the individual share of the secret sharing scheme with a new share, so that when the shares are added together, e.g. for use in the signing protocol, they are still equal to the value of the private key.

a: Secure key rotation
In TSS this can be achieved as it is possible to generate many different and random combinations of secret distributed shares that can still be combined to generate the same secret key [105]. Key rotation can be performed proactively at regular intervals or on demand if deemed necessary to address a potential security risk. For example, an attacker might attempt to compromise one party at a time until it has VOLUME 4, 2016 the required number of shares. In a secure key rotation, the attacker must in practice compromise at least t parties in a (t, n) secret sharing scheme within the key rotation interval. For a short key rotation interval, this task is likely to be much more difficult. In a traditional MultiSig system, if one party is compromised and the adversary learns the value of the key share, a key update is required in which entirely new private keys are generated and an on-chain transaction is performed to synchronize the public and private keys and accounts. Changing a private key in a cryptocurrency, for example, results in a changed account or payment address, which is often undesirable. This is not the case with TSS, as it is possible to perform secure key rotation while maintaining a static account address.

b: User replacement
There are many scenarios in which it may be necessary to replace, remove, or add a party participating in a multiparty approval scheme. For example, if an employee who holds a secret share leaves the company or is replaced by another employee. In this case, his or her secret share must be invalidated and a new share generated for the new employee. Preferably, this should be done without changing the address or account protected by the secret sharing scheme. Again, both of these processes can be easily accomplished using TSS. To remove a party from a secret sharing scheme, the secure key rotation mentioned above can be performed between the remaining users. Once the key rotation has been performed, the secret share of the leaving party can no longer be used in any way, effectively removing the party from the sharing scheme. To add another party, all that is necessary is to issue another share to the new party. For example, if Lagrange interpolation is used in TSS, the share is derived from a point on the polynomial corresponding to a number associated with the new party, e.g., a hash of ID.

B. CONSENSUS AND SYBIL-RESISTANCE
In a distributed consensus, participants propose a value and later agree on that value. To be fair, consensus protocols involving anonymous identities must ensure that each participant does not cheat by having more influence on the outcome than they should [106]. A malicious participant could hide behind multiple identities and have an unfair amount of voting power. This is also called a sybil attack [107] and requires special mechanisms to either reduce the impact or ensure that this does not happen. In the next subsections, we present common sybil-resistance mechanisms used in the blockchain and explain how they use verifiable computing concepts.

1) Proof of Work
To participate in the consensus on the blockchain, computing power can be used. This is the approach taken by PoW-based blockchains such as Bitcoin [10]. In a distributed system [108], the ability of nodes to reach consensus on a value is called liveness [109]. Conversely, safety is a guarantee that nodes will not come to a consensus with different values [109]. Bitcoin uses the Nakamoto consensus, which emphasises liveness over safety, and the longest chain with the most accumulated work is the source of truth. Participants in the network, known as miners, have an incentive to expend computational power for the chance to publish a block and thus secure the block reward. The PoW algorithm that Bitcoin uses is called Hashcash [110]. Miners who want to compete for the right to publish the next block try to find a value called nonce, which serves as one of the inputs to a cryptographic hash function. The output of such a function must yield a value h, such that h < d, where d is the current difficulty of the network. Once a miner finds the satisfying nonce value, it is broadcast to the network as part of the new block and others verify its correctness by recomputing h. In this context, nonce serves as a proof of the computation itself. What guarantees sybil-resistance is the fact that finding nonce is computationally intensive and requires a brute force approach. However, once the nonce is found, its verification is cheap and occurs in constant time. Therefore, the cost relation between the computation method C and the verification method V is V << C. As the blockchain grows, the computational cost of rewriting history increases exponentially [10], while the cost of verification remains constant.

2) Proof of Useful Work (PoUW)
One of the biggest criticisms of the PoW mechanism is that it is wasteful in terms of energy [111]. Due to environmental concerns, there is active research into how to replace it with alternative algorithms, puzzles, or problems. There have also been successful attempts to replace SHA256 mining with solving NP-complete problems [112], [113] to achieve PoUW. To keep the protocol fair, it is important that no participant has an advantage in solving these problems because they know the solution beforehand. For this reason, randomly generated problems can be used, but their solutions are of limited use because they may have no practical applications. Other works [114]- [116] describe systems and frameworks that solve problems from specific domains such as artificial intelligence, in particular machine learning. These limitations have also led to the use of trusted hardware, i.e., TEE (subsection II-F), to perform more general computations. One of the first algorithms to use trusted hardware for sybil-resistance was Proof of Elapsed Time (PoET), proposed by Intel for the Sawtooth Lake [117] project and based on the SGX module. Instead of performing cryptographic computations, miners run code that idles for a random amount of time, and the miner with the shortest wait time gets to lead the consensus round and reaps the reward. PoET has been shown to have some vulnerabilities and limitations. An attacker is able to successfully attack the network by compromising only a small fraction of the participants [118]. PoET also incentivizes the use of cheap and outdated hardware specifically designed for mining, which leads to waste, i.e., all the hardware collected does not perform useful work [97]. Moreover, reliance on a single manufacturer can be considered centralized. The Resource-Efficient Mining (REM) framework [97], which also relies on trusted hardware, addresses the risk of compromised SGX CPUs and achieves more promising PoUW. REM measures computation in the number of instructions executed for useful work and is therefore more flexible in the variety of work that can be used for PoUW. It allows users to use their CPUs for any workload, such as protein folding, machine learning, data compression, and hashing [97]. Thus, REM enables even less wasted computing power in mining, while maintaining security guarantees similar to PoW.

3) Proof of Stake
Instead of using PoW for sybil-resistance, some blockchains opt for the PoS mechanism, where the voting power is based on participants' stake in the network [119]. This approach is very effective as it consumes a fraction of energy compared to PoW-based blockchains and helps in scaling the network. In PoS, participants can take a special role as proposers or validators who are responsible for growing the blockchain. A proposer creates a new block, which must then be checked by validators before it is appended to the blockchain. A naive approach is to use the block hash as a source of randomness and derive the probabilities for selecting proposers and validators [14]. Since transactions in the block can be reordered or omitted, this allows miners to keep doing so until they find the hash that would most favor them in the next round of consensus. To overcome this vulnerability, another source of randomness should be used.
An example of a project that uses verifiable random functions for its sybil-resistance mechanism is Algorand [120]. The VRF takes a private key and a value and produces a pseudorandom output along with a proof that can be used to verify the result. The VRF is used to select the leaders who propose a block and also the committee members who vote on a block [121]. The chance of being selected is proportional to the stake in the network, ensuring that a participant does not gain an advantage by creating multiple identities. Nodes participating in consensus rounds first validate the VRF proof to ensure that the associated output is correct before moving on to the next phase. Other blockchain networks such as OmniLedger [96], Cardano [122], and others [123]- [125] also use VRF as part of their consensus mechanism.

C. SMART CONTRACTS
A smart contract is a computer program running on top of the blockchain [126]. In general, smart contracts only have access to what is already on the blockchain, which was generated or put there by the network participants. The ability to connect real world, i.e. systems external to the blockchain, with smart contracts is of a great value and is one of the major milestones towards increased blockchain adoption. In next subsections, we explain how verifiable computing assists in getting data, randomness or results of general computation to the blockchain and enables to keep private the smart contract code, execution, and data.

1) Data
Due to its nature, the blockchain can also be defined as a replicated deterministic state machine. This means that any state change at any point in time can be seen and verified by all peers in the network. Suppose there is a method M within a smart contract. When executed, method M makes a request to an external API to obtain and process some data and return the result R. If transaction T which is a call to method M , occurred at time t i , then we can assert that the blockchain was moved from one state to another, S T − → S ti . The problem occurs when this transaction is sent to the network and needs to be verified. Each peer in the network will also execute T once it reaches it, but the time of execution will not be the same. This means that each peer will execute T at a different time t j and the state transition will be S T − → S tj . When the data requested from the API changes or becomes unavailable, the peers will end up in different state S , breaking the invariants of the blockchain and its determinism. The same problem arises with any subsequent verification of state transitions.
This problem is also known as the oracle problem and consists of two parts. First, there is the question of how data can be moved between blockchains and external systems, and second, how this can be done in a secure and decentralized manner. To get at the data outside the blockchain, smart contract methods typically send out events that systems outside the blockchain listen for and respond with the data in the form of a new transaction. These systems are known as oracles and serve as middleware between blockchains and the real world [127]. This poses the risk of potentially insecure systems passing data to smart contracts on a supposedly highly secure decentralized blockchain network. To solve this problem while still maintaining decentralization and security properties, the approach of verification by replication can be applied. As suggested by Chainlink [77], there are generally two methods by which this can be done: in-contractor aggregation and off-chain aggregation. In the first method, multiple independent actors first fetch the data from an external source and then submit it to a smart contract responsible for reaching a quorum. This is expensive and energy consuming as each actor has to submit a separate transaction. The second method uses Schnorr signatures [18], where aggregation and agreement occurs outside the blockchain and is later submitted as a single transaction.
Other problems that arise are authenticity and confidentiality. A malicious oracle can change the retrieved data before it is sent to the blockchain. In a decentralized oracle network, this would require the majority of oracles to collaborate and carry out the attack together. Some oracle services, such as Provable [128], provide authenticity proofs along with the data [129]. The Town Crier [98] system also addresses some of these problems by using Intel's trusted hardware SGX. In particular, it guarantees that data supplied by a website has not been tampered with. It also provides confidentiality by enabling private data requests with encrypted parameters. VOLUME 4, 2016 For example, a request might include a password to log into a server from which the data is then retrieved [130]. SGX ensures that such secret data remains hidden from everyone, including Town Crier operators. Other hardwarebased distributed oracles also extend this by implementing a reputation system to address problems with overloaded or malicious oracles, favoring those with the shortest response times [131]. Another protocol, DECO [93], achieves most of the same functionality but without trusted hardware. Instead, DECO is making use of a MPC to allow users to prove in zero-knowledge that data accessed via TLS [132] originated from a specific website.

2) Randomness
Smart contracts sometimes require a random number generator for scenarios such as minting non-fungible tokens (NFT) in games, picking lottery winners, or choosing leaders in consensus rounds.
Similar to Proof of Stake, a naive approach is to use the block hash as a source of randomness. However, this is not secure as it can be manipulated by miners [133], [134]. Other solutions, such as decentralized commitments with deposits [135], [136], are complex and costly because they require multiple participants to submit transactions to the blockchain as part of the process of selecting a random number.
For a provably fair and verifiable source of randomness, a verifiable random function can be used. Generally, a random number is generated outside the blockchain and then sent to the network along with the cryptographic proof. Chainlink has implemented VRF [137] for smart contracts, providing developers with both security and ease of use when dealing with random numbers. Each time a random number is requested, a new random number with the associated proof is generated off-chain by oracle operators and then published and verified on-chain before the random number is used in a smart contract to ensure that no tampering has occurred.
A verifiable delay function (VDF) can also be used to generate randomness in smart contracts. The VDF is used to provably delay the revelation of randomness and prevent the randomness from being influenced by the malicious party, who can choose whether or not to submit the generated random value. The delay is designed to allow the seed of the random value to be committed in an earlier block. VeeDo [138], a STARK-based VDF service, allows users to request a random value from an off-chain service, which is then verified on-chain with a corresponding proof. A longer delay increases security, as other parties that may be malicious must also wait the same amount of time to compute the VDF output. When using VeeDo, the user can choose between a 3 minute and 7 minute delay.

3) Computation
Each network participant that takes part in the smart contract execution process must perform the entire computation again as part of the verification process, which can result in a large computational overhead and network congestion.
Proofs of computation, such as zk-SNARKs, can be used to solve this problem. Since they are hard to construct for non-specialist users, high-level languages have been developed to facilitate their development [85], [86], [139]. An example of such a system for the Ethereum platform is ZoKrates [85]. It allows developers to write their zk-SNARK program in a high-level language from which Solidity code is generated, allowing for easy integration with other smart contracts. A transaction containing the result of the computation and a proof can then be sent to a smart contract, and miners only need to verify the proof of correctness. A provable program can also be created using Cairo [86], a highlevel language for generating zk-STARKs. Since SNARKs or STARKs cannot be constructed for most programs, this verification method has limited applicability. It is therefore not particularly well suited to complex computations and is best used when some information to be kept secret and a proof of the computation must be immediately available.
Instead of relying on cryptographic proofs, computations can also be verified through an interactive game [140]. TrueBit [24] uses game-theoretic principles as part of its interactive verification protocol. This allows for heavy computations to be performed off the blockchain by a single solver, who must submit a deposit as a guarantee that the computation will be performed correctly. During a certain period of time, any verifier can redo the computation and check if the result is correct. If there are no disputes, the computation is marked as final and the solver receives his deposit back, along with a reward for performing the computation. However, if the verifier and the solver disagree on the result and the adjudication system finds verifier's solution to be correct, the solver loses his deposit and the verifier is entitled to the reward. To incentivize the verifiers' participation, the TrueBit protocol occasionally inserts errors that the verifiers try to find.

D. SCALABILITY
Scalability describes how well a system is able to handle an increased load. A system can be scaled vertically by upgrading hardware and horizontally by distributing the load across multiple machines. By combining these methods, a distributed system can achieve linear scalability. However, this becomes more difficult with blockchains because there may be malicious nodes that do not adhere to the protocol rules. Also, all events must be verifiable by every other node in the network. This raises the question of how blockchains can scale efficiently while maintaining properties such as decentralization and security. One of the metrics used to describe how well a blockchain scales is transactions per second (TPS). In the next subsections, we discuss recent advances in scaling both on-chain and off-chain and how they leverage verifiable computing.

1) On-chain
The blockchain design as originally proposed by Bitcoin [10] has not proven to be easily scalable in practice. Since then, numerous solutions have been proposed that make changes to the base layer of the blockchain. Some of these solutions include changing the blockchain data structure [80], using smaller signatures for transactions [141], and sharding [142], [143].

a: Simplified Payment Verification
In traditional blockchains, all transactions since the beginning of the network are stored and hosted by individual network participants called full nodes [10]. This data can accumulate over time to a size of hundreds of gigabytes. In addition, when other full nodes join, they must download all transactions from other participants, which takes up both bandwidth and storage. It is also possible to participate in the network as thin or lightweight node [10] where only the block headers need to be downloaded to validate transactions using the Simplified Payment Verification (SPV) method. A thin node acquires all block headers from a full node and, if needed, asks the full node for a Merkle proof of a particular transaction to verify its existence.
Some of these requirements for thin nodes can be relaxed by using Non-Interactive Proofs of Proof-of-Work (NIPoPoWs) [75]. NIPoPoWs enables the verification of transactions on PoW-based blockchains without the need to acquire all block headers. NIPoPoWs nodes only need to download a polylogarithmic number of block headers, which is enabled by the fact that for PoW, statistically half of the blocks produced exceed the network difficulty d [75]. If D is a number of leading zeros in the network difficulty, then half of the block hashes produced start with D + 1 zeros, a quarter start with D + 2 zeros, and so on. These blocks are called superblocks and form a superchain, a compressed blockchain.

b: Succint blockchain
Mina [80] goes a step further and introduces the notion of a succinct blockchain, where the traditional blockchain structure is replaced by an easily verifiable cryptographic proof. Instead of verifying the entire blockchain from the beginning, participants verify the network and transactions with recursive zk-SNARKs. When a new block is created, the proof of computation not only validates the new block, but also the proof of an existing, previous block. This new state is then used as the previous state when another block is created. This keeps the size of the network constant (about 20 kB) and is more accessible to weak clients than a constantly growing ledger, which stores the entire history and has a higher barrier to entry. Smaller devices, such as smartphones, can perform a full verification of the entire network history in only about 200 ms.

c: Shard committee selection
Another technique that changes the blockchain base layer is sharding. Sharding in blockchain means that the network is divided into several parts, called shards, with only a subset of participants responsible for each shard at any given time [143]. The shards operate in parallel and are able to communicate with each other, resulting in higher transaction throughput. Each shard usually has a group of validators, called a committee, that is responsible for consensus and verification of transactions on the same shard. The selection of the committee could be based on a block hash or round robin algorithm. However, in these approaches, an attacker could manipulate or predict the selection and potentially corrupt a particular shard. Therefore, it is important to have a fair, unbiased, and publicly verifiable random method for selecting a committee for each shard. Verifiable random functions (VRF) [59], verifiable secret sharing (VSS) [54], and publicly verifiable secret sharing (PVSS) [55] have been applied to this problem. VRF allows a participant to generate verifiable randomness, while VSS and PVSS allow a group of participants to generate collective randomness. In VSS, each participant can verify the validity of their own share, while in PVSS, everyone can verify that each participant received the correct share through public proofs without direct interaction between participants. Previous works, such as Elastico [144], used the least significant bits of the PoW hash as a source of randomness to determine the committees, which allowed adversaries to influence the selection process in the next round. A more secure approach is taken by other sharded blockchain protocols such as OmniLedger [96] and RapidChain [92], which generate randomness for committee selection using VRF and VSS, respectively.

d: Masternode quorums
Masternodes are incentivised full nodes with a required minimum level of performance (e.g., proof-of-service [23]) that can provide advanced functionality and participate in governance in addition to the regular tasks of a full node. Masternodes have the additional requirement of holding a collateral, which makes them sybil-resistant, i.e., a malicious user cannot spin a number of nodes to gain an advantage. Typical additional tasks include validating blocks proposed by miners, protecting against 51% miner attacks, enabling instantly re-spendable transactions, and enhancing transaction privacy and fungibility for cryptocurrencies [23].
In order to provide some of these services, masternodes must collectively reach an agreement that requires the exchange of a large number of messages between them. With a large number of masternodes, this affects the scalability of the network. The solution proposed and used by Dash [23] is to use subsets of masternodes called long-living masternode quorums (LLMQ) [145]. The main task of an LLMQ is threshold signing of consensus-related messages. Multiple LLMQs of different sizes are formed as needed using a DKG protocol and can be active simultaneously for long periods of time, e.g., hundreds of blocks, allowing load balancing between these quorums. A node can be active in multiple quorums simultaneously. LLMQs are selected in a random deterministic manner from all currently active masternodes and the result of this selection, i.e., the quorum participants, is mined on-chain before the LLMQ is actually used. The LLMQs are statistically representative of the entire network. For example, to protect against 51% mining attacks and chain reorganizations, a mechanism called Chainlock [146] is used where masternodes in LLMQ perform a verifiable vote of the "first seen" block to checkpoint it. If a threshold of masternodes participating in LLMQ (e.g., 80%) saw the block as first, then statistically about the same threshold of nodes across the whole network should also have seen the node as first and the block can be checkpointed. Similarly, LLMQs enable instantly re-spendable transactions through locking transactions by an LLMQ until miners include them in a block. The miner must include the locked transaction in the next block or the block will not be accepted by the masternodes. All nodes participating in an LLMQ threshold sign the messages using the BLS signature scheme. The result of the signing session can then be aggregated in a single BLS threshold signature, regardless of quorum size, and propagated network-wide. By distributing a load across multiple LLMQs and aggregating signatures, LLMQs provide a robust solution for scaling on-chain.

2) Off-chain
Instead of dealing with scalability directly on-chain, another approach is to move parts of the system off-chain and update the data on the chain at a later time, either with partial, compressed, or representative data. A number of off-chain scaling solutions have been proposed for Ethereum and other blockchains, such as state channels [147], [148], side chains [149]- [152], and rollups [153], [154].

a: State channels
State channels allow participants to transact directly outside the blockchain [147]. First, participants open the state channel via multisignature, locking the part of a blockchain state. Participants can then transact with each other. Once this is done, they close the state channel and update the blockchain with the new state, unlocking the state on the blockchain. The disadvantage of this approach is that opening and closing the state channel requires the participants to be fully reachable.

b: Sidechains
A sidechain is another blockchain which is linked to a main blockchain via a two-way peg, providing a way to transfer assets between the two [149]. A two-way peg is a mechanism that allows assets to be locked on one chain which can then be used on the other chain and vice versa [150]. Sidechains can have their own consensus protocols, accounting models, or privacy guarantees that may differ from those of the main blockchain. There is usually a trusted or trustless intermediary, that orchestrates the communication between the main and sidechain. Zendoo [81] and zkRelay [82] leverage zk-SNARKs to generate succinct proofs of the state of the sidechain, allowing efficient verification in constant time on the mainchain. This is an improvement over previous approaches such as BTC Relay [76] and NIPoPoWs [151], which have linear and polylogarithmic costs for the number of blocks, respectively. Since sidechains are separate blockchains, they can lack security and be expensive to maintain.

c: Rollups
Rollups, which allow transactions to be executed off-chain and transaction data to be published later on the chain, are a particularly interesting solution. Since only the Merkle state root and the compressed transactions are stored onchain, transaction throughput is greatly increased and network fees are significantly reduced. The largest space savings is achieved by using the BLS aggregate signature [20] for multiple transactions. There are two approaches to rollups, optimistic and zero-knowledge. As the names imply, optimistic rollups are based on optimistic assumptions, i.e., transactions are assumed to be valid by default and rely on fraud proofs, while zero-knowledge rollups use ZKPs as validity proofs [153]. In optimistic rollups, the entity responsible for submitting a batch of transactions is required to put down a deposit so incentives are aligned that it does not act fraudulently [154], [155], while zero-knowledge rollups require a deposit to ensure that the relayer eventually updates the state [156]. For optimistic rollups, after a new state root and compressed transactions are sent on-chain, there is a challenge period, usually one week, in which a challenger can submit a proof of fraud. If the proof of fraud shows that the batch was not constructed correctly, the entity that sent the incorrect rollup loses its deposit, the challenger is rewarded, and the on-chain state is reversed. For zeroknowledge rollups there is no challenge period, as a valid zk-SNARK or zk-STARK asserts the correctness and existence of transactions and proves the valid transition from the old to the new state. This leads to much faster finality and even less data stored on-chain. Optimistic rollups are currently better suited for general purpose computation, as NIZKPs can be complex and expensive to construct, generate, or verify. However, as the technology behind NIZKPs improves, zeroknowledge rollups are expected to overcome these issues [153]. There are numerous projects such as Optimism [78], Loopring [83], and others [79], [84], [157] that implement these two approaches for Ethereum.

E. PRIVACY
This section discusses more generally how privacy is achieved for on-chain transactions, general computation, and in smart contracts.

1) Transactions
Public blockchains are referred to as pseudo-anonymous. This is because while the identities behind the network participants are not known, the transaction data associated with those identities is public [49]. Once the identity on the blockchain is linked to an individual, there is a risk that someone can trace their entire transaction history.
One of the solutions applied to this problem was zeroknowledge proofs. Zcash [89], [90] was one of the first to use the concept of shielded transactions based on zk-SNARKs. This concept allows senders and recipients of transactions to prove that encrypted transactions are valid. The sender, recipient, and transaction data cannot be inferred from the transaction itself, providing confidentiality and strong privacy guarantees.
To address the downsides of zk-SNARKs, such as trusted setup and size, other projects have begun to look at other cryptographic protocols. Projects based on the Mimblewimble [158], [159] protocol, such as Grin [160] and Beam [161], provide not only confidential transactions but also better scalability. Mimblewimble uses Pedersen commitments [57] to prove that transaction inputs and outputs are valid, so Tx In − Tx Out = 0, and Bulletproofs [43] as range proofs to prove that committed values are nonnegative and lie in the range ∈ [0, 2 64 ]. Mimblewimble also does not require all transactions to be stored permanently, resulting in a significant reduction in blockchain size. Monero [91], which used ring signatures [162]- [164], also implemented bulletproofs, resulting in a drastic reduction in transaction size, faster verification times, and lower fees [165]. Encrypted transactions allow parties to take advantage of public blockchains while protecting their privacy.

2) Computation
Entities that cannot afford to run their own infrastructure usually delegate their computations to cloud services. However, adding a trusted party to manage their data poses a privacy risk. Computation networks combined with blockchain using a secure MPC can overcome this problem. Not only can a single participant keep their data private, but all participants can collectively compute something with their individual data.
ARPA [95], a privacy-preserving computation network, uses MPC in addition to information-theoretic Message Authentication Codes (MACs). In ARPA, the correctness of computations can be verified with MACs at constant time complexity, while privacy is preserved through a secret sharing protocol. This enables private smart contracts and protection of shared data being worked on.
Enigma [6] proposed a decentralized computation platform with guaranteed privacy based on MPC using blockchain for identities, access control and storage for verifiable trails. However, the originally proposed MPC protocol was impractical due to the computational overhead, so Enigma initially only supported TEEs for their secret contracts and deferred the implementation of MPC to future releases. For providing their computational resources, nodes in Engima are compensated with fees paid by those who submit tasks.

3) Smart contracts
Since smart contracts in most blockchains are stored on a public blockchain, their code, state, and all associated transactions can be viewed by anyone. This presents a hurdle for companies that want to move to blockchain but do not want their assets to be public.
The Hawk framework [87], which uses zk-SNARKs, was one of the first to offer a solution to this problem. Hawk splits the contract into a public contract and a private contract. The public contract is executed on the blockchain, while the private contract is executed off-chain by managers. The drawback of Hask is that the confidentiality of smart contracts depends on a manager being trusted, and each circuit requires a trusted setup for new SNARK. These issues are addressed by zkHawk [94], which replaces SNARKs and the manager with an MPC protocol. Zether [88] proposes the use of bulletproofs for confidential transactions compatible with existing smart contact platforms. Ekiden [99] and ShadowEth [100] also achieve private smart contracts by using trusted hardware such as Intel SGX, but this imposes additional trust requirements on TEE manufacturers. Arbitrum [79] also allows smart contracts to scale by using off-chain computation, but with privacy guarantees. Arbitrum allows someone to create an Arbitrum Virtual Machine, a special smart contract, and select managers to be responsible for its execution. Arbitrum, with its weaker trust assumptions, guarantees that a single honest manager can ensure that the computations were done correctly. With Arbitrum, the smart contract code does not need to be public, the computation cost is constant, and only the cryptographic hash of the state is stored onchain.

IV. CONCLUSION
Verifiable computing techniques are used to provide core functions in blockchain projects. They aim to reduce energy requirements while maintaining or increasing security and improving network efficiency, scalability, and privacy. Due to its recent and growing popularity, blockchain technology has been a driving factor for research in this area.
In this paper, we have provided an overview of verifiable computing techniques currently used in popular blockchain projects. We have divided the verifiable computing applications in blockchain into main application areas, i.e., multiparty approval for secure key management, sybil-resistance and consensus, smart contracts and oracles, scalability, and privacy. We have described how and for what purpose verifiable computing is used in large blockchain projects. As far as we are aware, this is the first overview of its kind that aims to map specific verifiable computing techniques to blockchain applications while providing example projects.
Future research should further develop existing verifiable computing methods and propose new ones that are less computationally intensive and enable a broader range of applications. In addition, further research is needed to extensively test the security of existing practical implementations of verifiable computing methods. Part of our current research is devoted to reviewing available state-of-the-art implementations of various verifiable computing techniques, highlighting their unique properties. In an effort to find a sustainable replacement for Proof-of-Work, we are also exploring a solution that uses verifiable computing to verify work in a Proofof-Useful-Work consensus mechanism without relying on a trusted execution environment.
In summary, verifiable computing applications are being actively explored and improved in a rapidly evolving blockchain technology context. A move towards a sustainable model where one party computes and all others verify efficiently would not only be a technological advance, but also an environmental one.