Adjustable Target Block size for the EIP 1559 base fee mechanism

[AxCortesCubero]

We propose introducing a mechanism that dynamically adjusts the target block size used in the EIP 1559 base fee mechanism, to maximize some determined target function.

Motivation

The EIP 1559 mechanism reduces the difficulty of estimating transaction fees, by introducing a base fee, which is a posted price for gas usage that users do not need to guess. This base fee is updated at every epoch, based on block usage relative to a target block size. If the current block gas usage is smaller than the target block size, the base fee is reduced for the next epoch, and if the current block is larger than the target bock size, base fee is increased.

This mechanism assumes that the optimal block size that the network should use at all times is then the pre determined target block size. When the target block size is fixed only by engineering constraints, as the largest possible block size the network can consistently process, this is a mechanism which is designed to optimize simply for lowest possible base fee.

For various reasons, the network may want to optimize for something other than lowest base fee. In a first price auction mechanism, for instance, miners would generally optimize for maximum total network revenue. Particularly in periods of low demand, this could be achieved by restricting the block size to a smaller optimal size.

Introducing a mechanism that can dynamically vary the target block size used in EIP 1559 would enable the network to optimize for any different target of choice, whether it is total network revenue, or something else deemed of value.

Proposed mechanism

We denote the base fee at epoch $t$ as $r_t$, the target block size as $B^T$, and the block size at epoch $t$ as $B_t$. Currently, the base fee then evolves according to the EIP 1559 rule:
$$r_{t+1}=\left(1+c\frac{B_t-B^T}{B^T}\right)r_t,$$
where $c=1/8$. Furthermore, the block size is restricted to $B_t\in[0,2B^T]$.

We propose replacing the target block size with a dynamic one, $B_t^T$ that is allowed to change over time according to network demand,
$$r_{t+1}=\left(1+c\frac{B_t-B^T_t}{B^T_t}\right)r_t,$$
where $c=1/8$. Furthermore, the block size is restricted to $B_t\in[0,2B^T]$.

The dynamic target block size would follow a similar updating mechanism of the general form
$$B_{t+1}^T=f(\Delta T_t, \Delta B_t; B_{t}^T),$$
which depends on the previous value of the target block size, $B_t^T$, on the change in the utilized block size, $\Delta B_t=B_t-B_{t-1}$, and the change in the given target function that is being maximized, $\Delta T_t=T_t-T_{t-1}$. As a simple example in analogy to first price auctions, the target function could be total network revenue, or anything else the network deems valuable. The target block size would be bounded within the region $B_t^T\in (0,B^T)$.

Further motivation and analysis

We further motivate this idea, as well as provide more details of possible formalisms that could work for the Filecoin network in this extended document.

[Stebalien]

I generally prefer this mechanism to the "batch balancer", but the motivation needs quite a bit of work.

As far as I can tell, the argument is based on two assumptions that aren't (yet, at least) true.

miners would generally optimize for maximum total network revenue

This is not true in the network as it exists today. As it exists today, storage providers use nearly all the network bandwidth to maintain and onboard storage, which means they pay for nearly all the gas.

In this scenario, storage providers do not want the base fee to go up because they'd effectively be giving money away to everyone not paying for network bandwidth (all the other token holders).

Of course, if other users burn tokens by deploying smart contracts, this may change. But we'd need to know:

1. Fraction of circulating supply coming from "holders" versus the block reward.
2. Fraction of chain bandwidth used by storage providers versus users.

myopic miners

This is obviously false. This is a fine assumption to make in a research paper about a theoretical system, but it it's not an assumption we can make when designing a real system.

Storage providers are not myopic and they don't make the majority of their profits on gas premium. As you noted, gas premium amounts to almost nothing, yet everything still works.

Everything still works because:

1. Storage providers make the vast majority of their profits on block rewards.
2. Storage providers are heavily invested in the network (hardware, vesting tokens, collateral).
3. If storage providers stopped including messages, the utility of the network would go to 0.

In other words, even if the utility of including all messages went below 0, I'd still expect storage providers to continue including messages for the same reason I keep showing up to work even nobody's paying me for each line of code I write.

