Transaction fee discussion

Ecosystem Governance
1

Hasu just published “Transaction fee economics in NEAR”, reviewing few of the concepts that NEAR uses for charging transactions and doing contract rewards. Really appreciate diving in and thinking through the design. Let’s open conversation here.

There are two arguments in that article:

  • Leaving out a “tip” for block producers will lead to off chain black markets
  • Portion of the gas fee going to contracts would lead to negative consequences

Tip or no Tip

Let’s start with compensation of validators for their costs. Tip is not doing that.
In general, transaction fees are actually not doing that for the most part.

Validators in PoS must validate every block that was produced to themself be included in consensus and not getting kicked out. E.g. if someone produces a valid block - they need to extend computational resources and bandwidth to receive (and propagate to those who it’s unknown if they are sending their approvals to them). State storage is a bit separate and probably should be discussed in a separate article.

Validator that includes transaction into block originally has two things to consider:

  • Very minimal cost of “including” transaction into block (e.g. ~100 bytes of bandwidth per transaction). But there is an opportunity cost of not including transaction as it burns the supply, however small that is it’s on the order of sending extra bytes over network.
  • Nodes routing transactions to the validator detecting that validator is not including their transactions.

Note, NEAR doesn’t have mempool in normal sense, transactions are routed to the next few chunk producers in the respective shard. With ~1 second blocks and constant validator rotation transaction get routed pretty quickly to the validator that will include them. Given routing node knows where they are routing and observer produced blocks, they can detect if it wasn’t included. (Though this is not really implemented right now, but it is easy addition to keep track of “dropped” transactions on routing and having heuristics around that)

Let’s review few cases:

  • Some subset of validators only accept transactions that were bribed, dropping others. This is where tip actually would make sense but it’s unclear why would validators do this as they have opportunity cost by not including transactions. Also as mentioned above - it is detectable and attributable (e.g. not like in PoW) and can be also punished on social level via community shifting delegations away from such validators.
  • Validators include transactions that were paid off-chain first. Interestingly, given MEV in Etheruem right now - this is happening even with current gas auctions and can happened with EIP-1559 / tip because can be done via side-channeling. E.g. prices are been driven up by miner themself while they still front-run all the transactions themself. The way to fix this is actually to require specific order of transactions in the block. For example, they should be ordered randomly shuffled with random seed from previous block. This means that validator will have ~1 second to try to literally mine a transaction that would sort before an arbitrary transaction that they want to front-run.

Because NEAR was designed with dynamic resharding in mind, even though it’s expected that temporarily there can be congestion within current capacity due to spike in usage and hence gas price might adjust up - relatively soon there will be more capacity added by the network via resharding.

I think the main concern here is really spamming - if someone starts to spam network filling all the blocks with low value transactions - applications and users that have high value transactions want to get in.

Even though it’s a clearly a concern, let’s do back of envelope: initial price for 1Tgas is 0.0001 N. So one block is 0.1N at the minimum.

For those who need predictable capacity (vs extracting economic value due to timing) - there can be even better solution, where you can rent your own “shard” - e.g. some pre-determined gas limit shard on which only specific contract(s) operate and hence not be subject to congestion from other contracts. This is useful for oracles for example.

Now, we are adding EVM “vaults” (aka EVM shards), and for them dynamic resharding won’t work as all contracts inside one EVM shard are synchronous and need to live on the same shard. This means that adding tip for such transaction would make sense.

So why no tip in the first place, if it should work without it anyway?

Main reason has been that block producers can agree on side-channel repayment of the tip to always include some transactions at the top of the block. This is also directly leads to MEV, as block producers themself can include anything. This is possibly addressable by non-tip ordering of transaction but hasn’t been fully analyzed.

There are also possible attacks that is way easier to execute in PoS than in PoW where order is not deterministic, where block producers can execute on transactions with tips, by maintaining gas price at minimum by producing full block followed by empty block on repeat. Which means it will just degrade to a tip auction (and given tip is usually designed not proportional to gas). This also sounds like something that social consensus would prevent though.

