Massbit Route

• Team Name: Codelight
• Payment Address: 0xD068C7E05CF20fcEE618C8F9207e019020c62F35
• Level: 2

Project Overview 📄

Overview

• Codelight team's vision is to build a decentralized, user-operated, and governed Blockchain Distribution Network. To achieve the goal, we build Massbit blockchain on Substrate framework, with MBT token to create an economy, where Node Providers stake and earn Massbit token for servicing the BDN and Consumers pay in token for global access to decentralized blockchain APIs.

• The majority of existing dApps are utilizing blockchain Infrastructure-as-a-Service (IaaS) such as Infura or GetBlock to shorten the time to bring their products into production. Those blockchain IaaS services have gained traction quickly and contributed to the growth of many layer-1 and layer-2 blockchain networks. But that added value comes with downsizing that many "dApps" rely on a centralized blockchain IaaS service and are prone to outages caused by IaaS providers. Massbit Route eliminates blockchain API single-point of failure by forming a global network of Independent node providers to allow dApps access to the nearest blockchain data source with optimal response time.

Project Details

Architechture Overview

• Massbit Route is a blockchain distribution network (BDN) operated and governed by users all over the globe. It provides decentralized applications access to different blockchain APIs by routing request network traffic to a blockchain node with optimized response time. In addition, Massbit Route is built to provide performance-optimized access to blockchains and aims at eliminating blockchain API single-point of failure by forming a global network of independent Node Providers. We build a network operated and serviced by users that provide fast and redundant access to blockchain sources. Massbit Route facilitates a network of Gateways and Nodes infrastructure in 6 different zones around the world:

  • Asia
  • North America
  • Africa
  • Europe
  • South America
  • Oceana

• Users can join the Massbit network as Providers from any of those regions by running Massbit Nodes and Gateways connected to blockchain data sources such as Ethereum or Polkadot. As the Massbit network grows in the number of Nodes and Gateways as well as independent node providers, the network becomes highly available and redundant. When a Provider experience an issue with their nodes, blockchain API requests will be served by other Providers, which eliminates single-point-of-failure in Web2 CDN architecture.

Components

| 1. Massbit Core

• Massbit Core (MC) is the orchestrator of the entire Massbit network. New Nodes and Gateways that need to join Massbit network can obtain installation script and network configuration generated by MC.

• MC works along with other components to onboard new Gateways and Nodes onto the Massbit network, and make sure traffic is routed by Gateways and Nodes effectively. When Providers need to operate Nodes or Gateways in the Massbit network, they need to obtain a set of instructions created by the MC from the Portal for their servers. By executing the instructions in the form of a bash shell script, the server will negotiate with MC and Verification Service if it is qualified to participate in the MassBit routing network. Once a Gateway is successfully verified in the Massbit network, MC provides a list of dAPI entry-points and Nodes in the same zone the Gateway needs to server request and forward traffic respectively.

• As the Massbit Route network grow globally and blockchain traffic needs to be directed optimally, MC constantly updates Gateways with a set of traffic routing and handling instruction to adopt a change within the Massbit network. For example, when some nodes in a zone go offline, new nodes are added or Consumers adjust the request rate for dAPI entry-point, MC generates a new set of configurations for all of the Gateway in the zone.

| 2. Gateway Manager

• Gateway Manager the DNS component of Massbit network based on the opensource project gdnsd. It runs as an authoritative DNS system of the Massbit network, and can be seen as a directory for all Community Gateways and Nodes around the world.

• When a dApp queries blockchain API through a Massbit dAPI entry-point, it needs to lookup the IP address for the dAPI entry-point through their configured recursive DNS servers. If the recursive DNS servers do not have the entry for the dAPI entry-point, they will perform an authoritative lookup to Gateway Manager. With geographic IP capability, Gateway Manager resolves the DNS lookup with the IP of the Gateway closest to the requesting dApp based on the source IP in the request Header.

