Geth, Viper, and Wafr: New Ethereum Developments
The Ethereum environment is constantly growing and changing with new updates, releases, and smart contracts introduced into the tech. It’s worth noting what’s new and developing within this innovative ecosystem.
Next week, Ethereum will see two new Geth clients introduced. Geth is the command line interface for running a full Ethereum node implemented in Go-Ethereum. The two new Geth clients (Geth 1.4.19 and 1.5) will accommodate the upcoming hard fork and will include new features such as the alpha light client and the Swarm daemon functionality. All new Geth releases must be compatible with the hard fork in order for it to be feasibly used. Swarm is the distributed storage platform and content distribution service; a native base layer service of the Ethereum web 3 stack. What this new release means is that users will be able to access blocks, transactions, and the state from swarm storage instead of stored locally.
UPDATE: Hard Fork announced:
After many hours of coding, testing, more coding, reviews and discussions, we can finally announce the next hardfork's block number:
Main net: 2.675.000 Test net: 1.885.000
Geth HF enabled releases:
Geth 1.4.19 and 1.5 will be released next week. 1.5 contains many new features including alpha light client and swarm daemon— JΞFF (@jeffehh) November 13, 2016
Growing from the Ethereum ecosystem is also an experimental programming language called Viper. This new programming language aims to provide the following features:
- Bounds and overflow checking, both on array accesses and on arithmetic
- Support for signed integers and decimal fixed point numbers
- Decidability - it's possible to compute a precise upper bound on the gas consumption of any function call
- Strong typing
- Maximally small and understandable compiler code size
Vitalik Buterin’s notes on Viper:
- Just to reiterate, Viper is pre-alpha. Use with extreme caution at this point.
- Viper is technically not "total functional", it's "total" or "decidable" (see here for entry to the relevant rabbit hole). So it doesn't do functions without side effects. That said, I certainly could forbid permanent variable changes or outside calls that could lead to such changes in constant functions - in fact, I'll probably do that in the next release, which will make the language at least more functional-friendly.
- Viper is NOT meant to be one-language-to-rule-them-all and is not meant to replace Serpent, Solidity and LLL. Releasing Viper should NOT be taken as a statement that I believe that Viper is superior to existing languages in all situations, or that it solves problems that modifications to existing languages cannot solve. Solidity developers are also working on overflow checking and other safety features; this is great work and I support it. The reasoning behind starting fresh was to provide greater freedom for initial experimentation without stepping on anyone's toes, to provide different properties and tradeoffs compared to existing languages, and to increase choice. See also: Bamboo, another experimental HLL-under-development.
- Why did I make viper instead of continuing working on Serpent? First of all, Viper is strictly less powerful than Serpent in certain intended ways, such as being decidable and thus not having dynamic-length loops. Another example is that Viper only supports 128 bit integers, addresses, bytes32s and decimal fixed point values, whereas Serpent supports larger integers. Serpent also adds the ability to directly call the EVM, which Viper does not have. Developers working on Serpent may not be ready to accept all of these restrictions. Second, the Serpent compiler's C++ codebase honestly is hard to work with and hard for both myself and new developers to get their hands on. The choice to write the compiler in C++ was made originally because we had thought it would be directly available from inside Geth, Mist, etc; now this consideration doesn't exist and python is clearly easier to read and develop on.
- What will the future of Serpent be? This honestly depends on what the Serpent community (Augur, btcrelay, looking at you!) want it to be. I personally have little time to keep developing Serpent myself, especially given that the codebase is at least in my opinion not in a state that's very friendly to continued expansion, and so far I have not been very successful in getting outside community participation. That said, Serpent users are welcome to make their voices heard; options include (i) keeping the language itself fairly static and doing ongoing maintenance to keep up with EVM changes (eg. EIP 86, sharding), (ii) expanding Viper and providing a pathway for all Serpent code to get (mostly) automatically converted into Viper code, and (iii) some team taking on Serpent and pursuing a much more active and independent development path.
Wafr is also a new development within the intricate design of Ethereum. Wafr is proposed to be a “super simple, wafer thin, Solidity contract testing harness.” It was created to serve as a bootstrapped tester for Solidity contracts. It compiles contracts, then provides a test class that can be inherited to test various contracts. Wafr does the following:
- Compiles contracts
- Deploys any contract with test in filename that inherits wafr/Test.sol
- Sends some ether to the test contract
- Runs the setup method, if any
- Then runs any method with “test” in the name
- Then it tests everything against the assertTrue method