No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Simplicity: A New Language for Blockchains
Abstract
Simplicity is a typed, combinator-based, functional language without loops and recursion, designed to be used for crypto-currencies and blockchain applications. It aims to improve upon existing crypto-currency languages, such as Bitcoin Script and Ethereum's EVM, while avoiding some of the problems they face. Simplicity comes with formal denotational semantics defined in Coq, a popular, general purpose software proof assistant. Simplicity also includes operational semantics that are defined with an abstract machine that we call the Bit Machine. The Bit Machine is used as a tool for measuring the computational space and time resources needed to evaluate Simplicity programs. Owing to its Turing incompleteness, Simplicity is amenable to static analysis that can be used to derive upper bounds on the computational resources needed, prior to execution. While Turing incomplete, Simplicity can express any finitary function, which we believe is enough to build useful ``smart contracts'' for blockchain applications.
... For example, one could wish to forbid the money from being spent before a certain date, or to require multiple people to agree to spend the money. The tool that is used to establish these requirements is Script, which is a non-Turing-complete scripting language designed specifically for this purpose (O'Connor, 2017;Klomp and Bracciali, 2018;Jansen et al., 2019). ...
... A comprehensive description of different formalizations and extensions of Script can be found in . These works have focused on proposing executable semantics of Script, and some extensions of it, and on enabling the formal verification of some properties of protocols defined in this language (Andrychowicz et al., 2014;O'Connor, 2017;Atzei et al., 2018b;Atzei et al., 2018a;Bartoletti and Zunino, 2019;Singh et al., 2020). In this sense, our definition of Script follows a different direction, guided by the need to study the unlockability problem, which, to the best of our knowledge, has not been considered in previous works. ...
... Script (Bitcoin Wiki, 2021) is a simple stack-based language which allows to push elements to a stack, and manipulate its content using basic arithmetic, logical operations, if-else statements, and cryptographic primitives such as hashing and signature verification. Script is designed to be loop-free and is, therefore, not Turing-complete (O'Connor, 2017), which allows it to be more secure, and to be implemented efficiently. In spite of this, Script still allows to express an array of complicated conditions, giving rise to what is known as "smart contracts", which are nothing more than non trivial Script programs that specify how an output of a previous transaction can be unlocked. ...
With the popularity of Bitcoin, there is a growing need to understand the functionality, security, and performance of various mechanisms that comprise it. In this paper, we analyze Bitcoin’s scripting language, Script, that is one of the main building blocks of Bitcoin transactions. We formally define the semantics of Script, and study the problem of determining whether a user-defined script is well-formed; that is, whether it can be unlocked, or whether it contains errors that would prevent this from happening.
... Hence, reading through all the initial set of works, we recognized an additional 7 papers to complement the initial set of works ultimately, providing us with the final set of 35 related works for this SLR (See references ( Hirai, 2017 ;Amani et al., 2018 ;Le et al., 2018 ;Bhargavan et al., 2016 ;Bigi et al., 2015 ;Abdellatif and Brousmiche, 2018 ;Bai et al., 2018 ;Kalra et al., 2018 ;Chaudhary et al., 2015 ;Kim and Laskowski, 2017 ;Dennis et al., 2016 ;Breidenbach et al., 2017 ;Kosba et al., 2016 ;Matsuo, 2017 ;Luu et Biryukov et al., 2017 ;Mavridou and Laszka, 2018 ;Ellul and Pace, 2018 ;Idelberger et al., 2016 ;Sergey and Hobor, 2017 ;Liao et al., 2017 ;Pîrlea and Sergey, 2018 ;Grishchenko et al., 2018 ;Cerezo Sánchez, 2017 ;Zhang et al., 2016 ;Hildenbrandt et al., 2018 ) and ( O'Connor, 2017 ;Grossman et al., 2018 ;Sergey et al., 2018 )). A brief summary of all the relevant studies (i.e. ...
... The language is used to express security patterns against which smart contracts are verified. ( O'Connor, 2017 ) Simplicity Simplicity is a functional language without loops or recursions for blockchain based systems. It has the following key features: ...
... The authors also propose SASC which is a static analysis tool that is meant to find potential logic risks in smart contracts and generate topological diagram of invocation relationships. O'Connor ( O'Connor, 2017 ) introduces Simplicity, which is a combinator-based, typed, functional language meant to be used for blockchain based applications. Simplicity does not support loops and recursions. ...
Blockchain as a distributed computing platform enables users to deploy pieces of software (known as smart contracts) for a wealth of next-generation decentralized applications without involving a trusted third-party. The advantages of smart contracts do, however, come at a price. As with most technologies, there are potential security threats, vulnerabilities and various other issues associated with smart contracts. Writing secure and safe smart contracts can be extremely difficult due to various business logics, as well as platform vulnerabilities and limitations. Formal methods have recently been advocated to mitigate these vulnerabilities. This paper aims to provide a first-time study on current formalization research on all smart contract-related platforms on blockchains, which is scarce in the literature. To this end, a timely and rigorous systematic review to examine the state-of-the-art research and achievements published between 2015 and July 2019 is provided. This study is based on a comprehensive review of a set of 35 research papers that have been extracted from eight major online digital databases. The results indicate that the most common formalization technique is theorem proving, which is most often used to verify security properties relating to smart contracts, while other techniques such as symbolic execution and model checking were also frequently used. These techniques were most commonly used to verify the functional correctness of smart contracts. From the language and automation point of views, there were 12 languages (domain specific/specification/general purpose) proposed or used for the formalization of smart contracts on blockchains, while 15 formal method-specific automated tools/frameworks were identified for mitigating various vulnerabilities of smart contracts. From the results of this work, we further highlight three open issues for future research in this emerging domain including: formal testing, automated verification of smart contracts, and domain specific languages (DSLs) for Ethereum. These issues suggest the need for additional, in-depth research. Our study also provides possible future research directions.
... The design choice for a Turing-complete smart contract language has been criticized in the past [138,210] due to (1) verification issues and (2) the nature of smart contracts. Regarding (1), less expressive languages would be easier to verify and proposals for alternative programming language designs exist [210], although a transition towards a non-Turing complete language is unlikely, especially due to compatibility issues. ...
... The design choice for a Turing-complete smart contract language has been criticized in the past [138,210] due to (1) verification issues and (2) the nature of smart contracts. Regarding (1), less expressive languages would be easier to verify and proposals for alternative programming language designs exist [210], although a transition towards a non-Turing complete language is unlikely, especially due to compatibility issues. Critics of the Turing-complete language point out that (2) most smart contracts do not need the expressive power of such a language, since they are relative small programs, lacking control flow characteristics offered by Turing-completeness in the first place [138]. ...
Die Erfindung von Bitcoin hat ein großes Interesse an dezentralen Systemen geweckt. Eine häufige Zuschreibung an dezentrale Systeme ist dabei, dass eine Dezentralisierung automatisch zu einer höheren Sicherheit und Widerstandsfähigkeit gegenüber Angriffen führt. Diese Dissertation widmet sich dieser Zuschreibung, indem untersucht wird, ob dezentralisierte Anwendungen tatsächlich so robust sind. Dafür werden exemplarisch drei Systeme untersucht, die häufig als Komponenten in komplexen Blockchain-Anwendungen benutzt werden: Ethereum als Infrastruktur, IPFS zur verteilten Datenspeicherung und schließlich "Stablecoins" als Tokens mit Wertstabilität. Die Sicherheit und Robustheit dieser einzelnen Komponenten bestimmt maßgeblich die Sicherheit des Gesamtsystems in dem sie verwendet werden; darüber hinaus erlaubt der Fokus auf Komponenten Schlussfolgerungen über individuelle Anwendungen hinaus. Für die entsprechende Analyse bedient sich diese Arbeit einer empirisch motivierten, meist Netzwerklayer-basierten Perspektive -- angereichert mit einer ökonomischen im Kontext von Wertstabilen Tokens. Dieses empirische Verständnis ermöglicht es Aussagen über die inhärenten Eigenschaften der studierten Systeme zu treffen. Ein zentrales Ergebnis dieser Arbeit ist die Entdeckung und Demonstration einer "Eclipse-Attack" auf das Ethereum Overlay. Mittels eines solchen Angriffs kann ein Angreifer die Verbreitung von Transaktionen und Blöcken behindern und Netzwerkteilnehmer aus dem Overlay ausschließen. Des weiteren wird das IPFS-Netzwerk umfassend analysiert und kartografiert mithilfe (1) systematischer Crawls der DHT sowie (2) des Mitschneidens von Anfragenachrichten für Daten. Erkenntlich wird hierbei, dass die hybride Overlay-Struktur von IPFS Segen und Fluch zugleich ist, da das Gesamtsystem zwar robust gegen Angriffe ist, gleichzeitig aber eine umfassende Überwachung der Netzwerkteilnehmer ermöglicht wird. Im Rahmen der wertstabilen Kryptowährungen wird ein Klassifikations-Framework vorgestellt und auf aktuelle Entwicklungen im Gebiet der "Stablecoins" angewandt. Mit diesem Framework wird somit (1) der aktuelle Zustand der Stablecoin-Landschaft sortiert und (2) ein Mittel zur Verfügung gestellt, um auch zukünftige Designs einzuordnen und zu verstehen.
... Theorem proving is a formal verification technique that encodes a target system and its properties into a mathematical logic and derives a formal proof of satisfaction of the properties by axioms and proof rules. The theorem proving technique has been employed to verify the correctness of blockchain smart contracts [33]- [36]. In [34], Amani et al. extend an existing EVM (Ethereum Virtual Machine) formalization in Isabelle/HOL by a sound program logic. ...
... They encode bytecode sequences into blocks of straightline code and propose a program logic to analyze them. O'Connor [33] has proposed a new language called Simplicity to maintain and enhance the desirable properties of smart contracts. The language provides formal semantics and facilitates reasoning on smart contracts by using a theorem prover. ...
A blockchain is a list of data blocks as a publicly distributed ledger, which are linked together using cryptography. By allowing Turing-complete programming languages to implement smart contracts, recent blockchains such as Ethereum can reduce needs in trusted intermediators, arbitrations and enforcement costs. However, subtle errors in smart contracts have induced an enormous financial loss—for examples, the DAO attack, Parity multisignature wallet attacks, and integer underflow/overflow attacks. To identify such errors in smart contracts, various researches are performed, which are based on static analysis and theorem proving. However, they only support checking for pre-defined error patterns, or they cannot explore the whole searching space exhaustively or be fully automatic. Hence, in this paper, we propose a novel formal verification technique to analyze blockchain smart contracts by using ATL model checking. In our methodology, we represent the interaction between users and smart contracts into a two-player game and verify properties we want to check using MCMAS that is an efficient ATL model checker for multi-agent systems. To the best of our knowledge, there is no work to apply ATL model checking for analysis of blockchain smart contracts. Moreover, we present three case studies to demonstrate that our proposal can successfully identify subtle flaws in real world smart contracts.
... Coq, Isabelle/HOL, and Agda theorem provers are used to develop formal semantics of low- [18,40,53,89,109,161], intermediate- [41,132,185], and high-level [117,225] programming languages for smart contracts, including DSLs for financial contracts [25,126]. However, Li et al. [132] suggest that, among them, intermediate-level languages are the most suitable for formal verification. ...
... However, Li et al. [132] suggest that, among them, intermediate-level languages are the most suitable for formal verification. Annenkov et al. [21] note that the authors of formal semantics often focus on metatheory, i.e., verification of language properties, as in case of Plutus Core [53] or Simplicity [161]. Established through its formal semantics, general properties of Marlowe [126] smart contracts include a bound on transactions that a contract can accept and preservation of money within the contract. ...
A smart contract is a computer program which allows users to define and execute transactions automatically on top of the blockchain platform. Given the significance of smart contracts in supporting important activities across industry sectors including supply chain, finance, legal and medical services, there is a strong demand for verification and validation techniques. Yet, the vast majority of smart contracts lack any kind of formal specification, which is essential for establishing their correctness. In this survey, we investigate formal models and specifications of smart contracts presented in the literature and present a systematic overview in order to understand the common trends. We also discuss the current approaches used in verifying such property specifications and identify gaps with the hope to recognize promising directions for future work.
... Babbage [56] was designed to express smart contracts in terms of mechanical components. Bamboo [57], Obsidian [58] and Simplicity [59] are other languages which specify contracts as state machine functions. ...
Blockchain-based smart contracts enable the creation of decentralized applications, which often handle assets of considerable value. While the underlying platforms guarantee the correctness of smart-contract execution, they cannot ensure that the code of a contract is correct. Today, as evidenced by a number of recent security breaches, developers still have a hard time making contracts that work properly.Even though these incidents often exploit contract interaction, prior work on smart-contract verification, vulnerability discovery, and secure development typically considers only individual contracts in isolation. To address this gap, we introduce the VeriSolid framework for the formal verification of contracts that are specified using a abstract state machine based model with rigorous operational semantics. Our model-based approach allows developers to reason about and verify the behavior of a set of interacting contracts at a high level of abstraction. VeriSolid allows the generation of Solidity code that is functionally and behaviorally equivalent to verified models, which enables the creation of correct-by-design smart contracts. We additionally introduce a graphical notation (called deployment diagrams ) for specifying possible interactions between contract types. Based on this notation, we present a framework for the automated verification, generation, and deployment of contracts that conform to a deployment diagram. To demonstrate the applicability of VeriSolid , we translate existing Ethereum Improvement Proposal (EIP) specifications to temporal properties for two of the most popular contract interfaces: ERC20 and ERC721. We also show you how to write code for the ERC20 and ERC721 interfaces in a way that is safe, and we do this by using VeriSolid . We evaluate our framework on 726 contracts that are currently deployed on the Ethereum blockchain, which include 267 ERC20 and 459 ERC721 contracts. Our experiments indicate that 18% of ERC20 contracts and 4% of ERC721 contracts fail to satisfy the EIP specifications.
... In particular, Elements 24 , whose production deploymentthe "Liquid" sidechain [53]-uses a BFT consensus algorithm within a permissioned mining network consisting of cryptocurrency businesses 25 . Elements provides additional features with respect to Bitcoin, including confidential assets [58] and more advanced programming capabilities, which may be further expanded [54]. ...
Distributed Ledger Technologies (DLTs), when managed by a few trusted validators, require most but not all of the machinery available in public DLTs. In this work, we explore one possible way to profit from this state of affairs. We devise a combination of a modified Practical Byzantine Fault Tolerant (PBFT) protocol and a revised Flexible Round-Optimized Schnorr Threshold Signatures (FROST) scheme, and then we inject the resulting proof-of-authority consensus algorithm into Bitcoin (chosen for the reliability, openness, and liveliness it brings in), replacing its PoW machinery. The combined protocol may operate as a modern, safe foundation for digital payment systems and Central Bank Digital Currencies (CBDC).
... For AC-SC and FC-SC, which generate smart contract codes as output, the codes are not always directly executable, because the generation results can be smart contract skeletons that require manual completion of its core execution logic [15]. Meanwhile, the implementation of executable smart contract codes can be based on script-based languages (e.g., BitML [58] and Simplicity [59]) or Turingcomplete languages (e.g., Solidity (https://soliditylang.org/, accessed on 20 April 2022). ...
In the last decade, blockchain smart contracts emerged as an automated, decentralized, traceable, and immutable medium of value exchange. Nevertheless, existing blockchain smart contracts are not compatible with legal contracts. The automatic execution of a legal contract written in natural language is an open research question that can extend the blockchain ecosystem and inspire next-era business paradigms. In this paper, we propose an AI-assisted Smart Contract Generation (AIASCG) framework that allows contracting parties in heterogeneous contexts and different languages to collaboratively negotiate and draft the contract clauses. AIASCG provides a universal representation of contracts through the machine natural language (MNL) as the common understanding of the contract obligations. We compare the design of AIASCG with existing smart contract generation approaches to present its novelty. The main contribution of AIASCG is to address the issue in our previous proposed smart contract generation framework. For sentences written in natural language, existing framework requires editors to manually split sentences into words with semantic meaning. We propose an AI-based automatic word segmentation technique called Separation Inference (SpIn) to fulfill automatic split of the sentence. SpIn serves as the core component in AIASCG that accurately recommends the intermediate MNL outputs from a natural language sentence, tremendously reducing the manual effort in contract generation. SpIn is evaluated from a robustness and human satisfaction point of view to demonstrate its effectiveness. In the robustness evaluation, SpIn achieves state-of-the-art F1 scores and Recall of Out-of-Vocabulary (R_OOV) words on multiple word segmentation tasks. In addition, in the human evaluation, participants believe that 88.67% of sentences can be saved 80–100% of the time through automatic word segmentation.
... Simplicity [18] is an alternative language for Bitcoin scripts. It is a typed, combinatorbased, functional language without loops and recursion. ...
This paper investigates the usage of logic and logic programming in the design of smart contracts. Our starting point is the logic-based programming language for smart contracts used in a recently proposed framework of quantum-secured blockchain, called Logicontract (LC). We then extend the logic used in LC by answer set programming (ASP), a modern approach to declarative logic programming. Using ASP enables us to write various interesting smart contracts, such as conditional payment, commitment, multi-party lottery and legal service. A striking feature of our ASP implementation proposal is that it involves post-quantum cryptographic primitives, such as the lattice-based public key encryption and signature. The adoption of the post-quantum cryptographic signature overcomes a specific limitation of LC in which the unconditionally secure signature, despite its strength, offers limited protection for users of the same node.
... Another line of related work investigates the possibility of implementing financial contracts on distributed ledgers such as blockchains [6]. Included in this work is work on establishing a certified foundation for executing programs (also called smart contracts) on such architectures [18]. ...
We present an extension to a certified financial contract management system that allows for templated declarative financial contracts and for integration with financial stochastic models through verified compilation into so-called payoff-expressions. Such expressions readily allow for determining the value of a contract in a given evaluation context, such as contexts created for stochastic simulations. The templating mechanism is useful both at the contract specification level, for writing generic reusable contracts, and for reuse of code that, without the templating mechanism, needs to be recompiled for different evaluation contexts. We report on the effect of using the certified system in the context of a GPGPU-based Monte Carlo simulation engine for pricing various over-the-counter (OTC) financial contracts. The full contract-management system, including the payoff-language compilation, is verified in the Coq proof assistant and certified Haskell code is extracted from our Coq development along with Futhark code for use in a data-parallel pricing engine.
... In this manner, concurrent transactions are not upheld in the blockchain. Simplicity [30], Scilla [33] and Pact [32] smart contracts are constructed dependent on functional programming semantics. Their fundamental objective is to have side-effects less blockchain functions by utilizing a functional programming based methodology. ...
Existing blockchain smart contract platforms are designed as monolithic architectures. Even though there are multiple smart contracts with fully independent business logic, they run on a single monolithic container. This dependence on a monolithic container can be a performance bottleneck during the processing of a large number of transactions. To address this challenge, microservice-based architecture is adopted in the blockchain smart contracts by introducing a novel architecture to run independently on separate microservices. The new smart contract architecture is built on top of Mystiko blockchain, a functional programming and actor-based "Aplos" concurrent smart contract platform. Aplos is identified as a "Smart Actor" platform since it is built using Actor-based concurrency handling. Based on the philosophy of microservices, the Aplos Smart Actor platform on Mystiko blockchain is redesigned. This architecture is introduced as "SaaS-Smart actors as a service". With SaaS, different Aplos smart actors in the blockchain are deployed as separate independent services(e.g docker containers) instead of a single monolith service. This ensures different smart actors can execute transactions independently. An additional benefits to SaaS is that the architecture increases the scalability by guaranteeing concurrent execution of transactions, producing high transaction throughput on the blockchain.
... Each stakeholder can develop its own local knowledge at a lower level and subsequently update any sharable knowledge, which includes setting the related smart contracts (Bhargavan et al., 2016;Knecht and Stiller, 2017;O'Connor, 2017), agents that can manipulate the knowledge on the hierarchical KGs, and any data descriptions into the global KG. All updated knowledge from stakeholders will be regarded as transactions on the blockchain and all such knowledge will then be processed by integration agents into the global KG, before broadcasting the update to all nodes in the network. ...
In this article, we discuss a data sharing and knowledge integration framework through autonomous agents with blockchain for implementing Electronic Health Records (EHR). This will enable us to augment existing blockchain-based EHR Systems. We discuss how major concerns in the health industry, i.e., trust, security and scalability, can be addressed by transitioning from existing models to convergence of the three technologies – blockchain, agent-based modeling, and knowledge graph in a decentralized ecosystem. Each autonomous agent is responsible for instantiating key processes, such as user authentication and authorization, smart contracts, and knowledge graph generation through data integration among the participating stakeholders in the network. We discuss a layered approach for the design of the proposed system leading to an enhanced, safer clinical decision-making system. This can pave the way toward more informed and engaged patients and citizens by delivering personalized healthcare.
... Similarly, we also verify that the revised Payment Protocol in [32] fixes the vulnerability. This is the first formal model for an application of the Bitcoin blockchain and is complementary to other work in the research community which includes formal models for Nakamotostyle consensus protocols [21], formal verification of the runtime and functional correctness [7,25,44,29] for smart contracts in other cryptocurrencies due to substantial thefts, and formal languages for writing Bitcoin script [40]. ...
The Payment Protocol standard BIP70, specifying how payments in Bitcoin are performed by merchants and customers, is supported by the largest payment processors and most widely-used wallets. The protocol has been shown to be vulnerable to refund attacks due to lack of authentication of the refund addresses. In this paper, we give the first formal model of the protocol and formalise the refund address security goals for the protocol, namely refund address authentication and secrecy. The formal model utilises communication channels as abstractions conveying security goals on which the protocol modeller and verifier can rely. We analyse the Payment Protocol confirming that it is vulnerable to an attack violating the refund address authentication security goal. Moreover, we present a concrete protocol revision proposal supporting the merchant with publicly verifiable evidence that can mitigate the attack. We verify that the revised protocol meets the security goals defined for the refund address. Hence, we demonstrate that the revised protocol is secure, not only against the existing attacks, but also against any further attacks violating the formalised security goals.
... Similarly, we also verify that the revised Payment Protocol in [32] fixes the vulnerability. This is the first formal model for an application of the Bitcoin blockchain and is complementary to other work in the research community which includes formal models for Nakamotostyle consensus protocols [21], formal verification of the runtime and functional correctness [7,25,44,29] for smart contracts in other cryptocurrencies due to substantial thefts, and formal languages for writing Bitcoin script [40]. ...
The Payment Protocol standard BIP70, specifying how payments in Bitcoin are performed by merchants and customers, is supported by the largest payment processors and most widely-used wallets. The protocol has been shown to be vulnerable to refund attacks due to lack of authentication of the refund addresses. In this paper, we give the first formal model of the protocol and formalise the refund address security goals for the protocol, namely refund address authentication and secrecy. The formal model utilises communication channels as abstractions conveying security goals on which the protocol modeller and verifier can rely. We analyse the Payment Protocol confirming that it is vulnerable to an attack violating the refund address authentication security goal. Moreover, we present a concrete protocol revision proposal supporting the merchant with publicly verifiable evidence that can mitigate the attack. We verify that the revised protocol meets the security goals defined for the refund address. Hence, we demonstrate that the revised protocol is secure, not only against the existing attacks, but also against any further attacks violating the formalised security goals.
... Simplicity [15] is a non-Turing-complete (no recursions or loops) low-level SC language. Like SCUR it is intended as a compilation target instead of a higher-level programming language. ...
Transactions (TX) sent and executed by a public Blockchain (BC) need to pay a TX fee. The fee is relative to the resources consumed when including the TX into a block. The sender of the TX pays the fee in the native currency of the BC used. Such a fee protects the network from Denial-of-Service (DoS) attacks and incentivizes the TXs inclusion. BCs that support Smart Contracts (SC), where TXs can execute user-provided code, require a mechanism for fee calculation depending on resources consumed by the code execution. Ethereum uses an elaborated mechanism compared to Bitcoin, leading to an increase in the attack surface of their SCs. The mechanism that makes the Bitcoin script-a limited version of SCs-more secure is the ability to compute, independent from the BC state, an upper-bound on the resources needed to execute a TX. Thus, this work here proposes a new approach that enables security benefits by defining an upper-bound on resource usage for general SCs. Furthermore, the approach allows for the payment of fees in any currency and not just the native currency of the BC.
... Vyper [33] is a popular language on Ethereum network that restricts loops and disallows recursion with the aim of enhancing security and readability. Simplicity [26] is a functional language for smart contract programming accompanied by formal denotational semantics defined in Coq. Tezos [17] blockchain supports contracts written in Liquidity [25], which is a high-level typed language with a formal verification framework under development. ...
This paper presents SigVM, a novel blockchain virtual machine that supports an event-driven execution model, enabling developers to build fully autonomous smart contracts. SigVM introduces another way for a contract to interact with another. Contracts in SigVM can emit signal events, on which other contracts can listen. Once an event is triggered, corresponding handler functions are automatically executed as signal transactions. We built an end-to-end blockchain platform SigChain and a contract language compiler SigSolid to realize the potential of SigVM. Experimental results show that SigVM enables contracts in our benchmark applications to be reimplemented in a fully autonomous way, eliminating the dependency on unreliable mechanisms like off-chain relay servers. SigVM can significantly simplify the execution flow of our benchmark applications, and can avoid security risks such as front-run attacks.
... In this manner, concurrent transactions are not upheld in the blockchain. Simplicity [30], Scilla [33] and Pact [32] smart contracts are constructed dependent on functional programming semantics. Their fundamental objective is to have side-effects less blockchain functions by utilizing a functional programming based methodology. ...
Existing blockchain smart contract platforms are designed as monolithic architectures. Even though there are multiple smart contracts with fully independent business logic, they run on a single monolithic container. This dependence on a monolithic container can be a performance bottleneck during the processing of a large number of transactions. To address this challenge, microservice-based architecture is adopted in the blockchain smart contracts by introducing a novel architecture to run independently on separate microservices. The new smart contract architecture is built on top of Mystiko blockchain, a functional programming and actor-based “Aplos” concurrent smart contract platform. Aplos is identified as a “Smart Actor” platform since it is built using Actor-based concurrency handling. Based on the philosophy of microservices, the Aplos Smart Actor platform on Mystiko blockchain is redesigned. This architecture is introduced as “SaaS - Smart actors as a service”. With SaaS, different Aplos smart actors in the blockchain are deployed as separate independent services (e.g. docker containers) instead of a single monolith service. This ensures different smart actors can execute transactions independently. An additional benefits to SaaS is that the architecture increases the scalability by guaranteeing concurrent execution of transactions, producing high transaction throughput on the blockchain.
... These proposals all aim to make the contracts more predictable. Simplicity [33] exhibits larger expressiveness yet allowing easy static analysis compared to EVM code. Static analysis provides useful upper bound computation estimation on the transactions, thus giving the peers more predictable views on the transaction execution. ...
... All transactions execute sequentially and it is the same when updating the ledger. This results in low transaction throughput and latency [5], [6]. ...
... It can be compiled to a Bitcoin script and its main advantage is its comprehensibility, which enables fast writing and an easy understanding of the code. Simplicity [174] is a typed functional language that works with combinators. It is equipped with (formal) denotational and operational semantics, which facilitate the estimation of the required computing resources. ...
Blockchains are distributed systems, in which security is a critical factor for their success. However, despite their increasing popularity and adoption, there is a lack of standardized models that study blockchain-related security threats. To fill this gap, the main focus of our work is to systematize and extend the knowledge about the security and privacy aspects of blockchains and contribute to the standardization of this domain. We propose the security reference architecture (SRA) for blockchains, which adopts a stacked model (similar to the ISO/OSI) describing the nature and hierarchy of various security and privacy aspects. The SRA contains four layers: (1) the network layer, (2) the consensus layer, (3) the replicated state machine layer, and (4) the application layer. At each of these layers, we identify known security threats, their origin, and countermeasures, while we also analyze several cross-layer dependencies. Next, to enable better reasoning about security aspects of blockchains by the practitioners, we propose a blockchain-specific version of the threat-risk assessment standard ISO/IEC 15408 by embedding the stacked model into this standard. Finally, we provide designers of blockchain platforms and applications with a design methodology following the model of SRA and its hierarchy.
... In fact, by constraining the expressiveness of Bitcoin script as well as introducing financial asset and transaction notions as first-class concepts, it renders large classes of potential smart contract vulnerabilities simply impossible by design. The functional language Simplicity is another notable language for designing smart contracts that are secure by design [17]. Simplicity is a functional language without loops and recursion, which comes with formal denotational semantics defined in Coq. ...
... Developing new contract language is an effective way to write the correct smart contract. A variety of programming languages such as Idris [35], Simplicity [36], Obsidian [39], and Flint [37] have been proposed. These Type-based functional languages make the development process safer. ...
A smart contract is an agreement between two or more parties, which is executed by the computer code. The code does the execution without giving either party the ability to back out, so it ensures the trustless execution. The smart contract is one of the most important features in blockchain applications, which implements trusted transactions without third parties. However, with the rapid development, blockchain smart contracts have also exposed many security problems, and some attacks caused by contract vulnerabilities have led to terrible losses. In order to better deal with such dilemma, making a comprehensive survey about the security verification of blockchain smart contracts from major scientific databases is quite indispensable. Even though the significance of studying security verification of blockchain smart contracts is evident, it is really fresh yet. The major contributions of our survey work come from three aspects. First, after retrieving all-sided research studies, we select 53 most related papers to show the state-of-the art of this topic, where 20 papers focus on dealing with security assurance of blockchain smart contracts, and 33 papers focus on the correctness verification of blockchain smart contracts. Second, we propose a taxonomy toward the topic of security verification of blockchain smart contracts and discuss the pros and cons of each category of related studies. Third, through in-depth analysis of these studies, we come to know that the correctness verification of smart contracts based on the formal method has already become the more significant and more effective method to validate whether a smart contract is credible and accurate. So, we further present representative studies of formal verification of smart contracts in detail to demonstrate that using a formal method to validate blockchain smart contracts must have a promising and meritorious future.
... On the verifiability aspect of smart contracts, O'Connor et al. [69] design a low-level Intermediate Representation (IR) language, Simplicity, which makes use of denotational semantics defined in Coq [192], a popular verification tool. With Coq and other auxiliary tools, Simplicity helps developers easily validate the security of smart contract. ...
Smart contract has been regarded as one of the most promising and appealing notions in blockchain technology. Its self-enforcing and event-driven features make some online activities possible without a trusted third party, especially those related to financial and business. However, problems such as high security risk and low processing rate prevent it from being widely applied. In order to facilitate the construction of secure smart contract, and to improve the execution performance, various schemes and tools are proposed. However, to our best knowledge, a comprehensive survey for these proposals is absent, hindering new researchers and developers from a quick start. This paper surveys the literature on constructing and executing smart contracts over the period 2008-2020. We review the literature in three categories: 1) design paradigms that give examples and patterns on contract construction; 2) design tools that facilitate the development of secure smart contracts by providing security analysis or other auxiliary helps; and 3) extensions and alternative systems that improve the privacy or efficiency of smart contract executions. We start by a brief introduction of essential backgrounds, and then investigate the contract construction schemes on the most prevalent and representative smart contract platforms, i.e., Bitcoin and Ethereum. We list and group them into the first two categories according to their utility. As for the last category, we review the existing contract execution mechanisms, and further divide the state-of-the-art solutions into three classes: private contracts with auxiliary tools, off-chain channels, and extensions on the core functionality. Finally, we summarize the future research directions towards secure and privacy-preserving smart contracts. As far as we know, our work is the first systematic survey on schemes of contract construction and execution.
... Babbage [33] was designed to express smart contracts in terms of mechanical components. Bamboo [34], Obsidian [35] and Simplicity [36] are other languages which specify contracts as state machine functions. ...
... Such issues may manifest as security vulnerabilities, some of which have led to security incidents with financial losses in the range of hundreds of millions of dollars worth of cryptocurrencies [20,43]. As a response, the research community has stepped forward and introduced a number of tools (e.g., [2,36,55,44]), frameworks (e.g., [37,39,38]), and even new languages (e.g., [45]) to help developers. ...
Blockchain-based platforms are emerging as a transformative technology that can provide reliability, integrity, and auditability without trusted entities. One of the key features of these platforms is the trustworthy decentralized execution of general-purpose computation in the form of smart contracts, which are envisioned to have a wide range of applications. As a result, a rapidly growing and active community of smart-contract developers has emerged in recent years. A number of research efforts have investigated the technological challenges that these developers face, introducing a variety of tools, languages, and frameworks for smart-contract development, focusing on security. However, relatively little is known about the community itself, about the developers, and about the issues that they face and discuss. To address this gap, we study smart-contract developers and their discussions on two social media sites, Stack Exchange and Medium. We provide insight into the trends and key topics of these discussions, into the developers’ interest in various security issues and security tools, and into the developers’ technological background.
... Furthermore, functional languages lend themselves towards translation into theorem proving frameworks, where assisted proofs for contract properties can be performed. Simplicity by O'Connor [30] is a typed functional contract language intended for UTXO-blockchains such as Bitcoin, with execution semantics formalized in Coq. Scilla [31] [32] draws inspiration from both functional and automata-based languages, but ultimately represents a functional language with an adaptor to Coq. ...
Smart contracting protocols promise to regulate the transfer of cryptocurrency amongst participants in a trustless manner. A safe smart contract implementation should ensure that each participant can always append a contract transaction to the blockchain in order move the contract towards secure completion. To this goal, we propose Bitcoin Trace-Net, a contract verification framework which generates an executable symbolic model from the underlying contract implementation. A Trace-Net model consists of a Petri Net formalism enriched with a Dolev-Yao-like actor knowledge model. The explicit symbolic actor knowledge model supports the verification of contracts featuring cryptographic sub-protocols, which may not be observable on the blockchain. Trace-Net is sufficiently expressive to accurately model blockchain semantics such as the delay between a transaction broadcast and its subsequent confirmation, as well as adversarial blockchain reorganizations of finite depths, both of which can break smart contract safety. As an implementation level framework, Trace-Net can be instantiated at run-time to monitor and verify smart contract protocol executions.
... Program execution removes the input UTXOs from the set and adds the fresh ones. This model was pioneered by Bitcoin's [26] Script [36] language, and has been adopted by a few more recent languages such as Simplicity [27] and Plutus [14]. Though UTXOs are a good choice for a platform with a single native currency and limited programmability, they are cumbersome to use for general-purpose state changes. ...
Smart contracts are programs that implement transactions on modern blockchain platforms. In this rapidly evolving environment, smart-contract programming languages must allow users to write programs that flexibly manage and transfer assets, while providing strong protection against sophisticated attacks. Addressing this need, we present flexible and reliable abstractions for programming with digital currency in the Move language. Move uses novel linear resource types with C++11/Rust-style move semantics as an explicit representation to represent assets such as money. When a resource variable is assigned to a new variable, the variable previously holding it must be invalidated. When combined with other abstraction features of Move, linearity ensures resource conservation: assets represented by resources can only be created or deleted by authorized parties, and cannot be duplicated or lost by others possessing them. We present an executable bytecode language with move semantics and show that it satisfies a set of resource safety guarantees.
... Such issues may manifest as security vulnerabilities, some of which have led to security incidents with financial losses in the range of hundreds of millions of dollars worth of cryptocurrencies [20,43]. As a response, the research community has stepped forward and introduced a number of tools (e.g., [2,36,55,44]), frameworks (e.g., [37,39,38]), and even new languages (e.g., [45]) to help developers. ...
Blockchain-based platforms are emerging as a transformative technology that can provide reliability, integrity, and auditability without trusted entities. One of the key features of these platforms is the trustworthy decentralized execution of general-purpose computation in the form of smart contracts, which are envisioned to have a wide range of applications. As a result, a rapidly growing and active community of smart-contract developers has emerged in recent years. A number of research efforts have investigated the technological challenges that these developers face, introducing a variety of tools, languages, and frameworks for smart-contract development, focusing on security. However, relatively little is known about the community itself, about the developers , and about the issues that they face and discuss. To address this gap, we study smart-contract developers and their discussions on two social media sites, Stack Exchange and Medium. We provide insight into the trends and key topics of these discussions, into the developers' interest in various security issues and security tools, and into the developers' technological background.
... However, most prominent studies have focused on the formal verification of the bytecode of the EVM, and the development of high-level formal specifications for Solidity and relevant formal verification tools has attracted considerably less interest despite its importance in programming and debugging smart contract software. Although some intermediate specification languages between Solidity and EVM bytecode have been developed, such as Scilla [17], Simplicity [18] and Bhargavan et al.'s [19], the Solidity syntax and semantics have not been formalized in a manner that is consistent with official documentation. However, the formal syntax and semantics of programming languages actually play a crucial role in several areas of computer science, particularly in program verification. ...
This paper reports a formal symbolic process virtual machine (FSPVM) denoted as FSPVM-E for verifying the reliability and security of Ethereum-based services at the source code level of smart contracts. A Coq proof assistant is employed for programming the system and for proving its correctness. The current version of FSPVM-E adopts execution-verification isomorphism, which is an application extension of Curry-Howard isomorphism, as its fundamental theoretical framework to combine symbolic execution and higher-order logic theorem proving. The four primary components of FSPVM-E include a general, extensible, and reusable formal memory framework, an extensible and universal formal intermediate programming language denoted as Lolisa, which is a large subset of the Solidity programming language using generalized algebraic datatypes, the corresponding formally verified interpreter of Lolisa, denoted as FEther, and assistant tools and libraries. The self-correctness of all components is certified in Coq. FSPVM-E supports the ERC20 token standard, and can automatically and symbolically execute Ethereum-based smart contracts, scan their standard vulnerabilities, and verify their reliability and security properties with Hoare-style logic in Coq.
... Simplicity (Bitcoin) [27] is a typed, combinator-based, functional language. It is designed to work as Turing incomplete schematic without loops and recursion, to be used for crypto-currencies and blockchain applications. ...
Smart contract is a programming interface to interact with the underlying blockchain storage models. It is a database abstraction layer for blockchain. Existing smart contract platforms follow the imperative style programming model since states are shared. As a result, there is no concurrency control mechanism when executing transactions, resulting in considerable latency and hindering scalability. To address performance and scalability issues of existing smart contract platforms, we design a new smart contract platform called “Aplos” based on the Scala functional programming language and Akka actors. In Aplos, all blockchain-related smart contract functions are implemented with Akka actors. The Aplos platform is built over Mystiko—a highly scalable blockchain storage for big data. Mystiko supports concurrent transactions, high transaction throughput, data analytics and machine learning. With Aplos smart contracts over Mystiko, we have developed a blockchain for highly scalable storage that aligns with big data requirements.
This paper presents SigVM, the first blockchain virtual machine that extends EVM to support an event-driven execution model, enabling developers to build truly decentralized smart contracts. Contracts in SigVM can emit signal events, on which other contracts can listen. Once an event is triggered, corresponding handler functions are automatically executed as signal transactions. We build an end-to-end blockchain platform SigChain and a contract language compiler SigSolid to realize the potential of SigVM. Experimental results show that our benchmark applications can be reimplemented with SigVM in a truly decentralized way, eliminating the dependency on centralized and unreliable mechanisms like off-chain relay servers. The development effort of reimplementing these contracts with SigVM is small, i.e., we modified on average 3.17% of the contract code. The runtime and the gas overhead of SigVM on these contracts is negligible.
In recent years, advanced smart contract languages (ASCLs) have been proposed to solve the problem of difficult reading, comprehension, and collaboration when writing smart legal contracts among people in different fields. However, this kind of languages are still hard to put into practice due to the lack of an effective conversion method from the ASCLs to executable smart contract programs. Aiming at this problem, we take SPESC as example to explore how to design conversion rules from the contract in it to the target programming language in Solidity, and to propose a three-layer smart contract framework, including advanced smart-contract layer, general smart-contract layer, and executable machine-code layer. These rules provide an approach to convert the definition of SPESC contracting parties into party-contracts on target language, as well as to produce SPESC contract terms into main-contract on target language. Moreover, the proposed framework specifies not only program architecture and storage structure on general smart-contract layer, but also important mechanisms, including personnel management, timing control, exception handling, etc., which can assist programmers to write smart contract programs. Furthermore, taking four SPESC contracts as testing objects, we provide the whole process of converting from SPESC contracts to Solidity programs by the SPESC-Translator, and verify the efficiency and security of the conversion process, including coding, deploying, running, and testing through Ethereum. The instance results show that the conversion rules and the three-layer framework can simplify the writing of smart contracts, standardize the program structure, and help programmers to verify the correctness of the contract programs.
Blockchain-enabled smart contracts are subjected to several issues leading to vigorous attacks such as the decentralized autonomous organization (DAO) and the ParitySig bug on the Ethereum platform with disastrous consequences. Several solutions have been proposed. However, new threats are identified as technology evolves and new solutions are produced, while some older threats remain unsolved. Thus, the need to fill the gap with a more comprehensive survey on existing issues and solutions for researchers and practitioners arises. The resulting updated database will become an essential means for choosing a particular solution for a specific subject. In this review, the authors embrace mainly codifying security privacy and performance issues and their respective solutions. Each problem is attached to its corresponding solutions when they exist. A summary of the threats and solutions is provided as well as the relationship between threat importance and the given answers. They finally enumerate some directives for future works.
Several languages have been developed for writing smart contracts for specific domains, such as health, finance, and business processes. However, none of them includes the constructors needed for writing smart contracts used in application integration processes which have their own particularities. Such smart contracts are responsible for monitoring the communication between the process and the applications to guarantee that the rights of the parties involved in the integration process are observed. To cover the gap, this paper discusses a domain-specific language for writing smart contracts in the application integration domain. It provides constructors to write smart contracts with a level of abstraction close to the natural language used in conventional contracts.
Blockchain is a disruptive technology intended to implement secure decentralised distributed systems, in which transactional data can be shared, stored, and verified by participants of the system without needing a central authentication/verification authority. Blockchain-based systems have several architectural components and variants, which architects can leverage to build secure software systems. However, there is a lack of studies to assist architects in making architecture design and configuration decisions for blockchain-based systems. This knowledge gap may increase the chance of making unsuitable design decisions and producing configurations prone to potential security risks. To address this limitation, we report our comprehensive systematic literature review to derive a taxonomy of commonly used architecture design decisions in blockchain-based systems. We map each of these decisions to potential security attacks and their posed threats. MITRE’s attack tactic categories and Microsoft STRIDE threat modeling are used to systematically classify threats and their associated attacks to identify potential attacks and threats in blockchain-based systems. Our mapping approach aims to guide architects to make justifiable design decisions that will result in more secure implementations.
Despite the great potential capabilities and the mature technological solutions, the smart contracts have never been used at a large scale, one of the reasons being the lack of good methods to verify the correctness and security of the contracts—although the technology itself (e.g. the Ethereum platform) is well studied and secure, the actual smart contracts are human-made and thus inherently error-prone. As a consequence, critical vulnerabilities in the contracts are discovered and exploited every few months. The most prominent example of a buggy contract was the infamous DAO attack—a successful attack on the largest Ethereum contract in June 2016 resulting in $70 mln-worth Ether stolen and the hard fork of the Ethereum network (80% of Ethereum users decided to revert the transaction and hence two parallel transaction histories exist from that event).
A smart contract is a computer program that allows users to automate their actions on the blockchain platform. Given the significance of smart contracts in supporting important activities across industry sectors including supply chain, finance, legal, and medical services, there is a strong demand for verification and validation techniques. Yet, the vast majority of smart contracts lack any kind of formal specification, which is essential for establishing their correctness. In this survey, we investigate formal models and specifications of smart contracts presented in the literature and present a systematic overview to understand the common trends. We also discuss the current approaches used in verifying such property specifications and identify gaps with the hope to recognize promising directions for future work.
This paper investigates the usage of logic and logic programming in the design of smart contracts. Our starting point is the logic-based programming language for smart contract used in a recent proposed framework of quantum-secured blockchain called Logicontract (LC). We then extend the logic used in LC by answer set programming (ASP), a modern approach to declarative logic programming. Using ASP enables us to write various interesting smart contracts, such as conditional payment, commitment, multi-party lottery and legal service. A striking feature of our ASP is that it involves post-quantum cryptographic primitives such as lattice-based public key encryption and signature. The adoption of post-quantum cryptographic signature overcomes a limitation of LC, in which only unconditionally secure signature is used.
The development of Industry 4.0, smart contract is one of critical application in the blockchain platform, which is the remove of intermediary services to facilitate transactions directly between stakeholders, in which the trust between stakeholders is guaranteed by a blockchain system. However, existing solution of automated execution of smart contract is simply given by the prescribed program code. This solution results in two negative effects: the contract is not human-readable and difficult to modify; contracting parties cannot collaboratively draft the contract and cannot assure the shared consent of the contract. Therefore, we will introduce a brand-new solution of smart contract, called Intelligible Description Language Contract (IDLC). It will allow contracting parties to draft a contract collaboratively just as working on text editor with a supportive tool of concept disambiguation through Supervised Sentence Contract (SSC). SSC consists of Machine Natural language (MNL) via Semantic input method (SIM). SIM provides a method of supervised contract obligation creation. MNL provides the capability of universal computer-understandability. Meanwhile, in the complex contract transactions and management, especially in supply chain management, a chained evidence sequence is designed to avoid collusion. IDLC is a first paradigm that bridges the traditional contract based on natural languages and the smart contract based on blockchain platform.
Blockchain-based decentralized infrastructure has been adapted in various industries to handle the sensitive data in a privacy-preserving manner without trusting third parties. However, integrating state-of-the-art blockchain platforms with the scalable, enterprise-level applications result in several challenges. Current blockchain platforms do not support high transaction throughput, lack high scalability, and cannot provide real-time transaction processing and back-pressure operation handling in high transaction throughput applications(e.g Big data, IoT). In this paper, we propose a novel permissioned blockchain platform “Rahasak” for highly scalable, enterprise applications. Rahasak blockchain adopts the Apache Kafka-based consensus on top of a “Validate-Execute-Group” blockchain architecture to handle real-time transaction execution on the blockchain. The architecture is equipped with a functional programming and actor-based smart contract platform that enables concurrent execution of transactions in the blockchain. Rahasak supports high transaction throughput, high scalability, concurrent transaction execution, data analytics features. With Rahasak, we make blockchain more scalable, secure, structured and meaningful for further data analytics.
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 prevent 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.
Blockchain is a disruptive technology that has attracted the attention of the scientific community and companies, as proven by the exponential growth of publications on this topic in recent years. This growing interest is mainly due to the promise that the use of blockchain enables it to be verified, without including any trusted intermediaries, that the information received from the network is authentic and up-to-date. In this respect, blockchain is a distributed database that can be seen as a ledger that records all transactions that have ever been executed. In this context, smart contracts are pieces of software used to facilitate, verify, and enforce the negotiation of a transaction on a blockchain platform. These pieces of software are implemented by using programming languages, which are sometimes provided by the blockchain platforms themselves. This study aims to (1) identify and categorise the state-of-the-art related to smart contract languages, in terms of the existing languages and their main features, and (2) identify new research opportunities. The review has been conducted as a multivocal mapping study that follows the guidelines proposed by Garousi et al. for conducting multivocal literature reviews, as well as the guidelines proposed by Kitchenham and Charters for conducting mapping studies. As a result of the implementation of the review protocol, 4,119 papers were gathered, and 109 of them were selected for extraction. The contributions of this article are twofold: (1) 101 different smart contract languages have been identified and classified according to a variety of criteria; (2) a discussion on the findings and their implications for future research have been outlined. As a conclusion, it could be stated that a rigorous and replicable overview of the state-of-the-art of smart contract languages has been provided that can benefit not only researchers but also practitioners in the field, thanks to its multivocal nature.
We present a model/executable specification of smart contract execution in Coq. Our formalization allows for inter-contract communication and generalizes existing work by allowing modelling of both depth-first execution blockchains (like Ethereum) and breadth-first execution blockchains (like Tezos). We represent smart contracts programs in Coq’s functional language Gallina, enabling easier reasoning about functional correctness of concrete contracts than other approaches. In particular we develop a Congress contract in this style. This contract – a simplified version of the infamous DAO – is interesting because of its very dynamic communication pattern with other contracts. We give a high-level partial specification of the Congress’s behavior, related to reentrancy, and prove that the Congress satisfies it for all possible smart contract execution orders.
It is crucial that smart contracts are tested thoroughly due to their immutable nature. Even small bugs in smart contracts can lead to huge monetary losses. However, testing is not enough; it is also important to ensure the quality and completeness of the tests. There are already several approaches that tackle this challenge with mutation testing, but their effectiveness is questionable since they only considered small contract samples. Hence, we evaluate the quality of smart contract mutation testing at scale. We choose the most promising of the existing (smart contract specific) mutation operators, analyse their effectiveness in terms of killability and highlight severe vulnerabilities that can be injected with the mutations. Moreover, we improve the existing mutation methods by introducing a novel killing condition that is able to detect a deviation in the gas consumption, i.e., in the monetary value that is required to perform transactions.
Blockchain technology is believed by many to be a game changer in many application domains. While the first generation of blockchain technology (i.e., Blockchain 1.0) is almost exclusively used for cryptocurrency, the second generation (i.e., Blockchain 2.0), as represented by Ethereum, is an open and decentralized platform enabling a new paradigm of computing—Decentralized Applications (DApps) running on top of blockchains. The rich applications and semantics of DApps inevitably introduce many security vulnerabilities, which have no counterparts in pure cryptocurrency systems like Bitcoin. Since Ethereum is a new, yet complex, system, it is imperative to have a systematic and comprehensive understanding on its security from a holistic perspective, which was previously unavailable in the literature. To the best of our knowledge, the present survey, which can also be used as a tutorial, fills this void. We systematize three aspects of Ethereum systems security: vulnerabilities, attacks, and defenses. We draw insights into vulnerability root causes, attack consequences, and defense capabilities, which shed light on future research directions.
This paper reports on the development and formal verification (proof of semantic preservation) of CompCert, a compiler from Clight (a large subset of the C programming language) to PowerPC assembly code, using the Coq proof assistant both for programming the compiler and for proving its correctness. Such a verified compiler is useful in the context of critical software and its formal verification: the verification of the compiler guarantees that the safety properties proved on the source code hold for the executable compiled code as well.
Ethereum is a framework for cryptocurrencies which uses blockchain technology to provide an open global computing platform, called the Ethereum Virtual Machine (EVM). EVM executes bytecode on a simple stack machine. Programmers do not usually write EVM code; instead, they can program in a JavaScript-like language, called Solidity, that compiles to bytecode. Since the main purpose of EVM is to execute smart contracts that manage and transfer digital assets (called Ether), security is of paramount importance. However, writing secure smart contracts can be extremely difficult: due to the openness of Ethereum, both programs and pseudonymous users can call into the public methods of other programs, leading to potentially dangerous compositions of trusted and untrusted code. This risk was recently illustrated by an attack on TheDAO contract that exploited subtle details of the EVM semantics to transfer roughly $50M worth of Ether into the control of an attacker.
In this paper, we outline a framework to analyze and verify both the runtime safety and the functional correctness of Ethereum contracts by translation to F*, a functional programming language aimed at program verification.
This article presents a full formal machine-checked verification of a C program: theOpenSSL implementation of SHA-256. This is an interactive proof of functional correctness in the Coq proof assistant, using the Verifiable C program logic. Verifiable C is a separation logic for the C language, proved sound with respect to the operational semantics for C, connected to the CompCert verified optimizing C compiler.
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
We present an efficient interactive identification scheme and a related signature scheme that are based on discrete logarithms
and which are particularly suited for smart cards. Previous cryptoschemes, based on the discrete logarithm, have been proposed
by El Gamal (1985), Chaum, Evertse, Graaf (1988), Beth (1988) and Günter (1989). The new scheme comprises the following novel
features.
A unification algorithm is described which tests a set of expressions for unifiability and which requires time and space which are only linear in the size of the input.
Monads provide a way of structuring functional programs. Most real applications require a combination of primitive monads. Here we describe how some monads may be combined with others to yield a combined monad. 1 Introduction Monads are taking root in the field of functional programming. Although their origins lay in the abstractions of category theory, they have a wide range of practical applications. Moggi [6] showed how they could be used to structure the semantics of computations. Since then Wadler [9, 10] adapted this idea to structure functional programs. When structuring functional programs like parsers, type checkers or interpreters, it is often the case that the monad needed is a combination of many, a so called combined monad. For our purposes, we will think of a monad as a type constructor, together with three functions that must satisfy certain laws. For instance, we may have an interpreter and wish it to return, not just a value, but the number of reduction steps taken t...
BIP16: Pay to Script Hash
- G Andresen
G. Andresen. 2012. BIP16: Pay to Script Hash. Bitcoin Improvement Proposal.
(2012). https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki.
BIP114: Merkelized Abstract Syntax Tree
- J Lau
J. Lau. 2016. BIP114: Merkelized Abstract Syntax Tree. Bitcoin Improvement Proposal. (2016). https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki.
Zero-Knowledge Contingent Payment
- G Maxwell
G. Maxwell. 2011. Zero-Knowledge Contingent Payment. (2011). https://en.
bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment.
misc changes. https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82). shownotehttps
- S Nakamoto
Ethereum: A Secure Decentralised Generalised Transaction Ledger
- G Wood
G. Wood. 2014. Ethereum: A Secure Decentralised Generalised Transaction
Ledger. (2014). http://gavwood.com/paper.pdf.
Urbit: A Solid-State Interpreter
- C Yarvin
- P Monk
- A Dyudin
- R Pasco
- P Yarvin
- A Monk
- R Dyudin
- Pasco
- Yarvin C.
C. Yarvin, P. Monk, A. Dyudin, and R. Pasco. 2016. Urbit: A Solid-State Interpreter.
(May 2016). http://media.urbit.org/whitepaper.pdf.
Enabling Blockchain Innovations with Pegged Sidechains
- A Back
- M Corallo
- L Dashjr
- M Friedenbach
- G Maxwell
- A Miller
- A Poelstra
- J Timón
- P Wuille
A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra,
J. Timón, and P. Wuille. 2014. Enabling Blockchain Innovations with Pegged
Sidechains. (2014). https://www.blockstream.com/sidechains.pdf.
Formal Verification of Smart Contracts: Short Paper
- K Bhargavan
- A Delignat-Lavaud
- C Fournet
- A Gollamudi
- G Gonthier
- N Kobeissi
- N Kulatova
- A Rastogi
- T Sibut-Pinote
- N Swamy
- S Zanellabéguelin
K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier, N.
Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. ZanellaBéguelin. 2016. Formal Verification of Smart Contracts: Short Paper. In Proceedings
of the 2016 ACM Workshop on Programming Languages and Analysis for Security
(PLAS '16). ACM, New York, NY, USA, 91-96. https://doi.org/10.1145/2993600.
2993611
Script. https://en.bitcoin.it/w/index.php?title=Script&oldid= 61707
- Bitcoinwiki
bitcoinwiki. 2016. Script. https://en.bitcoin.it/w/index.php?title=Script&oldid=
61707. (2016).
BIP112: CHECKSEQUENCEVERIFY. Bitcoin Improvement Proposal
- M Btcdrak
- E Friedenbach
- Lombrozo
BtcDrak, M. Friedenbach, and E. Lombrozo. 2015. BIP112: CHECKSEQUENCEVERIFY. Bitcoin Improvement Proposal. (2015). https://github.com/bitcoin/bips/
blob/master/bip-0112.mediawiki.
CRITICAL UPDATE Re: DAO Vulnerability
- V Buterin
V. Buterin. 2016. CRITICAL UPDATE Re: DAO Vulnerability. https://blog.
ethereum.org/2016/06/17/critical-update-re-dao-vulnerability/. (June 2016).
Standards for Efficient Cryptography 2: Recommended Elliptic Curve Domain Parameters. Standard SEC2
- Certicom Research
Certicom Research. 2000. Standards for Efficient Cryptography 2: Recommended
Elliptic Curve Domain Parameters. Standard SEC2. Certicom Corp., Mississauga,
ON, USA.
Announcing Ivy Playground
- Chain
Chain. 2017. Announcing Ivy Playground. (May 2017). https://blog.chain.com/
announcing-ivy-playground-395364675d0a.
Σ-State Authentication Language, an Alternative to Bitcoin Script
- A Chepurnoy
A. Chepurnoy. 2017. Σ-State Authentication Language, an Alternative to Bitcoin Script. Poster Session at the 21st International Conference on Financial
Cryptography and Data Security. (April 2017).
Solidity Documentation: Release 0.4.14. https://media. readthedocs.org/pdf/solidity/develop/solidity.pdf
- Ethereum
Ethereum. 2017. Solidity Documentation: Release 0.4.14. https://media.
readthedocs.org/pdf/solidity/develop/solidity.pdf. (June 2017).
Signature Hash Types
- Bitcoin Developer Guide
Bitcoin Developer Guide. 2014. Signature Hash Types. (2014). https://bitcoin.
org/en/developer-guide#signature-hash-types.
misc changes. https://github.com/bitcoin/bitcoin/commit/ 4bd188c4383d6e614e18f79dc337fbabe8464c82
- S Nakamoto
S. Nakamoto. 2010. misc changes. https://github.com/bitcoin/bitcoin/commit/
4bd188c4383d6e614e18f79dc337fbabe8464c82. (Aug. 2010). https://bitcoin.svn.
sourceforge.net/svnroot/bitcoin/trunk@131.
FIPS 180-4, Secure Hash Standard Publication 180-4 Blog post
National institute of standards and technology. 2015. FIPS 180-4, Secure Hash
Standard, Federal Information Processing Standard (FIPS), Publication 180-4. Technical Report. DEPARTMENT OF COMMERCE. http://nvlpubs.nist.gov/nistpubs/
FIPS/NIST.FIPS.180-4.pdf
[25] R. O'Connor. 2016. Covenants in Elements Alpha. (2016). Blog post, https:
//blockstream.com/2016/11/02/covenants-in-elements-alpha.html.
The Multi-sig Hack: A Postmortem https://blog.parity. io/the-multi-sig-hack-a-postmortem
- Parity
Parity. 2017. The Multi-sig Hack: A Postmortem. (July 2017). https://blog.parity.
io/the-multi-sig-hack-a-postmortem/.
BIP65: OP_CHECKLOCKTIMEVERIFY. Bitcoin Improvement Proposal
- P Todd
P. Todd. 2014. BIP65: OP_CHECKLOCKTIMEVERIFY. Bitcoin Improvement Proposal. (2014). https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki.
- M Btcdrak
- E Friedenbach
- Lombrozo
BtcDrak, M. Friedenbach, and E. Lombrozo. 2015. BIP112: CHECKSEQUENCEV-ERIFY. Bitcoin Improvement Proposal. (2015). https://github.com/bitcoin/bips/
blob/master/bip-0112.mediawiki.
Re: Transactions and Scripts: DUP HASH160
- S Nakamoto
S. Nakamoto. 2010. Re: Transactions and Scripts: DUP HASH160... EQUALVER-IFY CHECKSIG. https://bitcointalk.org/index.php?topic=195.msg1611#msg1611.
(June 2010).
Covenants in Elements Alpha
- R O'connor
R. O'Connor. 2016. Covenants in Elements Alpha. (2016). Blog post, https:
//blockstream.com/2016/11/02/covenants-in-elements-alpha.html.
Covenants in Elements Alpha
- R Connor
Efficient Identification and Signatures for Smart Cards Proceedings of CRYPTO »89 . C. P. Schnorr. 1989. Efficient Identification and Signatures for Smart Cards Proceedings of CRYPTO
- C P Schnorr
- Schnorr C. P.