Lessons from The DAO

One of the goals of RSK (rootstock) is to focus on the real-world applications of smart contract technology. While we are excited about DAOs as a radical new way to solve the age-old trust problem, we believe that Bitcoin, its blockchain, smart wallets, and crypto assets have the potential to be disruptive and that we can use these technologies to achieve true financial inclusion. Using simple and clear smart modules, it is very easy to analyze, infer, and review them, which is a must for our success.

Last month, we saw the creation of The DAO, which raised $200 million in crowdfunding. I was skeptical about whether The DAO’s creators were prepared to protect such a large amount of funds. After all, The DAO was an untested experiment. In this post, I will summarize the main reasons for the DAO incident, and then analyze the design of RSK to explain how we can minimize such risks. Our goal with RSK is to provide a layered security guarantee: so that a breach of one layer of protection does not lead to the collapse of the entire system. Ethereum has its own security model, so it survived the DAO incident and even became stronger after this incident. I hope that it can learn this hard lesson, after all, it was also deeply affected by it.

Using the analogy of airplane flight

When most of us started using Bitcoin (buying it or receiving it as payment), it was still an experiment: all its features were working. Bitcoin has been compared many times to an airplane that has to be repaired in mid-air. However, Bitcoin is a plane that has been flying for 7 years without landing once, which is why people never tire of calling it reliable. In contrast, when many people invested in the DAO, its code had not yet been run. Would you trust your life to an automatic airplane pilot software that has never been tested? Unfortunately, that is what the investors in the DAO did. They forgot to do their due diligence, and so were punished by their impulsive enthusiasm. Some would say that most of the investors in the DAO invested only a small amount of money, and basically they took a small gamble for fun (I know high-end people often invest blindly), but there were some institutional investors who invested millions in the DAO. So the investors in the DAO should share some of the responsibility for this accident.

Design of Ethereum Virtual Machine

One of the design goals of Ethereum was to simplify the specification of the consensus layer. This was a great goal, as it increased the reusability of the platform across different languages ​​and constraints. Although the minimal Turing-complete instruction set could be limited to 10 instructions, Ethereum did not impose such a limit on itself because (a) it was inefficient and (b) it made the compiled code difficult to audit. As a result, Ethereum has 100 different opcodes. However, to achieve simplicity, the call opcode was encumbered with two functions: one to call another contract, and one to send ether. However, the semantics of these two functions are very different, and the contexts in which they are used are very different. This was a factor in the DAO attack. Interestingly, by creating a temporary contract and using the self-destruct opcode, the Ethereum VM can indirectly implement the send ether function without calling any functions, although it consumes a little more gas. From this we can draw a conclusion: the VM should provide a send opcode without calling any code, reducing the complexity of the upper layer. One could argue that by limiting the gas supply of a call to 2300, no other calls can be executed, so it is safe. This approach breaks down if we consider that the VM could implement a hard fork in the future: this would reduce the cost of calling operations, or smart contracts would be allowed to pay themselves. So, basically, this approach is short-sighted, hides the real problem, and it hinders future improvements. In RSA, we use a simple send opcode that does not call any code in the destination contract.

Some people will object: most smart contracts will deal with crypto assets, not just ether, so sending an asset will actually call the asset issuance contract. These cases will have different symbols added, and the restriction method can be used. The send opcode does more than just fix the requirement problem.

Solidity

It is well known that dynamic languages ​​are more difficult to verify (or even infer) than static languages. Ethereum smart contracts will make dynamic language code consume more computer resources than static languages. Solidity is a static language based on javascript. The choice of static language gives a good first impression, but the question is, why re-create a language from scratch? A language that is not domain-specific and has no features designed for smart contracts. Aren't there existing languages ​​that are good enough? Previous smart contract projects, such as QixCoin, simulators based on RISC processors, or sandboxes running x86 instructions, allow programmers to use mainstream standard programming languages ​​and compilers. Solidity is immature: for example, I have a contract that makes Solidity generate errors for unknown reasons. I have also encountered examples of Solidity generating bad code. When people start reading Ethereum contract source code instead of contract bytecode in order to audit them, the issue of compiler quality (the risk of tampered compilers) is very important.

Back to the DAO incident, let's take a look at the source code of the DAO. We are not going to discuss this vulnerability again, it has been analyzed enough, we just look at these two lines of code that may be exploited by hackers:

a) if (_recipient.call.value(_amount)()) {
b) if (p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender) == false)

The first line of the undefined contract _recipient is sending _amount of ether, and there is no method defined. In the second line, a specified method called (createTokenProxy) is sending fundsToBeMoved ether. The Solity documentation 0.2.0 has this warning: Add and set the .value(x) or .gas(y) parameters, call the function to send gas, and only the content in the last brackets is executed. If the .gas() suffix is ​​omitted, then all the unused gas is cheap to external calls, so the contract recursion vulnerability exists (however, this is not clearly stated in its documentation). I think the call symbol is also flawed because it is very unusual. First of all, other languages ​​do not allow such a modifier to modify a method reference, which makes the call of this method unclear. It seems that the method call replaces "value()" with "createTokenProxy".

