Also, during this time Aaron Davis (Kumavis) made some excellent progress towards a JS light client by utilizing IPFS’s libp2p to build a in-browser mesh network and IPLD to provide the merklization layer. This will be important work in the future for building pure in-browser clients. Also Casey Detrio worked on a standard json RPC test suite, which you can see the results of here.
After the Seattle Meetup, we (Axic and Wanderer) sat down for a week long hackathon in Budapest to hash out some details of ewasm. Elsewhere in JS world, Fabian is doing a huge refactor of Web3.js for the 1.0 release, while Nick Dodson has been busy with ethjs. The rest of this post will be charting the various projections that this technology could provide as well as going into some details about each individual project. All these projects are all open source and encourage community participation, so if you are interested please check them out, say hello and send in a PR if you have time!
Ewasm’s goal is to research and replace the EVM with Webassembly and secondarily, implement a client for the current system which can be efficiently JITed (or transcompiled) to WebAssembly.
A major piece of evaluating WebAssembly for blockchain usage will be create a test network and this year the focus of the Ewasm team will be bringing that test network to life. The testnet work will:
- enable hands-on work with ewasm for a wider audience
- enable related work, such as experiments with casper to be done by providing a flexible platform for experimentation
The ewasm track is dedicated to ewasm research and development, while the client integration track will be dedicated to developing the network and bring full and light clients into existence. But there are many shared components to these two tracks. The Ewasm project is being broken down into two main components: the Kernel Layer, which handles IPC and manages the state, and the core VM. This should enable us to use the same framework for different VM implementations.
So to recap, the major tasks for ewasm are:
- Build an ewasm test network
- Creating a reusable “kernel” module
- Revamp ethereumjs-vm
- Use ewasm-kernel for the message passing
- Implement the latest EIPs
- Ewasm integration tools
- Solidity-ewasm integration (upcoming effort for the solidity hackathon!)
Please come join the implementation effort! We have semi-weekly meetings on Tuesdays. Our communication channel is on Matrix at prima:matrix.org (or #ewasm on IRC or at gitter)
There are several reasons to have an Ethereum networking implementation in JS. For one, it would allow us to implement a full and light Ethereum JS node. These light clients would run both in a node.js environment and in a browser. A prerequisite for an in-browser light client is “bridge” nodes. These nodes might also act as signaling servers for the webrtc network that the browser light clients would use to relay messages from the RLPx network to the webrtc network. This work is being spearheaded by Metamask using IPFS’s libp2p. Also the RLPx implementation was recently revamped by fanatid.
Ethereum’s blockchain and on-chain state can be understood as a graph of hash-linked data. IPFS/IPLD is proposed as a generic system to describe and distribute hash-linked data. Therefore we can describe Ethereum as an application layer on top of the hash-linked data availability platform. As a proof of concept, Kumavis implemented IPLD resolvers for the Ethereum data formats that define where hash-links are encoded inside the canonical Ethereum formats (e.g. block and state trie node). This, combined with other generic features of libp2p (IPFS’s generic p2p networking stack), enables the creation of minimal Ethereum clients that focus on the consensus protocol and state transition mechanism. One advantage of this approach is that the networking layer is transport-agnostic and can be used in environments that don’t have access to tcp/udp (such as the browser) that the standard Ethereum clients require. This project is still in the research phase. MetaMask hopes to use this approach to implement a browser compatible Ethereum light client via a secondary network, bridged by hybrid nodes.
Web3.js 1.0 incoming!
A new version of web3.js is in the making. It is the biggest refactor of the codebase since the inception of the popular Ethereum library. It will have a lot of convenience features like confirmation and receipt event on transactions, a nice subscription API, and checksum checks on address inputs.
The API is still not yet finalized, but if you are eager to have a look you can check out the docs here.
The new version will also have quite a few breaking changes, but those updates are necessary to get the new API right and remove some some deprecated methods along the way, like synchronous calls. 1.0 will only have promises and in some events “PromiseEvents” to better reflect multiple events on a transaction’s execution. For those who are thinking of transitioning their apps to the new web3, there will be a migration guide upon launch to help make the transition from 0.x.x as easy as possible.
In Mist there will be no web3 exposed by default anymore, as this encourages the bad habit of relying on the Mist-provided web3, which makes breaking changes disastrous for dapps. Instead, there will be an “ethereumProvider”, which libraries like web3 can use to talk to the underlying node. Web3.js will automatically detect any given provider and expose it on its API for easy instantiation.
For those who can’t wait and want to try it right now, checkout the 1.0 branch in the web3.js repo. Be aware there might be dragons!
Ethjs is a new highly optimised, light-weight JS utility for Ethereum geared to working with the json RPC, much like web3.js but lighter, async only and using bn.js. The current ongoing activity includes:
- Adding the ABI methods for decoding logs in ethjs-abi
- Having fixed a small decoding bug in ethjs-abi (handling 0x addresses)
- Merged new schema for personal recover and sign ethjs-schema
- Looking for help making ethjs-filter stateless (infura ready)
- Bug fixing in ethjs-contract
- Documentation updates all around
- Upcoming ethjs version 0.2.7 release!
Working on the 4.0.0 release! This release will include:
- Database persistence. Now you can create a test chain and save that data, just like any other private chain!
- Clean up of how data is stored in memory, which should reduce memory issues significantly. Although there will be a slight cost in some performance, which mostly be unnoticeable unless you’re making thousands of transactions, it will bring a huge increase in stability.
- Bundling for the browser (provider only).
- Easier installs on Windows, and possibly other platforms.
We’ll be moving the TestRPC to the Truffle github organization since it’s primarily maintained by Truffle developers. There are significant new TestRPC add-ons coming. And we’re investing significant energy in documentation and branding that unifies it under the Truffle brand. Any feedback on this move is appreciated. Lastly, the TestRPC needs a new name that exudes everything it can do. If you have an idea let us know!
The Ethereum JS community is an exciting and wonderful thing to be a part of. There are many great projects happening. If you are interested in plug in we have weeklyFriday meetings at 3:00 EST / 10:00 PST / 18:00 UTC. Watch our gitter channel for the chat link. Also, we are organizing an upcoming hackathon. Let us know if you are interested.
ADDENDUM [Mar. 22, 2017]: Note that some of the projects in this post are not directly supported by Ethereum Foundation, but have been included as they are relevant to the overall Ethereum JS ecosystem update by the author.