MONET Technical Roadmap

This article aims to describe the goals and ambitions of Mosaic Networks and the MONET open-source project until the 4th quarter of 2019. It clarifies our objectives and which goals are part of those objectives. This article may serve as a reference for Code Bounty campaign participants and provide insight on the development of the project.

Deliverables

• Babble: our core blockchain BFT consensus engine.
• Mobile SDKs: Babble packages for Android and iOS.
• EVM-Lite: a light-weight EVM wrapper with a generic consensus interface.
• MONET Node: the software run by MONET validators, i.e. EVM-
  Lite with Babble and extra MONET-specific functionality.
• MONET Hub: the always-on blockchain that backs the Tenom token
  and offers optional services to the rest of the MONET ecosystem of ad-hoc
  blockchains.
• Client-Side Tools: a set of tools to interact with MONET nodes.

Versioning

We will use the “Semantic Versioning” system to dictate how version numbers
are assigned and incremented. Under this scheme, version numbers and the
way they change convey meaning about the underlying code and what has been modified from one version to the next.

Guiding Principles

Our guiding principles are modularity, simplicity , testing and documentation. Every new feature among the list provided below should be implemented with these principles in mind. In particular, unit tests and documentation will
accompany any significant contribution.

Change Log

This article will be updated as we change our minds about the necessity or appropriateness of certain items

10/05/18

• Added MONET Hub to the roadmap

02/04/18

• Removed TLS objective. We will handle encryption using the same primitives and keys as the core
• Added objective to change consensus functions

03/08/18

• Drop monthly cycles as they are not flexible enough for the type of work
  ahead of us (research, not handle-turning tasks)
• Define the seven deliverables
• Strike-through some items in Blockchain Interface goal as they are imple-
  mented in v0.1.2
• Add CheckTx and gRPC items to Babble Blockchain Interface goal
• Strike-through Mobile Package goal. Implemented in v0.1.2
• Update FastSync implementation plan to reflect what has been done in
  the dev branch
• Remove the weighted voting requirements from the Dynamic Membership
  Protocol goal
• Remove the Change Consensus Methods goal; we are sticking to our interpretation of Hashgraph
• Rename Mobile Demo goal to Mobile SDKs, and update implementation
  plan to account for recent work
• Introduce EVM-Lite objective
• Update EVM-Babble objective in light of EVM-Lite and completed work
• Introduce MONET Node objective

17/10/18

• Update architecture diagram
• Update Babble section to reflect recent work: Inmem proxy, and major changes to config and peers management. Setting the stage for Dynamic Participants work.
• Strike-through EVM-Lite Generic Consensus Interface goal. Dropped plan to integrate Tendermint and plugged Hashicorp/Raft instead, demonstrating that the underlying consensus system is not necessarily a Blockchain.
• Update EVM-Lite HTTP API plan.
• REMOVE EVM-Babble goal. It is now an integral part of EVM-Lite and the EVM-Babble project is deprecated.
• Strike through task of deploying small testnets. The EVM-Lite repo contains scripts to automate the deployment of testnets locally (with docker) or in AWS.
• Strike-through first tasks in EVM-Lite Node.js client libs, and added a couple of items.
• Updated EVM-Lite CLI objective to reflect recent and future work

27/02/19

• Strike-through FastSync objective.
• Strike-through Dynamic Membership objective.
• Update Implementation Plan for Mobile SDK Demo objective with WiFi Direct, Dynamic Membership, and iOS developments.
• Add an important objective for Snapshot/Restore in EVM-Lite section.
• Strike-through TENOM objective in MONET section.
• Add a new goal for PoA in MONET NODE section.
• Strike-through client JS libs objective.
• Strike-through MONET Wallet objective.

17/07/19

• Strike-through PoA objective.
• Update Implementation Plan for Babble Blockchain Interface objective with task to “merkelize” the block structure.
• Update EVM-Lite-CLI objective with completed task to integrate PoA commands.

Objectives for the 4th quarter of 2019

Babble

Babble, the first component of the Mosaic Networks suite, is a pluggable soft-
ware component that provides BFT Consensus to applications written in any programming language. It was initially based on the Hashgraph consensus algorithm which is particularly suited for mobile deployments due to its low networking overhead. Our objective is to improve on the current codebase and add critical features to support our vision of mobile ad-hoc blockchains.

1. Blockchain Interface

• Goal

Map Hashgraph Events onto a linear chain of blocks as they come out from
the core algorithm in consensus order. Blocks will contain a header and a list
of transactions in consensus order. A block header contains the application’s
state hash, resulting from applying the block’s transactions sequentially. The
application consumes blocks directly, ignoring the underlying Hashgraph details.
Block signatures, gossiped by piggy-backing on the hashgraph routines, offer a trivial block verification mechanism.

• Success Criteria