There has been a lot of research on creating a language that is powerful and easy for programmers to understand. Golang, C# and Java are good examples. They find a reasonable balance between human understanding, language expression and symbolic compactness. Solidity does not seem to be such a language. I also do not recommend using Serpent because there is too little information and examples about it.

Help for the operating environment

It seems that the security of smart contracts depends entirely on the contract code itself. The virtual machine has no special service to limit recursion, and the Solidity runtime environment has no signal to prevent it. This type of recursion vulnerability in the DAO was known as early as 2014, so there was plenty of time to prepare before this incident. However, it is clear that these tools are not mature, and high-quality tools will take several years to develop. Ethereum's decentralized development may have many benefits, but it also brings some disadvantages: lack of clear instructions, security-related upgrades are delayed indefinitely, etc.

In RSK, we plan to provide a solidified operating environment to prevent default reentry of contracts. Although this cannot completely solve the problem, it can avoid most human errors.
Security Audit

Anyone who has done security audits should know that no single security audit can cover all potential vulnerabilities. Every researcher or organization will miss some issues, depending on their previous experience. This is especially true if they are dealing with code that uses new technologies (smart contracts), new languages ​​(Solidity), and new attack classes (such as game-theoretic). The number and depth of security audits is related to the amount of money and the code being audited. A new piece of code can cost millions of dollars, multiple security reviews, and may require the cooperation of multiple teams to complete. In fact, this is what Ethereum did, and they hired LeastAuthority, Dejavu, and Coinspect to audit it. However, the creators of the DAO did not do this, and the regulators of the DAO, including the founder of Ethereum, should have advised the DAO to do so.

Normalization

Designing smart contracts with a standardized model and using static/dynamic verifiers to verify the correctness of the code is irreplaceable by security audits. A standardized approach has always been a strong guarantee, although this model is difficult to implement. Domain-Specific Languages ​​(DSLs) avoid a wider range of bugs. The problem is that standardization means cost, so it is often ignored. So, this is another lesson: security issues are about cost. We look forward to the emergence of new standardized tools dedicated to RSK and Ethereum. In any case, many tools designed for traditional programming languages ​​​​such as Java (JML, KeY) already exist, which is why RSA has created a similar tool chain so that smart contracts can be completed in Java. We look forward to using this tool chain to develop high-risk contracts.

Progressive decentralization

The difficulty in creating an organization like the DAO is not only getting the code right, but also the dynamics of the voting system can create potential flaws that are hard to predict. Organizing a vote is a complex human process that requires trial and error before it can be formalized. A reasonable approach is to start with a contract that is controlled by a group of notaries with a (n,m) multisig, which can be upgraded and improved in a simple and straightforward way, where n simply represents the majority and n is gradually increased until notary consensus is achieved, which is necessary. Finally, after the contract has been tested in a real environment, the multisig feature is automatically removed after a period of time. The DAO may have done little of this early on, but doing so greatly increases the chances of success.

RSK puts this principle into its hybrid consensus system: it requires notary confirmation at the beginning, but with the emergence of fusion mining contracts, the number of notary confirmations will be reduced. We call this approach progressive decentralization, and it can be used for smart contracts and consensus systems.

Ignoring risks

In the past, I have received many responses when dealing with security audit reports: there is no such vulnerability because the attack conditions will never be triggered, or the attack is too difficult to implement, or that fixing such problems will affect practicality. Everything in reality shows that these statements are untenable. Because changes in software can activate latent vulnerabilities, when the software is later upgraded, the previously dormant code will be run and suddenly become a vulnerability. The assessment of the complexity of the attack is even more incorrect: the hacker will correctly assess the benefits and workload, which is far higher than the victims, who have no idea of ​​the hacker's capabilities. The practicality argument is even more untenable. Even if the practicality of the software is very strong, once it is hacked once, who will use it a second time? The recursive call problem is a good example. This vulnerability is known and documented, but few people take it seriously.

Lack of documentation

Ethereum developers are in urgent need of a dedicated website to document design patterns, common mistakes, misconceptions, and best security practices related to writing smart contracts. In RSK, we will set up a resource space dedicated to smart contract security, and we will invite researchers to participate in setting standards. We have a mid-term plan to create a platform for smart contract hacking challenges and hold hacker competitions (similar to hacker capture the flag competition CTF).

RSK Security Guarantee Partner Program

RSK is working with security companies to vouch for the security of smart contracts. This allows startups to test their code against smart contract security vulnerabilities as a first layer of security prior to a full code audit. We invite all computer security companies interested in this initiative to participate.
Summarize

The smart contract space is in its infancy and mistakes are inevitable. Until more tools and documentation are available, we should adopt a "defense in depth paradigm" for smart contract programming, adding as many layers of security as possible to reduce the impact of vulnerabilities. Human errors are amplified by ambiguous programming semantics and lack of documentation. We at RSK and its ecosystem have fully learned the lessons of the DAO incident, and we are ensuring that RSK uses a mature tool set to keep contract development on track. We encourage smart contract companies and platforms to perform security audits, and encourage investors and users to be careful and rigorous in their evaluations.