TL;DR: We can't say "let's assume" and follow up with "therefore we should do X".

---

All of this isn't to say that we shouldn't consider a mechanism like this. We just need to live in the world as it exists, not as we define it.

Reasons to consider this mechanism:

1. There may be cases where higher base-fees are good for storage providers, but that requires more analysis and isn't something we can just blindly state.
2. Some minimal amount of burn is necessary to secure the network (from a technical perspective). Otherwise, "spam" is free.
3. I would generally feel more comfortable having a more direct mechanism encouraging inclusion of messages if/when capacity exceeds demand.

[AxCortesCubero]

Thanks for your comment!

On the first point, I completely agree, maybe this was a wrong oversimplification on my part when writing the "short version" for this discussion. But In the linked expanded document I indeed go in detail that the story is more complicated for Filecoin specifically, given that at least currently, our SP's are the largest consumers of gas, so it is unclear what is it they would want.

When I said "first price auction miners would generally optimize for maximum total network revenue", I meant more like "Bitcoin first price auction miners", where it is assume they don't have particularly significant gas expenses of their own. This is clearer in the extended version, but I agree it could be better explained in this short version.

About the question of what would Filecoin SP's want to maximize for, I have a section in the document investigating that, including the fact that they are large consumers of gas. It is indeed a much more complex question for Filecoin than something like Bitcoin, but here is my attempt at coming up with some target to optimize.

In the end, however, deciding what the target to optimize for is very much up for discussion. I am not proposing we should optimize for total network revenue, that would be one simple option to consider, but certainly not the only one. That is actually something I would like to get out of this discussion, some community feedback of what should be maximized for.

In the end I propose some formula for what I consider to be a reasonable target function for Filecoin. That formula is also a simplification, with some assumptions, considering myopic miners. But I personally am very open to hearing other suggestions for target function too, and I mention in a separate section, that this mechanism is sort of an open canvas, we are free to think of some quantity that as a network we'd like to maximize, and put that in there.

I think the core think I am proposing is **having an adjustable target block size, which adjusts to try to maximize some quantity we all agree upon". I have some simple suggestions for that target, but the best would be to gather some more community opinion on what should be optimized.

[Stebalien]

I think the core think I am proposing is **having an adjustable target block size, which adjusts to try to maximize some quantity we all agree upon". I have some simple suggestions for that target, but the best would be to gather some more community opinion on what should be optimized.

What I'm looking for here is a clear motivation.

When I said "first price auction miners would generally optimize for maximum total network revenue", I meant more like "Bitcoin first price auction miners", where it is assume they don't have particularly significant gas expenses of their own. This is clearer in the extended version, but I agree it could be better explained in this short version.

I'm just confused about why we're assuming that Filecoin behaves like Bitcoin when trying to motivate a Filecoin proposal. Can we just remove this assumption from https://hackmd.io/@cryptoecon/B10RGzlHo#Motivation-hyperdrive-and-batch-balancer? That'll make it significantly easier to understand.

That formula is also a simplification, with some assumptions, considering myopic miners.

Simplifications are fine, but then you need to argue why the simplification is valid. In this case:

• The myopic miner simplification is valid when arguing that the incentive mechanism is correct. If a mechanism is correct with myopic miners, then it'll be correct even with long-term oriented miners (baring any long-term disincentives to message inclusion).
• The myopic miner simplification is not valid when arguing that an incentive mechanism is necessary. In this case, you were arguing that EIP1559 is insufficient, necessitating a new mechanism.

[AxCortesCubero]

To be clear, I don't believe or assume that Filecoin behaves like Bitcoin, but I understand where that impression comes from when seeing your feedback.

My approach to communicating a complex issue was to first communicate an alternate version of the problem that while not the most correct is easier to understand. That's why I talk at length about how it would work in Bitcoin and Ethereum, because the dynamics are simpler and its easy to see why those miners would't want to optimize for lowest base fee, but for their own profit.

