PaperlayerView exact revision on arXiv

Source-linked AI summary

A comprehensive survey on smart contract construction and execution: paradigms, tools, and systems

Bin Hu, Zongyang Zhang, Jianwei Liu, Yizhong Liu, Jiayuan Yin, Rongxing Lu, Xiaodong Lin

arXiv:2008.13413v2cs.CR

TL;DR

Smart contracts face privacy, security, efficiency, and complexity problems that limit their application. This survey categorizes 159 studies on contract construction and execution, identifies persistent challenges, and outlines future research directions.

  • Problem

    Public transaction details can leak privacy, while duplicated execution and validation limit blockchain throughput, restricting smart-contract applications.

  • Method

    The survey analyzes literature and online resources, categorizing construction schemes into paradigms and tools and execution systems into three classes.

  • Results

    The survey identifies five persistent challenges: vulnerabilities, incomplete paradigms, inefficient tools, low processing rates and contract complexity, and limited privacy.

  • Takeaways & Limitations

    Secure, privacy-preserving, and efficient smart contracts remain open research problems requiring further investigation.

  • Takeaways & Limitations

    The survey mainly covers Bitcoin and Ethereum and excludes other platforms and high-level smart-contract descriptions involving technologies such as artificial intelligence, cloud computing, and the Internet of Things.

Abstract

from arXiv · show

Smart contracts are regarded as one of the most promising and appealing notions in blockchain technology. Their self-enforcing and event-driven features make some online activities possible without a trusted third party. Nevertheless, problems such as miscellaneous attacks, privacy leakage, and low processing rates pre-vent them from being widely applied. Various schemes and tools have been proposed to facilitate the construction and execution of secure smart contracts. However, a comprehensive survey for these proposals is absent, hindering new researchers and developers from a quick start. This paper surveys the literature and online resources on smart contract construction and execution over the period 2008-2020. We divide the studies into three categories: (1) design paradigms that give examples and patterns on contract construction, (2) design tools that facilitate the development of secure smart contracts, and (3) extensions and alternatives that improve the privacy or efficiency of the system. We start by grouping the relevant construction schemes into the first two categories. We then review the execution mechanisms in the last category and further divide the state-of-the-art solutions into three classes: private contracts with extra tools, off-chain channels, and extensions on core functionalities. Finally, we summarize several challenges and identify future research directions toward developing secure, privacy-preserving, and efficient smart contracts.

1. INTRODUCTION

Smart contracts expanded blockchain applications but remain constrained by security, privacy, and efficiency problems. This survey systematically reviews construction and execution schemes, organizing prior work into taxonomies and identifying challenges and research directions.

  • 1. INTRODUCTION: Security, privacy, and efficiency problems restrict smart contracts’ adoption across application domains.Public transaction details can leak privacy, while replicated execution limits throughput; attacks can also cause severe economic losses.
  • 1. INTRODUCTION: The survey addresses state-of-the-art paradigms, tools, and alternative systems for secure smart contract development and execution.Its research questions cover current schemes, challenges to efficient development and adoption, and potential directions for overcoming those challenges.
  • 1.1. Methodology: The review applies a systematic search across major scholarly databases and related venues, collecting 159 directly relevant papers or online resources by August 2020.The search combined database queries, conference and workshop searches, citation tracking, and reference screening.

2. BACKGROUND, NOTATIONS, AND RELATED WORK