The resulting Blockchain contains transactions in the correct consensus order.
Signatures are gossiped and appended to Blocks as part of the normal hashgraph messaging routines.

Implementation Plan:

• Design the new Header, Block and Blockchain data structures — Achieved
• Extend the Store interface to handle these new objects — Achieved
• Project Hashgraph Events onto the Blockchain as they come out of
  the core consensus methods — Achieved
• Update the Proxy API so that Babble commits Blocks to the App — Achieved
• Sign Blocks, gossip, and collect signatures — Achieved
• Implement Inmem proxy — Achieved
• Document new interface and breaking changes — Achieved
• “Merkelize” the block structure. Hashes should be obtained from Merkle trees rather than hashing a flat JSON encoding
• Implement a light-client
• Add CheckTx method
• Look into gRPC

2. Package for Mobile SDK — Completed

• Goal

Create a babble/mobile package with a wrapper around the Node object to
expose functionality to native mobile apps. This package will ultimately be
compiled into the mobile SDK using the gomobile tool.

• Success Criteria

The SDK and language bindings produced from this package and gomobile are usable from native Android and iOS applications. They allow the application to start a Babble node with a specific configuration, submit transactions, and receive committed results from the node.

Implementation Plan:

• Design a satisfactory interface between the Node object and Java or
  Objective-C clients. Consider configuration options, how to submit
  transactions and how to receive committed objects (Blocks, Events
  or Transactions) — Achieved
• Create a wrapper around the Node object that will generate the
  appropriate bindings when run through the gomobile tool — Achieved

3. FastSync — Completed

• Goal

Create a mechanism whereby a node that fell behind can catch up with the tip of the Hashgraph without having to sync all the Events that it missed.

• Success Criteria

Test with docker demo that a node that was stopped for a long time can join
the network, execute the fast-sync routine automatically upon detecting that
it is too far behind, and proceed with the regular babbling routine once it has
caught up with the tip of the Hashgraph. Ensure that the solution does not
undermine the BFT guarantees of Hashgraph.

Implementation Plan:

• Introduce concept of Frames — Achieved
• Include FrameHash in Block header — Achieved
• Implement FastForward methods in core — Achieved
• Implement FastForward methods in node — Achieved
• Document the solution and prove that it does not undermine the
  BFT properties. — Achieved

4. Dynamic Membership Protocol — Achieved

• Goal

Enable the list of peers to change as participants join and exit a network.

• Success Criteria

Robust end-to-end tests demonstrate the workability of our solution. Practical
tests on live networks indicate the effectiveness of joining and leaving without
undermining the rest of the network or affecting the user experience.

Implementation Plan:

• Refactor config/peers management — Achieved
• Update the core consensus methods to use a dynamic list of partici-
  pants. — Achieved
• Define the interface between Babble and Application that enables
  dynamic changes to the peers list. — Achieved
• Create a special type of transaction for Entry/Exit requests that
  gets intercepted by Babble and handled in a special way. This is a
  non-standard type of transaction because Babble does not read and
  interpret normal transactions. — Achieved
• Extend the proxy interface with a method to interrogate the application if an JoinRequest should be accepted. — Achieved
• Monitor the transaction until it reaches consensus and approval by
  +1/3 of participants and update the participant list accordingly. — Achieved

Click here to back to deliverables list in the beginning of the article.

Mobile SDKs

The mission statement that binds the community around the Mosaic Networks open- source project is centered around the idea of dynamic ad-hoc blockchains running on mobile devices. We will stay close to this goal by producing and maintaining workable SDKs (Android first, then iOS) as well as one or more demo apps.

1. Demo

• Goal

Demonstrate a Babble network composed of mobile devices running a basic
application (eg. chat or game). Devices will be able to join from different
networks and the list of participants will be dynamic.

• Success Criteria

The distributed application runs seamlessly even as participants join and leave the group and different networks are involved. Participants receive the same transactions in the same order and their experience is consistent.

Implementation Plan:

• Produce the Babble Android library based on the babble/mobile package
  and_gomobile_ — Achieved
• Implement a simple Android application demonstrating the value of the
  distributed state machine — Achieved
• Create a mechanism for dynamically generating an initial peers.json file with the public IPs and public keys of the initial participants and dis-
  tribute the file to all nodes:

– using QR codes — Achieved

– using WifiDirect — Achieved

• Create a mechanism to request joining or leaving an existing network — Achieved
• Support dynamic IP changes

2. Android SDK

• Goal

Produce an Android SDK for other developers to adopt Babble in their appli-
cations.

• Success Criteria

The SDK exposes all the necessary, reusable, functionality enabling other de
velopers to integrate with Babble. These developers need not know anything about Blockchain or consensus; just plug and play. The abstraction should be
compatible with state of the art design patterns (MVC).

Implementation Plan:

• Refactor the demo application to decouple the application logic from
  the Babble logic
