ava-labs / hypersdk

Opinionated Framework for Building Hyper-Scalable Blockchains on Avalanche
https://hypersdk.xyz/
Other
193 stars 100 forks source link

[chain] Add `base.Tip` on top of `base.MaxFee` #717

Open patrick-ogrady opened 7 months ago

patrick-ogrady commented 7 months ago

We can prioritize transactions even with multi-dimensional fees by allowing a fixed fee tip (not based on unit prices, looks like a payment) to be paid on top of the MaxFee rather than extracting from the delta between paid fee and MaxFee.

It is unclear what aspects of this joint fee should be paid to the chunk producer vs burned by the network. A simple approach (that makes it easy for producers to prioritize) is to just burn the usage contribution and send the tip to the producer.

aaronbuchwald commented 7 months ago

My initial thought for this was that if we switch from paying a tip per unit of gas to a fixed fee paid to the producer, it makes the profit maximizing strategy for block builders much more complex.

For the simplest case of the EVM consuming a single dimension of fees gas, it's simple for a block builder to create the profit maximizing block.

The block builder can simply execute transactions sequentially in order of the highest effective tip, since this will pay them the highest possible tip for the space that they are taking up in the block (small caveat: there could be edge cases where they're not able to fully fill the block and a different assortment would have been more profitable).

If block builders instead received a fixed fee per transaction they included, then they would need to reason about how many transactions they can fit into the block. For example, if txA consumes pays the highest fixed tip of 1 ETH, but would consume all of the gas in the block, then the block builder may be better off by building a block containing three transactions that each pay a fixed tip of 0.5 ETH.

Definitely different when applying this to chunks and handling rewards/fees for users/chunk producers/block builders.

patrick-ogrady commented 6 months ago

If block builders instead received a fixed fee per transaction they included, then they would need to reason about how many transactions they can fit into the block. For example, if txA consumes pays the highest fixed tip of 1 ETH, but would consume all of the gas in the block, then the block builder may be better off by building a block containing three transactions that each pay a fixed tip of 0.5 ETH.

Good callout 👍

patrick-ogrady commented 6 months ago

May make more sense as an additional % of the fee paid (bounded by MaxFee * % Tip). You could then sort mempool by this % (may want to set a minimum %).

github-actions[bot] commented 4 months ago

This issue has become stale because it has been open 60 days with no activity. Adding the lifecycle/frozen label will exempt this issue from future lifecycle events.

patrick-ogrady commented 3 months ago

@dhrubabasu mentioned an interesting paper that could be used to help pack blocks in a MDF world.