The background contrasts Bitcoin’s limited script-based contracts with Ethereum’s Turing-complete execution model and introduces core transaction workflows and related survey work. It also highlights privacy leakage and the trade-offs underlying contract design.

  • 2.1.2. Smart contract: Bitcoin scripts support automatic enforcement but are limited by the absence of loops, a 520-byte script cap, difficult syntax, and security concerns.These constraints restrict Bitcoin contracts to relatively limited scenarios despite applications such as storage, voting, gambling, and poker.
  • 2.1.2. Smart contract: Ethereum supports arbitrary deterministic programs through the EVM and high-level languages such as Solidity, enabling more complex decentralized applications.High-level contracts are compiled into EVM bytecode, supporting applications including lotteries, loans, auctions, and decentralized finance.
  • 2.1.2.1. Contract execution in Bitcoin: Bitcoin P2SH redemption verifies the sender’s signature, matches payload code against the script hash, and checks additional data before accepting the transaction.The simplified workflow omits the time field and requires payload data that makes the script evaluate to true.
  • 2.3.2. Properties of contracts: Bitcoin’s public scripts expose transaction information to the network, so pseudonyms do not eliminate privacy leakage.The paper treats this public visibility as an inherent privacy concern in Bitcoin’s execution setting.
  • 2.3. Related work: The survey distinguishes construction paradigms and tools from execution alternatives, including private contracts, off-chain channels, and extensions of core functionality.It presents this taxonomy as a roadmap for researchers and developers and further subdivides categories by technique.

3. SYSTEMATIZATION METHODOLOGY

The paper systematizes smart-contract research by separating construction from execution and organizing each area around distinct mechanisms and tools. It further classifies construction resources and execution solutions according to their roles, implementation choices, and support for theory or realization.

  • Construction and execution: Construction and execution are treated as separate scheme categories because platform expressivity and execution mechanisms differ across script-based and Turing-complete blockchains.Script-based systems support limited operations, whereas Turing-complete systems support arbitrary functions; the paper therefore discusses their construction schemes separately.
  • Research challenges: The systematization addresses security, privacy, efficiency, transaction delay, and contract complexity as recurring challenges across smart-contract platforms.These concerns motivate schemes for privacy protection, throughput improvement, and more secure contract development.
  • Construction schemes: Construction schemes comprise design paradigms and design tools, distinguishing reusable application patterns and best practices from development-support resources.Design tools include analysis tools for checking security after near-completion and auxiliary tools that operate during construction.
  • Execution schemes: Execution schemes are grouped into private contracts with extra tools, off-chain channels, and extensions on core functionalities.The first category uses cryptographic protocols or hardware, the second avoids extra tools or underlying modifications, and the third modifies execution mechanisms to introduce new functionality or properties.
  • Classification criteria: The review organizes reported schemes by theory and realization, recording whether works provide formal security proofs, complete descriptions, open-source implementations, non-open implementations, or no implementations.Table 1 uses C, H, and B symbols to encode these theory and realization statuses.

4. CONSTRUCTING SMART CONTRACTS WITH SCRIPTS

Script-based blockchains use limited stack-based opcodes, so Bitcoin contract construction emphasizes reusable paradigms and tools for storage, multi-party computation, off-chain payments, privacy, and safer programming.

  • Bitcoin script contracts are relatively simple because script-based blockchains provide limited stack-based opcodes for basic financial conditions.
  • The survey divides Bitcoin construction schemes into design paradigms and security-oriented design tools.Paradigms provide modular patterns, while tools target secure contract development.
  • Four paradigm areas cover data storage, secure multi-party computation, layer-2 protocols, and scriptless contracts.These areas address tamper-resistant storage, privacy-preserving interaction, payment efficiency, and contract-content privacy.
  • Layer-2 protocols: Payment channels move repeated payments off-chain after setup, avoiding per-payment confirmation delays and fees for small frequent transfers.The channel uses a multisignature deposit and a timelocked refund transaction.
  • Scriptless contracts: Scriptless contracts hide contract contents by making settlements indistinguishable from standard transactions, but their functionality is limited by directly verifiable final outputs.ECDSA-based work makes this approach compatible with Bitcoin and Ethereum without requiring a hard fork.
  • Design tools: High-level tools such as BALZaC, Simplicity, and BitML simplify Bitcoin contract development, but security analysis or expressiveness remains incomplete for some systems.BALZaC lacks security analysis, Simplicity’s security proof is lacking, and BitML cannot express every contract.
  • Design tools: High-level languages reduce programming burden, while translating between high-level and script languages without sacrificing correctness remains a major challenge.

