Lessons The DAO: How perfect code Ethereum? Part 1

One of our goals in the RSK was - to focus on the use of smart technology contracts in the real world. Despite the fact that we are happy to see new approaches to old problems of trust, such as DAO, we think Bitcoin, blokcheyn, smart wallets and crypto assets have sufficient revolutionary potential that only by means of these innovations we can achieve actual financial accessibility.

The main thing that is necessary for success, so it is simple and succinct intelligent building blocks that are easy to analyze, which is easy to talk and are easy to check.

In recent months we have witnessed the creation of The DAO kraudfandingovoy during the campaign, which managed to collect more than $ 200 million. However, I doubt that the creators of the project were ready to protect such huge amounts of money, as The DAO was and remains inconclusive experiment testing. In this article I will show you why the experiment failed The DAO and what causes it helped. Then, we analyze the design of RSK and trace any way we used to minimize the risk factors. Our main task in the RSK was to create and provide multi-level security, where the failure of one level is not wagging the work remaining. Ethereum survive during the fall The DAO, it becomes even harder. However, it still hurt. I hope that this will be put right lessons.

The analogy with a flying plane
When most of us started using Bitcoin (or because of need to buy, or because obtaining Bitcoin fees) cryptocurrency was running an experiment: its entire functionality was already "in flight." Several times Bitcoin compared with the plane, which should be repaired in the air. However, Bitcoin - a plane that flew for more than seven years in and never landed, it says a lot about its reliability.

In a situation where a lot of people have invested in The DAO, it was the opposite - the code is never executed. You trust your life autopilot program, which is never tested on real airplanes? Unfortunately, it did so investors The DAO. They allowed HYIP system to fool yourself and forget about the preliminary analysis of the facts. Kto-to may be noted that the majority of investors in The DAO «share» with the project a small amount of money, so they can be viewed as an investment rate (I know personally qualified people who invested blindly). But there were some whales, invest in The DAO millions. So let's lay our part of the blame for the incident including investors.

Design VM Ethereum
Among the design goals Ethereum Virtual Machines (Eth VM) level of consensus was to simplify the specification. This is a noble goal, as it contributes to the re-introduction of the platform in different programming languages ​​and requirements. However, even if the minimum number of instructions needed to turn Turing-complete smart contracts less than 10 Ethereum did not restrict itself in such a minimum for several reasons:

a) It significantly reduces performance

b) It makes the compiled code is difficult to audit

So, at the Ethereum have about 100 different operating codes. Anyway, it seems to me that in order to minimize the CALL opcode was overloaded with two functions: to invoke a method from another contract and send a broadcast. But the semantics of these two functions and the context in which each of them is used, very different. Lack of education was one of the factors that contributed to the attack on The DAO. It is interesting to note that indirectly VM already provides the means for sending air without having to call a function, creating a temporary contract and using suicide operating code, to which will have to spend much more fuel.

This possibility leads us to the simple conclusion that the VM should offer operational code SEND, which does not cause any additional code, thus simplifying the complexity of the higher levels. Some may argue that by limiting the amount of fuel proposed for the call to 2300, has a side effect - no one will be able to add an additional operation code the CALL, and therefore, it is safe. This argument is false, given that in the future the system will fall under the influence of hard-forks, which are: can reduce the cost of the CALL operation, or allow the contract to pay for its fuel. So, in general, this solution - short-sighted, hides the real problem from the user and blocks future improvements. The RSK, we created a simple SEND operation code, which does not cause any additional code in the final contract.

Some may argue that the majority of contracts are more likely to work with crypto-asset, rather than with ether, so that the asset will be sending a call contract, issuing this asset. In such cases, the description will be different, and the user will be faced with unexpected side effects. Opcode SEND helps, but it's certainly not the only necessary correction.

Solidity
Programming languages ​​with dynamic type of control is well known the fact that they are more difficult to interpret than statically entered Spanish. Also, you need to spend resources on memory and compute smart Ethereum contracts, it makes objects dynamically injected code is much more expensive than static code objects.

Solidity - it is a statically typed language, founded in JavaScript. Selection of static typing at first glance seem right. However, it raises the question of whether to create a new software language from scratch. It is a language that does not affect the problem areas and the code does not provide any special features on the smart contracts. Is the existing languages ​​are not good enough?

Some previous designs smart contracts, such as QixCoin, were based on the emulation CPU core RISC. Some newer designs emulate other processors: Codius executes x86 code in the sandbox, and Bloq Ora performs Moxie. Emulation existing kernel allows the programmer to use the standard common programming languages ​​and compilers tested. Solidity is too young. For example, I have a contract, which makes Solidity crash, and the cause is not known. I also found cases in which that language generates bad code.

As for the code audit people learn the source code Ethereum contracts, rather than bytecode compiler question the quality (and the risk of malicious compiler) assumes great importance.

Going back to the incident with The DAO, let's see what is hidden in the source code of the project. We will not discuss the vulnerability, which has properly studied, but we look at the two lines of code that a hacker could take advantage of:

a) if (_recipient.call.value (_amount) ()) {

b) if (p.splitData [0] .newDAO.createTokenProxy.value (fundsToBeMoved) (msg.sender) == false)

In the first line, untyped contact _poluchatel sent _kolichestvo ether. Not specified no method. In the second line, a certain method, called (createTokenProxy) sends broadcast via fundsToBeMoved. Solidity 0.2.0 documentation warns that adding .value (x) or .gas (y) only (locally) sets the price and the amount of fuel that is sent with the call function, and only the parentheses at the end really makes a call. If postfix .gas () is missing, the entire amount of the unused fuel is offered outside call, so that recursion contract possible (however, this fact is not specified in the documentation). I believe that the description of the call is defective, because it is too unusual. Very few programming languages ​​allow you to change the link to the call such modifiers (one of them - Python), and such a structure is not used often. It becomes unclear which method is called. It seems that the method is called »value ()» instead of »createTokenProxy».

It has been done a lot of research in order to develop practical programming languages ​​that also help the programmer in understanding the code, golang, c # and Java - good examples of the correct balance between the human understanding, linguistic expression and compact documentation. Solidity - definitely not one of them. However, I can not recommend the use of du Serpent, because as it is available even less information, and there is a lack of examples associated with it.

Help with code execution
It seems that the safety performance of clever contract was entrusted entirely to the code of the contracts themselves. Virtual Machine Ethereum makes no specific ways to limit recursion, just like Solidity runtime. Bug with recursion means used in the attack on The DAO, has been known since 2014, so there was plenty of time for developers to prepare. However, it is clear that these instruments - raw, and it will take years of intensive development of high-quality tools. Decentralized development Ethereum possible and it had a lot of benefits, but it also resulted in the bad consequences: it has no clearly defined guidelines, and security updates become postponed indefinitely.

The RSK, we plan to provide reliable execution environment in which the system is installed by default to prevent the recall of the contract itself. Again, it does not solve all the problems completely, but to prevent the majority of human error.

To be continued…