Designing Secure Ethereum Smart Contracts: A Finite State Machine Based Approach

The adoption of blockchain-based distributed computation platforms is growing fast. Some of these platforms, such as Ethereum, provide support for implementing smart contracts, which are envisioned to have novel applications in a broad range of areas, including finance and Internet-of-Things. However, a significant number of smart contracts deployed in practice suffer from security vulnerabilities, which enable malicious users to steal assets from a contract or to cause damage. Vulnerabilities present a serious issue since contracts may handle financial assets of considerable value, and contract bugs are non-fixable by design. To help developers create more secure smart contracts, we introduce FSolidM, a framework rooted in rigorous semantics for designing con- tracts as Finite State Machines (FSM). We present a tool for creating FSM on an easy-to-use graphical interface and for automatically generating Ethereum contracts. Further, we introduce a set of design patterns, which we implement as plugins that developers can easily add to their contracts to enhance security and functionality

An empirical analysis of smart contracts: platforms, applications, and design patterns

Smart contracts are computer programs that can be consistently executed by a network of mutually distrusting nodes, without the arbitration of a trusted authority. Because of their resilience to tampering, smart contracts are appealing in many scenarios, especially in those which require transfers of money to respect certain agreed rules (like in financial services and in games). Over the last few years many platforms for smart contracts have been proposed, and some of them have been actually implemented and used. We study how the notion of smart contract is interpreted in some of these platforms. Focussing on the two most widespread ones, Bitcoin and Ethereum, we quantify the usage of smart contracts in relation to their application domain. We also analyse the most common programming patterns in Ethereum, where the source code of smart contracts is available.Comment: WTSC 201

Capturing Smart Contract Design with DCR Graphs

Smart contracts manage blockchain assets. While smart contracts embody business processes, their platforms are not process-aware. Mainstream smart contract programming languages such as Solidity do not have explicit notions of roles, action dependencies, and time. Instead, these concepts are implemented in program code. This makes it very hard to design and analyze smart contracts. We argue that DCR graphs are a suitable formalization tool for smart contracts because they explicitly and visually capture these features. We utilize this expressiveness to show that many common high-level design patterns in smart-contract applications can be naturally modeled this way. Applying these patterns shows that DCR graphs facilitate the development and analysis of correct and reliable smart contracts by providing a clear and easy-to-understand specification

Interacting Components

SystemCSP is a graphical modeling language based on both CSP and concepts of component-based software development. The component framework of SystemCSP enables specification of both interaction scenarios and relative execution ordering among components. Specification and implementation of interaction among participating components is formalized via the notion of interaction contract. The used approach enables incremental design of execution diagrams by adding restrictions in different interaction diagrams throughout the process of system design. In this way all different diagrams are related into a single formally verifiable system. The concept of reusable formally verifiable interaction contracts is illustrated by designing set of design patterns for typical fault tolerance interaction scenarios

Smart Contract Upgradeability on the Ethereum Blockchain Platform: An Exploratory Study

Context: Smart contracts are computerized self-executing contracts that contain clauses, which are enforced once certain conditions are met. Smart contracts are immutable by design and cannot be modified once deployed, which ensures trustlessness. Despite smart contracts' immutability benefits, upgrading contract code is still necessary for bug fixes and potential feature improvements. In the past few years, the smart contract community introduced several practices for upgrading smart contracts. Upgradeable contracts are smart contracts that exhibit these practices and are designed with upgradeability in mind. During the upgrade process, a new smart contract version is deployed with the desired modification, and subsequent user requests will be forwarded to the latest version (upgraded contract). Nevertheless, little is known about the characteristics of the upgrading practices, how developers apply them, and how upgrading impacts contract usage. Objectives: This paper aims to characterize smart contract upgrading patterns and analyze their prevalence based on the deployed contracts that exhibit these patterns. Furthermore, we intend to investigate the reasons why developers upgrade contracts (e.g., introduce features, fix vulnerabilities) and how upgrades affect the adoption and life span of a contract in practice. Method: We collect deployed smart contracts metadata and source codes to identify contracts that exhibit certain upgrade patterns (upgradeable contracts) based on a set of policies. Then we trace smart contract versions for each upgradable contract and identify the changes in contract versions using similarity and vulnerabilities detection tools. Finally, we plan to analyze the impact of upgrading on contract usage based on the number of transactions received and the lifetime of the contract version

Contract as Pattern Language

This essay examines how patterns enable the transformation of contractual provisions into contracts, contracts into transactions, and transactions into markets. Although contract design patterns are broader than contract boilerplate (as described in Part II.C. below), some of the extensive legal scholarship on boilerplate19 helps explain how contract patterns generate agreements, transactions, and markets. The work of Henry Smith on the modularity of contract boilerplate proves particularly useful in this regard. Contract patterns perform several functions. Contract patterns break complex problems and bargains into components. Attorneys can then repeatedly apply these particular solutions to similar problems. Patterns also serve as heuristics for attorneys, i.e., devices to estimate quickly whether particular language solves certain bargaining problems, meets client objectives, and will be interpreted by courts in an anticipated manner

Make Versus Buy in Trucking: Asset Ownership, Job Design and Information

Explaining patterns of asset ownership in the economy is a central goal of both organizational economics and industrial organization. We develop a model of asset ownership in trucking, which we test by examining how the adoption of different classes of on-board computers (OBCs) between 1987 and 1997 influenced whether shippers use their own trucks for hauls or contract with for-hire carriers. We find that OBCs' incentive-improving features pushed hauls toward private carriage, but their resource-allocation-improving features pushed them toward for-hire carriage. We conclude that ownership patterns in trucking reflect the importance of both incomplete contracts (Grossman and Hart (1986)) and of job design and measurement issues (Holmstrom and Milgrom (1994)).

A Formal Model of Algorand Smart Contracts

We develop a formal model of Algorand stateless smart contracts (stateless ASC1). We exploit our model to prove fundamental properties of the Algorand blockchain, and to establish the security of some archetypal smart contracts. While doing this, we highlight various design patterns supported by Algorand. We perform experiments to validate the coherence of our formal model w.r.t. the actual implementation