5. CONSTRUCTING SMART CONTRACTS WITH TURING-COMPLETE LANGUAGES

Turing-complete blockchains extend Bitcoin’s limited script operations through virtual machines that execute smart contracts as bytecode and support richer programming languages.

  • Ethereum introduces a virtual machine and Turing-complete languages, extending the operations and application scenarios available for smart contracts.Contracts execute in the Ethereum Virtual Machine as EVM bytecode.
  • Ethereum serves as the representative Turing-complete blockchain because derivative systems use similar EVM-based execution mechanisms and support Turing-complete languages.

5.1. Design paradigms

Design paradigms provide application-specific and general patterns intended to reduce programming errors and support reliable smart-contract construction. The survey covers common application scenarios, classifications, and recurring security limitations.

  • Design paradigms are divided into application-specific patterns and general-purpose patterns designed against common attacks.
  • Some earlier paradigms may become vulnerable or inefficient as smart-contract platforms evolve and should therefore be treated as potential counter-examples.
  • Lottery, loan, and auction contracts illustrate applications that use blockchain properties but retain unresolved privacy, fairness, security, or oracle risks.
  • Loan: Ethereum loan schemes depend on oracle contracts for exchange rates, but oracle manipulation can cause substantial economic loss.
  • Classification and patterns of common contracts: Financial and notary-related contracts account for most transactions in the surveyed Bitcoin and Ethereum classification, especially on Bitcoin.The classification reflects activity through January 2017.
  • Common vulnerabilities and errors: Common-vulnerability classifications require continual updates, and practical analysis found that exploited funds represented at most 0.27% of ETH marked vulnerable.

5.2. Design tools

Design tools support smart-contract development through analysis and auxiliary software. The survey extends earlier tool surveys by comparing contract languages and vulnerability-detection tools through August 2020.

  • The survey divides design tools into analysis tools and auxiliary tools that support security assessment or simplify development.
  • Prior surveys: Earlier surveys compared analysis-tool efficiency, accuracy, supported vulnerabilities, languages, and security-tool classifications from complementary perspectives.
  • The authors compare existing contract languages and vulnerability-detection tools in detail through August 2020.

5.2.1. Analysis tools

Analysis tools target recurring smart-contract vulnerabilities, including re-entrancy, gas waste, trace issues, event ordering, and integer errors. The surveyed approaches range from static and symbolic analysis to fuzzing and runtime protection, with persistent accuracy and scalability trade-offs.

  • The survey classifies analysis tools into six groups: re-entrancy, gas consumption, trace, event-ordering, integer, and general detection tools.
  • Re-entrancy attacks related: Re-entrancy attacks exploit fallback-driven recursive invocation, while tools such as fuzzing-based ReGuard and runtime Sereum address detection or deployed-contract protection.
  • Re-entrancy attacks related: Runtime protection extends analysis beyond pre-deployment detection by monitoring EVM instructions and locking state during outside calls.
  • Existing tools often require manual checks because false-negative results remain possible, motivating future automation and accuracy-efficiency trade-off analysis.
  • Gas consumption related: Gas mechanisms limit operations and denial-of-service risk but impose user costs, motivating tools that detect or optimize gas-expensive code.

5.2.1.3. Trace vulnerability.

Trace and related vulnerability analysis must balance coverage, accuracy, efficiency, and computational cost. The survey describes symbolic execution, fuzzing, abstract interpretation, and targeted analysis as complementary approaches, each with scalability or false-negative constraints.

  • Trace vulnerability: Event-ordering bugs can make contract state changes unpredictable, although some applications may intentionally use such behavior for randomness.
  • Integer bugs: Integer bugs include arithmetic, truncation, and sign-related errors, while VERISMART uses a decision procedure to avoid expensive operations and improve scalability.
  • General detection tools: General detection tools use symbolic execution and fuzzing, with research emphasizing accuracy, operation efficiency, and calculation cost.
  • Symbolic execution: Symbolic execution improves analysis accuracy but suffers memory explosion as target-program size grows.
  • Symbolic execution: Scaling methods skip less important paths for efficiency, but this can produce false negatives; SECURIFY instead traverses all possible paths with abstract interpretation and symbolic execution.