• Group the Babble logic into a separate Android package
• Document the SDK (API + How To Guide)

Click here to back to deliverables list in the beginning of the article.

EVM-Lite

EVM-Lite is a spin-off of EVM-Babble (which is now deprecated), where the EVM is completely decoupled from the underlying consensus system. With Babble, it is the second main product in Mosaic Networks’ suite of open-source modular blockchain software.

1. Generic Consensus Interface — Achieved

• Goal

Make EVM-Lite compatible with a broad range of consensus systems, not just
Babble.

• Success Criteria

Integrate Tendermint ABCI and Babble

Implementation Plan:

• Refactor EVM-Babble to decouple Babble — Achieved
• Create separate repo — Achieved
• Integrate Solo consensus — Achieved
• Integrate Raft consensus — Achieved

2. HTTP API

• Goal

Expose an HTTP API to interact with the EVM’s state

• Success Criteria

A working and well documented API exposing relevant functionality

Implementation Plan:

• Extend/refactor current EVM-Babble API

3. Snapshot/Restore

• Goal

Implement Babble’s Snapshot/Restore interface to enable FastSync.

• Success Criteria

Nodes can come in and out of a EVM-Lite/Babble cluster, and fast-sync to the
appropriate state.

Implementation Plan:

• Define EVM Snapshots of State Trie
• Implement BabbleProxy functions for Snapshot/Restore

Click here to back to deliverables list in the beginning of the article.

MONET Node

This is the software powering a MONET validator node on the Hub; a combination of EVM-Lite, Babble, and MONET-specific functionality. We shall release Docker images and binaries for every significant update, and ensure that validators stay up to date with the latest releases leading up to the mainnet launch.

1. Tenom Token — Achieved

• Goal

Implement Tenom, MONET’s native token, on top of EVM-Lite, with sup-
port for a Genesis block defining pre-set accounts.

• Success Criteria

Accounts are implemented on the built-in EVM account model, which enables
reusing the same key format and key-management software; everything happens as if using Ether. Presale accounts are created and credited in a Genesis block.

Implementation Plan:

• Use EVM’s built in account model — Achieved
• Create a genesis Block with predefined accounts — Achieved

2. Block Rewards

• Goal

Implement the logic that generates and distributes block rewards to validators
(without weights at this stage). The block rewards are themselves composed of built-in emission and transaction fees. 50% to validators and 50% to Reserve.

• Success Criteria

The built-in emission and transaction fees are correctly calculated at every new block. Validator accounts get credited a proportion of the block rewards after every block commit. 50% of the block rewards get credited to a Reserve Smart Contract.

Implementation Plan:

• Create a Reserve SmartContract as part of the Genesis block (it can be
  empty at this stage)
• Implement built-in emission
• Find link between EVM and transaction fees. Rewire this logic to channel
  transaction fees towards block rewards
• Distribute rewards to validators and reserve SmartContract. Keep it extensible because we will introduce weights later

3. Proof-of-Stake

• Goal

Introduce Proof of Stake based on Tenom. Validators Bond Tenom and earn
a proportional share of block rewards. The PoS logic is implemented in a set
of SmartContracts that ship with the MONET node (like the Reserve). When Babble’s dynamic Membership Protocol is ready, the PoS system become dynamic too.

• Success Criteria

Ascertain the link between the MONET validator set and Babble’s peers list.
Unbonding and Slashing logic works in live scenario (including testnets).

Implementation Plan:

• Further specify and document the PoS logic
• Write a set of SmartContracts to control the list of validators and their
  ‘bonded stakes’ (bonding, unbonding, slashing)
• Link between this SmartContract logic and Babble participant set
• Update Block rewards to distribute rewards proportionately to stake
• Add support for dynamic validator set
• Delegated PoS

4. Proof-of-Authority

• Goal

Implement a PoA mechanism to link Babble’s membership protocol with a SmartContract, as an alternative to PoS. The List of Babble members is
controlled by existing members through the SmartContract (adding/removing validators).

• Success Criteria

Members can add/remove public-keys from the PoA SmartContract, thereby controlling the underlying Babble peer-set.

Implementation Plan:

• Write PoA SmartContract. Controls the whitelist of public-keys forming the Babble peer-set. Adding/removing an item requires a majority of votes from existing members. — Achieved
• Link Babble’s handling of InternalTransactions to the SmartContract. JoinRequest are only accepted if the corresponding public-key is in the whitelist. — Achieved

5. Interoperability (IBC)

• Goal

Draft a first version of the IBC protocol. Provide tools (Light-Client SmartCon-
tract template, IBC Packet creator) to demonstrate the protocol in practice.

• Success Criteria
End-to-end tests for proving on one Babble chain that something happened on another chain. The protocol should be flexible enough to eventually accommodate other platforms (Ethereum, Cosmos, Polkadot, etc).

