Lessons The DAO: How perfect code Ethereum? Part 2

Lessons The DAO: How perfect code Ethereum?
security Audit
Those who work safety auditors are aware that even the most meticulous checks at times does not prevent problems. Each expert or group of security experts tend to skip them unknown flaws, depending on their level of knowledge and experience. Everything is so in the case when you need to check the code with an entirely new perspective (smart contracts), with a new language (Solidity) and a new class of attacks (such as game-theoretical). The number and depth of security audits must be directly related to the amount of money that the audit checks. For new code array, which must handle hundreds of millions of dollars, several checks made by different firms - quite a regular practice. Security Audit - what in fact was done by the founders Ethereum, they hired LeastAuthority, Dejavu and Coinspect platform for audit. But the creators of The DAO did not, though, among the curators of the project were known Ethereum activists who should recommend such a check.

formalization
Security Audit does not replace the use of formal models for the development of smart-contracts and the use of static / dynamic confirm correct code. Formal methods always give the best guarantees, despite the fact that the model may be too complicated to set up. Also, domain-specific languages ​​(DSL'y) can prevent a wide range of bugs. The problem is that formalization is very expensive, so it is often overlooked. This is another lesson to learn is: secure programming costs money.

We look forward to the formalization of new tools written specifically for the RSK and the Ethereum. Anyway, a lot of tools already available in traditional programming languages ​​such as Java, JML, KeY. That's one of the reasons why the RSK builds parallel Chain-tools (toolchain), which allows smart contracts to be written in Java, and we expect that high-risk contracts will be developed using these tools.

Progressive decentralization
In something as complex as the creation of a decentralized autonomous organization, it is impossible to predict or correct the code or the dynamics and possible flaws in the voting system. Organization of voting - is a complex human process, and as such it will require testing and finding bugs before they will be properly formalized. An adequate approach is to endeavor to contract, which can be quickly and easily updated via (n, m) multipodpisey owned several "notaries", where n - a simple majority, and the progressive increase of n can take place until a full consensus of the notary. Finally, when the contract is fully tested in real conditions, multipodpis automatically removed after a specified period of time. Perhaps The DAO would be much less support in the beginning, but in the long term, this increases the chances of success.

RSK adapt the criteria for consensus of the hybrid system: at the beginning it requires notarization, but the number of "notary" decreases with time, until it disappears altogether due merged-Meiningen. We call this approach the progressive decentralization. It can be applied to smart systems contracts and consensus.

Ignoring the risks
Many times in the past when I've receive reports on safety audits, often came the answers, asserting that there is no such vulnerability, as necessary attack conditions will never become real, or attack is too complex to execute it, or that a solution can have a high degree of influence on the user comfort. In fact, in my experience, this argument is weak. Inactive vulnerability exists due to changes in the software so that a suspicious piece of code that is not activated on the top can be a potential vulnerability after the next update.

The complexity of the attacks is calculated correctly: the attacker correctly calculates profit relative of effort, much more accurately than does the victim, who does not know about the possibilities of the attacker. The impact on user comfort can be completely irrelevant if the software is useful for a short period of time, as long as someone does not commit the attack and will not throw all use it. The problem is a recursive call - a clear example of a case when the vulnerability was well known and documented in advance, but only a few people took it seriously.

poor documentation
Ethereum developers desperately need a special site for documentation of design patterns, common errors, wrong interpretations, and security best practices for programming smart contracts. The RSK we will create the resource area is completely dedicated to the security of smart contracts, and we will invite researchers to participate in the creation of standards. Our medium-term plan includes the creation of a platform for the competition on hacking smart contracts and other hacking activities (something like CTF).
Concluding remarks
Area smart contract is still in the growing stage. It is clear that the error can not be avoided. Not yet developed sufficient tools and a set of rows is not written documents to them, we should come to the programming of contracts in terms of "defense in depth" by creating and adding a variety of security levels, thereby reducing the impact of vulnerabilities.

Human errors provoked unclear semantics of programming languages ​​and a lack of documentation. People in the RSK and the entire community learn by example The DAO, but at the same time, we reiterate that the RSK uses this approach to the use of adult language to develop contracts that will guide us on the right path. We also call on companies and platforms involved in smart contracts to conduct security audits, and investors and users exert maximum efforts in finding vulnerabilities and analysis of the facts before making a responsible decision.