Download v126.96.36.199 clients from https://github.com/BreakoutCoin/Breakout-Chain-Client/releases/tag/v188.8.131.52. Version v184.108.40.206...
Properties of Breakout Chain Permissive Smart Contracts Stifle DAO-like Attacks
In this article, I discuss how Breakout Chain’s proposed permissive smart contracts are by nature much more secure than Ethereum’s smart contracts.James Stroud
On Friday June 17, 2016, $60,000,000 worth of a digital currency called ethereum (ETH) was drained into the accounts of an individual who exploited a logical error in a computer program. At the time, the total value, or market cap, of ETH was over $1.6 B. Two hours later the ETH market cap had plummeted nearly 30% to under $1.2 B and continued to fall to $0.8 B over the next 36 hours.
The program exploited by the attacker runs on Ethereum, a decentralized computing platform powered by a currency called ether (ETH) in the sense that the execution of each instruction on the Ethereum platform must paid for with ether. Ethereum programs are a class of Turing complete programs called “smart contracts” that enforce fiducial relationships between parties to the contract. Turing completeness describes programs that can execute any logic available to computers. Ethereum contracts have the tremendous, and probably unnecessary, power to submit transactions, meaning that the contract itself can transfer money.
The faulty program is part of a group of programs that operate a decentralized autonomous organization, or DAO. Many decentralized autonomous organizations run on the Ethereum platform, but the DAO with the faulty computer program is confusingly called “The DAO”.
The DAO (or any DAO for that matter) is a fully automated business that conducts all its operations on a decentralized computer, meaning no single person, or even group of coordinated individuals, controls the DAO. Instead, The DAO works like a corporation with shareholders who vote on company directives. This type of structure is possible because user accounts are represented in The DAO’s computer programs, and these accounts have balances that correspond to ownership. In addition to user shares, The DAO has its own ETH account, meaning that The DAO has a bankroll.
The DAO’s balance originated from fundraising, where investors sent money to The DAO’s ETH account. In return, investors received shares of ownership. Because The DAO is an experimental entity, investors have the option to withdraw their investment through a process called a “split”, illustrated in Figure 1. The DAO attacker took funds contributed by shareholders, reducing the The DAO’s ETH balance from about $220 M of ETH to about $160 M.
Figure 1. A split of The DAO allows investors to withdraw their investment. In the initial state of this example split (A) the investor has 1000 shares (worth 10 ETH) and 0 ETH. The process of a split begins with (B) withdrawing the funds, where 100 shares equals 1 ETH. The share balance is not yet adjusted. The split program (C) then checks the ETH balance against the amount that corresponds to the shares. If the ETH balance is too large after withdrawal, the split is invalidated. Otherwise, (D) the investor’s share balance is zeroed out. The net effect of this process is that the investor’s share balance is converted to to appropriate ETH balance.
The ability for a computer program to be a DAO is tied to its ability to send a digital currency like ETH. Without this capacity, the program would have little influence on the state of the world outside of the computer on which it runs. With the ability to send money, a DAO can appropriate goods and services to achieve its directives, thereby serving the interests of its shareholders.
Perhaps the defining property of a DAO is that it acts in perfect adherence to a charter consisting entirely of computer programs. This property is usually offered as a feature of DAOs because it renders them immune to the fallibility of human judgment. One pitfall, made obvious by the attack on The DAO, is that flaws in the computer programs that constitute a DAO are vulnerable to potentially devastating exploits.
The type of flaw exploited by the DAO attacker is called “reentrancy”, which means that the attacker was able to repeatedly reenter a part of the computer code that sends the attacker money. The technical details behind this attack are extensive, but the premise is that the attacker was able to fool a check for maximum withdrawal, then execute the withdrawal 30 times in one cycle of the attack. On top of this, the attacker amplified gains by preventing the share balance from being zeroed at the end of each cycle, then repeating the multiple withdrawal for unlimited cycles. The attack is illustrated in Figure 2.
Figure 2. The DAO attacker fooled a balance check for ETH, a balance rectification for shares, and forced a repeated withdrawal of ETH to the attacker’s account. The attack begins (A) as a normal split (Figure 1), with a withdrawal (B) of ETH corresponding to the value of the shares. The attacker used a logical loophole to repeat the withdrawal, each time (C) fooling a balance check that invalidates the transaction if the withdrawn ETH exceeds the value appropriate to the share balance. At the end of a normal split, the share balance is zeroed. The attacker fooled the splitting program into seeing no share balance by (D) transferring the shares to a proxy before the share balanced is zeroed (E). Before another iteration of the entire split, the attacker (F) moves back the shares, allowing the process to be repeated indefinitely. Outlined crosses are points at which Breakout Chain permissive smart contracts would stifle an attack, as described in the text.
This attack exploits three properties of Ethereum’s scripting engine. The first property of Ethereum’s scripting engine that the attacker exploited is that of a shared state between different smart contracts. This part of the exploit happened when the attacker temporarily sent shares to a proxy account then sent them back after zeroing the share balance, depicted in steps D and E of Figure 2. Shared state vulnerabilities arise because the state of a contract can be changed by code that is not part of the contract. In the attack, the part of the state representing the attacker’s share balance was changed by a sending transaction. Key is that the contract itself had no control over these funds and was never privy to the state change represented by temporarily hiding shares.
The second property exploited is that of unbound recursion, which means that the attacker was able to execute the same instructions repeatedly and essentially indefinitely. Although recursion is essential for Turing completeness, it must be controlled. Ethereum controls recursion by using the ETH as a sort of gas that is expended during a program’s execution. If the gas runs out before the program finishes successfully, execution is stopped and the program’s results are nullified, although the gas is not returned to the individual who ran the program. Ethereum’s approach to recursion puts bounds on a program’s execution. However, it puts no other limits on the number of times a particular stretch of code can execute in a given run.
The third property exploited is the potential to share code between two smart contracts. Two contracts share code when the one contract executes the code of another contract. The DAO attacker exploited this property after step F in Figure 2. Each split is itself a smart contract that has code different from The DOA. In short, the attacker caused The DAO to execute a part of the split’s code, beginning yet another split. For each split, the balance check was fooled, shares hidden, and a withdrawal claimed.
Breakout Chain’s planned permissive smart contract system (described in the white paper at http://wp.breakoutcoin.com/) has safeguards against each of these three vulnerabilities, indicated in Figure 2 as outlined crosses. Breakout Chain’s permissive smart contracts are Turing complete and work like Ethereum’s smart contracts but have some key differences. Most notably, Breakout Chain smart contracts cannot autonomously submit transactions. Instead, they permit or prevent transactions by parties to the contract. Each Breakout Chain smart contract is executed when a user submits a transaction. The first transaction submitted to a contract begins execution at the first instruction and stops at a specific place defined by the program. Unless execution reaches the end of the program, each transaction resumes execution where the previous transaction stopped, requiring that all transactions that execute a given contract have a specific ordering. These transactions are said to make a “transaction chain”. The segment of the program executed by each transaction is perfectly defined by the smart contract.
The first key safeguard in Breakout Chain permissive smart contracts is that they do not share state. The state of each permissive smart contract is fully contained within the smart contract itself, either in data structures called stacks or in the contract balance. To a limited extent, a permissive smart contract may examine the historical state of a different smart contract, but a smart contract may not change the state of a different smart contract. The only possible way to change the balance of a permissive smart contract is through a transaction that requires cryptographic proof of spending authority and results in marking the money spent. This crucial latter step was bypassed in The DAO attack where the same money was essentially spent multiple times and never marked spent. The requirement of cryptographic proof of spending authority, combined with marking money spent, is indispensable for valid permissive smart contract transactions. This requirement would stifle an attack at the cross labeled “1” in Figure 2. The fact that a permissive smart contract can not modify the state of another would stifle an attack at the crosses marked “2” and “3” in Figure 2.
The second second safeguard is that each cycle of permissive smart contracts can only be initiated by a new transaction, greatly reducing the speed of exploits that rely on recursion. The places in code execution where this type of throttling is applied are called transaction control points. Throttling is in general not a burden for permissive smart contracts because transactions make natural places to pause execution, as demonstrated in an example of crop insurance in the white paper. In crop insurance, smart contract execution is paused after purchase of the policy and after the buyer makes a claim, if any. Although not a burden in most cases, transaction control points add to the security of permissive smart contracts because they make exploits expensive in terms of time and money, especially if the contract checks for confirmation of previous transactions.
The third safeguard in Breakout Chain permissive smart contracts is that they can not execute the code of other contracts. The reason is that such execution would require submitting a transaction (which permissive smart contracts cannot do). Execution is limited only to the transactions within the transaction chain of a contract. This means that not only can one permissive smart contract not access the state of another contract directly, it cannot even do so indirectly through code execution. This limitation in itself would have completely prevented the attack on the DAO, indicated by the cross labeled “4” in Figure 2.
Breakout Chain permissive smart contracts are meant to mirror traditional contracts in that they define and enforce relationships between parties. They do not have the power to submit transactions nor do they share state. As we have seen from The DAO, the abilities to execute transactions and share state are unnecessary and highly prone to exploits. These properties dramatically increase the security of the smart contract platform without sacrificing its usefulness.