5.2.1.6.2. Syntactical analysis.

Syntactical analysis parses smart-contract code into structured representations and matches patterns to detect potential vulnerabilities, but its accuracy still requires manual checking.

  • SmartCheck converts Solidity source code into an XML parse tree and uses XPath queries to identify patterns associated with security, function, execution, and development problems.
  • NeuCheck improves processing speed and complements vulnerabilities not fully covered by tools such as SmartCheck.
  • Syntactical analysis is relatively lightweight and efficient compared with symbolic execution, although its accuracy cannot be guaranteed.
  • Abstract-interpretation tools such as EtherTrust abstract EVM bytecode into Horn clauses and verify contract reachability through clause resolution.
  • eThor addresses the lack of provable soundness in existing analyzers by providing a sound analyzer for user-defined properties expressed in HoRSt.
  • Gigahorse extends Vandal and decompiles over 99.98% of deployed contracts, compared with Vandal’s 88%, while improving precision and completeness.

5.2.1.6.4. Data-flow analysis.

Data-flow and related analyses reduce resource demands for large contracts, while complementary symbolic, model-checking, fuzzing, and deductive methods trade scalability, completeness, accuracy, and formal guarantees.

  • Data-flow analysis consumes fewer resources and therefore supports large smart contracts, improving the practicality of vulnerability detection at scale.
  • Slither converts Solidity contracts into control-flow graphs and the SlithIR intermediate representation for automated vulnerability detection.
  • Model checking combines symbolic model checking, abstract interpretation, and constrained Horn clauses in ZEUS, which is claimed to achieve zero false negatives and faster analysis than OYENTE.
  • Model checking scales poorly because the number of states grows with contract size, limiting the approach to small-scale contracts.
  • Fuzzing can miss deep execution paths, whereas symbolic execution reaches them at high resource cost; ILF combines the two to seek more vulnerabilities efficiently.
  • Fuzzing accuracy and soundness cannot be proved because vulnerability discovery relies on random collisions.

5.2.2. Auxiliary tools

Auxiliary tools support contract construction through frameworks, languages, privacy mechanisms, and formal-analysis foundations, but several remain incomplete, unreleased, or lacking formal guarantees.

  • Frameworks: Construction frameworks simplify development, support privacy or security analysis, and reduce learning costs for beginners through simpler tools or familiar languages.
  • Frameworks: Hawk separates private and public contract portions, automatically generating contracts and cryptographic protocols intended to preserve privacy and correctness.
  • Frameworks: ZoKrates provides an open-sourced language and compiler for off-chain computations and generates a zero-knowledge-proof protocol, but lacks a formal security proof.
  • Frameworks: FSolidM models smart contracts as finite state machines and provides plugins to detect vulnerabilities such as re-entrancy and transaction-ordering dependence.
  • Frameworks: Event-B-based design can support property verification and simplify later security analysis, but requires further improvement in completeness and syntactic complexity.
  • Basic tools: Formal EVM and bytecode definitions provide foundations for analysis, yet their relationships and correspondences remain formally unspecified.

6. EXECUTING SMART CONTRACTS