• A dAPI entry-point URL has the following format:

https://[API ID].eth-mainnet.massbitroute.net/[API key]
wss://[API ID].eth-mainnet.massbitroute.net/[API key]

• The host portion in the dAPI URL is a dynamic DNS entry in Gateway Manager. The resolved IP in the authoritative response by Gateway Manager will vary depending on the source IP in the request Header.

| 3. Session Manager

• When a dAPI entry-point is created by Consumer, a dynamic DNS entry is created by Gateway Manager and resolved to the nearest Gateway IP based on the source IP in the request header. Once traffic reaches a Gateway, in order to accept the API request from Consumers, it needs to obtain a dAPI session key from Session Manager. The session key is only valid for a certain amount of time and will be renewed for the dAPI entry-point if needed.

• In addition, Session Manager also controls the usage of the dAPI entry-point. Consumers need to deposit MBR tokens for the dAPI entry-point in advance to pay for the cost of dAPI usage. Depending on the amount of MBR deposit, Consumers will receive a corresponding quota for dAPI usage. Session Manager will inform if a dAPI entry-point is out of quota and Gateways will block incoming request until more MBR token is funded for the dAPI.

• Session Manager also prevents malicious actors from bypassing dAPI payments and sending blockchain requests directly to Gateway public IP. Without a valid session key and a dAPI entry-point, Gateways will reject the requests destined to their public IP. This will maintain the security of the network and form a building block for Massbit Route token comic.

| 4. Stats

• Stats collects telemetry from all verified Gateways and Nodes in the Massbit network. The service provides different metric data to allow the Portal to visualize Nodes and Gateway performance with charts. In addition, it calculates and keeps track of the available quota for each dAPI based on the amount of MBT token deposit.

| 5. Fisherman Pallet - Decentralized Node Verification Service

• Massbit Route becomes a faster and more reliable BDN when the number of Community Nodes and Gateway increases. For that reason, Nodes and gateways need to meet certain bandwidth and latency requirements checks by Fishermans in order to be part of Massbit global network. Fisherman Pallet is an Off-Chain Woker that is included with the Massbit Gateway installation script. The more Massbit Gateways are deployed, the more decentralized this service become, which make the process of node/gateway onboarding un-biased.

• When a Node requests to join the Massbit network, nearest Fishermans checks if the Node is able to forward requests to its blockchain data source and return results matching with the blockchain data source such as block data, block hash, and runtime version. If all checks passed the validation process, the node becomes a part of the Massbit network and gets ready to receive traffic from Gateways in the same zone.

• In each zone, a minimum of 1 Node is required in order for a Gateway to be verified. Without any Node or blockchain data source, it is unnecessary to run a Gateway in that zone because it introduces some routing overhead, and traffic will eventually be routed to the nearest zone.

• When a Gateway needs to join the Massbit network, Fisherman will validate if the Gateway has obtained a list of Node in its zone from Massbit Core and whether it can proxy traffic to the Nodes properly. If blockchain data returned by Gateway is correct and match with data from the Node and blockchain data source in that zone, the Gateway is verified and its public IP is updated in the Gateway Manager directory.

| 6. Massbit Route blockchain

• Building on the Substrate framework, the Massbit chain is a source of truth for token-related activities in the Massbit network. Massbit Consumers need to pay fees in MBT tokens in exchange for global dAPI service. In return, Providers earns rewards from Consumers' fee for handling blockchain API requests and maintaining the stability of the network. Through the Massbit chain, anyone can verify Providers' and Consumers' activities with the following pallets:

• Provider/Delegator activities Pallet

  • Staking/Un-staking amount on each Node/Gateway
  • Reward calculated after each Era from Consumer fees ​
  • Reward claim history ​
  • Node/Gateway State reported by Fisherman ​
  • Node verified duration eligible for staking reward​
  • Provider Wallet and transactions
  • Staking/Un-staking amount on delegated Node/Gateway

