On balancing high throughput blockchain network fees for security and adoption

In this note, we look at network integrity/total fees dynamics as a driver of a multichain environment. We suggest that it’s not the difference in blockchain features that will ultimately define the winners, as features can and will be copied, but the perceived integrity. We also suggest that integrity is a function of the total amount of fees collected by the chain (directly and via inflation) and propose two designs — one for a multichain (L1 + side chain + L2 is considered multichain as well) and another for a monochain future. We also discuss the limitations of the existing blockchains’ design that doesn’t allow a monochain environment.

— — —

The integrity of the public blockchain infrastructure is based on several pillars:

• cryptography — it is not feasible for a bad actor to hack the system and alter the records since it requires too much computation resources to break the codes.
• validators fees — becoming a very large validator allows a bad actor to alter some records (the ones created by the actor or its related parties). A large enough flow of fees, provided in a way, that ensures the validators invest a lot to have the right to validate, makes it hard for a bad actor to become a large validator and tamper with the system.
• number and diversity of validators.

The following discussion is focused on the validator fees. The economics there is less developed. On one hand, you want the fees to be high enough to secure the integrity of the infrastructure and make it worthwhile for validators. On the other hand, you don’t want the fees to be too high, not to impede the adoption.

You want the fees to be just right and also self-regulating. Some protocols already have fees, that are too high for small transactions, like in the case of the Ethereum, where the current transaction fee is around $5, which when sending $50 cross-border will be 10% of your transfer. For others, like Solana, it is just $0.0006 for the simplest transactions like a transfer of funds from one account to another.The difference is 4 orders of magnitude.

But what is the right fee level? One way to approach answering this question is to commit to a future of an “equilibrium of networks” discussed at the end of the article, where different networks are used for the transactions depending on the transacted value. But is there a way to support all transactions within a single network escaping the low fees — low integrity trap?

The proposal, discussed in detail below, is that for the high throughput blockchain networks (e.g. Solana, Ethereum 2.0) aiming to enable a wide range of supported transactions (by transacted value) the base transaction fee should be very low, to allow even the tiniest transactions to happen, while covering the costs and providing a reasonable profit margin to the validators. The total validators fees add up to a large enough sum by transacting entities voluntarily breaking down their transactions into smaller parts — fractional transactions (FT), each FT small enough to make altering impractical for the bad actor. The competition among validators determines the low level of the base fee while breaking down transactions by clients ensures a large enough fee pool to secure the system. This approach holds for simple transactions and smart contracts.

Why this approach? It starts with the idea, that having as small a transaction fee [1] as possible is great for the users. Setting the fees higher will cut off some use-cases, and invite competition.

However, if the fees are very low (even if it is still economical for the validator to process) the total amount of fees will also be small. Consider a network that takes fees of $0.001 and handles 1 million transactions per day. The fees amount to $1000/day or $365,000/year. The validators are happy to receive the fees but only willing to commit $1,000,000 of capital to this endeavor (to get a 5% annual return on investment, assuming a 15% net profit margin of the fees revenue) making it relatively inexpensive to tamper with the system.

The solution suggested is to incentivise users through the design of the protocol to break down their transactions in increments, each small enough to make tampering economicaly inefficient. Additionally, each increment produces a transaction fee, and that fee increases the total fee flow, which increases the total investment needed by the bad actor.

If a transaction is a payment of $1 you received from someone as a tip, the fee of $0.001 sounds awesome (it is just 0.1%). But if you are on a receiving end of a $100,000 payment, you might want this transaction broken down into a hundred thousand pieces.

Imagine that our system above handles the same 1 million transactions, but an average transaction size is $50 (there are small $1 transactions, but also large $50,000 ones). If the users break down the larger transactions, instead of 1m/day there will be 50m/day of $1 transactions, which would increase fees and validator investments by 50x. So now bad actor needs to come up with 50x of capital.

And what if a transaction is not monetary, like transferring tokenized shares of Tesla on a blockchain. The logic is the same. If the block of shares is worth $100k to the user, just break it down into a hundred thousand pieces and transfer one by one over a period of time.