After this point is understood, I then introduce the particular difficulties and intricacies of Filecoin, that make the problem of defining a target function more difficult. So thinking about maximizing miner utility doesnt lead us to maximizing total network revenue as it does in Bitcoin and Ethereum, So this is not what I am suggesting to adopt for Filecoin. I still do think it was a useful exercise to walk through the simpler Bitcoin and Ethereum scenarios first.

I think if I start out my discussion saying I think we should build a mechanism to maximize for
$$T_t= W\left(\frac{S}{S-\sum_{j\in B\in M}rg_j}-1\right)-r\cdot B,$$
People won't really get what I am talking about and why I thought up that quantity. So this is my best attempt at walking them through that reasoning.

And in the end, even that final suggestion for target function, I want to make clear it is just the best suggestion I came up with, but definitely up for discussion. I was thinking of a target that as much as is possible maximizes the utility for most SP's. Is that what we want to do as a community, optimize SP utility? Not for me to decide

[DecentCr8]

It is very difficult to understand why protocol revenue is so important at this stage for Filecoiin, and why protocol revenue should be kept high even when network utilization is low.

It's also hard to understand why Filecoin researchers are considering increasing the gas fee, and believe that this is beneficial to the entire ecosystem, when almost all public chains are trying to reduce the gas fee to attract more users and ecosystem participants. It's like the owner of a store adds more tax for all products to try to get more income when there are no more buyers coming in. Do you really not worry about customers leaving? Shouldn't it be to build a good ecosystem and have a better UX to attract more people to join? or even lower the prices to make your store more attractive?

High protocol income is a good thing by itself, but this should be based on ecosystem prosperity. When the demand is almost over network capacity, it is reasonable to increase gas fee as a tool to control the flow, thus network protocol income will naturally be high. This is for security reason, and fully understandable. However, if it is not the case, I would think it will go to the opposite if keeping the high gas fee only for the high network/protocol revenue purpose.

[DecentCr8]

I am in favor of adjusting or optimizing the gas adjustment mechanism, but the goal is to lower the cost for participants, not to increase the protocol revenue.

1. Lower the gas fee: The last upgrade caused the gas fee of every kind of message to more than double, which increased the cost of all participants.

   • Consider lowering the Batch Balancer, or other measures to reduce the gas consumption at the balance point;
   • We can expect the gas fee can rise quickly when the user-programmed contracts are online, . Is there any room to adjust the Network Target? This is of course carried out under the premise of network security

2. Stablize initial pledge amount. This can be achieved by removing circulating supply from the calculation of the initial pledge and simplifying the calculation directly on block rewards. At present, the initial pledge is linked to the circulation, and it is an anti-incentive design. It results in higher staking requirements when fewer participants join, in turn discourage potential storage providers from participating. In the past two months, the initial pledge per sector has increased by nearly 50%, but the miner's income has decreased, which is unreasonable. This is bad for new comers.

[AxCortesCubero]

It is very difficult to understand why protocol revenue is so important at this stage for Filecoiin, and why protocol revenue should be kept high even when network utilization is low.

To be clear, I am not proposing that we should maximize for Total Network Revenue. That is an option that we could do, if that's what the community wants, but not what I was going for.

The main proposal here is: Standard EIP 1559 is a mechanism that aims to minimize base fee, that is what it is optimizing for. I present a mechanism that can optimize for some other target we deem important. It is also up for conversation to decide what that target should be.

I present the Bitcoin and Ethereum scenarios, not because I think they apply directly to Filecoin, but because they are a simple initial mental exercise to present and understand the problem space.

I don't know and shouldn't be the one to decide what the best target to maximize should be. In the extended document I do have one proposal at the end, where I go at length to discuss why Filecoin is different than Bitcoin and Ethereum, so total network revenue is not what would maximize SP utility. So I derive some quantity, that up to some approximations tries to maximize utility for Filecoin SP's (and it is not simply total network revenue)

What I had in mind is maximizing SP utility (and attempt to derive what that would mean). Still, maybe this is not what we want? it is up for community debate what we want to maximize for. But if we dont choose somethng, we are making the choice to maximize for low base fees.

[AxCortesCubero]

