In a lightning network, a user can find a path from an interconnected payment channel to pay another user. On this selected payment path, the node between the payer and the payee is the mediation node and can earn a mediation fee.
The charging model for this type of mediation fee can be designed in a variety of ways and is usually affected by a few parameters. A good mediation fee model design can stimulate channel balance (Translator's Note: to ensure that each node has a certain available balance to improve the probability of successful routing), thereby promoting the healthy development of the token network. Therefore, in order for the payment channel network to function well, it is important to define an appropriate mediation fee framework.
In this article, we will gain an in-depth understanding of the mediation fee mechanism currently implemented by the Thunderbolt Network, how users can modify the mediation fee according to their own needs, and which design standards are considered.
Setting the purpose of the mediation fee
As mentioned above, mediation fees can motivate users to create and maintain a healthy network by participating in transfer mediation. Users can reclaim all (or part of) the cost of participating in the network through mediation transfers, and even potentially realize profitability.
The costs covered by the mediation fee can be divided into two broad categories:
The client-specific (local) cost portion , for example, recovers the base cost including operating expenses, tokens locked into deposits for opening payment channels, and additional fees depending on the respective business model.
Performance Part : Depending on the capacity of the payment channel and the preferred channel balance distribution scheme (payable channel vs. receivable channel), different clients may be more motivated by some mediation nodes than others.
Introduce the mediation fee framework of the lightning network
Although the mediation fee is paid by the payment (payable) channel, the billing process cannot only consider the payable channel, but also consider the receiving (receivable) channel.
Therefore, the mediation fee (MF_total) can be modeled by the sum of the receivable channel fee (MF_in_channel) and the payable channel fee (MF_out_channel):
The two channel fees (MF_in_channel, MF_out_channel) are the sum of the fixed fee (that is, the cost proportional to the transaction size) and the unbalanced cost (taking into account the preferred channel balance) :
The imbalance cost F depends on the selected imbalance (Imbalance Penalty, IP), and its formula is as follows:
IP is a function that can be arbitrarily chosen by the mediation node, indicating how much the mediation node is willing to pay to get the best payment channel.
Under this framework, each client can set constants (const_flat and const_prop) and define capacity-dependent IP functions for the Receivables and Payables channels according to their needs. F can be either positive or negative, so it can be used as an incentive tool and even to subsidize some payments.
Although setting a constant parameter requires only a single number, the IP function appears as a set of X and Y values in a linear interpolation relationship.
Using this IP function and the method of deriving the actual value by linear interpolation, various functions can be derived. In the current model, only the mediation node can earn mediation fees. In theory, if you consider the IP of both parties in the routing process, both will benefit, but to avoid being too complicated, skip this point.
Initial realization of unbalanced expenses
In the initial implementation, the imbalance cost can be described by a quadratic function. The mechanism of the imbalance cost is to hope that each channel is in an ideal state. We believe that the unbalanced cost of this design can be the default choice for most users, and it is a good starting point before more strategies are implemented.
As mentioned above, the IP function indicates how much the mediation node is willing to pay (in absolute terms) to avoid unsatisfactory channel capacity. If the mediation node wants to occupy a channel capacity of 5 and the total capacity of the payment channel is actually 10 (that is, this channel can transfer up to 5 tokens in both directions), the IP function is as shown below:
Set mediation fee in the lightning network client
All components of the mediation fee are turned off by default and can be set by specifying parameters on the command line (see the help page of the Thunderbolt Network):
Flat-fee : The fixed fee charged for each mediation (in the minimum unit of mediation, for example, the wei unit to charge WETH fees).
- Proportional -fee : The mediation fee is calculated based on the percentage of the mediation amount (10^-6).
Max-imbalance-fee : Set the worst-case imbalance (in the smallest unit of mediation token). The maximum unbalanced cost refers to the highest point of the range of valid values of the quadratic function of the imbalance penalty.
Decision basis behind the mediation fee model
Although the division of fixed fee and proportional cost is very clear and is a common method of division of the mediation fee model, we have not stopped here.
The design goal of the mediation fee model is to use mediation fees as a means of incentive transfer to promote the healthy development of the entire network. To achieve this goal, you can balance the payment channel by offering a lower transfer fee.
In order to properly explain the reasons for the imbalance in the payment channel, we must consider the receivable channel and the payable channel for each mediation node. The receivable channel of one node is the payable channel of another node, but different nodes may have different views on what is a balanced payment channel. Therefore, it is not in all cases that the counterparty can rely on the balance of the payment channel.
We believe that there is no objective criterion for the balance of a payment channel: if a user mainly uses the payment channel to pay for others, but rarely uses it to collect money, then he may prefer that the payment channel can be used toward himself. The payment direction is expanded. If it is a user who relies on running a mediation node to make a profit, then he may prefer a payment channel with a two-way capacity. To solve this type of problem, we used an imbalance penalty (IP) function to indicate how much the node is willing to pay to get the best payment channel. For each transfer, we calculate the imbalance cost by calculating IP(c_after) -IP(c_before) .
In the long run, the unbalanced cost is a zero-sum game for each mediation node: looking at the entire payment situation, the unbalanced cost portion of the mediation fee does not raise the total cost because of its increased cost and reduced The cost is quite. Therefore, from the perspective of overall transfer, the introduction of unbalanced costs will neither increase nor reduce costs. However, the unbalanced cost does change the allocation of fees between all transfers, motivating those transfers that improve the state of the channel, thereby improving the average level of the channel.
The future of the mediation fee mechanism
Although it is difficult to make predictions, and the mediation fee depends on the topology of each network and the actual payment path, we hope that the above mediation fee model can be effective, and it may be adapted to specific requirements and constantly changing. Adjust it for the situation.
The study of the mediation fee model is endless, and we started with the simplest and most economical model. We will continue to discuss it openly and explore how to integrate it with other models.
If you are interested in adjustment fees research and other solutions, we recommend the following readings:
"Lightning Network Cost" (Chris Stewart)
In addition, you can read this document to learn more about lightning network mediation fees, or look at the specific code implementation.
The Thunder Network team please follow us on Twitter and Medium and join our discussion on Reddit and Gitter.
Disclaimer: Please note that although we do our utmost to ensure the quality and authenticity of the information provided, there may be some personal biases, errors or omissions in this article. The author and representative offices are not responsible. The discussion and concepts relating to economic terms (such as "payment", "cheque", "currency", [value" "transfer") are used only to illustrate technical principles and do not necessarily conform to real world or legal definitions.
Author: Raiden Network
Translation: Min Min
(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.