• Consumer activities Pallet

  • dAPI deposit fee
  • dAPI remaining quota based on past usage on the deposit fee
  • Consumer wallet and transactions

| 7. Portal

• Portal is the user interface of Massbit Route that allows user to user to perform the following activities:

  • Create/stake/unregister Nodes and Gateways
  • Obtain the installation script for Nodes and Gateways
  • Claim reward for Nodes and Gateways
  • Visualize traffic of Nodes, Gateway, and dAPI entry-point
  • Create dAPI entry-point and view the quota
  • Deposit fee for dAPI

• Below is the first version UI of the Massbit Web Portal

Massbit Route Home Page

Massbit Gateway List

Massbit Gateway Detail

Massbit Node List

Massbit Node Detail

dAPI detail

| 8. Community Gateway

• Gateways are entry-points to the Massbit network, which receive blockchain API requests from dApps. It keeps a list of verified Nodes in the same zone, and forward requests to those nodes. It also stores static content of blockchain requests to reduce the response time for identical requests that come in later
• Utilizing Open Resty framwork, Gateways are repsonsible for blockchain traffic within each zone. The robust functionalities of Open Resty framework allows advanced and efficient routing capabilities for Massbit dAPI entrypoints including:
  • Load Balancing for multiple Node-as-a-Service enpoints like Infura or Getblock
  • accepting blockchain requests from dAPI entrypoints
  • Rate limiting
  • Geo IP detection and routing for optimal response time
  • Edge caching
  • Routing to only functional Upstream servers (Massbit Node)

| 9. Community Node

• Community Nodes receive requests from upstream Community Gateway and forward them to the attached blockchain data source. In addition, it works with Massbit Fisherman to make sure the data source is available and synchronized with peers before it can receive new blockchain API requests from Gateways.
• Also utilizing Open Resty framework, it acts as one of the Upstream Servers for all of the Massbit Gateways in the same zone, and forwards traffics to its own blockchain data source.
• Node Providers can make their own decision whether to run Massbit Node and blockchain RPC node on the same host/server or different ones.

Traffic Routing Mechanism

• In the Massbit network, Gateway Manager, Community Nodes and Community Gateways form a global blockchain CDN network in order to optimize blockchain API request and response time.

• Based on the public IP of each community-run Node and Gateway, a global geographic map of verified and staked Gateways is continuously updated. When a dApp sends a blockchain API request through Massbit Route API Entrypoint created by a Consumer, based on the global network IP map, the request is forwarded to a Gateway in which its zone is the same or closed to the request source IP.

• Each Gateway constantly updates Massbit Core to maintain a list of verified Node in its zone. From the gateway, the request is then forwarded to one of the nodes in the same zone in a round robit fashion. A node will will then relays the request to the blockchain data-source associated with the node.

• When a node or gateway experiences issues such as poor CPU, memory, and network performance which result in high latency and response time, it will be deregistered from the Massbit network by Fisherman. Only nodes with "staked" status in the Massbit network can serve API requests and earn token rewards to guarantee the stability of the entire network.

• Because Massbit Gateways, Nodes, and blockchain source nodes are operated by independent providers, single-point of failure is eliminated. Fisherman ensures DNS entries of offline or malfunctioned Nodes and Gateways are removed from the network and make sure blockchain requests are forwarded through active nodes, which maintains redundancy for the Massbit network.

Node Approval process

When a Node or Gateway joins Massbit, it needs to go through different states before it can serve dAPI traffics.

• Created: Node/Gateway information (name, zone, blockchain type that is served by this node, blockchain node IP) is registered with Massbit network. Based on the registered information, an installation shell script is generated for the new node.

• Installing: When the installation script is executed on a new server that needs to join the Massbit network, the status changes to Installing, and the public IP of Node/Gateway is recorded to the Massbit chain