Another consideration is that having two parameters that users and developers need to deal with increases complication of already something pretty complex like transaction fees in blockchains.

Contract rewards

One of the major problems with blockchain development, is that protocols that are not directly dealing with value transfers are actually really hard to capture value if they are running on top of existing Layer-1. E.g. DeFi applications can charge fees from tokens that are transferred, but any applications that is not directly dealing with transfer of funds doesn’t have this ability.

Hence the reason why things like Cosmos and Polkadot actually make sense for subset of use cases - where starting your own chain is a way to create a fee capturing mechanism on top of the developers and investors.

There are now some data providing applications trying to also create a fee generation process on top of Ethereum, like NEST - where they would be charging for a call to their contract to fetch data. The problem is that reading data off chain and proving it on chain is not that expensive (it’s proving trie merkle path) which means there is maximum that such applications can charge and it’s priced in the gas spent and usability.

NEAR’s contract rewards just create a floor for such operations.

Frequent arguments are: it will lead to suboptimal gas usage, developers will fork and contract will pay it back to users.

Suboptimal gas usage: this is actually true short term for any contract on NEAR. Just because NEAR is so cheap, people are not going to be optimizing things in the beginning. And given our goal is to provide scale, I think optimizations will be more happening on the protocol side. Of cause if developers maliciously adds 10x in gas usage or in some other way spends extra - this will be known and given most of these contracts will be used by other developers it will lead to this contract not been used.

Developers will fork: this is true about Ethereum right now as well. If there is a way to fork something, it will be forked. Hence contract must have some moat: either branding, community, already usage, external data providers, internal liquidity, etc. And even with all that, it’s possible to fork, but it won’t be because of contract fees.

Contract will pay users back: This is actually great. That means that is economics that make sense for developers to do that. For example, if contract has an ownership (governance) token that is distributed among developers, investors and users. Contract can use these fees to buy-and-burn this token, hence providing value to everyone. This would actually match experience of building your application on Layer 1 to provide the community with sustainable way to capture fees while paying the rest of the fees to validators and token holders of NEAR for running compute / storing data.

Would love to see if there are any wrong arguments here.

5 Likes
2

One argument that Hasu has made in his article - contracts paying users back will create a lot of unnecessary payback transactions. I assume that it’s not going to be an issue for a long time since one of the core ideas of NEAR is a high throughput of transactions. Still curious what do you think about this.

3

One argument that Hasu has made in his article - contracts paying users back will create a lot of unnecessary payback transactions . I assume that it’s not going to be an issue for a long time since one of the core ideas of NEAR is a high throughput of transactions. Still curious what do you think about this.

Token or a DAO are the easiest way to not do lots of transactions. E.g. contract just allocates tokens based on usage of the contract to users and periodically burns some portion of this token. As I mentioned - this is totally normal as it allows to create new economics for applications that previously wouldn’t have this naturally (e.g. non DeFi applications, or even DeFi that might have issues capturing flowing finances through it)

4

This is great! Adding a summary at the end with the two overarching topics relative to your response would be great for the lay person.

  1. The 1 second block time and validator rotation is key to avoid a tipping mechanism.

  2. Incentive through the contract to users and shareholders is a very nice touch! Elaboration on a more concrete example of this may help solidify the idea.

  3. Addressing the compelling reasons in summary of why a hard-fork will not address the overarching issues and how it will only create the issues that already exist in other Tier 1 blockchains.

Lastly, I love the writing style of the last several blog posts Eric and the team have put out. It’s top notch! Having this repurposed in a deliverable format for the blog, might be a good idea. Not necessarily this topic specifically, but premise behind the key points.

4 Likes
5

And another question while we are at it - let’s say there is a “corrupt” validator with the following business model - 0% fee, but they make profits through routing bribed transactions exclusively. They attract delegators that are chasing purely economic incentives.

