[Proposal] Self-Motivated Infrastructure Growth(SIG) through Profit

This article is written by Loum from EOS NodeOne and will be submitted as a worker proposal later.

1. Purpose

We propose a way to encourage BPs to grow their infrastructure on a timely and voluntary basis by providing enough compensation for creating a new sidechain (for scalability of the network)

2. How to Increase Current RAM Available and Infrastructure

There are currently few means to put pressure on BPs to build new infrastructures in the EOS mainnet. [1] This article will deal with RAM, because it is the most important computing resource on the network.

At present, the capacity of RAM in the EOS mainnet is increased by consensus by 21 active BPs. Even if the actual infrastructure can manage 2TB of RAM, the main BPs may increase the available RAM size on the network as needed. As shown in Figure 1, the available RAM size on the mainnet is determined by the votes of the 21 active BPs.

Figure 1. Dan's telegram message. https://t.me/EOSGov/37929

For reference, the available RAM size of the current EOS mainnet is set to the initial setting of 64GB, which can be found on the site provided by EOS New York (https://www.eosrp.io/#).

RAM is a very limited computing resource that can currently be expanded to a maximum of approximately 4 TB or 16 TB. [2] Therefore, if more RAM is needed, the BPs must create a new chain, which requires BPs to deploy new servers with similar performance to existing chains. One of the most strengths using EOS blockchain is scalability problems can be solved by adding multiple-chains. However, there is no adequate means to encourage BPs to voluntarily create new chains so far. Therefore, the expansion of new infrastructure seems to solely depend on BP's goodwill.

If the RAM price is getting too high by speculation, the cost of operating a new dApp will be increased, which may induce developers to opt out of the EOS platform and choose another dApp platform.

2.1 Multi-Chain and Infrastructure Growth Needs

There are two methods to use computing resources in the cryptocurrency: 1) a fee-based method in which a user pays a commission, such as Ethereum, and 2) a rate-limiting method, which provides computing resources proportional to staked coins, such as EOS

However, it is very difficult through the fee-based method to defend spam attacks if the attackers are willing to pay a huge amount of fee. Therefore, Ethereum uses a method to increase the total cost of a block that can be included in the next block, ie, the gas limit per block (1/1024, or about 0.098%) [3] However, this is the same as limiting the block size to 1MB of Bitcoin, which in turn limits scalability.

On the other hand, the rate-limiting method of EOS is a proprietary resource allocation method that authorizes the use of computing resources proportional to the staking coin, which is a very good security method that can effectively defend spam attacks is. However, the biggest disadvantage of this is that the cost of the dApp developers involved is high when the RAM price is high.

To address this in part, EOS supports multi-chain, which allows almost unlimited scalability. This is a way to provide new computing resources to the network by adding new chains in addition to existing chains. And the other chains exchange information with the Inter-Blockchain Communication (IBC).

But running a new chain would incur additional expenses, which discourages BPs from paying for it if there is no compensation. Because of this, BPs may not be able to provide computing resources to the network in a timely manner. We call this problem Infrastructure Growth Needs. And the pressure to expand the infrastructure is mainly caused when adding new chains.

3. Self-motivated Infrastructure Growth (SIG)

Importantly, EOS is a distributed operating system capable of running various dApps. Thus, as a dApp ecosystem flourishes, the active BPs need to expand their computing resources on time to provide computing resources at the right price, which in turn can make the EOS platform more active. For this reason, new means are necessary to make BPs to properly increase computing resources in time.

So we propose Self-motivated Infrastructure Growth(SIG), which provides enough rewards for BPs every time they add new infrastructures. This is because the BPs are a third-party pursuits for profit, because there is no economic means to encourage them to voluntarily add new chains in time.

Some example of SIG methods are as below:

One example is applying SIG to the current BP reward system. In this case, we assume 1% yearly inflation of BP rewards which is composed of 0.25% of per-block rewards and 0.75% of per-vote rewards.

Example 1: Applying SIG to the current BP pay model

Each time BPs add a new chain, an additional payout can be set up.
For example, per new additional chain, +0.1% of inflation for additional payout
Whenever the BPs actually launch a new chain, 0.1% of inflation is added to their per-vote rewards. To be specific, adding an additional chain to the current mainnet, i.e. running two chains, makes per-vote rewards of 0.85%. Here we have 1.1% of total token supply for BP rewards. Likewise, if the BPs run three chains, 0.95% for per-vote rewards and 1.2% for BP rewards in total.

At this point, it is aimed at motivating BPs to get enough rewards as they run a new additional chain.

However, applying our proposal directly to the current BP pay model can cause some problems. Top BPs with a lot of votes will get enough rewards to increase their infrastructures, but BPs with fewer votes may not have enough rewards for that.

To be specific, if BPs run two chains, the per-vote rewards for BPs increase by about 13.3%. Since the minimum threshold to claim rewards is currently 100 EOS per day, the lowest per-vote rewards will be about 113 EOS per day, with the total additional reward of 390 EOS per month. However, in the case of that EOS price is low, the lower-ranked BPs may be reluctant to increase their infrastructure while the top BPs would get enough rewards for it.
In order to motivate lower-ranked BPs, therefore, this method has the problem of reducing the number of standby BPs that are rewarded by increasing the minimum rewards, the reward-claim threshold.

Example 2 below is applying SIG to the new BP pay model proposed by our team. Assuming inflation for BP compensation at 1% per annum. This is composed of: 0.25% per-block rewards, 0.5% per-vote rewards, and 0.25% equipment rewards.

The details of our proposed BP pay model can be found in the links below. link

Example 2: Applying SIG to our proposed BP pay model

Each time BPs run an additional chain, additional funds may be paid to BPs from the Worker Proposal funds or raising the equipment reward ratio(0.25% above).
In this case, all BPs will receive the same amount of rewards for growing their infrastructure. To be specific, in the case of increasing an additional 0.1% rewards for equipment rewards, the total equipment rewards will increase to 0.35% for running two chains.

Alternatively, as in Example 1, you can pay this for per-vote rewards. For running two chains, the per-vote rewards can be 0.6% and the BPs will be paid in proportion to the votes received.

The expected effects of SIG are:

There is no reason for BPs to be reluctant to add new chains. If you add new chains, if BPs get more profit than cost, they would gladly grow run additional chains.
As adding new chains, the computing resources available to the platform will increase accordingly, which can lower RAM prices in the RAM market and reduce the cost of new dApp participation in the EOS platform. This will greatly increase the availability of EOS as a dApp platform.

4. Conclusion

We have proposed a BP compensation method that BP get more rewards each time running additional chains, so they are self-motivated to do so. This can provide timely computing resources to the network and help dApp developers to take advantage of the EOS platform at a low cost for later participation.

Reference

[1] EOS.IO proposed a way for the active BPs to disclose the prices of their computing resources so that the active BPs are under pressure to increase their computing resources. link
[2] see the telegram messages of JEM: link1, link2
[3] GAVIN WOOD, "ETHEREUM: A SECURE DECENTRALIZED GENERALIZED TRANSACTION LEDGER", http://gavwood.com/paper.pdf, See Equation 45-46 on page 6.

This article is edited and translated by Leo of EOS NodeOne.