• Verifying: When the installation completes on the new server, it will proceed with the verification process for eligibility to join the Massbit network. Fisherman will be mainly responsible for this stage by checking the following criteria:

Criteria	Detail
Data integrity	The node/gateway must return data identical to the blockchain data-source from which the response was retrieved. This will prevent man-in-the-middle attacks The blockchain data-source must be fully synchronized.
Performance	Node/gateway needs to satisfy 3000 requests/sec with a 500 MB/sec transfer rate for 95% of test requests

• Verified / Failed: If a node/gateway passes Verifying stage, it becomes "Verified" and is ready to be approved by Fisherman for staking and serving dAPI

• Approved: In each zone, based on the dAPI demand, Fisherman automatically will approve the node/gateway to join Massbit.

• Staked: After the node/gateway gets approved, the Node Provider needs to stake a minimum of 100 MBT tokens. Once the node/gateway is staked, it is ready to service the dAPI and earn token rewards.

• Reported: While nodes/gateways are servicing the network, Fisherman continuously checks for the network stability of each node/gateway. In case a node/gateway does not pass the check, it will be reported and eliminated from the Massbit network.

How does Massbit make sure that the nodes actually fulfil the Performance requirements?

• In Milestone 1, we place Fisherman in each regions to check the network performance of new Nodes/Gateways before joining Massbit network. By measuring Rount Trip Time and network bandwidth from it self to the new Node/Gateway, it makes decisions whether the new node is eligible for joining the network.

• We are aware that this approach has many drawbacks and the evaluation proccess is not fair for all new nodes. The first version of Fisherman is a prototype for us to test the functionality of all Massbit components together.

• In Milestone 2, Fisherman is modified to be more decentralized and more efficient. All Massbit Gateways have Fisherman component included, which is responsible for ensuring the neighbor Nodes and Gateways are functional. Each Fisherman talks to a Scheduler in its region and perform assgined tasks.

1. When a Node/Gateway needs to join Massbit network, the Schedulers requires all active Gateways in the network to measure Round Trip Time (RTT) and network bandwidth to the new Node/Gateway.
2. Based on the result of RTT and network bandwidth from active Gateways to the new Node/Gateway, if they satisfy the RTT and network bandwidth baseline, the new Node/Gateway is verified. The Node Provider can stake the new node with MBT tokens and serve traffic. In case of a new Node, it also needs to be able to forward test RPC requests to its attached blockchain datasource and returns back valid RPC response.
3. Once the new Node/Gateway is staked and actively serving traffic, the Scheduler will inform the Massbit Core to update the network configuration for the whole network with the new node. Based on measured RTTs and network bandwidth measure from each active Gateway to the new Node/Gateway:
   • The new Gateway will receive a new network configuration to pair and forward traffic to low latency/nearby existing Nodes
   • The new Node will receive a new network configuration to receive traffic from nearby Gateways
4. The previous process will repeat periodically to update Gateway and Node pairings with the most optimized paths and make sure the new Node/Gateway remain functional in the Massbit network.

• The specific values for ideal RTT and network bandwidth are to be determined as Massbit team needs to perform more benchmark and testing for further evaluation.
• The Scheduler is designed to assign multiple checks/tasks to Fishermans on active Gateways. Depend on our findings, more tasks may be added after our internal testing and during testnet phase.

How does Massbit system deal with denial-of-service (DDoS) attacks?

• Malicious actors will find a way to disrupt Massbit network in order to cause outage and interuption for Web3/DApp. For Massbit Gateways and Nodes, the only required open port is 443 to minimize the attack surface to Massbit network. What counter-measurements does Massbit implement to prevent this problem?

• Massbit Route is designed as distributed network of Nodes and Gateways. As Massbit network grows in the number of Nodes/Gateways in 6 different regions, high network load is scattered across different paths to reach a specific blockchain RPC node, which will reduce the network congestion and mitigate the effect of DDOS attacks.