The question is - will people delegate their NEAR to a 1% fee validator that is “clean”? Because from the game theory standpoint people should switch to “clean” validators since the negative externalities arising from delegating to a “corrupt” validator outweigh the economic incentives. However, people might not be sufficiently informed about the state of the validators.

6

Great idea! @shreyas is this sth that our marketing/content guild could work on?

8

I would like to elaborate a bit on the transaction ordering and inclusion in blocks.
Imagine the following Doom day scenario:

  • Top 5-10 validators / pools by stake / hashing power are secretly colluded;
  • The collusion is covering the situations that [potentially] lead to massive changes in the value captured by the blockchain (for example, native currency price), (let’s call it the Doom day);
  • By the terms of collusion, if the Doom day happens, these validators will stop including any transactions in the block with exception of from white-listed wallets;

Let’s analyse the above scenario.

  1. There’s absolutely no problem in doing that because of the limited amount of parties involved.
  2. Taking into account the lack of decentralisation in existing L1 solutions, the drop in the performance of the chain may be tremendous. For example, top 10 pools in Bitcoin have produced 434 blocks out of 565 within last 4 days, which equals 76%+.
  3. Because of the rapid performance drop, colluded pools may use their prioritised transactions to front-run all the other blockchain users: they can cash out earlier with favourable exchange rates.
  4. Since there’s no ability to prove the absence of the information, no-one can blame colluded pools that they have known the transactions from the mempool, but refused to include them in the blocks. This fact would be probable but not proovable.

Now, to put even more drama here, imagine, that there’s no collusion, but pools understand this problem and are ‘selling the tickets to the lifeboats’ for the doom day scenario, mitigating this risk for end users. Is this a ‘dark market’ or an insurance? How to distinguish here a ‘dark side’ from the ‘light side’?

None of the existing (direct fees; EIP-1559) or potential (randomized tx ordering) approaches to transaction fees in the public blockchains can solve this issue; only the proper decentralisation, which would be impossible without removing a pool as a user uniting mechanism.

IMO, this is much more important concern. And it’s not transaction fees structure that we should put emphasis on, but rather decentralisation and the ability to scale under load. Ethereum and Bitcoin have failed to deliver this with no simple solution within 5y horizon. NEAR at least proposes some options that either delivered or going to be delivered within months from now.

2 Likes
9

Why is it attributable? How do you distinguish between a network glitch and intentional omission by the chunk producer? Also how can you tell precisely which chunk producer should include your transaction?

1 Like
10

In general, transaction fees are actually not doing that for the most part

Confused; do you mean that tx fees are not compensating NEAR validators, or that tx fees don’t compensate any validators anywhere, or that validators anywhere have greater Miner Extractable Value (MEV) from transaction sequencing arbitrage opportunities?

As Hasu pointed out, not imposing a transaction sequence (ie. bigger gas fees go first), the opportunities for MEV on Near are huge, so relatively, you could be saying that tx fees aren’t compensating NEAR validators, relative to the amount of potential profit via MEV

if someone produces a valid block - they need to extend computational resources and bandwidth to receive (and propagate to those who it’s unknown if they are sending their approvals to them).

This was unclear. Do you mean that:
Validators must confirm that each block is valid, and that block producers have to aggregate “is-valid” messages by validators?

But there is an opportunity cost of not including transaction as it burns the supply…

I don’t understand how not including a transaction burns the supply. Presumably, you mean the supply of NEAR tokens to be rewarded as block rewards? I don’t recall reading about a mechanism like that though, that burned the block reward in relation to the non-included transactions in a block

This means that validator will have ~1 second to try to literally mine a transaction that would sort before an arbitrary transaction that they want to front-run.

I think you mean here that a block producer has 1 second to insert their own arbitrage transactions around a transaction in the block they’re writing, which is totally viable

11

Validators’ reward come from a combination of inflation and transaction fees. Since the total reward is fixed in percentage, as a validator, it is naturally more desirable to include more transaction in order to burn more tokens so that the reward they get is more valuable.