As I'm writing this, I’m sitting in the London office and pondering how to give you a good overview about the work we’ve been doing to secure Ethereum’s protocols, clients and p2p-network. As you might remember, I joined the Ethereum team at the end of last year to manage the security audit. As spring has passed and summer arrived and meanwhile several audits finished, it’s now a good time for me to share some results from the inspection of the world computer’s machine room. ;-)

This much is clear, as much as the delivery of the clients is an elaborate product development process, it is an exciting yet heavily complex research effort. The latter is the reason why even the best planned development schedule is subject to change as we discover more about our problem domain.

The security audit started at the end of last year with the development of a general strategy for ensuring maximum security for Ethereum. As you know, we have a security driven, rather than a schedule driven development process. With this in mind, we put together a multi-tiered audit approach consisting of:

• Analyses of the new protocols and algorithms by established blockchain researchers and specialised software security companies
• End-to-end audit of protocols and implementation by a world-class expert security consultancy (Go followed by C++ and a basic audit for the educational Python client), as well as
• The bug bounty program.

• The gas economics
• The newly devised ASIC-resistant proof of work puzzle as well as
• The economic incentivisation of mining nodes.

The first major security audit (covering the gas economics and PoW puzzle) by security consultancy Least Authority was started in January and continued until the end of winter. We are very glad that we agreed with most of our external auditors that those audit reports will be publicly available once the audit work and fixing of the findings is completed. So along with this blog post, we are delighted to present the Least Authority audit report and accompanying blog post.  In addition, the report contains helpful recommendations for ÐApp developers to ensure secure design and deployment of contracts. We expect to publish further reports as they become available.

We have also engaged another software security firm at the beginning of the year to provide audit coverage on the Go implementation. Given the increased security that comes with multiple clients and as Gav mentioned in his previous post, we have also decided to give the Python and C++ audit a lightweight security audit starting early July. The C++ code will receive a full audit right after – our goal with this approach is to ensure several available audited clients as early as possible during the release process.

We kicked off this most encompassing audit for the Go client, aka the “end to end audit”, in February with a one-week workshop that would be followed by weeks of regular check-in calls and weekly audit reports. The audit was embedded in a comprehensive process for bug tracking and fixing, managed and thoroughly tracked on Github by Gustav with Christoph and Dimitry coding up the corresponding required tests.

As the name implies, the end-to-end audit was scoped to cover “everything” (from networking to the Ethereum VM to syncing layer to PoW) so that at least one auditor would have cross checked the various core layers of Ethereum. One of the consultants recently summarized the situation pretty succinctly: “To be honest, the testing needs of Ethereum are more complex than anything I’ve looked at before”. As Gav reported in his last blog post, because of the significant changes in the networking and syncing strategy we eventually decided to commission further audit work for Go – which we are about to finish this week. The kick-off for the end-to-end C++ and basic Python audits is taking place now.

The audit work with subsequent bug fixing and regression testing as well as related refactoring and redesign (of networking and syncing layer) make up the majority of work that’s keeping the developers busy right now. Likewise, fixing of findings, redesign and regression testing are the reason for the delay in the delivery. In addition, the Olympic testing phase has taught us a great deal about resiliency under various scenarios, such as slow connections, bad peers, odd behaving peers and outdated peers. The greatest challenge so far has been fighting off and recovering from forks. We learnt a lot from the recovery attempts in terms of required processes when it comes to dealing with these type of scenarios and incidents.

It might not come as a surprise that the various audits represent a significant expenditure – and we think money that could not be better invested.

As we draw closer to release, security and reliability is increasingly uppermost in our minds, particularly given the handful of critical issues found in the Olympic test release. We are very grateful for the enthusiasm and thorough work that all auditors have done so far. Their work helped us sharpen the specification in the Yellow Paper and to weed out ambiguity and fix several subtle issues, and they helped with identifying a number of implementation bugs.