Stablize initial pledge amount. This can be achieved by removing circulating supply from the calculation of the initial pledge and simplifying the calculation directly on block rewards. At present, the initial pledge is linked to the circulation, and it is an anti-incentive design. It results in higher staking requirements when fewer participants join, in turn discourage potential storage providers from participating. In the past two months, the initial pledge per sector has increased by nearly 50%, but the miner's income has decreased, which is unreasonable. This is bad for new comers.

I feel like this is a different conversation. Maybe the formula for initial pledge can be redesigned? but It is unclear to me how it is connected to this proposal. Not sure if adjustable target block size can help minimize initial pledge, if that's what you mean?

Otherwise, I think this would go on a separate FIP discussion about re-thinking the initial pledge formula.

[anorth]

FIlecoin is different from many other blockchains in that its mission is to be a storage network. The core value proposition is secure storage. From this, I disagree that we should want to maximise protocol revenue captured through execution gas fees. Execution gas is a strategic complement to storage. Filecoin storage gets more valuable as execution cost decreases, because clients and applications can do more with the data.

Your note about the infinite blockchain "problem" is my dream. If all the messages cost only cents and we could satisfy an unlimited demand for them, then Filecoin would be a fantastically better platform for decentralised storage. Experience from other execution environments suggests that some minimal fee is necessary to control spam, but that that is the ideal fee level.

As @DecentCr8 points out, my dream world is coming around because there are huge amounts of development effort going into efficient and secure execution environments in other blockchains, rollups etc. I expect the Web3 world will see a dramatic decrease in execution costs though the maturity and adoption of these technologies and platforms. The same transformation must happen to Filecoin in time, with hierarchical side-chains, rollups etc. There is no room for sustainable value capture in execution fees.

I would however separate FIlecoin's core value proposition of proven storage from general execution gas. I think Filecoin should retain a specific fee for proving storage which is independent of the CPU cost of verifying a proof, and comes to form the bulk of FIlecoin's protocol revenue. Today that fee is mixed up with gas, but I will make a proposal to separate it at some point. I view the batch balancer mechanism as a somewhat awkward way to set a floor on that proof fee.

I ack that you have responded above that protocol revenue is just one possible target. However I posit that the desirable target is minimising user transaction cost / maximising available capacity, which if I understand correctly, is what you claim the current mechanism does.

I also note that your proposal would only kick in times of low demand, and disappear as demand emerged, perhaps relevant only for a short term. However there is very little extra protocol revenue to be captured with low demand; I don't think it could justify the complexity. Our efforts should be focussed on increasing demand instead by driving continued technological and product improvements to reduce costs and increase functionality.

[anorth]

Please take these as projections with very high uncertainty, but:

• I expect there to be quite a bit of differentiation in execution networks around dimensions like, e.g., security/trust assumptions, and these will give some pricing power to some networks.
• I would expect them to be sustainable in the same way commodity businesses like, say, grocery retailers are. They can capture a reasonable return to sustain business and subsistence profits, but with little room to raise prices to increase those returns above market.

Trying to come up with an analogy, maybe like gas/petrol/fuel stations (Filecoin) with attached corner stores (execution)? People come for the fuel, and might buy a snack in the store because it's convenient, even if priced slightly higher (worse cost structure than supermarket). But they'll never do their weekly grocery shop there, and if prices are pushed too high they'll stop buying snacks too, because there are cheaper alternatives around the corner.

(Someone will probably come and tell me that gas stations make all their profit on the grocery store. The analogy is weak because gas stations are themselves a commodity and lack pricing power).

[AxCortesCubero]

To double down on the imperfect analogy, before seriously addressing your other points, What I think is that gas stations would want to optimize their revenue on any front, whether it is from gas sales or from convenience store, and whichever of the two is generating the most profit at a given moment will help to sustain the two businesses.

On that note I think the analogy here works better the other way around, Filecoin is a set of convenience stores, competing with the big box super stores, however, we offer we offer other benefits, like the convenience of decentralization of our stores where you can get your stuff anywhere your car is. To be able to run this set of convenience stores, we must be able to sell gas to the users so they are able to get to our stores and buy our stuff. Filecoin gas stations, however, need to consume also a lot of gas for their operations, to move the gas trucks, to bring all the goods in trucks and keep the lights on. Filecoin gas station network will be sustainable if Filecoin gas stations are making profit, from either of their two sources, convenience store or gas sales.

