It’s been some time, I recognize, but these are indeed hectic days.
I pen this missive from a Starbucks in Shanghai, sitting behind the Great Firewall, occasionally able to glance out. Over the last few weeks, I’ve traveled in Asia with Marek, primarily attending meetups, workshops, and technical discussions. Throughout this period, we’ve witnessed the launch, obstacles, and persistence of the Olympic testnet, which serves as a clear indication that a multi-client architecture would greatly surpass the current monoculture. We’ve initiated the second external Go audit, mainly to identify regressions but also to provide insights and feedback on modifications that have occurred, such as Go’s networking framework and synchronization strategies. We’ve observed both Mix and Solidity advancing and evolving. Moreover, through continuous development and improvements of the APIs, all clients are becoming cleaner, swifter, and more robust.
Exchanges
We continue to collaborate with exchanges, with Marek and Konstantin both offering significant technical assistance, helping the developers from the exchanges grasp the considerable differences between standard cryptocurrency APIs and Ethereum’s smart-contract-based methodology. To enhance our support for them and maximize uptake, we’ve crafted and launched a middleware JSON RPC proxy that allows a more familiar interface to Ethereum for exchanges.
C++
On the C++ front, we’ve rolled out PV61, a new Ethereum network protocol version (backwards compatible to avoid disrupting the Frontier release timeline for Go) enabling ultra-fast parallel hash-chain downloads and significantly greater resilience against dirty hash-chain attacks. Arkadiy is assisting in coding this for C++ with hopes of integrating it into Go ahead of Homestead.
In the meantime, Solidity has made considerable advancements: it can now predict gas consumption structurally, optimize for storage access and code size effectively, and support internal-function calls with dynamic types, alongside a plethora of additional features. Liana continues to refine that codebase alongside Christian.
Mix, under the direction of Aeron and Jutta, with Avsa providing design insights and Yann contributing to coding efforts, is undergoing significant UX enhancements and restructuring, aiming to become an extremely user-friendly yet powerful IDE for contract development. ÐApps can now be deployed to the network through a straightforward three-stage process, and the state/blockchain management layer is experiencing substantial improvements, featuring a single-pane view where all transactions, calls, and logs can be easily monitored, making it simpler to propagate transactions amidst chain-refreshes.
Alex persists in refining the low-level networking layer, now receiving assistance from Vlad. Three weeks ago, we convened a summit in Zug where I outlined plans for our libp2p networking layer, as well as clarifying how the Whisper and Ethereum protocols fit within that structure. Our initial full-time developer focused on Whisper, Vlad, will continue to enhance libp2p and Whisper, fortifying the protocol against various Ethereum networking threats while progressing the R&D for the p2p asynchronous non-endpoint-specific signaling protocol.
Pawel, working from Warsaw, has been advancing on the JIT EVM and EVM libraries, optimizing stack utilization and assisting in resolving the stack depth challenges we encountered on Mac OS X. Meanwhile, Vladimir continues his testing endeavors and Marian is focused on the netstats page, which has recently proven its value in multiple ways. Those experimenting with mining setups on the Olympic testnet will likely recognize Lefteris’s contributions in taking over the Ethash implementation, updating, refining, and generally supporting Tim Hughes’ OpenCL execution. Special thanks to every community member who has lent a hand, directly or indirectly, with the development of this code. You know who you are (-: Christoph, in the meantime, is now addressing test coverage for the core classes while also assisting in resolving various core issues.
Aside from collaboration with the Mix teams, Arkadiy and Marek, I have been coding the new C++ wallet/secret store protocol (a revamped format compatible with Go and Python), optimizing the core (recently measuring import times for at least one gas-heavy block to be approximately 10x faster than Python and 3x quicker than Go), fixing bugs throughout the core, implementing the new ‘ethvm’ binary for standalone EVM operation, and the ‘ethkey’ binary for wallet management. Most recently, I am developing a greatly improved interactive console interface, akin to Go’s Javascript console. I aspire to establish a far better blockchain download diagnostic display shortly within AlethZero.
Auditing
An internal audit of the C++ code base has commenced, with Christoph working on tests for all core classes and Arkadiy assisting with certain core optimizations. The SecretStore and Wallet classes have already undergone auditing by Christian, thus affirming that the C++ client is reasonably secure for handling private keys. The external audit for C++ will initiate in just three weeks.
Following the significant failure of the testnet caused by issues in merely one of the three clients, including problems that persisted through two auditing processes, we’ve realized that auditing, whether external or internal, isn’t a cure-all. While we remain committed to delivering top-notch software and will continue with our auditing initiative, let us be clear: there’s nothing enchanted about the Go client merely for having gone through an auditing process. Our goal is to have all clients undergo at least a basic auditing process by the Homestead release, and I see no reason to prefer the Go client over other alternatives (C++ or Python) at this stage, nor, for the vast majority of users, during Frontier. No clients provide any guarantees. In fact, there’s an argument suggesting that minority clients, being a smaller target, are less susceptible to attacks.
Onwards
We persist in our preparations for the Frontier release. Although we remain uncertain about the precise release date, we are increasingly satisfied with the resilience of the Olympic testnet. As the Olympic testnet’s failures unfolded, it prompted reflection on how we might circumvent such issues in the future. The depth and span of the consensus disruption can, broadly speaking, be attributed to two factors: first, a bug in the Go codebase that allowed it to accept invalid blocks (in this instance, blocks with an invalid proof-of-work nonce); secondly, significant challenges in upgrading the network since miners continued to mine on the ‘bad’ chain and were slow to upgrade their nodes to mine on the correct chain. Essentially, the first was a forensic issue while the second was a problem of organization.
To ensure that this never becomes so profound or widespread in the future, I have devised two new protocols: the Bad Chain Canary and the Bad Block Reporting API. The flawed chain canary is an uncomplicated contract. It is governed by a single key (although there might be several) and remains dormant until activated by its proprietor. I will be one of those proprietors, along with Vitalik and Jeff as two others, while there is likely a fourth, Christoph. When activated, it is provided with a blockhash and block number pair; this pair pertains to a recent block on a defective chain. If they correspond to the chain that the contract believes it is situated on, it transitions into the “bad chain” state. This enables the Ethereum core developers to notify everyone operating a client on a defective chain (i.e. one that does not adhere to the Yellow Paper due to an error) that it is indeed such. The default setting in clients (which can easily be altered) is to refrain from mining on such chains (as doing so would be a misallocation of energy), but instead to notify the user to upgrade at their earliest convenience.
The Bad Block Reporting API is a straightforward JSON RPC that permits several of our nodes to operate in a ‘sentinel’ mode. In this configuration, if they encounter a flawed block, they automatically generate a standardized report detailing what transpired, including anticipated transaction receipts, VM traces, proof-of-work, and block error data. This report is immediately dispatched to a ÐΞV server where it can activate an early warning system and, should the release coordinator (that would be Taylor) find it necessary, alert the core developers. Through standardization and the application of a simple format, it is structured so that we can effortlessly develop a JSON-comparison engine to swiftly identify where the consensus problem lies.
One prospective task is to merge the two so that the JSON-RPC can also handle the reporting of canary data – in this scenario, a user may configure a sentinel server to notify them via email whenever the contract indicates that mining has halted and/or they should upgrade their node to continue mining.
Foundation
Ultimately, the three directors of the Ethereum Foundation (Vitalik with three votes, followed by Taylor and Mihai with one vote each) will soon gather for, in Vitalik’s own words, a “kind of grand transfer of the baton event.” Kelley, ÐΞV’s tenacious COO, has been leading the effort to search for qualified candidates from various domains who can contribute real value to the foundation both in terms of fundraising and promoting adoption. We are extremely appreciative of all her diligent efforts in this matter.
