Leveraging Interledger Protocol for Node Remuneration on the Flare Network

[seanrowan]

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 (v₁, v₂, v₃ and v₄), and the quorum slices are: v₁ : {v₁, v₂, v₄}, v₂: {v₂, v₃, v₄}, v₃: {v₂, v₃, v₄} and v₄: {v₂, v₃, v₄}. Although v₁’s quorum slice doesn’t include v₃, node v₁ still depends on v₃ within its quorum because at least one member of v₁’s quorum slice depends on v₃ within its quorum. This means that v₁ depends on v₂, v₃ and v₄ for externalising transactions it proposes, but v₂, v₃ and v₄ do not depend on v₁ 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 v₁. 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 v₄:

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 v₁₂. There are quorums from v₁₂’s perspective that can externalise the user’s transaction that do not include all nodes that v₁₂ includes in its quorum slice sets. For example, the set of nodes {v₁₂, v₈, v₉, v₁, v₂, v₃} is a quorum from v₁₂’s perspective, and could externalise the user’s transaction. However, the user would pay the costs of nodes v₁ to v₁₂, because this is the set of all nodes within all of v₁₂’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 v₁. 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 v₁.
3. At block j+N, the node v₁ clears its balance by paying nodes v₂, v₃ and v₄ for the user’s transaction.
4. Later on, node v₂ decides to change its fee from 4 units to 5 units.
5. Before this fee change takes effect, node v₃ decides to remove v₂ from its quorum slice set. However, because v₃ still contains v₄ in its quorum slice set, v₂ would still be included in v₃’s quorum. This means that v₃ would still have to pay v₂ for transactions until v₄ removes v₂ 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.