The question here is, If Filecoin gas stations could have a say in the supply of oil (as they do in FPA gas stations), is there an optimal supply of oil that would be the best for them? One option would be to produce extremely large supply of oil, so gas prices go to zero, so that everyone can readily drive to their convenience stores at any time and they can sell more goods. Maybe that is the best, I am not sure. Maybe there is a better optimal point that balances their convenience store revenues, with revenues they could get also from gas sales minus their own gas expenses to keep their operations running.

[AxCortesCubero]

Your note about the infinite blockchain "problem" is my dream. If all the messages cost only cents and we could satisfy an unlimited demand for them, then Filecoin would be a fantastically better platform for decentralised storage.

A key element here is that this mechanism should not stop us from satisfying an * unlimited demand*, if that unlimited demand comes around. This however gives us a survival plan for where demand is not yet at the level of supply we have built.

Of course the best solution to most cryptoecon problems would be "we should have better demand" let's instead build nice features so everyone wants to use our network and demand catches up. That would be good, but that doesnt mean we can't work on both ends, and be ready to do the best with what we have, until demand arrives.

I also note that your proposal would only kick in times of low demand, and disappear as demand emerged, perhaps relevant only for a short term. However there is very little extra protocol revenue to be captured with low demand; I don't think it could justify the complexity. Our efforts should be focussed on increasing demand instead by driving continued technological and product improvements to reduce costs and increase functionality.

Also I do not see this as a short term solution at all, mainly because as you expressed too, I am optimistic about the progress in all the new scalability techniques. By the time demand for Filecoin picks up, I hope we have made so much technological progress that we are at the same spot again, that demand is still not where supply is.

About complexity, a main motivation here is actually to reduce complexity, specially by establishing a simple, future proof mechanism. I think for instance this is a more transparent and simple approach than the batch balancer. The batch balancer is also just a patch to address one particular technological advance that was introduced at some point (proof batching).

I dont know what will be the next hyperdrive-like innovation that comes to filecoin, and when that comes, we'll likely want to have a batch-balancer-like patch on top of that. This is a future of a variety of innovations and a bunch of ad hoc economical patches for each of them.

This is a simpler mechanism that tries to secure the optimal economic conditions for SP's regardless of whatever future innovations we make on the supply side.

[anorth]

that doesnt mean we can't work on both ends, and be ready to do the best with what we have, until demand arrives.

Ok but raising prices for customers is not an improvement. We (network and SPs as an aligned group) are like a pre-product-market-fit startup at the moment. Finding that fit and building growth in usage is primary. Squeezing nickels out of our early adopters is a tactical error. We can raise prices once a truly differentiated product has a firm and growing grasp on the market.

[anorth]

Having thought a bit more about this and crystallised some complementary ideas in #557, I would certainly prefer this proposed mechanism to the current batch balancer as a mechanism to provide some base fee support in times of low demand. I still think it needs to be carefully weighed against the much simpler option of just raising the floor on base fee, but anything that gets us toward removing the batch balancer is welcome.

[dmc314]

Here is a summary and comparison table with some pros and cons of transaction fee mechanisms that might be helpful background:

[anorth]

Another alternative to add is simply increasing the base fee floor, a trivial parameter adjustment which would increase gas costs at low utilisation.

However, this table assumes that increased network revenue, or "miner utility", from burning more gas fees is a good thing. In my view, the real problem/issue with the proposal is that it increases costs of using the network, particularly to end clients/users. Even if it were simple and SPs weren't the dominant consumers of gas, I do not think this is wise for the network at this stage of development. I think we must gain alignment there first before getting too deep into mechanisms.

[dmc314]

I absolutely agree that we don’t want to drive fees up in such a way that drives away our valuable network participants. The way I think about this proposal is more of a second order effect than a first order one, so not gigantic price movements...and it may be the case that there is enough slack in the parameter space to increase aggregate miner utility, (or quantity X, or quantity Y…) before individual users or storage clients or stakeholder Z would even notice a change in base fee. In which case…why leave that value on the table?

