Let's dive right into changes since last time.
Many teams are using their own approach to generate a genesis start event for Ethereum 2.0. Like Prysmatic says in their latest update, some are using YAML files, others are using file dumps, some others use live testnets like Goerli. We decided to make a tool that would make it easy for us to generate a genesis on the fly in seconds, but we also wanted to make it useful for other teams.
Thundercloud is a simple JS bootstrapping script which creates a reproducible Ganache environment for both your team and third parties. Here's how it works:
- Clone it and modify the mnemonic in the
- If you want to add some pre-created private keys, add them to the
- Install prerequisites with something like
yarn installand then run
node start.js. Optionally, pass in a
vargument to autogenerate that many validators
mykeysargument to make the script read the keys specified in step 2.
The script will:
- Generate validators based on the
vflag and the
mykeyskeys, seed them with 32.1 ether each.
- Generate a faucet account with 1 million ether.
- Deploy the Ethereum 2.0 deposit contract
- Send each validator's 32 ether to the deposit contract with a valid deposit (valid BLS keys, signature, etc.)
- Save all the private keys, deposit contract's address, and faucet address and key into
- Open up a web3-enabled ganache from these settings, so it can be immediately connected to.
You now have a readable Ethereum 2.0 genesis setup that you can upload to a server somewhere and run - if you define the same mnemonic and the same keys in
.mykeys, you will always end up with the same state, so this test environment is reproducible.
Now that the Ganache chain is running, you will have a file
faucet.txt in the
deploy/keys folder. Grab that address and private key, and insert them into
config.json.example). Then run
yarn facuet to host the faucet. You should be able to request 32 test ether per tweet or 1 ether regardless of tweet from the faucet account at
localhost:5000 or wherever you decide to host the faucet.
We're also working on a dead simple validator UI so you can stake from a simple web page.
Note: Thundercloud is under active development and will evolve. PRs that keep it simple but make it more effective are highly appreciated!
Work has begun on a Nim-Go interop. We're exposing some common Whisper APIs from Nimbus for consumption by Status, with the endgame being replacing Status-go with Status-nim (a long ways off!). This integration will allow the Status Console Client to use Whisper via Nimbus.
You can try to experiment with it by following the draft of instructions here, and you can check out the library in the making at Status-nim. Caution - highly experimental, very volatile, and very likely not usable for anything other than fun experimenting with Whisper.
- with minor critical fixes added to the frozen 0.8 spec, Nimbus is now almost in sync with the newest 0.8.2 version.
- as our features are slowly becoming more and more rounded off, we're ramping up our efforts to harden the code and improve security. There's a checklist we'll be going through and there's going to be some bounties to score too, so keep an eye on [this issue](https://github.com/status-im/nimbus/issues/164.
- we've identified some bugs in the justification and finalization and are working on resolving them - once that's done, we'll push Libp2p onto Testnet0 as well. If you're not too familiar with the concepts of justification and finalization, here's an explainer to bring it home.
- our libp2p testnet1 has been running since July without problems. If you decide to try it out, be warned, it's a little verbose in output right now! Having made sure it works as intended, we're thrilled to have the ball rolling in regards to nim-native libp2p development. Status and Nimbus are looking forward to further collaborating with the Ethereum Foundation and Protocol Labs on pushing libp2p ahead!
- the metrics library we mentioned last time is evolving - new collector types have been added like Histogram and Summary!
- as our metrics and JSON-RPC endpoints mature, we've realized we need a production-ready HTTP server to serve those requests. The standard one in Nim isn't up to par and our implementations have been "good enough" so far, but now we're ramping up efforts to get a dedicated one out.
- last time we mentioned Nimplay - a Nim-flavored language for EWASM smart contracts. We have a proof of concept now: a simple Web3 page for interacting with the EWASM-deployed King of the Hill contract! Check it out here - once you switch your Web3 provider to the EWASM testnet, you'll be able to see all the players so far and the contract's source code.
Ethereum 1 progress
- we adopted the new bootnodes as advertised recently by Geth's 1.9 update so now Nimbus will default to them on first run.
- we fixed an ECRecover bug in our VM which now lets us run Nimbus in production mode past block 1.3 million (at a speed of ~400k per hour), which means we're slowly doing an archive sync from our Geth and Parity peers - all live, all production. It's becoming more and more likely that we'll be reading Ethereum 2 genesis information from Nimbus itself come launch day early next year 🤞
That's it for this week, we'll talk again soon! The Nimbus team will be in Berlin for a team meet next week (13th to 17th August) so if you want to chat, collab, or grab a beer and wurst, let us know!