• Protection at Node level:

  • Massbit nodes only need to receive traffic from nearby Gateways with low RTT and high network bandwidth. For that reason, HTTPS connections are only whitelisted for those nearby Gateways.

• Protection at dAPI level:

  • Attacker can obtain Massbit dAPI URL from Web3/DApps source code and perform volume-based DDoS at Layer 7 on the URL with the desire of saturating the bandwidth of the whole network. Each Massbit dAPI created has a default rate limiting configuration of 100 requests/sec which is applied on all Gateways that will be serving traffic for the specific dAPI URL. The consumers can adjust this number from the Web Portal based on their usage.

  • When the dAPI URL is called, the traffic is handled by a Gateway which is in the same zone as the requester's source IP. If the DDoS attack is lauched from many different botnets in a single or multiple Geo resgions to the dAPI endpoint, their traffic is served by multiple Massbit Gateways, which mitigate the impact of high-volume traffic. Once the request/sec threshold reaches on a Gateway, it start to refuses subsequent incoming requests. As a result, Massbit Gateways prevents volume-based DDoS traffic from entering Massbit network, and reaching underlying Massbit Nodes/RPC nodes. The more Gateways are deployed across regions, the better Massbit network sustain volume-based DDoS attack

  • The Fisherman component of the nearby Gateways periodically check its neighbor for liveness, and inform Massbit Core to update the routing/DNS configuration for the entire network to instruct healthy Gateways to serve incoming RPC requests within a zone. If a Gateway's resources are overwhelmed and can no longer serve request due to DDoS protocol attacks such as SYN flood, or IP spoofing, Massbit Core updates with Gateway Manager to stop resolving the host portion in the dAPI URL to the unhealthy Gateway. This will add redundacy and ensure Massbit network remain functional in the event of some Gatways are taken down due to DDoS attack.

  • The attacker can also create multiple Massbit dAPI entries to increase the attack surface, and amplify the magnitude of the attack. In order for the attacker's volume-based network traffic to penerate into Massbit network and reached Massbit Nodes and RPC nodes, they will need to deposit MBT token to their Massbit dAPI and receive a specific quota according to the deposit amount. If the dAPI quota reaches 0, Gateways stop serving traffic for the dAPI URL. This also discourage the attacker as there is cost involved in launching the attack, and the Node Providers earns reward for maintain the network.

• Protection at Gateway level:

  • The attacker can focus on a specific Gateway IP and perform a direct DDoS attack without using the dAPI URL.

  • At Layer 3 and 4, monitoring network health and anomaly detection is one of our team's primary focus for DDoS mitigation strategy. Each Gateway and Node will be installed with a monitoring client which will report network statistics, network flow and top talkers. Known DDoS attack patterns are rejected and alerted to our internal team's monitoring service with pre-configured patterns/rules such as certains IPs causing peaks in network, open connections and resource depletion.

  • Additionally, based on our observation, we can also implement a new traffic configuration policy, and allow Massbit Core to update the entire network of Massbit Gateways/Nodes to defend against malicious DDoS traffic. DDoS protection at Layer 3/4 for Massbit network is a challenging task with unexpected and sophisticated threats, so we will have to take both pro-active and re-active approach to keep the network healthy.

• Other counter-measurements:

  • Gateway Manager is also a crucial part of Massbit network as it the authoritative DNS component of the network. DNS components are prone to reflection and amplification attack, which accelerate the rate of malformed traffic to deplete the server resources. We will utilize existing third-party service with Deep Packet Inspection capability, DNS query whitelisting and rate-limiting to add a layer of defense and DDoS mitigation to this component.

  • Massbit Core and Massbit web portal are also placed behind a Web Application Firewall and Layer 3 Network Firewall to protect against DDOS and common web application attacks.

Tokenomic of MBT