It all needs to be modeled to understand the magnitude of impacts better, of course - both in a current world and in future likely scenarios.

[anorth]

This proposal suggests that burning more gas fees is beneficial for SPs, "maximising miner utility". @Stebalien brought this up, but I'd like to more explicitly request analysis of who benefits when tokens are burnt, and the sizes of their interest, for context on this any any future proposals. A couple of big categories would include:

• Current SPs according to (a) their pledged and vesting funds, and (b) rewards due to existing sector commitments (we can simplify to something like assuming ~3y commitments, or parameterise on this).
• Genesis investors vesting on-chain
• PL vesting on-chain
• Other token holders
• Market participants with escrow or collateral funds

I would assert that current SPs don't have interests in the entire not-yet-minted reward, beyond that due to already-committed sectors. Future SPs will, but they will take a cost base of the tokens at the time they purchase and pledge them – any network revenue today doesn't benefit them. Similarly the unallocated mining reserve is held by the network, with no particular interested party today.

So who actually benefits when a token is burnt? Of course, a change that is good for the network as a whole may not have equal benefit to different groups, but we should still understand which parties benefit how much.

[AxCortesCubero]

This is actually a very important question here, and happy you brought this up for this discussion. A key aspect of this discussion is trying to decide as a community "what is a good target", and I explicitly don't want to propose a specific one at this stage, this is not a question for me but for the community. But exactly, a "good target" begs the question "a good target for who?".

My initial thoughts are that a target for this base fee formalism should be about "maximizing SP utility", (once that is accepted it is an entire other difficult question to formulate a target that represents SP utility). My thoughts for using this principle of SP utility was based admittedly on these preliminary meditations on Bitcoin and ETH, that miners would try to maximize their utility with these mechanisms, and that if miners are too unhappy that puts the network at risk.

One could think of targets for other groups, of course passive token holders are a potential beneficiary of increasing total burn, in the sense of introducing a new deflationary pressure. PL is a large token holder, so in this sense benefits too.

It think this gets into less savory questions like talking about token price, because in the end a passive token holder just wants the token price to go up. So maybe they would want to focus on a number of things, not just token burn. But presumably having a strong useful network would be beneficial to the price, so token holder should want network power growth, onboarding and all that, because speculatively that should bring real value to the network, so They would have different things to balance for their own target. In any case I don't think passive token holders should be the basis for choosing a target to maximize, but that's just my opinion.

I'll add that I think transparency is important, that is a part of this proposal, say in comparison to the Batch balancer mechanism. Batch balancer does something similar to what I propose, which is regulate how much "supply" the network releases, given the level of demand, to not release too much supply when it is not needed. However it is obscure how it makes this decision, this is hidden in the parameters of batch balancer mechanism, and it is not transparent what it is optimizing for. I would like to present a network target we all agree upon, front a center, and be able to say explicitly this target is what we chose to maximize with this mechanism, and should be easy to understand and follow how the mechanism is trying to optimize that target.

[dmc314]

Here are a few ideas for the Target Function inside the Adjustable Block Size mechanism that may be worth exploring.

These are the two quantities that Axel mentioned in his extended writeup:

• maximize utility to the miners
• maximize a term that sums utility to the miners and network power growth

But what about…

• maximize the miner utility while also minimizing base fee
  -- Could formulate this as the ratio of total_network_revenue / base_fee
  -- Or formulate as a sum of normalized values like: (network_revenue/max_network_revenue) * (gamma) - (base_fee/max_base_fee) * (1-gamma)
  -- Where gamma is some factor that emphasizes network revenue as you dial it up to 1.0 or base fees as you dial back to 0.0.
• or somehow include the total_%value_locked or circulating_supply such that the network minimizes base fees when those economic indicators are growing…but will maximize network revenue if those indicators are declining.
• minimize energy consumption or latency by preferring messages that traverse a shorter network distance (calculated by the XOR distance or some algorithm as a proxy for physical distance? Could use Filecoin Green data, but would it be comprehensive enough for such calculations?)