Smart-contract execution is constrained by public disclosure, duplicated validation, limited processing rates, and bounded contract complexity, motivating privacy tools, off-chain channels, and core-functionality extensions.

  • Blockchain execution publicly discloses contract contents so miners and nodes can execute transactions and agree on final states, creating privacy concerns.
  • Every transaction is verified, executed, and packaged by all miners, making duplicated resource consumption a major limit on processing rate.
  • Blockchain platforms are unsuitable for applications demanding high processing rates because larger blocks consume more space and shorter intervals can cause undesirable forks.
  • Bitcoin and Ethereum limit contract complexity through restricted operations or gas-based instruction limits that preserve liveness but constrain complex on-chain execution.
  • The review groups execution solutions into private contracts with extra tools, off-chain channels, and extensions to core functionalities.
  • Off-chain channels: Off-chain channels move execution away from the blockchain to avoid low processing rates and confirmation delays while providing some protection for contract contents.

6.1. Private contracts with extra tools

Private-contract schemes add cryptographic or hardware tools to protect contract contents and executions, grouped around SMPC, ZKP, and TEE approaches. They improve privacy or efficiency but introduce participant, communication, storage, trusted-setup, or hardware-security constraints.

  • SMPC: SMPC-based contracts conduct most procedures off-chain, using blockchain mainly for safety or fairness while remaining flexible beyond inherent blockchain execution mechanisms.SMPC schemes may require witnesses or proofs, and Raziel combines SMPC, proof-carrying code, and non-interactive ZKP for private, verifiable execution.
  • SMPC: SMPC schemes face an open trade-off between best- and worst-case complexity, while compiling general functions into SMPC contracts and off-chain protocols remains unresolved.All participants may also need to remain online, and existing schemes have high computational and communication complexity.
  • ZKP: ZKP-based schemes hide contract contents and can reduce communication relative to SMPC, but they increase communication and storage overhead and may require trusted setup.Quorum uses zk-SNARK for private contracts, while Hawk and ZoKrates help developers integrate ZKP without understanding its protocol details.
  • TEE: TEE-based execution improves efficiency by avoiding heavy cryptographic overhead, but assumes secure hardware and shifts costs to contract executors.TEE executors must update hardware and validate execution proofs, while hardware bugs, attacks, or provider backdoors create additional risks.

6.2. Off-chain channels

Off-chain channels improve throughput, reduce transaction fees, and conceal much transaction activity by moving interactions away from the blockchain. The surveyed designs include payment-channel networks and state channels, but face privacy, dispute, conflict, and monitoring burdens.

  • Payment channel networks: Bidirectional payment channels and payment-channel networks target fair, efficient transfers without direct channels, but HTLC hash locks can reveal participants on the same path.Blind-signature vouchers are proposed for fairer and more anonymous off-chain exchange.
  • Payment channel networks: Lightning-style payment channels keep routine transfers off-chain, leaving settlement and disputes on-chain to reduce frequent transactions, delays, and blockchain load.Lightning combines RSMC and HTLC; in HTLC, decreasing timelocks and propagated preimages incentivize intermediaries to behave honestly.
  • Payment channel networks: Random numbers assigned to intermediaries prevent the described wormhole attack, preserve incentives for honest intermediaries, and receive a formal UC-model security proof.The attack allows an adversary controlling multiple intermediaries to bypass honest nodes by passing the random preimage directly among corrupted nodes.
  • State channels: Virtual state channels move arbitrary-contract operations off-chain, enabling nearly instantaneous, zero-cost opening and closing in the best case and reducing worst-case conflict resolution from O(nD) to O(D).Only deployment, dispute resolution, and settlement need on-chain multi-party contracts in the described design.
  • State channels: State channels may encounter external-state, concurrency, and silent conflicts, while disputes can force honest parties to submit large proofs and pay high transaction fees.Outsourcing solutions such as PISA reduce monitoring storage to O(1), compared with O(N) for Monitor.

6.3. Extensions on core functionalities

