Introduction
For the last few months we’ve been focusing mainly on two things:
- Replacing the Ethereum PoW-based client with Tendermint.
- Phasing out the deCerver.
Replacing Ethereum with Tendermint is essential, though it’s mostly about replacing the consensus system. It still uses the EVM (Ethereum Virtual Machine), which means Solidity code will still work. The reason we needed to switch is that the PoS consensus system in Tendermint is much better suited for our chains, because consensus is generally driven by a set of trusted nodes.
Phasing out the decerver involves moving dependency management over to docker, and moving the dapp logic into node.js. This means that dapps are just normal node.js applications that uses Eris javascript libraries to access the blockchain client, and the client is (preferably) running in a docker container.
Some of this will now be released for public testing.
The new eris-db server
Tendermint is now integrated into our stack, and can be run through a library we call eris-db. It is basically a Tendermint node wrapped inside of a simple webserver. You can call the node using JSON-RPC 2.0 (supports both HTTP and websocket), or through a REST-like web-api. It can handle multiple users at once, a mix of http and websocket, etc., so is more like a web-server then a simple RPC component. The purpose of this is to make it easy to set up an environment where one node can serve multiple users that connects via a web-browser.
We expose most of the functionality of the Tendermint client, like fetching account-, blockchain-, consensus-, and network-data, transacting in various different ways, and subscribing to events. You may also use filters when fetching large sets of data such as accounts and blocks. With JSON-RPC you add these filters as objects, and with the REST-like api you use a query structure similar to that of the Github API. A specification of the different web APIs can be found here, along with some info about the different concepts and objects the system uses.
The javascript library
There is also a new javascript api, eris-db.js. It can be added to a node.js application through npm or otherwise (npm install eris-db). It provides binding to all the RPC methods, and a number of helpers for doing things like listening to events.
This library is not a full set of tools for dapp-development, but more of a back-bone. It has the bindings for eris-db/tendermint. We have chosen to divide it up so that people may choose which tools they like, meaning there will be one node.js library for “web3-like” solidity contracts, one for remote-compiler bindings, and so on. If there’s a demand, we might make a collection library for all the common libraries, but initially it will be possible to choose which ones to import.
This library is tested in node.js, but will work in a browser as well. This will be the case for all our javascript libraries most likely.
Extras
The server-server
eris-db comes with a server that makes testing convenient. It accepts POST requests with chain configuration data in the body (validator.json and genesis.json, etc.). When receiving a request it will create a new working directory in the OSs temp directory, write the data into it, start a fresh erisdb in that directory, serve it on a port that is taken from a pool, and return the port in the response. It is then possible to use that node to do the tests.
This server is meant to solve a few problems that I’ve come across, for example: When testing code I usually need a clean, new node to get reliable results. This is the case in 80-90% of all testing that I do. Using an already running node works sometimes, but it is far better when you know that the starting-state of the node will be exactly the same in each test. Of course, some things like timestamps will be more or less random, but most of the output will be exactly the same; new contract addresses and hashes in particular.
Also, I like to be able to work on web-stuff on my Windows machine. Our remote compiler makes that possible to some extent, but i still have to run a node to do tests, and i like having that set up on a remote that will spin up new nodes in milliseconds when i need them, rather then having to set up boot2docker or some vm locally, or go through CI. I think Mac people would appreciate this as well - to be able to dev in their regular operating systems with their regular IDEs using a simple, out-of-the-box solution.
Test data
We use JSON for test-data, so that it works both with the server and the clients. If someone needs to make a client in some other language they can use the data to make sure it works.
TODOs
These are some of the things that needs to be added before we release version 1.0.
- The most urgent addition is perhaps the web3 javascript contract-objects. They will make it a lot easier to call contracts and listen to solidity events. This requires a PR to Tendermint because solidity events has not yet been integrated, so it will take a little while.
- Another urgent addition is javascript bindings for the remote compiler.
- A docker container, obviously.
- A new web-UI for viewing and (to some extent) interacting with a running chain.
- Browser testing of the javascript libraries.
- Support for CORS and TLS in the server. It’s been added but needs testing before we officially support it.
- Unit testing solidity contracts is useful, at least when working with large systems. My sUnit library allows unit testing from node.js, and can be hooked into whatever testing framework is used. I will port it over to erisdb and upload at some point. This is low priority.