Peer-to-Peer Architecture

The Network Can’t Be Shut Down

All data services that your Mainframe applications rely on are distributed in redundant fragments throughout the network. This eliminates the need to rely on or manage your own infrastructure, and makes it extremely difficult for would-be censors to deny access.

The two aspects that ensure the resilience of the Mainframe network are that it is both distributed and decentralized. Distributed networks are relatively commonplace today, mostly seen in the form of CDNs (Content Delivery Networks), where they provide highly-available access to online content. This type of architecture allows the network to seamlessly survive loss of or attacks against any subset of the nodes. The distributed nature of the Mainframe network means as participants in the network join and leave, the network has the ability to grow and heal around them. As the network scales up, the number of possible routing paths between any two nodes increases, dissipating potential hot-spots and further diminishing the overall effect nodes dropping out will have on the health of the network. The Kademlia network protocol will ensure that nodes try to discover new pathways when a peer is dropped in order to maintain an optimal overlay network.

Decentralized networks by definition have no central authority that can exert control over the flow of data across them. This makes them exceedingly difficult to shut down by a potential adversary, as there is no single point of failure or attack surface. Bittorrent operates this type of network, and while court orders were used to shut down websites advertising torrent content, the underlying file-sharing network could not be stopped effectively. The Mainframe network operates in a similar mode and is not reliant on any specific set of nodes being present or connectable at any time. No entity (even Mainframe itself) will be able to control or disrupt the operation of the network.

In addition to this resilient network structure, the various service layers provided by the network must be architected in a way that reduces reliance on specific nodes as much as possible. For this reason, services have been designed with redundancy in mind, storing individual shards of data across multiple nodes and designating multiple nodes to perform requested services. The network service layers have been designed to support the development of truly “unhosted,” or fully decentralized applications.1 This means that developers on our platform are not required to provision or manage their own infrastructure, as would be required for a traditional web service, and consumers do not need to trust third parties to maintain such infrastructure. Mainframe will continue to develop services to better meet the needs of fully decentralized applications as this space matures.

Diagram
1. The term “unhosted” and the conceptual diagram have been adapted from remotestorage.io.