• MBT tokens will be used within the Massbit network by Node Providers, dAPI Consumers, and Delegators. In order to join the Massbit network, Node Providers need to stake their Massbit Nodes and Gateways to become actively serving blockchain requests in Massbit. In return, Node Providers will receive MBT token rewards from serving requests from dAPI Consumers.

• The Consumers need to deposit MBT tokens to exchange for dAPI usage quota. The deposit amount is distributed to the Nodes Providers based on the amount of dAPI requests they served after each Era.

• In addition, anyone can delegate MBT token to actively running Massbit Nodes/Gateways to earn a small portion of the reward without the technical knowledge and effort to maintain Nodes/Gateways and RPC nodes.

• Our team is still expanding more detail for the Massbit token economy, which can be found in the this documentation

Project Technology Stacks

• Rust
• Substrate
• Node.js
• NGINX (Open Resty)
• Lua
• Docker
• Vue.js
• Polkadot.js

Ecosystem Fit

• Massbit Route is a decentralized network of Nodes and Gateways that route dApps requests to low latency blockchain nodes. Built on Substrate framework, we would like to create a diversified network of independent blockchain RPC nodes and Web3 applications that are servicing each other.

• Within the ecosystem, by using Massbit tokens, independent individuals, groups, communities, or organizations can freely join and get reward for servicing the BDN network by running Node/Gateways. With Massbit Route dAPI, Web3/DApps will have reliable and cost-efficient access to a independent blockchain RPC nodes through Massbit routing and caching mechanism. There is no middle-man or single entity that controls the entire blockchain distribution network which will eliminate the majority of undesired service interuption or censorship that may happen.

• With a foundational software design and network routing structure of Massbit Nodes and Gateways, the upcoming integration with more layer-1 protocols, ETH layer 2 solutions, and other parachains become less of a burden in the near future. Once our team sees a demand for a new type of blockchain in the Massbit Route network, the implementation for the new blockchain integration can be done in a short duration. Our team commits to listen and support our community's needs to enrich the ecosystem and maintain the stability of the Massbit network.

Team 👥

Team members

• Name of team leader: Minh Doan
• Names of team members:
  • Tran Thanh Vu
  • Vu Viet Tai
  • Nguyen Anh Huy
  • Nguyen Manh Dat
  • Thien Tuong
  • Bui Tran Huy Hoang

Contact

• Contact Name: Hoang Bui
• Contact Email: hoang@codelight.co
• Website: massbit.io

Legal Structure

• Registered Address: Craigmuir Chambers, Road Town, Tortola, VG 1110, British Virgin Islands
• Registered Legal Entity: MassBit Solutions Ltd

Team's experience

• Tran Thanh Vu: Massbit Technical Product Manager - 9+ years experience working with high load systems, designing architecture systems, resolving problems in high performance, high availability, scalability, distributed system, and big data.
• Vu Viet Tai: Massbit Product Owner - Co-Founder of Appbike, experience in product management and Scrum development
• Nguyen Anh Huy: Software Engineer (Rust) - Doctor of Computer Science and Intelligent Systems - Osaka Prefecture University
• Nguyen Manh Dat: Software Engineer (Rust - Blockchain) - Software Engineer with past experience building large E-commerce platforms and Fintech product
• Nguyen Thien Tuong: Full-stack Software Engineer - Software Engineer with past experience building large E-commerce and logistics platform
• Bui Tran Huy Hoang: DevOps Engineers - Experience with deploying/scaling/automating Enterprise network infrastructure and application on Public Cloud

Team Code Repos

• Massbit Core: https://github.com/massbitprotocol/massbitroute
• Fisherman: https://github.com/massbitprotocol/massbitroute_fisherman
• Gateway: https://github.com/massbitprotocol/massbitroute_gateway
• Node: https://github.com/massbitprotocol/massbitroute_node
• Stat: https://github.com/massbitprotocol/massbitroute_stat
• Session: https://github.com/massbitprotocol/massbitroute_session
• Gateway Manager: https://github.com/massbitprotocol/massbitroute_gwman
• Massbit Chain: https://github.com/massbitprotocol/massbitchain