But how about freeloaders? Those who would not want to break transactions down and pay higher fees — and would just assume that the rest of the participants do. Wouldn’t it quickly lead to the situation where everyone adopts this strategy and the system collapses?

It should not. The protocol should be designed in a way that breaking transaction into FTs decreases (preferably in a superlinear way) the risk of the whole transaction being undone by the bad actor. If that’s the case, the freeloader, by not breaking down a large transaction, is exposing itself to a significant risk, which in the case of low transaction fees is not worth it.

To make sure the base fee is as low as economically viable it should be adjusted algorithmically based on the signals from validators. In the beginning, however, it is practical to set it up and adjust manually.

Note, that the base fee is not a congestion fee. The latter should be implemented separately to help prioritize the transactions in case of congestion. One of the implementations burns this fee, to make sure there are no incentives for miners to game it.

Until now only the simplest transactions were considered — sending tokens/tokenized assets from A to B. But blockchains also process more complex items, like smart contracts. The processing fee there will be higher, as it should cover higher validators’ expenses to process the item. But the logic of breaking down one large transaction into multiple smaller ones holds.

The breakdown of the transactions should be done automatically by the software so that it doesn’t create friction on the user side.

A note on the tokens’ total market cap. The integrity of the system does not depend on it directly. Rather, the cap “happens” based on the fees, use of staking in the model, and tokens velocity.

As an example, consider a PoW system servicing $8T of transactions annually, charging effective fees of 0.1%, and generating $8B in fee flow. These numbers are on the same order of magnitude as the estimates for the Ethereum network in 2021 [2].

If the native tokens of this system are used only to service fee payments (the users buy the tokens only to pay validators their processing fees), depending on the velocity of the tokens, the market cap can be as low as <$1B, for the annual velocity of 8+ (all tokens change hands between miners and users every month) or even lower in case of fees economic abstraction.

* ETH market cap is much higher than that because it is not defined solely by the total amount of transaction fees. There are a lot of other factors, like speculation, using as collateral, just HODLing, etc.

However, that would not affect the system integrity, as long as the total amount of validator fees is not affected, and the total amount shouldn’t be affected if the system is designed properly. The total amount of transaction fees will ensure a significant CapEx barrier for the potential bad actor.

The network described above would have validator investments of $24B (assuming net margin for fees of 15% and required ROIC of 5%), making it quite expensive for a bad actor to run a scam.

Note, that in the PoS system the calculations for the market cap will be different, however, the logic stands.

The alternative to this fractional transactions approach is an equilibrium of networks (including a combination of L1 and L2 or a side chain) charging different fees and being used respectively for the different transaction sizes. Network A charges $5 per transaction and is used for transactions between $1,000 and $50,000 while network B charges $0.005 and is used for transactions $1 to $50. Assuming a similar difference in total fees collected by A and B, system A will be significantly more secure.

Since it’s the total amount of fees that matter, there will not be too many systems. As a system becomes more popular, the total amount of fees flowing through it grows, and the security of the system increases, not to mention other network effects leading to the same result. The specific features of the networks seem unlikely to change the dynamics as the features can be copied by the competing systems.

While less aesthetic, the equilibrium approach can also do the trick of offering low transaction fees and high security where it matters. Here, instead of breaking down the transactions, users switch systems. The software can manage these switches without any overhead on the user side.

A couple more notes:

• The use-case of powering the financial markets where there is a need to move assets worth billions of dollars back and forth multiple times a second requires a separate discussion.
• The storage fees are also a topic for a separate discussion.

[1] The transaction fees should be set/adjusted in a way that connects them to the natural costs of the validators; so that in medium term they change not due to the speculative moves of the native token, but due to the changing cost structure of the validators.

[2] See https://timestabloid.com/ethereum-is-poised-to-settle-8-trillion-in-2021-heres-the-primary-reason-for-the-increase/ for transacted value estimates and fees calculations based on this and the price of ETH = $2000, also see here.