MassBit Route [Decentralized API Service]: Consume Endpoints The Web3 Way

Published in

MassBit Protocol

6 min readJul 21, 2022

Since its introduction, blockchain technology, the backbone of Web3, has seen an upsurge in use case this past decade. Developers around the world can attest to the immutability, decentralization, and near-impregnable layer of security that blockchain technology possesses. There has been a paradigm shift in application development in recent years, as more Web3 developers have emerged and a myriad of Web3 applications have been released. A Web3 application is also commonly known as a dApp (Decentralized Application).

Computer applications often need to interact with other applications or systems, without necessarily being an integral part of that system — to share data. When an application exposes parts of its data for another application to access and use, it does this through an interface called an API (Application Program Interface). Besides interoperability and information sharing, APIs allow for fast and agile application development.

Web2 apps have, over the years, employed various methods for apps to consume API endpoints faster, cheaper and more reliably. Some services have used methods such as powering API services over a CDN (Content Distribution Network).

Web3 Unisolated

As Blockchain technology has moved from being a peer-to-peer payment system to a full application and data ecosystem — Virtual Machines, dApps, the Metaverse — the need for data and information to be exposed and consumed between chains and sometimes off-chain is imminent. No fully functional dApp can exist in isolation, serving all of its own data needs. Typically, for a Web3 app to access external data via API, it needs to interface with non-deterministic systems and networks. The problem with interfacing with non-deterministic systems is that they are mutable, hence there is no guarantee of data integrity — data may change at any given time.

The Blockchain Oracle Was Born

Blockchain oracles were introduced to solve the data integrity problem of blockchain networks interfacing with the “outside world” for API data. Oracles sit between the blockchain and the off-chain API. When a call is made to an API via a blockchain oracle, the oracle fetches the data and records the fetched data on-chain. Hence it turns the mutable data of the “outside world” into immutable on-chain records. Though this is a step in the right direction, fetching external, out-of-chain API data via blockchain oracles has its drawbacks.

Some key questions come to mind: Why should we have a decentralized system when the data it parses and processes is from a centralised source that could get hacked, compromised or shut down? Even if a blockchain oracle fetches and stores out-of-chain API data on-chain, what happens if the API endpoint from which the oracle fetches its data gets shut down or goes offline? Our dApp will become stuck and inactive, or display outdated data.

Decentralized networks and dApps are built to eradicate the SPOF (Single Point of Failure) problem faced by centralized networks and services, hence the need for a fully decentralized API solution.

MassBit Route (MBR): Web3 API Gateway

MassBit is on a mission to make blockchain API calls fully decentralized, secure and cost-effective. Nodes make up a decentralized network. A consensus mechanism — an agreed upon verification method — used by nodes to verify work on the network is the backbone of every blockchain’s security.

MassBit Route is a fully-decentralized BDN (Blockchain Distribution Network) comprising user-run gateways and nodes which are powered by the MassBit Verification Protocol. The MassBit Verification Protocol uses the proof-of-stake consensus mechanism. In the MassBit Route network architecture, gateways are the entry-point to the MassBit network. Gateways keep a list of verified nodes in its zone (geographical location). When a blockchain API request is made, the gateway forwards the request to the nodes in its list. Gateways are like the “gate keepers” of the MassBit network. Gateways and nodes on the MassBit network are run by users, spread in different geographical locations of the world. Users who run nodes on MassBit are known as Providers.

As the number of Providers increase, the network will become highly efficient, with little possibility of downtime. When a Provider’s node becomes inactive, other active nodes pick up its task. Faulty nodes are deregistered from the network by a MassBit component called Fisherman. Fisherman ensures MassBit nodes and gateways function properly; if a node or gateway malfunctions, it reports to the MassBit Core API. MassBit core API then updates the configuration for all nodes and gateways to avoid routing traffic to the reported node. The Fisherman component is also fully decentralized; it is integrated into gateways on the MassBit network. Gateways that have the Fisherman component are responsible for the node/gateway approval and suspension on the network. The status of nodes are constantly updated; when a node’s status is not “staked”, it cannot serve API requests. This method ensures that only nodes working at their optimum capacity would be allowed to serve API requests. This way, dApps can rest assured that their blockchain API calls are served in the fastest, most efficient way possible.

Web2’s CDNs (Content Distribution Networks) were introduced to speed up delivery of content to internet users. Web2’s CDNs distribute content throughout the world by caching content on servers closest to where Web users will access the content from. Similarly, MassBit’s Blockchain Distribution Network (BDN) distributes its workload among servers spread across the world, albeit in a fully decentralized manner. This way, it is able to handle requests faster than the existing cloud cluster way of hosting decentralized nodes. The MassBit network maintains a global IP map of its gateways; whenever a dApp (requester) sends a blockchain API request, the request is forwarded to a gateway whose IP address and the requester’s IP address are in the same zone (geographical location). Nodes in the closest or same zone to the requester’s location serve the API request. Gateways also store cached content of recurring requests, so they are served in the quickest response time. This greatly reduces latency.

Every dApp needs MassBit

No Server Downtime: With MassBit Route, nodes have perpetual uptime. No server downtime that will keep your dApp hanging. Blockchain API requests are guaranteed to be served always.

Secure and Efficient: There is no room for bad actors or idle workers in the network as Fisherman deregisters any node that misbehaves.

Goodbye SPOF: There is no Single Point of Failure (SPOF) as nodes are independently hosted and geographically distributed.

BDN and Caching: dApps’ API requests are served via the most efficient and fastest route.

About the Author

Mandela Amoussou loves coding and writing about Software, Blockchain, NFTs, Play-to-earn and anything that breathes in Bits and breathes out Bytes. He is an early MassBit community member and contributor.

About MassBit

MassBit provides fully decentralized solutions for Defi and Web3 App project development. Currently MassBit has 3 products in the stage of development; MassBit Route, MassBit Cross-Chain Indexing and MassBit Insights. MassBit enables DeFi and Web3 App development to be faster, stable, scalable, and more cost-effective.

The powerful ‘glue’ holding together and supporting all the products is the MassBit Verification Protocol, which is based on proof of stake. The protocol incentivizes those working within the system to verify each other’s work. The verification of other nodes, gateways, or indexers gives rewards or penalties for the mistakes to each individual or entity. From that, the protocol ensures the whole network’s health.

Join the MassBit Community: