feat: sketch the spec of feemarket module

[yihuang]

Description

WIP #9963

Merge the idea of feemarket module in ethermint
into cosmos-sdk.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[tomtau]

FYI @fedekunze

[tomtau]

FYI @hxrts #8224 (comment)

I think the spec is quite straightforward. I'd suggest opening a PR with ADR first though, because the overall impact is unclear from the spec itself. A few points off the top of my head I'd like to see:

1. interaction with the Tendermint 0.35 mempool prioritization: this spec sketch doesn't seem to include the EIP-1559 "tip mechanism"
2. upgrade transitions: should one init the parameters in the same way as for genesis, or one could do better in upgrades where there's the previous block info?
3. the "disable empty blocks" option in Tendermint: could it still work when the gas price info is being calculated in every block?

[liamsi]

Suggested change

	The feemarket module implements a base gas prices in consensus level.
	The feemarket module implements a base gas price at the consensus level.

or: base gas prices

[hxrts]

Excited for this! So you're aware, there is some work from the tx working group (see WG links here) that you may want to be aware of. Would also be good to get someone on the arch/planning calls to coordinate (@tomtau just added you).

[yihuang]

FYI @hxrts #8224 (comment)

I think the spec is quite straightforward. I'd suggest opening a PR with ADR first though, because the overall impact is unclear from the spec itself. A few points off the top of my head I'd like to see:

1. interaction with the Tendermint 0.35 mempool prioritization: this spec sketch doesn't seem to include the EIP-1559 "tip mechanism"

Since we validate the tx.Fee() >= expectedFee, user can always pay fee higher than minimal one, it's just we don't order the mempool based on the tip fee, the good thing is we don't need to change tx format (change the fee fields) in this proposal, I guess we can do that together with the mempool prioritization change.

2. upgrade transitions: should one init the parameters in the same way as for genesis, or one could do better in upgrades where there's the previous block info?

it seems not much difference for genesis or in the middle of the chain.

3. the "disable empty blocks" option in Tendermint: could it still work when the gas price info is being calculated in every block?

The base gas price overall will be higher with "disable empty blocks", since the empty blocks will have the side-effect of lowering the base gas prices.

[hxrts]

1. agree, we would ideally do this together with mempool prioritisation, which is essential for creating a functioning fee market. @alexanderbez likely has the most context + @cmwaters wrote this in response "To me it seems the way fees are calculated and the use of them as a measurement of priority in the mempool are largely orthogonal and I don't foresee any issue with this persons proposal and the prioritized mempool"
2. I like the idea of persisting the fee across upgrades (one less thing to think about), in either high or low-fee scenarios it seems like the worst case would be a price correction over the course of a few blocks. I think we may still want to ensure the fee is non-zero.
3. This is an interesting case. Seems like we may not know the real gas fee if we don't know the number of empty blocks. This should only happen if there are no transactions in the mempool with fee >= minfee, which means the minfee should either be falling, or its at the absolute min and there are no transactions at all. In either case I think we can maybe assume validator altruism and have them absorb the gas cost. Open to suggestions here though.

[amaury1093]

Would it be possible to add another .md file for how the state (kv store) looks like? In particular:

• under which key is this total gas stored in the substore? (e.g. 0x0)
• which encoding to use for the integer?

Also see SPEC_SPEC for more info.

[fedekunze]

I don't understand why is this being added to the SDK, why rely on another dependency for Ethermint (DynamicFeeTxs) and the JSON-RPC? the timelines and release cycles for both projects are very different

[tomtau]

I don't understand why is this being added to the SDK, why rely on another dependency for Ethermint (DynamicFeeTxs) and the JSON-RPC? the timelines and release cycles for both projects are very different

the context is "Consensus Fees" WG for Cosmos SDK: #9058
#8224
#9962 #9963

So it's a separate effort and the only relation is that it may get inspiration for the implementation.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[yihuang]

need to redo this, closing now.