Okay, a minor update on what we are (and are not) doing here at Ethereum DEV.
We are first and foremost developing a robust, quasi-Turing-complete blockchain. This is known as Ethereum. In addition to being almost Turing-complete, it meets a number of other important considerations, stemming from the fact that we’re developing an entirely new blockchain technology, including:
- fast, through a block time of 12 seconds;
- easy to use for thin clients by using Merkle roots in headers for compact inclusion/statement testing and DHT integration to allow thin clients to host and share small parts of the full chain;
- ÐEasy to apply, even for thin clients, by using multi-level Bloom filters and transaction receipts. Merkle tries to allow for lightweight log indexing and testing;
- Finite Blockchain Compatible: We designed the core protocol to make it easy to upgrade to this technology, further reducing the thin client footprint and helping ensure scalability in the medium term;
- ASIC Incompatible – Through the (yet unconfirmed) choice of PoW algorithm and the threat that we will upgrade to PoS in the not too distant future.
It is robust because:
- is unambiguously formally defined, allowing for highly manageable parsing, saturation testing, and formal auditing of implementations;
- has an extensive, and ultimately complete, set of tests to provide an exceptionally high degree of probability that a particular implementation will conform;
- modern software development practices are followed including a CI system, internal unit testing, strict peer review, a strict no warnings policy, and automated code analyzers;
- its mesh/p2p (also known as libp2p) backend is built on a well-proven secure foundation (technology derived from the Kademlia project);
- official deployments undergo a full industry-standard security audit;
- A full-scale stress test network will be instituted to profile and test against potential adverse conditions and attacks prior to final launch.
Secondly (and consequently with a lower priority), we are developing materials and tools to make the use of this unprecedented technology possible. This includes:
- develop a single, custom-designed CO (contract-oriented) language;
- develop a secure natural language contract specification framework and format;
- formal documentation to help codify contracts;
- tutorials to help code contracts;
- sponsorship of web-based projects for the purpose of engaging people in development;
- development of a blockchain integrated development environment.
Third, to facilitate adoption of this technology, gain testers, and stimulate further development, we are developing, collaborating with, and sponsoring a number of force multiplication technologies that leverage legacy technology, including:
- a graphical client “browser” (taking advantage of browser components from the Chromium project and Qt 5 technology);
- a set of basic contracts and ÐApps, including those for registration, reputation, trust network, and accounting (taking advantage of pre-existing compilers and development technology);
- a hybrid messaging/multi-DHT system, codenamed Whisper (which takes advantage of pre-existing p2p protocols and back-ends);
- a simple DHT reverse hash lookup, codenamed Swarm (which also leverages pre-existing p2p protocols and backends), for which there is an internal implementation underway, but which could end up being merged or a collaboration with the IPFS project .
We no longer actively target multiple languages (LLL and Mutan are discontinued, Serpent continues as a side project). We are not developing any server technology. And, until there is a working, robust, secure, and efficient blockchain along with basic development tools, other parts of this overall project are of substantially lower priority.
After the launch of the Ethereum blockchain, the other components are expected to spend more and more time on them.