Implementation Plan:

• Define IBC packets
• Babble light-client template
• Demo

6. Peer Discovery

• Goal

Implement a peer-discovery service in a SmartContract that ships with MONET by default. This service is open to all; anyone can advertise a service and peer-info.

• Success Criteria

Integrate with a demo app using this solution as a Peer Discovery mechanism.

Implementation Plan:

• Simple SmartContract
• Web API bindings
• Integrate with mobile SDK and demo app

7. STUN/TURN

• Goal

Incorporate a STUN/TURN server to MONET Node. This service enables NAT
traversal when peers are behind NATs.

• Success Criteria

Integrate with a demo mobile app.

Implementation Plan:

• Research existing solutions
• Deploy side-by-side with EVM-Babble
• Link with Peer Discovery service
• Integrate with mobile SDK and demo app

Click here to back to deliverables list in the beginning of the article.

MONET Hub

As described in the MONET whitepaper, the Hub will be a public utility
blockchain, powered by EVM-Babble, offering infrastructure services for the
rest of the network, as well as a SmartContract platform hosting non-transient
logic. Very early, we will deploy a testnet consisting of a few nodes, starting
on AWS, which shall be extended and updated as we make progress with the
roadmap; this will serve as a playground before deploying the production Hub.

1. Testnet

• Goal

Setup a staging environment to test new releases of the MONET Node and
other tools. The idea is to get third-party validators on board early, help them
install the software and familiarize themselves with the process of operating a
MONET node.

• Success Criteria

Each iteration of the testnet will have different success criteria until all the features described in the whitepaper are correctly implemented. The main objective is to battle-test the MONET Node and network against common or exceptional scenarios (software updates, adding/removing validators, slashing defective validators, planning hard forks, delegated proof of stake, etc.).

Implementation Plan:

• Deploy a small testnet on AWS — Achieved
• Bring in third parties
• Roll out updates as they come out
• Simulate Tenom allocation and validator stakes
• Design test scenarios/ requirement before validating Mainnet
• Work towards meeting these requirements iteratively

2. Mainnet

• Goal

Deploy live MONET Hub with real Tenom token and services as described in
the whitepaper.

• Success Criteria

Stable, all governance and emergency procedures are known and tested.

Implementation Plan:

• Follow plan defined in the testnet phase
• Publish a stable release of all the software involved (Docker images and
  binaries for various platforms)
• Coordinate fist set of validators for launch
• Launch

Click here to back to deliverables list in the beginning of the article.

Client-Side Tools

Tools to interact with EVM-Lite and ultimately MONET node.

1. EVM-Lite Node.js libraries

• Goal

Create a reusable library with all the logic to interact with an EVM-Lite node.
This will be used by all the other clients.

• Success Criteria

The library can be imported into any javascript/node.js project to invoke operations on an EVM-Lite node. Presents the right level of abstraction to work with accounts and SmartContracts.

Implementation Plan:

• Refactor code from current EVM-Babble demo — Achieved
• Create a separate repo and Node.js package — Achieved
• evm-lite API client — Achieved
• SmartContract abstractions — Achieved
• Full Wallet functionality — Achieved
• Event Subscribe for sync/async transactions

2. CLI for EVM-Lite

• Goal

Command Line Interface to talk to an EVM-Lite node.

• Success Criteria

The CLI allows performing a wide variety of operations on the node:
Query/manage accounts, send transactions (signed or unsigned), Deploy/Call smart contracts, Query blocks.

Implementation Plan:

• Simple wrapper around Node.js libraries — Achieved
• Accounts: list, create — Achieved
• Transfer (local signing) — Achieved
• Transaction management — Achieved
• PoA commands — Achieved
• Event subscriptions
• SmartContracts

3. MONET Wallet — Achieved

• Goal

GUI wallet for MONET.

• Success Criteria

The wallet offers all the functionality to create/manage a MONET account (denominated in Tenom), create a deploy new SmartContracts, and inter-
ract with MONET built-in SmartContracts (Governance, Peer-Discovery, Staking/Bonding, Managing/Viewing reserve governance).

Implementation Plan:

• Create Electron application that uses our client JS libraries and does everything the CLI does.

4. MONET Dashboard

• Goal

Web interface to monitor the state of MONET Network

• Success Criteria

Interface is configurable (can point it to different networks), displays relevant
information that allows to monitor the health of a network, assess the behavior of different validators to support delegators in choosing who to delegate to. This tool should help us ‘test’ our testnets moving towards mainnet.

Implementation Plan:

• Write a web-service in the middle to aggregate info from all nodes
• Build a UI to consume and display the info produced by web-service

Click here to back to deliverables list in the beginning of the article.

We encourage talented developers and engineers to participate in the Code Bounty Campaign and contribute to the open source project that we are aspiring to build!