Team LinkedIn Profiles (if available)

• Tran Thanh Vu: https://www.linkedin.com/in/baysao/
• Vu Viet Tai: https://www.linkedin.com/in/viet-tai-vu-b83a1057/
• Nguyen Anh Huy: https://www.linkedin.com/in/anhhuy-nguyen/
• Nguyen Manh Dat: https://www.linkedin.com/in/nguyenmanhdat/
• Nguyen Thien Tuong: https://www.linkedin.com/in/tuong-nguyen-thien-83a33a194/
• Bui Tran Huy Hoang: https://www.linkedin.com/in/hoangtbui/

Development Status 📖

• Massbit Route team has completed the code base for the Massbit Route blockchain distribution network including:

  • Core API
  • Stats
  • Session manager
  • Fisherman and Verification service
  • Gateway Manager
  • Massbit Node
  • Massbit Gateway

• Through a network of Massbit nodes and gateways, Massbit Route is now supporting traffic routing to ETH and DOT blockchain nodes. We have tested the network internally with 150 Massbit nodes and gateways deployed in 5 zones. We came to the conclusion that, in each zone, each working Massbit node requires 4 Massbit Gateway to achieve a reponse time under 500 ms for a blockchain API request through dAPI entry-point.

• Currently, we are in Testnet with a target of 100 independent user-operated Massbit nodes (each node attach to an ETH/DOT full node) and Gateways that span across 5 different zones. Through this testnet phase, we would like to introduce Massbit Route core functionality to professional and individual node providers as well as dApps partners that need cost-efficient and fast access to ETH/DOT blockchain nodes. Additionally, we take this opportunity to object real-world network traffic/usage to evaluate the following key points for further improvement in preparation for main-net launch:

  • The effectiveness of the blockchain traffic routing mechanism
  • Find out key metrics to adjust the fairness for the node approval process
  • Adjust the fee for dAPI usage and fair reward distribution to node providers who served the API request

Development Roadmap 🔩

Overview

• Total Estimated Duration: 2 months (only applied for the delivery scope of this project)

• Full-Time Equivalent (FTE): 6 FTE

• Total Costs: $50,000 USD

• We do not have an estimate for the actual cost and duration of this project, as we continue to integrate more blockchain projects, improve the performance/efficiency of the network, and building tools to support dAPI users.

Milestone 1 - Global Blockchain Distribution Network

• Estimated duration: 1 month
• FTE: 6
• Costs: $35,000

Number	Deliverable	Specification
0.a	License	Apache 2.0
0.b	Documentation	We will release a detailed official guides for node operation, routing mechanism, and Node/Gateway performance metric requirements on Massbit mainnet
0.c	Testing Guide	Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0.d	Docker release	We will provide docker files to simulate Massbit network that can be used to test all of the functionality delivered with this milestone
0.e	Article	We will publish an article that explains the technical details of Massbit Routing mechanism, Node/Gateway verification process and how individuals/communities around the world can run Nodes and Gateways and participate in service Massbit network
1.	Massbit Core Implementation (Lua)	We will implement Massbit Core which is responsible for ochestrating, generating installation scripts and routing configuration for all Nodes and Gateways within Massbit network
2.	Gateway Manager Implementation (C)	We will implement Gateway Manager as an Authoritative DNS server for Massbit network
3.	Fisherman - Node Verification Service (Rust)	We will implement the first version of Fishserman. This allows the Node/Gateway to be verified with Fisherman in each before join Massbit network
4.	Massbit Nodes and Gateway (Lua)	We will implement Massbit Node and Gateway with Open Resty framework. These components are responsible for routing API requests to RPC blockchain nodes nodes within each zone
5.	Web Portal implementation (Vue.js)	We will implement the front-end web portal to allow user interaction with Massbit such as creating new node/gateway and generate installation scripts, or staking and claiming token rewards
6.	Pallet Implementation for Consumer dAPI fee and reward distribution for providers	We will implement reward distribution from Consumer fee to Node providers based on the number of API requests served by each Provider.
7.	Pallet Implementation for Node Provider/Delegator staking and reward distribution	We will implement the Node/Gateway Staking feature for Providers and Delegators. In addition, the reward for each Node staking can be also claimed and sent to stakers' wallets

