Paper summary. Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab
This paper, on our seminar reading list, was our first real intro to the "smartcontracts", so we liked that the paper was written to be very accessible.
A smart contract is a program that is executed by all miners and its outputs incorporated to the blockchain. A contract consists of program code, a storage file, and an account balance. The program code of a contract is fixed when the contract is created, and cannot be changed.
The contract's code is executed whenever it receives a message from a user or from another contract. While executing its code, the contract may read from or write to its storage file. The contract's storage file is stored on the public blockchain. A contract can also receive money into its account balance, and send money to other contracts or users. A contract's entire state is visible to the public.
Ethereum uses the concept of "gas" (bought by currency) to discourage over-consumption of resources. During the execution of a transaction, every program instruction consumes some amount of gas. If the gas runs out before the transaction reaches an ordinary stopping point, it is treated as an exception: the state is reverted as though the transaction had no effect, but the Ether used to purchase the gas is not refunded!
This program in Ethereum Serpent language (Ethereum now uses Solidity as the programming language) implements a simple financial "swap" instrument. The contract allows two parties, Alice and Bob, who take opposing bets about the price of a stock at some future time. Both parties initially deposit equal amounts of money (as units of Ether currency). After a deadline has passed, the current price of the stock is queried by interacting with a designated stock price authority (implemented as a smart contract, StockPriceAuthority). Depending on the price at that time, the entire combined deposit is awarded to either Alice or Bob.
On lines 1 and 2, the contract's storage allocates space for the public keys of Alice and Bob, and 2) the deadline and threshold of the swap contract. The contract also defines a function determine outcome, which any party may invoke.
In Section 4.1, the concurrency caused errors take the lead place. As the paper "Blockchains from a distributed computing perspective" argued, smartcontracts have a surprising amount of concurrency in them in the so-called chain serialized transactions. The paper mentioned: "We have seen that the notion that smart contracts do not need a concurrency model because execution is single-threaded is a dangerous illusion."
In the "rock, papers, scissors" contract, what happens to a third player that attempts to join and sends money to the contract? That money becomes inaccessible to anyone.
Another thing that was surprising to me is that when you are writing a smartcontract you need to take incentives into account as another constraint in the problem. In the "rock, papers, scissors" contract,
For example, one party can wait for the other to open its commitment. Upon seeing that he will lose, that party may elect to abort (after all revealing its committed input costs gas). But, this denies payment to the other player as well. The solution is to use an additional security deposit and add a deadline after which not revealing implies losing.
Step 1: You have a problem
Step 2: You introduce a blockchain to solve problem
Step 3: You now have an incentives problem, a trust distribution problem, a community management problem, a regulation problem, a speculation problem, an upgrade path problem.
Of course there are additional problems due to cryptography, how to keep the committed inputs secret, etc. Finally, Section 4.4. in the paper discusses Ethereum specific bugs. I am not sure how many of these still apply after 3 years, in 2018.
2. Every miner needing to execute the smartcontract for validation is also very wasteful. How can that be relaxed? Is it possible to devise a way where the output can be checked quickly without having to execute the entire code?
PS: Relevant to this paper, here is the DAO smartcontract attack modeling I wrote about earlier.
A smart contract is a program that is executed by all miners and its outputs incorporated to the blockchain. A contract consists of program code, a storage file, and an account balance. The program code of a contract is fixed when the contract is created, and cannot be changed.
The contract's code is executed whenever it receives a message from a user or from another contract. While executing its code, the contract may read from or write to its storage file. The contract's storage file is stored on the public blockchain. A contract can also receive money into its account balance, and send money to other contracts or users. A contract's entire state is visible to the public.
Ethereum uses the concept of "gas" (bought by currency) to discourage over-consumption of resources. During the execution of a transaction, every program instruction consumes some amount of gas. If the gas runs out before the transaction reaches an ordinary stopping point, it is treated as an exception: the state is reverted as though the transaction had no effect, but the Ether used to purchase the gas is not refunded!
This program in Ethereum Serpent language (Ethereum now uses Solidity as the programming language) implements a simple financial "swap" instrument. The contract allows two parties, Alice and Bob, who take opposing bets about the price of a stock at some future time. Both parties initially deposit equal amounts of money (as units of Ether currency). After a deadline has passed, the current price of the stock is queried by interacting with a designated stock price authority (implemented as a smart contract, StockPriceAuthority). Depending on the price at that time, the entire combined deposit is awarded to either Alice or Bob.
On lines 1 and 2, the contract's storage allocates space for the public keys of Alice and Bob, and 2) the deadline and threshold of the swap contract. The contract also defines a function determine outcome, which any party may invoke.
Pitfalls of Smart Contract Programming
Section 4 describes prominent errors made when coding smart contract. It uses a "rock, papers, scissors" playing smartcontract and show a surprising amount of things that can go wrong in a simple problem like that.In Section 4.1, the concurrency caused errors take the lead place. As the paper "Blockchains from a distributed computing perspective" argued, smartcontracts have a surprising amount of concurrency in them in the so-called chain serialized transactions. The paper mentioned: "We have seen that the notion that smart contracts do not need a concurrency model because execution is single-threaded is a dangerous illusion."
In the "rock, papers, scissors" contract, what happens to a third player that attempts to join and sends money to the contract? That money becomes inaccessible to anyone.
Another thing that was surprising to me is that when you are writing a smartcontract you need to take incentives into account as another constraint in the problem. In the "rock, papers, scissors" contract,
For example, one party can wait for the other to open its commitment. Upon seeing that he will lose, that party may elect to abort (after all revealing its committed input costs gas). But, this denies payment to the other player as well. The solution is to use an additional security deposit and add a deadline after which not revealing implies losing.
Step 1: You have a problem
Step 2: You introduce a blockchain to solve problem
Step 3: You now have an incentives problem, a trust distribution problem, a community management problem, a regulation problem, a speculation problem, an upgrade path problem.
Of course there are additional problems due to cryptography, how to keep the committed inputs secret, etc. Finally, Section 4.4. in the paper discusses Ethereum specific bugs. I am not sure how many of these still apply after 3 years, in 2018.
MAD questions
1. Every miner needing to store all contracts' data storage may limit the scalability, right? Is there a way to provide a sharding service for smartcontracts as well? Is it possible to apply the techniques introduced in Aspen for this?2. Every miner needing to execute the smartcontract for validation is also very wasteful. How can that be relaxed? Is it possible to devise a way where the output can be checked quickly without having to execute the entire code?
PS: Relevant to this paper, here is the DAO smartcontract attack modeling I wrote about earlier.
Comments