As I compose this, I’m situated in the London office contemplating how to provide you with a comprehensive overview of the efforts we’ve undertaken to safeguard Ethereum’s protocols, clients, and p2p-network. As you may recall, I became part of the Ethereum team at the close of last year to oversee the security evaluation. As spring transitioned into summer and multiple audits were completed, it’s a suitable moment for me to convey some findings from the assessment of the world computer’s machine area. 😉
It is evident that, although the delivery of clients involves a sophisticated product development procedure, it represents an exhilarating yet profoundly intricate research initiative. This complexity is why even the most meticulously planned development timelines are prone to adjustments as we uncover more about our problem area.
The security evaluation commenced at the end of last year with the formulation of a broad strategy aimed at guaranteeing optimal security for Ethereum. As you are aware, our development process is driven by security rather than by schedules. With this perspective, we devised a multi-layered audit strategy consisting of:
- Assessments of new protocols and algorithms conducted by established blockchain researchers and specialized software security firms
- Comprehensive review of protocols and implementation by a top-tier security consultancy (Go followed by C++ and a basic audit for the educational Python client), in addition to
- The bug bounty initiative.
The assessments of the new protocols and algorithms addressed issues such as the security of:
- The gas economics
- The newly developed ASIC-resistant proof of work puzzle as well as
- The economic incentives for mining nodes.
The “crowd-sourced” audit segment began around Christmas coinciding with our bug bounty initiative. We allocated an 11-digit satoshi amount to reward individuals who identified bugs within our code. We’ve received high-quality submissions to our bug bounty program, and participants received appropriate rewards. The bug bounty initiative remains ongoing, and further submissions are needed to exhaust the designated budget…
The initial significant security audit (covering the gas economics and PoW puzzle) by the security consultancy Least Authority commenced in January and extended until the winter’s conclusion. We are pleased to confirm that we reached an agreement with most of our external auditors to make those audit reports publicly accessible once the auditing work and resolution of the findings are concluded. Thus, alongside this blog post, we are excited to present the Least Authority audit report and the related blog post. Furthermore, the report includes valuable recommendations for ÐApp developers to guarantee secure design and deployment of contracts. We anticipate the publication of additional reports as they become available.
We have also engaged another software security firm at the start of the year to deliver audit coverage on the Go implementation. With the enhanced security that comes with multiple clients and as Gav noted in his earlier post, we have opted to initiate a lightweight security audit for the Python and C++ implementations beginning in early July. The C++ code will undergo a full audit subsequently – our aim with this strategy is to ensure multiple audited clients are available as early as possible during the release timeline.
We commenced this most thorough audit for the Go client, also known as the “end-to-end audit”, in February with a one-week workshop that would be succeeded by regular check-in calls and weekly audit reports. The audit was integrated within a detailed process for bug tracking and resolution, managed and meticulously tracked on Github by Gustav with Christoph and Dimitry developing the corresponding necessary tests.
As the name suggests, the end-to-end audit was designed to encompass “everything” (from networking to the Ethereum VM to syncing layer to PoW) ensuring that at least one auditor verified the various core layers of Ethereum. One consultant recently articulated the scenario quite succinctly: “To be honest, the testing needs of Ethereum are more complex than anything I’ve encountered before.” As Gav reported in his most recent blog post, due to the substantial alterations in the networking and syncing strategies, we ultimately resolved to commission further audit work for Go – which we are on the verge of completing this week. The kickoff for the end-to-end C++ and basic Python audits is taking place now.
The audit tasks along with subsequent bug fixing and regression testing, as well as related refactoring and redesign (of networking and syncing layers), constitute the majority of work currently occupying the developers. Similarly, the resolution of findings, redesign, and regression testing are the reasons for delays in delivery. Additionally, the Olympic testing phase has provided us with significant insights regarding resiliency under various circumstances, such as slow connections, problematic peers, erratic behaving peers, and outdated peers. The most significant challenge thus far has been addressing and recovering from forks. We have gained much knowledge from the recovery attempts concerning the necessary processes for managing these types of scenarios and incidents.
It may not be surprising that the various audits represent a considerable investment – which we believe is money well spent.
As we approach the release, security and dependability are increasingly prominent in our considerations, especially given the handful of critical issues identified in the Olympic test release. We are exceedingly appreciative of the enthusiasm and meticulous work all auditors have dedicated thus far. Their contributions have aided us in refining the specifications within the Yellow Paper, removing ambiguities, addressing several subtle concerns, and identifying a number of implementation bugs.
