Incentivization

Incentivized packet routing

Peer nodes enter into an agreement to provide services to one another; in this case, the reliable receipt and delivery of packets. They keep track of how much bandwidth they’ve sent to and received from each other using the SWAP protocol (Swarm Accounting Protocol for Service Wanted and Provided).

Each participating node in the SWAP protocol uses a checkbook contract to manage the service accounting process, depositing funds into the contract in the form of ERC20 tokens. Mainframe nodes transact in Mainframe tokens (ticker symbol: MFT). Nodes publish their services and prices using a service discovery protocol. By allowing nodes to agree upon services, pricing, and a medium of exchange, the impartiality and interoperability of the network is improved, and a wider array of stakeholders have stronger incentives to participate. If potential peers can agree upon acceptable service prices, they enter into a peering relationship.

Mainframe’s service discovery protocol
is used to determine each node’s services and rates

Periodically, when the amount of bandwidth provided by a node’s peer exceeds a certain threshold, the peer issues an “invoice” requesting additional funds. The node issues a “check” to the peer in return by cryptographically signing a piece of data that can be used as an input to the checkbook contract. A node may cash the check immediately, or it may hold the check under the assumption that it will eventually owe money in return. If this occurs, it may simply void the check to “pay back” its peer, or it could issue another check. Each node has a configurable threshold for how long it will wait to accumulate checks before it attempts to settle its accounts. Checks are exchanged off-chain. This increases the risk of default, but allows the participants to avoid frequent costly transactions.

Checks also may or may not be backed by sufficient funds. If a node attempts to cash a check for tokens and there are insufficient funds in the checkbook contract, the node incurs a loss, but bounced checks also damage the reputation of the sender and will eventually prevent it from participating on the network. If a node doesn’t send a check within its peer’s declared deadline or bounces a check, these actions are visible in the blockchain ledger for all other nodes to see.

Nodes may retrieve the credit scores of other nodes using the Mainframe credit scoring API, factoring these scores in with additional criteria of their own, if desired. Nodes with little or no history have a middling score that increases as they pay their bills punctually and fund their checks reliably, or decreases as they fail to pay bills and default on payments. Each node’s service discovery manifest advertises the prices it charges for different credit score thresholds, and a node may even choose to disconnect altogether from a peer with a credit score that is too low.

Incentivized packet delivery

In tandem with the direct economic relationship between peers, Mainframe incentivizes packet delivery across multiple peer-to-peer hops in the network with the concept of cryptographically certified delivery. This mode of operation allows a sending node to issue a conditional bond specifying an escrow condition that some data be obtained from the receiving node proving that a packet was delivered. Performance and reliability can be balanced by only verifying some fraction of packets this way.

Alice sends a packet to Diane with a bond for certified delivery.
Each node collects a portion of the bond, sends another one on,
and returns a receipt proving delivery to its peer.

Each node can show the receipt from its neighbor as takeover proof, or proof that the packet was successfully delivered to its neighbor, challenging that neighbor to show similar proof until delivery of the packet is confirmed. Nodes that cannot show proof of delivery must either prove that the receiver was offline and that they are likely to be nearest neighbors of the receiver using their Kademlia addresses, or they can be blamed for failed delivery and forfeit staked tokens. This process is called finger pointing,² and essentially ensures guaranteed delivery.

In dark routing mode, rather than verifying delivery to all matching addresses, at each hop in the dark route, a bond is only sent to a randomly selected fraction of the neighbors, thus maintaining the anonymity of the receiver while providing a reasonable incentive for relays to deliver packets reliably. Because of its promiscuous duplication of packets, incentivized delivery in dark routing mode costs more. Network inference allows senders to get an estimate of how much packets will cost to send, depending on their luminosity settings and the configuration of their neighbor selection algorithm.

Incentivized packet holding

Mainframe communications must continue to function even when some nodes are disconnected from the network. Since Mainframe infrastructure is entirely based on services provided by nodes in its underlying peer-to-peer network, some use cases require that packets intended for a node that is offline be held in reserve by other nodes until it goes back online. This service is incentivized.

Nodes may advertise packet holding in their service discovery manifest. Other nodes requiring packet holding execute a service discovery query to find nodes offering packet holding for acceptable prices. Once they find acceptable packet holding delegates, they enter into a service agreement with these nodes and use the data services interface to update their packet holding delegate list in the global packet holders table. At this time, the delegate also stakes a certain number of tokens against the possibility that it may fail to hold packets according to its agreement.

Nodes may pay delegates to hold packets for them while they are offline

Nodes wishing to send packets to other nodes must first check the global packet holders table to see if the node they wish to send packets to has a delegate. If this is the case, the sender must send packets to all the receiver’s delegates in addition to the receiver. The receiver periodically updates its delegates with a signed list of the packet IDs it has recently received. Delegates may then delete these from their queue of held packets, charging nodes for the time they were held. Nodes that have been offline for a while may also request held packets from their delegates.

Delegating a packet holder ensures that packets are held
while nodes are offline for later retrieval

If a delegate is suspected of violating its service agreement, it can be challenged by opening a case with the swindle contract. The contract behaves as a state-machine conducting a court proceeding; witnesses are called and a guilty/not-guilty verdict is reached based on their testimony. Delegates that are proven guilty forfeit the funds they previously deposited into the swear contract. The swindle verdict is recorded on-chain, and can be used to quantify a node’s trustworthiness.

Incentivized file storage

Mainframe's incentivized file storage layer makes use of the swear and swindle stages of service provision, in addition to the swap stage used in packet routing. Nodes attest (swear) that they are storing random portions of a file (chunks) by staking tokens on the possibility that they might fail a storage test. Then they can be queried for a cryptographic proof of storage for any particular chunk periodically. If they are unable to return valid chunks, a swindle proceeding may be made against them, causing them to lose their staked tokens if proven guilty. Storage nodes are incentivized by earning tokens when file chunks are requested by other nodes.³

Incentivized data services

While file storage supports many use cases, it is inefficient to have to load and save a large file whenever small changes are made to it. For these kinds of use cases, Mainframe provides incentivized database services.

Nodes wishing to earn tokens for providing these services advertise their availability using the service discovery protocol. Other nodes may store indexed datasets with them for subsequent retrieval and querying. These datasets are stored with a user-specified level of redundancy. The greater the redundancy, the more compensation a node can earn in the unlikely event that its data is lost. Reliable service is incentivized using swindle witnesses, whose testimony may result in the confiscation of providers’ staked tokens if they fail to provide requested data.⁴

Dataset owners can specify who is allowed to read, write, update and delete rows from the set. This fine-grained access control enables many useful application features. For example, mailbox functionality could be implemented by allowing any user (or, alternatively, any previously-authorized user) to insert rows into a dataset representing another user’s mailbox, but only the mailbox owner could read, update or delete rows from the dataset. Users with read privileges can subscribe to receive notifications of any changes to the dataset.

Example messaging application using Mainframe data services. Alice can write
new messages to the table representing Bob’s mailbox, but she cannot read or alter the
messages in the mailbox. As the mailbox owner, Bob can read and modify the messages.
The Mainframe data services layer ensures that multiple copies of these datasets are
stored across the network for high availability and redundancy.