.jpg)
I know it’s been a while, but these are kind of busy days.
I’m writing this from a Starbucks in Shanghai sitting behind the great firewall, only able to peep out occasionally. I’ve been in Asia with Marek for the past two weeks, mainly for meetings, workshops and technical meetings. During this time, we have seen the Olympic Testnet launch, struggle, and survive, which is a very clear indication that a multi-client system will be much better than the current monoculture. We have seen the start of a second external Go audit, mainly to check regressions but also to provide feedback and criticism on aspects that have changed in the meantime such as Go’s network layer and synchronization strategy. We’ve seen Mix and Solidity continue to progress and mature. Through the continued development and advancement of our APIs, we have seen all customers become cleaner, faster and more flexible.
Exchanges
We have continued to work with exchanges, and both Marek and Konstantin now provide significant technical support, helping programmers from exchanges understand the wide differences between using standard cryptocurrency APIs and Ethereum’s smart contract-based approach. In order to better support them and maximize adoption, we designed and introduced a JSON RPC proxy allowing a much more familiar interface to Ethereum for exchanges.
C++
On the C++ side, we introduced PV61, a new version of the Ethereum network protocol (backward compatible so as not to disrupt Frontier’s release schedule for Go) that provides ultra-fast parallel hash-chain downloading and much greater resilience to dirty hash-chain attacks. Arkadiy is helping to program this for C++ in the hope that it can be worked on in Go before Homestead.
At the same time, Solidity has advanced greatly: Solidity can now predict structurally with gas, optimize storage access and code size very well, and support internal function calls with dynamic types, along with a whole host of other features. Liana continues hacking into this database with Christian.
Mix, under the guidance of Aeron and Jutta with Avsa providing visual design insights and Yann hacking, is seeing significant refinement and refactoring of the user experience, with the overall goal of making it a highly usable yet powerful IDE for contract development. ÐApplications can now be deployed to the network in a simple 3-stage process, and the state management/blockchain layer has been greatly improved, featuring a single-pane view where you can easily see all transactions, calls, logs, and publishing transactions between the chain is easily updated.
Alex continues to work on the low-level network layer, and is now assisted by Vlad. We had a summit at Zug 3 weeks ago where I laid out the plans for our libp2p network layer, and how Whisper and Ethereum protocols fit into that. Vlad, our first full-time developer on Whisper, will continue hacking libp2p and Whisper, making the protocol more resilient to various Ethereum network attacks while continuing the research and development of the non-endpoint asynchronous signaling protocol.
Paul, based in Warsaw, has continued to work on the JIT EVM and EVM libraries, improving stack usage and helping to fix the stack depth issues we were seeing on Mac OS Netstat page Which has recently proven its usefulness in more than one way. Those who have tried mining setups on the Olympic Testnet will likely recognize Lefteris’ work in taking over the Ethash implementation, modernizing, refactoring, and generally supporting Tim Hughes’ OpenCL implementation. Special thanks to every community member who helped in one way or another in developing this code. You know who you are (-: Kristoff, meanwhile, is now working on testing coverage for the core classes, as well as helping to fix various problems at the center.
Apart from working with the Mix, Arkadiy and Marek teams, I coded the new C++ wallet/secret store code (renewed formatting and compatibility with Go and Python), and improved the kernel (import times for at least one gas). The heavy cluster was recently measured to be ~10x faster than Python and 3x faster than Go), fixes cross-kernel bugs, and implements a new “ethvm” binary to run EVM in standalone mode and an “ethkey” binary for wallet management. More recently, the development of a much better interactive console interface, similar to Go’s Javascript console. I also hope to get a better diagnostic view of the blockchain download soon at AlethZero.
Audit
The internal review of the C++ database has begun, with Christoph working on tests for all core classes and helping Arkadiy with some basic optimizations. The SecretStore and Wallet classes have already been audited by Christian, giving credibility that the C++ client is reasonably secure for managing private keys. The C++ external audit will begin in three short weeks.
Since the major testnet failure was caused by issues in only one of the three customers, including issues that survived two audits, it became clear to us that an audit, whether external or internal, is not a silver bullet. While we are committed to providing the best software and will continue our audit program, please be clear: there is nothing magical about a Go client undergoing an audit. We aim to have all clients pass at least a basic vetting process through the Homestead release and I see no reason to use the Go client instead of other clients (C++ or Python) at this point, nor for the vast majority of users, during the limitations. No clients come with any guarantees. In fact there is an argument that minority customers, being a smaller target, are less vulnerable to attack.
Onwards
We continue our preparations for the release of Frontier. Although we’re still unsure of the exact release date, we’re becoming increasingly happy with the flexibility of the Olympic Test Network. As the Olympic Testnet continues to fail, this ordeal has caused some reflection on how we might be able to mitigate such problems in the future. The depth and duration of the consensus failure can be traced, roughly, to two problems: first, there was a bug in the Go database that led to invalid blocks being accepted (in this case, blocks with invalid proof-of-work nonces); Secondly, there was a huge problem with upgrading the network since miners kept mining on the “bad” chain and were slow to upgrade their nodes so that they could mine on the right chain. Essentially, the first was a criminal problem and the second a regulatory problem.
To ensure that this will not be as deep or as wide in the future, I designed two new protocols: A canary with a bad streak And the Bad block reporting API. The canary on a bad chain is a simple necklace. It is controlled by a single switch (although there may be several) and remains quiet until its owner presses it. I will be one of those owners, Vitalik and Jeff, two others and there will probably be a fourth, Christophe. When poked, it is given a pair of block numbers and block numbers; This pair indicates a recent block on a bad chain. If it matches the chain the contract thinks it is sitting on, it puts itself into a “bad chain” state. This allows Ethereum core developers to notify anyone running a client on a bad chain (i.e. a chain that does not comply with the yellow sheet due to a bug) that it is so. The default flaw in clients (which can be easily bypassed) is not to mine such chains (since doing so would be a waste of energy), but rather to inform the user that they should upgrade at the earliest opportunity.
The Bad Block Reporting API is a simple JSON RPC that allows a number of our nodes to operate in “sentinel” mode. In this mode, if they encounter a bad block, they automatically compile a consolidated report of what went wrong including expected transaction receipts, VM traces, proof of work, and block error information. This report is then immediately sent to the ÐΞV server where it can trigger an early warning system and, if the release officer (which would be Taylor) deems it necessary, alert the core developers. Through standardization and using a simple format, it is designed so that we can easily code a JSON comparison engine to quickly diagnose where a consensus problem exists.
One future functionality would be to combine the two so that JSON-RPC can also manage the reporting of canary information – in this case, the user could set up a sentinel server to give them an email when a node indicates that mining has stopped and/or they should upgrade their node to continue mining .
institution
Finally, the three directors of the Ethereum Foundation (Vitalik with three votes, then Taylor and Mihai with one each) will meet soon for, in Vitalik’s words, “a kind of great baton passing event.” Kelly, ÐΞV’s indomitable COO, has been leading the search for proven candidates from a variety of fields who can add real value to the organization in terms of fundraising and driving adoption. We are extremely grateful for all her hard work in this regard.
