Leveraging Interledger Protocol for Node Remuneration on the Flare Network


This post contains further concrete details about how we are leveraging the Interledger Protocol with the Flare Network, a Turing-complete federated Byzantine agreement network.

This is a follow-on post from: Flare - A Turing-Complete Federated Byzantine Agreement Network, where the Flare Network was introduced.

Flare Network Topologies and Pricing

The following Flare Network topology has 4 nodes (v1, v2, v3 and v4), and the quorum slices are: v1 : {v1, v2, v4}, v2: {v2, v3, v4}, v3: {v2, v3, v4} and v4: {v2, v3, v4}. Although v1’s quorum slice doesn’t include v3, node v1 still depends on v3 within its quorum because at least one member of v1’s quorum slice depends on v3 within its quorum. This means that v1 depends on v2, v3 and v4 for externalising transactions it proposes, but v2, v3 and v4 do not depend on v1 for externalising transactions that they propose.

Each node can independently set as many quorum slices as they want, and then market forces cause overlaps of trust on the network which give rise to the network-wide rule for consensus.

In the above scenario, a user U submits a transaction with a computational complexity of 40,000 gas to an initial node v1. Each node independently sets their transaction price, and this is scaled by the gas usage to give the cost of a single transaction. The total price that a user pays is determined by including a fee for every node in all of the possible quorums that the initial node depends on. For example:

Here is an example of the costs if the user instead submits the transaction directly to node v4:

A node operator can charge extra to a user that submits transactions directly to it. A typical scenario would be that a business that depends on the Flare Network would run their own node and only permit a user to directly submit transactions to their node that relates to their business.

Above is an example of a more complex quorum topology. In this example, a user submits their transaction to node v12. There are quorums from v12’s perspective that can externalise the user’s transaction that do not include all nodes that v12 includes in its quorum slice sets. For example, the set of nodes {v12, v8, v9, v1, v2, v3} is a quorum from v12’s perspective, and could externalise the user’s transaction. However, the user would pay the costs of nodes v1 to v12, because this is the set of all nodes within all of v12’s possible quorums. This wide payment rule creates a mechanism to motivate each node to be more selective in how they form their quorum slices, and disincentives nodes from choosing quorum slice sets that are very wide. Users also have selection over the nodes that they submit their transactions to, and the users can determine if the node that they select has enough nodes in its quorums to provide safety.

Node Payment Mechanics with Interledger Protocol

Below is an example timeline of events that conveys how a user pays for their transaction, and how this payment is then dispersed to nodes in the Flare Network. A Flare Network sets a parameter, N >= 1, that determines the distance between block heights when changes to quorum slice choices take effect on the network. Any federated Byzantine agreement construction cannot have N < 1, because quorum slice changes cannot take effect mid-slot. For example, the Stellar network fixes this parameter at N == 1. On the Flare Network, these checkpoints are also used to define when changes to a node’s fees take effect. Larger values of N give tighter expectations on transaction costs, and also more time for a node operator to react to quorum slice and fee changes that other node operators make.

The following example assumes the quorum topology from the first example conveyed above.

  1. Before block j, a user pre-pays their transaction fees over Interledger Protocol to the node operator that they will be submitting Flare transactions to in the future. In this example, the user prepays 4,000,000 gas-units (i.e. 200 units at a gas usage of 20,000) to node v1. The node operator that receives this pre-payment accumulates all of its pre-payments and issues a non-repudiable receipt to the Flare Network. This signals to the other nodes in the Flare Network how much gas-unit bandwidth this node is permitted to expend in the period from block j to block j+N. The user’s prepayment can extend into future block periods beyond block j+N, and a node operator can also set its own strategy for issuing refunds to a user.
  2. At a block k, j <= k < j + N, the user submits a transaction with a complexity of 40,000 gas to node v1.
  3. At block j+N, the node v1 clears its balance by paying nodes v2, v3 and v4 for the user’s transaction.
  4. Later on, node v2 decides to change its fee from 4 units to 5 units.
  5. Before this fee change takes effect, node v3 decides to remove v2 from its quorum slice set. However, because v3 still contains v4 in its quorum slice set, v2 would still be included in v3’s quorum. This means that v3 would still have to pay v2 for transactions until v4 removes v2 from its quorum in this example.

In the event of a node not paying other nodes for transaction fees, the other nodes can drop the node off of their known validator list. If the set of nodes that remove the non-paying node are at least a v-blocking set, then this would prevent that node from being able to externalise transactions. This, however, is the liveness assumption of federated Byzantine agreement and its analogy in a traditional Byzantine agreement network with n nodes would be if more than (n-1)/3 nodes in the network drop the node off of their known validator list. Node operators can also choose to require a refundable security deposit from nodes that wish to include them in their quorum.

Turing-complete Smart Contracts With XRP Ledger Accounts