We've spoken about Ethereum 2.0 developments quite a bit, but those were generic and introductory. We haven't spent much time telling you specifically about what was done so far. Each individual entry of the Nimbus development update below will be further explained in a future post in the Two Point Oh series.
The updates in this section focus on the Serenity side of things. If you're interested in Nimbus' status in regards to Ethereum 1.0, please see the end of the post.
The bulk of Nimbus' Serenity-related development is happening in the nim-beacon-chain repository. This repository also contains the proof of concept beacon chain implementation we're hoping to demonstrate in late December.
While there's still a lot of work to be done, the basic building blocks are there. The chain implementation compiles and can do attestation checks to some degree. The shuffling of validators works but there are some spec-wide issues that need to be resolved. In general, the code needs further refinement as a lot of effort has gone into synchronizing our implementation with the recent specification changes.
To add RPC magic to Nimbus (in order to be able to connect to Nimbus nodes remotely), the Nimbus team published the independent nim-json-rpc library which serves to facilitate routing JSON 2.0 formatted remote procedure calls over different transports.
Due to Nimbus aiming for high performance, we're benchmarking everything that's done and deemed ready (ish), comparing the results across optimization attempts.
On the Serenity client networking front, there is now a working Nim client implementation for connecting to the libp2p daemon at nim-libp2p. This allows for direct peer to peer communication with some caveats. A tutorial on using this standalone implementation is coming within a week or two, along with detailed docs.
In general, in regards to the beacon chain implementation we're hacking away at, we have started attaching the good first issue label to some issues to encourage outsiders to contribute. There's a very high probability that we'll turn those into bounties as well.
To help with all matters crypto, the common cryptographic algorithms have been implemented in the nimcrypto library.
The library is pending an external audit - the team is working on making it industry standard in the nim ecosystem. Full docs here.
Originally there was no spec, so the implementation was improvized and used as a proof of concept that it's possible to use BLS / signature / verification / aggregated signature and aggregated verification. The next version supported both 32 and 64 bit architecture and improved performance, compressing signatures to 48 bytes. The verification key was serialized uncompressed, so took up 192 bytes. It worked, but wasn't up to spec. The most recent update uses G2 for signatures and G1 for Verification of public keys and Signature and Verification (public) key are now optimized to 96 and 48 bytes respectively.
In other words, we now have compatibility with the zkcrypto pairing scheme.
Debugging with Chronicles
To further help with Nimbus development and to be able to more effectively debug, the team have developed nim-chronicles, a logging library that outputs structured and human readable data. The human-readable format can be printed in the terminal/console of the user's choice, while the JSON output format is compatible with most log processing software.
We encourage Nim enthusiasts to check it out, use it in their projects, and join Chronicles' further development. Note that if you do try any of our Nimbus related repos out in any way, there might be some coding style inconsistencies that indicate a prototype phase. All these things will be cleaned up before it's time to merge nim-beacon-chain and its dependencies with the general Nimbus repo.
The nim-eth-trie repository provides an implementation of Merkle Patricia Tries as specified by Ethereum. The README is quite comprehensive so we encourage you to give it a look and if you need a refresher on MPTs, this is a handy answer.
It should be noted that this functionality was developed with the help of paying out significant bounties to third party contributors and as such marks our first serious collaboration with non-core-members.
Oh, we've also done some experimental work on adding eWASM into the mix and compiling smart contracts (it goes through
clang with a
wasm back end), but this hasn't exactly been a priority and was a highly experimental implementation, so it's been a while since the library has been updated. We'll publish a getting started tutorial soon, but this shouldn't be relied on for anything.
The Ethereum 1.0 Client
Nimbus is also slowly being brought up to date with Eth 1.0. The current 1.0 compatibility TODO list is here and several members of the team are actively working on these. Right now, Nimbus will sync the chain up to block 50000 or so, but does nothing else really since as we explained earlier, 1.0 is not a priority.
If you're interested in 1.0 progress, we have a nearly feature-complete VM implementation in Nim, which means that you'll soon be able to use it at the very least to compile and test your smart contracts locally. We're actively working on supporting the feature set that's needed by the most popular frameworks today: Truffle and Embark. If you'd like to take a look at the EVM implemented in Nim, this is the spot.
RLP encoding in nim-rlp, a Nim port of the RLP specification from the Yellow paper and wiki, is fully operational, and probably the most stable package in our arsenal. It is also the one least useful outside of Nimbus.
At the same time, a tool is being developed that's akin to the geth console or a similar web3 interface, allowing for programmatic access and read/write operations with exposed smart contract interfaces and the running node's API. The initial idea is to use this to detect registrations of validators in the deposit contract, but will later be expanded for general use.
The nim-stint repo contains a fast and portable stack-based multi-precision integer library in pure Nim. While generally usable across the board if you need performance, the library benefits the Ethereum ecosystem by adding
Int256 for Ethereum Virtual Machine usage and
Uint2048 for Ethereum Bloom filters (used to a large extent in Whisper communication and in searching Ethereum logs in a space-efficient way).
There is some low hanging fruit among the issues, if you'd like to contribute.
We're moving ahead with a proof of concept beacon chain implementation for December, which should turn into a beacon chain client by the end of March 2019 - by then, we aim to have it connect to all other beacon chain clients out there.
In the meanwhile, we'll keep developing independent and externally-usable components and building the ecosystem in an effort to get external contributors on board and indirectly improve our own work, which in turn improves Nimbus as a whole. If you'd like to be part of the ecosystem we're creating, please get in touch on our forum, in our repos, or on Twitter. Alternatively, join the ecosystem by using our project starter skeleton and booting up your own Nim project.