MONET Development Update (07/19)

We completed the PoA milestone which was the last major requirement before kicking off the first MONET testnet. In the process we made some important improvements to Babble, EVM-Lite, and wallets. All this work is concentrated in monetd which is the server process for a MONET node. We also created an iOS version of Chatterbox, and leveraged Babble’s Dynamic Membership protocol to improve the user experience when creating and joining chats.

monetd

Monetd is the program run by validators on the MONET Hub. It is a smart-contract platform based on the Ethereum Virtual Machine, powered by our Babble consensus engine. Technically a wrapper around EVM-Lite, monetd has a dedicated repository, and documentation.

In the first rollout of the MONET Hub, the set of validators involved in consensus is governed by a whitelist in a Smart Contract that ships with monetd. The whitelist dictates who is allowed to become a validator and can only be amended via a voting process. We call this process Proof of Authority, although it is sometimes used with a different meaning by other projects. Please refer to this document for a longer explanation of our design choices.

To become a validator, and participate in the testnet, one must be added to the whitelist, and run monetd to join the network. We will start by reaching out to partners directly, but if you are interested please give us a shout on Slack or Telegram.

To access the testnet as a user or validator, we recommend using our CLI client, evm-lite-cli. It offers convenient functionality to generate keys, transfer coins, deploy smart-contracts, and participate in the PoA system. That being said, the idea of using the Ethereum Virtual Machine is that you should also be able to leverage existing tools from the Ethereum ecosystem.

Babble

We made major improvements to Babble while implementing PoA, particularly regarding FastSync and DynamicMembership. The node state-machine has changed, and some breaking changes were introduced since the last release. Below is a list of the most important changes in v0.5.0:

Babble used to FastSync automatically upon receiving a limit response from a peer. Now, the decision to FastSync or not is made only once, upon starting a node, based on the — fast-sync config value. The — sync-limit parameter governs the maximum size of a SyncResponse or EagerSyncRequest, but does not affect the FastSync protocol.

We also made some major improvements to the core FastSync algorithm. In particular, a major redesign of the Root data-structure, which simplifies the process considerably, and enabled us to remove an important chunk of intricate code, all the while increasing the robustness of the overall system. After 8 months of testing since the last dev update, we are ready to merge into the master branch.

Please refer to the FastSync document for more detail.

In this release, we have finally merged the Dynamic Membership code, which had been in the develop branch until now. We rectified an important theoretical mistake concerning the round at which changes to the validator-set can take effect: from R+4 to R+6. We also implemented the Leave functionality, which enables a node to politely leave a network by requesting to be removed from the validator-set.

We also refactored the concept of InternalTransactions, which are special transactions that govern changes to the validator-set. They are now immutable objects signed by the joining/leaving peer, and verified by all validators upon inserting an Event. The decision made by the application as to accept or refuse InternalTransactions, is recorded in InternalTransactionReceipts, which are part of Babble blocks.

The joining process has changed slightly, and we introduced the peers.genesis.json file to differentiate the initial and current peer-sets. The genesis peer-set is necessary for a node when it joins an existing network without fast-forwarding because it has to replay the entire hashgraph, which might have been started with a different peer-set than the current one.

The Bootstrap process is not automatic anymore. It is governed by the — bootstrap flag which tells babble to load itself from an existing database if it exists. If the — bootstrap flag is not set, and the — store flag is set, babble will create a backup of the existing bader_db and create a new one.

Regarding cryptographic keys, we switched from using the P256 curve to secp256k1, like Ethereum and Bitcoin. This will facilitate the creation of light clients in EVM because we can now easily verify Babble signatures in Smart Contracts. Also, validators can reuse the same keys in Babble and EVM-Lite, which is necessary for PoA and eventually PoS.

Chatterbox

A big development on the mobile front has been the release of an iOS version of Chatterbox. This is fully compatible with the Android version at the Babble layer, meaning that the consensus protocol works as expected on both. As with the Android version we’ve used our Go version of Babble and compiled it to an iOS library. Unfortunately iOS does not support WiFi direct, so we reverted to using fixed networking infrastructure, namely regular WiFi. However to smooth the discovery process we’ve implemented mDNS on both Android and iOS. This allows seamless discovery of Babble groups across both platforms.

The dynamic membership updates in Babble allowed us to simplify the process of creating and joining groups. Whereas previously some orchestration was required to collect group members, now a new group is initiated with a single member and other members can dynamically join this group, thus completely removing the overhead of collecting group members before starting a chat.

We’ve also begun work on the Babble Android library, which will allow developers to easily integrate Babble into their own apps. We hope to open source this in the next few days, we’ll say much more about this in our next dev update.

What’s Next

In the coming weeks, we will start the first MONET testnet. We will reach out to partners to operate validator nodes, and encourage the community to use the client-side tools to test out the platform.

In terms of development, the next items on the roadmap are to implement a Babble light-client in a smart-contract template and a Babble Android Library in order to enable other developers to use Babble in their apps.

Stay tuned!