Been a moment, I know, but these are rather busy days.
I write this from a Starbucks in Shanghai sitting behind the big firewall, capable of taking a look only on the occasion. I have been in Asia with Marek for a few weeks, mainly for meetings, workshops and technical meetings. Meanwhile, we saw the release, the fight and the survival of the Olympic test, a very clear signal that a multi-client system would be much higher than the current monoculture. We saw the start of the second external GO audit, mainly for the verification of regressions but also to offer comments and criticisms on the aspects that have changed in the meantime like the network layer and the synchronization strategy of Go. We have seen the mixture and solidity continue to progress and mature. And thanks to the continuous development and the progression of APIs, we have seen all customers become cleaner, faster and more resilient.
Trade
We have continued to work with the exchanges, now Marek and Konstantin provide substantial technical support, helping the coders of exchanges to understand the major differences between the use of standard cryptocurrency APIs and the approach based on intelligent Ethereum contracts. In order to provide them with better support and maximize adoption, we have designed and introduced a JSON Middleware RPC proxy allowing a much more familiar interface in Ethereum for exchanges.
C ++
On the C ++ side, we have introduced PV61, a new version of the Ethereum network protocol (compatible behind so as not to hinder the border version calendar for GO) offering a super fast parallel chopping chain download and much more resilience to attacks on the Sales hash chain. Arkadiy helps code this for C ++ in the hope that he can be worked before Homestead.
Solidity, on the other hand, has progressed considerably: solidity can now structurally predict the use of gas, optimize very well access to storage and size of the code, and take charge of internal functional function with dynamic types, as well as a multitude of other features. Liana continues to hack this code base with Christian.
Mix, under the direction of Aeron and Jutta with Avsa providing information on the visual and hacking of Yann, see a substantial ux varnish and refactoring, the general target being to be an ultra-unit, but powerful IDE, for the development of contracts. ÐApp can now be deployed on the network in a simple 3 -step process, and the state management layer / blockchain improves from afar, with a single part view from which you can easily see all transactions, calls and newspapers and easily propagate transactions between the chain.
Alex continues to work on the low -level network layer, now helped by Vlad. We had a summit in Zug 3 weeks ago when I presented the plans of our LibP2P networking layer, and how the Whisper and Ethereum protocols correspond to it. Our first full -time developer on Whisper, Vlad will continue to hack on Libp2p and Whisper, making the protocol more resilient at various Ethereum networking attacks while continuing R&D for the non -specific signaling protocol not with the asynchronous P2P key.
Pawel, working from Warsaw, continued in the Jit Evm and Evm libraries, optimizing the use of the battery and helping to solve the battery depth problems that we saw on Mac OS X. Vladimir continues while waiting for his work on the tests and Marian on the Netstats page which recently proven its usefulness to more than one title. Those who have experienced the mining configurations on the Olympic test will probably recognize the work of Lefteris to resume the implementation of the Ethash, and update, refactor and generally support the implementation of the Tim Hughes opencl. A special thank you to each member of the community who helped one way or another with the development of this code. You know who you are (-Christoph, meanwhile, is now working on the coverage of tests for basic classes, as well as to solve various problems in the heart.
In addition to working with the mixing teams, Arkadiy and Marek, I coded the new C ++ Wallet / Secret Store portfolio (a revised format and compatibility with Go and Python), optimization of the nucleus (import times for at least a gas blocking have recently been measured as being ~ 10x faster than the Python and ~ 3x Fast Bug in autonomous mode and the binary “ethkey” for portfolio management and, more recently, the coding of a much better interface of interactive console, similar to the JavaScript console of Go. I also hope to get a much better display of blockchain download diagnostic that will soon be to Alethzero.
Audit
The internal audit of the C ++ code base began, Christoph working on tests for all basic classes and Arkadiy helping some of the basic optimizations. The secret classes and Wallet have already been verified by Christian, giving the credibility that the C ++ customer is reasonably secure for the management of private keys. The C ++ external audit will start in three weeks.
Since the substantial failure of the testnet caused by problems in one of the three customers, including the problems that have survived two audit procedures, it has become clear for us that the audit, external or internal, is not a miracle solution. Although we are committed to providing the best software and we will continue our audit program, please be clear: there is nothing magical in the fact that the Go customer has followed an audit process. We aim to have all customers through at least one basic audit process by the Homestead version and I do not see any reason to use the GO customer compared to other customers (C ++ or Python) at this stage, nor for the vast majority of users, during Frontier. No customer sees with guarantees. Indeed, there is the argument that minority customers, being a smaller target, are less likely to be attacked.
Ahead
We continue our preparations for the release of Frontier. Although we are not yet uncertain of the precise release date, we become more and more satisfied with the resilience of the Olympic test. While the failure of the Olympic test test was underway, adversity has caused a reflection on how we could alleviate these problems in the future. The depth and duration of consensual insufficiency can, roughly, be reduced to two problems: first, there was a bug in the GO code base, which made it accept non-valid blocks (in this case, blocks with proof of non-valid non-working work); Second, there has been a huge problem with the network upgrade since the minors continued to exploit the “bad” chain and were slow to upgrade their nodes so that they have extracted the right chain. Essentially, the first was a forensic problem and the second an organizational problem.
To make sure that it is never so deep or wide in the future, I designed two new protocols: the Bad canary channel and the Bad block report api. Bad chain canary is a simple contract. It is controlled by a single key (although there can be several) and is quietly found until its owner is screwed up. I will be one of these owners, Vitalik and Jeff two others and there will probably be fourth, Christoph. When he is screwed up, he receives a pair of blocks of blocks and blocks; This pair refers to a recent block on a bad chain. If they correspond to the chain on which the contract thinks it is seated, it puts itself in the state of the “bad chain”. This allows the developers Ethereum Core to inform all those who manage a client on a bad channel (that is to say that which does not comply with yellow paper due to a bug) that it is such. The default value of customers (easily replaced) is not to use such channels (because it would be a waste of energy), but rather to inform the user that they should upgrade in their first opportunity.
The Bad Block reporting API is a simple RPC JSON which allows a number of our nodes to execute in “Sentinel” mode. In this mode, if they come across a bad block, they automatically compile a standardized ratio of what did not work, including the expected transaction receipts, the traces of virtual machine, proof of work and block error information. This report is then instantly sent to a ðV server where it can trigger an early alert system and, if the Liberation Tzar (which would be Taylor) the judge required, alert the basic developers. Thanks to the normalization and the use of a simple format, it is designed so that we can easily code a JSON-COMPARAGRY engine to quickly diagnose where the problem of consensus is located.
A future work is to combine the two so that the JSON-RPC can also manage the Canary Information Report-In this case, a user can configure a Sentinel server to give them an email whenever the contract reports that the mining has ceased and / or it should upgrade its node to continue the mining.
Foundation
Finally, the three directors of the Ethereum Foundation (Vitalik with three voices, then Taylor and Mihai with a vote each) will soon meet to, according to the words of Vitalik, a “sort of passage from the Baton event”. Kelley, an indomitable COO of ðV, directed the search for proven candidates from various fields which can add real value to the foundation both in terms of fundraising and conducting adoption. We are extremely grateful for all his hard work in this regard.
