Although the core concept was proven last summer when lead developers Vitalik Buterin, Gavin Wood, and Jeffrey Wilcke initiated the PoC (proof-of-concept) series in Python, C++, and Go, a lot of engineering effort has gone to solidifying these implementations. We’re all anxious to release a stable command line client and issues flagged in the external audit are being resolved when uncovered. As soon as this process is complete, a general release should\u00a0be around the corner. In the meantime, the rest of the ecosystem is continuing to evolve to more refined versions.<\/p>\n
One of the challenges with a project of this scope and complexity is simply agreeing on any particular thing. Translating human abstractions into code is a tough task, as even the words we choose<\/a> influences different ways of expressing ideas with code. As we build more around these core ideas and truly experience how reality meets theory, we\u2019re able to refine the underlying specifications to remove ambiguity. This all pays off as the team shares a clean and well-understood vision\u00a0that should translate effectively to other developers of varying disciplines.<\/p>\n Complementing this, a variety of\u00a0test suites add an important level of confidence that the various implementations adhere to a specification. On the consensus front, we have used a series of VM and State tests to simulate known results and have added randomization and fuzzing to increase this testing space.\u00a0A series of system and networking tests are also being run, ensuring clients communicate in an expected manner or respond to certain networking scenarios predictably.<\/p>\n Not only are tests designed for success, but all sorts of error conditions are fed into the test suites to ensure that known errors (such as running out of gas or being abruptly disconnected from a peer) are reported correctly. What this means is that when changes are made\u00a0to the behaviour of the clients, the decision\u00a0is driven by data and metrics, rather than theory and gut feelings.<\/p>\n Beyond testing of the core components, we have begun implementing tests on the exterior layers to ensure that the clients respond to a\u00a0multitude of calls to the underlying system in the same way with easily-consumable JSON. These specifications are linked in the wiki<\/a> and drive the implementation and communication across diverse teams. This helps to ensure that what is in our heads is reliably translated into code, and that all of this is tested and audited.<\/p>\n All of these improvements are important to the health of the overlaying ecosystem and help shine a spotlight on otherwise very nuanced problems. In addition to refining the core virtual machine and serialization layers, security audits were initiated with a third-party firm experienced in decentralization and cryptographic technologies.<\/p>\n So how does all of this underlying technobabble expose itself to the general user? For the Frontier rollout, we are aiming to release stable binaries on major operating systems (Mac, Windows, Linux). The main interfaces will consist primarily of the command-line client, interactive JavaScript console, and JSON-RPC. In go-ethereum, we\u2019ve recently renamed this client to \u201cGeth\u201d, a nod to both Mass Effect<\/a> and Old English<\/a>.<\/p>\n Using the command-line client will be a familiar process to many. For example, you can create a new account with geth account new<\/span>, at which point the program will prompt you for a password to secure the account. Starting geth as a miner can be done by calling it with a parameter, like so: geth -mine<\/span>. This is a great way to start interacting with the system, but has its own set of limitations. For example, once you\u2019ve started mining, how does one\u00a0pause\u00a0it?<\/p>\n For a more useful way to control the program, Geth has a JavaScript console backed by a JavaScript API<\/a>. Start it with a simple command: geth console<\/span>. With Geth, this starts the interactive console<\/a>, giving users the familiarity of JavaScript scripting to control the system from the terminal. For example, to find out a bit more about the local node, run admin.nodeInfo()<\/span>.<\/p>\n This control is partly powered by ethereum.js<\/a>, a JavaScript library that helps provide a friendly interface to not only the console, but also DApps. It relies on a well-documented JSON-RPC<\/a> interface for automated processing or integration into existing infrastructure. Work on many of these components is ongoing as rigorous effort is being put in to ensuring that the implementations speak the same language and are as generally compatible as possible.<\/p>\n Of course, all of this is built publicly on GitHub and includes various continuous integration aspects such as automated builds and reporting on major platforms. This is not a program defining a spec\u2014this is a spec implemented and cross tested between machines and humans spanning the globe.<\/p>\n Concurrently, work is progressing on several other components to the ecosystem, including GUI interfaces for Mist (the DApp browser) and Mix (the IDE). Many of the tools we use and build upon are new and sometimes require patching upstream to ensure everything works as expected. This is a great benefit for all open source development, and one of the many positive byproducts of all the hours spent actually engineering software. Although the wait may seem long, progress and ongoing confidence in the whole system is increasing steadily.<\/p>\n Beyond the technical ins and outs of development, our communications team has continued interacting with the community to produce public education material like tutorials and videos. Furthermore, our admin staff helps process payments and comply with various local laws including tedious things like employment taxes.<\/p>\n Being part of the Ethereum project has been an exceptional experience filled with excitement. What started as only an idea<\/a> little more than a year ago has spawned an exceptional engineering effort led by professionals implementing all the necessary infrastructure required to build a revolutionary decentralized application platform.<\/p>\n When Netflix introduced Chaos Monkey<\/a>, they asserted, \u201cWe have found that the best defense against major unexpected failures is to fail often. By frequently causing failures, we force our services to be built in a way that is more resilient\u201d<\/em>. In the process of developing Ethereum, we\u2019ve experienced first-hand the benefits that come from continually straining a system<\/a>.<\/p>\n And while being\u00a0tasked\u00a0to craft the\u00a0very platform\u00a0that you dream about is a huge honour,\u00a0we build it because we want it to exist.\u00a0Thanks for your patience as we think, sleep, eat, and dogfood<\/a> the platform. We’re as anxious as anyone\u00a0to see what kind of DAapps will be launching after mainnet goes live!<\/p>\n<\/div>\n![\"Number](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/Screen-Shot-2015-03-28-at-15.39.17-1.png\")
<\/a>
\nNumber of git commits over time<\/p>\n![\"Graphing](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/peerconnections.jpg\")
<\/a> Graphing node connectivity allows us to visually inspect the health of network<\/p>\n![\"A](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/Ethereum-Infrastructure.png\")
<\/a>
\nA rough snapshot of development efforts.<\/p>\n![\"Using](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/geth9.gif\")
<\/a>
\n
Using Geth\u2019s interactive JavaScript console<\/p>\n![\"A](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/Screen-Shot-2015-03-28-at-22.06.02.png\")
<\/a>
\nA quick view of build status<\/p>\n![\"Who](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/Screen-Shot-2015-03-28-at-15.31.34.png\")
<\/a> Who needs sleep?<\/p>\n