Milestone 2 - Implementation for substrate-based Massbit chain

• Estimated Duration: 1 month
• FTE: 6
• Costs: $15,000

Number	Deliverable	Specification
0.a	License	Apache 2.0
0.b	Documentation	We will release a detailed official guides for node operation, routing mechanism, and Node/Gateway performance metric requirements on Massbit mainnet
0.c	Testing Guide	Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0.d	Docker release	We will provide docker files to simulate Massbit network that can be used to test all of the functionality delivered with this milestone
0.e	Article	We will publish an article that explains the usage of MBT token for dAPI and Node/Gateway staking, the reward distribution mechanism, and the Node Provider incentives to increase the number of Nodes and Gateway for high-traffic zones in Massbit Route network
1.	Fisherman Pallet - Collect Provider Performance Oracle	With performance metrics observed from testnet, we will use Subtrate Offchain Worker to allow the community to operate this component under the Proof of Authority concept. This will provide an unbiased, fair and decentralized Node Approval Process as Fisherman is no longer a single component in each zone controlled by the Massbit team. Active Gateways are also automatically update to include this component
2.	Session Manager (Rust)	We will implement Session Manager to control and grant session keys to Massbit Community Gateways
3.	Node Provider staking Pallet - Provider incentive pot	At the early stage of the Massbit network, the number of Consumers will be low, which leads a small reward for Node Providers. The Provider Incentive Pot is a module with 10% of the total token supply locked and will be allocated 0.01% of the remaining balance for each Era to incentivize Node Providers to maintain network service.
4.	Stats and monitoring system implementation	We will implement a metric collection module to observe traffic and network performance to make improvement/adjustment to routing mechanism, Consumer dAPI as needed

Future Plans

• Our testnet phase is currently open to let our community experiment with Massbit Route core routing functionality with ETH and DOT blockchain nodes. Within the scope of Milestone 1, we want to take this opportunity to observe the following to release the stable version of the Massbit Route blockchain distribution network:

  • User experience with Node/Gateway installation process
  • Node approval process with a fair evaluation of RTT and network bandwidth by distributed Fisherman component at different locations within a zone
  • Accuracy in IP Geolocation for Nodes/Gateways
    • This ensures Nodes/Gateways are approved and benchmarked by Fisherman in the right zone
    • Detect inaccuracy in IP Geolocation database by surrounding gateways

• In the short term, we put our effort into optimizing and improving the efficiency of core functionalities of Massbit Route. We will open testnet with unofficial Massbit token to allow active community members to experiment with the Massbit Route network. This also helps our team to patch any bugs or issues from the design and implementation from the Node Provider standpoint.

• Once Massbit Route achieves the stability and efficiency at the early stage, it will have a solid foundation to attract DApps to migrate to Massbit Route API and more Node Providers around the world to come and service the network. DApps and strategic partners are onboard and offered to use dAPI from Massbit Route launched testnet. We will collect feedback/performance metrics and improve the product from End-user/Consumer standpoint.

• In the long run, once we reach the stability of global Massbit routing performance and fair token distribution from Consumers deposit fees to Node Providers, we will focus on expanding the Massbit Route ecosystem by integrating the network with parachains and major L1/L2 that have a large number of transactions and data usage. In addition, when we reach a large network of node providers that span many different parts of the world and have quick access to mempool, it is a good opportunity for Massbit to expand the feature scope to Defi Trading such as determining the gas price to win a gas auction or future block mining.