Core-functionality extensions modify blockchain execution mechanisms to add capabilities, improve deployed-contract security, or support more efficient and private execution. These extensions include new opcodes, proof-carrying contracts, redesigned virtual machines, recursive proofs, and child-chain systems, but can introduce new vulnerabilities or compatibility limits.

  • Opcode extensions: Opcode extensions add capabilities such as covenants, vault transactions, and cross-chain contract movement, but may require soft forks and careful security analysis before deployment.The OP_MOVE design works only between blockchains sharing the same execution environment, and opcode changes can introduce vulnerabilities such as node-crashing exploits.
  • Security extensions: Proof-carrying smart contracts address the difficulty of updating tamper-resistant deployed contracts by modifying the underlying consensus and execution mechanisms.The survey identifies contract updating as a continuing research problem and points to auxiliary tools such as chameleon hashes.
  • Execution extensions: Arbitrum, YODA, and ACE move or reorganize execution to support complex contracts, but YODA and Arbitrum cannot handle concurrent interactive contracts assigned to different executor groups.ACE addresses cross-group invocation by extracting execution from traditional miners.
  • Privacy and efficiency: ZEXE extends Zerocash with recursive proofs so arbitrary user-defined predicates can have hidden contract contents and results, with overhead comparable to Zerocash and Hawk.Zerocash itself introduces zk-SNARKs but does not support smart contracts.
  • Privacy and efficiency: The survey identifies a trend toward off-chain execution by user-designated executors for privacy and parallelism, while cross-contract invocation across different executor groups remains insufficiently addressed.The cited direction includes HAWK, Arbitrum, and YODA, and later work may trade away some privacy improvements to handle invocation.

7. DISCUSSION

The survey identifies persistent barriers to smart-contract adoption and organizes future research around improving construction tools, execution systems, privacy, scalability, and practical deployment.

  • Limitations: The review mainly studies Bitcoin and Ethereum and excludes smart-contract schemes on other platforms and high-level integrations with artificial intelligence, cloud computing, and the Internet of Things.These exclusions are attributed to time and space constraints or to the focus on construction and execution mechanisms.
  • Challenges: Frequently occurring vulnerabilities, incomplete paradigms, inefficient analysis tools, low processing rates, limited contract complexity, and insufficient privacy remain the main challenges to adoption.The discussion links these challenges to security risks, evolving design practices, analysis trade-offs, transaction delay, and dependence on additional cryptographic techniques.
  • Future research directions: Future work should develop fair and economical off-chain networks, scalable or automatic analysis tools, high-level languages with formal proofs, and practical cryptographic implementations.The proposed directions span both script-based and Turing-complete blockchains, including migration of analysis techniques and improved developer guidance.
  • Privacy-preserving execution: Provably secure or private contracts, private-contract compilers, and efficient cryptographic schemes are highlighted as routes toward practical privacy-preserving execution.The survey specifically discusses secure multi-party computation, zero-knowledge proofs, blind signatures, ring signatures, UC-model proofs, and compilers for private contracts.

8. CONCLUSION

The conclusion presents a taxonomy of smart-contract construction and execution research, identifies five adoption challenges, and proposes directions for more practical, secure, private, and efficient systems.

  • Taxonomy: The survey categorizes 159 studies into construction paradigms and tools for script-based or Turing-complete blockchains, plus execution alternatives for privacy and efficiency.Execution alternatives include private contracts with extra tools, off-chain channels, and extensions on core functionalities.
  • Challenges: Privacy leakage, execution inefficiency, and contract complexity restrict smart-contract applications, alongside vulnerabilities, incomplete paradigms, inefficient analysis tools, and low processing rates.The conclusion consolidates these barriers into five aspects that require further attention.
  • Future directions: Future research should pursue fair off-chain networks, formal-proof languages, practical cryptographic protocols, provably secure or private contracts, scalable analysis tools, and private-contract compilers.The authors state that these directions could alleviate user concerns and promote smart-contract development.
  • Blockchain types: The survey distinguishes public, consortium, and private blockchains by participation and data-access rules, with closed consortium systems including Corda, Quorum, and Hyperledger Fabric.Public blockchains allow anyone to join, while private blockchains are controlled by one party.
Loading 2008.13413v2…