Split gas_limit

[MaksymZavershynskyi]

We need to split gas_limit into transaction_gas_limit and receipt_gas_limit, instead of dividing gas_limit by 2, because 2 is a magic number which should avoid from having in our protocol.

[evgenykuzyakov]

Blocked on discussion about shard congestion, because the current split might be deprecated based on the result of the discussion

[MaksymZavershynskyi]

@evgenykuzyakov to follow up with discussion on how this should be done.

[evgenykuzyakov]

Blocked by #2196

[evgenykuzyakov]

Blocked on new Economics. It's still unclear how gas price should be determined.

[MaksymZavershynskyi]

Since we are launching a single-sharded Mainnet, multi-sharded economics is not a priority for the Mainnet launch, and so we can keep the way it is currently done for now.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[bowenwang1996]

We should take this into consideration while researching gas price auction. cc @abacabadabacaba

[aborg-dev]

We will be tackling this as a part of Local Congestion Control work. More specifically in #8877, the split will be based on the amount of space left in delayed receipts queue, going to 0 when there is no more space in the queue to add new receipts from the transaction pool.

[jakmeier]

We will be tackling this as a part of Local Congestion Control work.

@Akashin the work on local congestion control has concluded for now, right?
My understanding is we haven't really change the tx/receipt gas split, yet. But maybe we will change it in the future when working on global congestion control. Can you please confirm or deny?

[aborg-dev]

We will be tackling this as a part of Local Congestion Control work.

@Akashin the work on local congestion control has concluded for now, right? My understanding is we haven't really change the tx/receipt gas split, yet. But maybe we will change it in the future when working on global congestion control. Can you please confirm or deny?

That's correct, I was initially planning to change this part but couldn't do it because we don't store information about the total attached gas of the delayed receipts in an easily consumable format (right now, we would need to compute it by iterating over all delayed receipts). So for now the limit is just based on the number of delayed receipts, but for global congestion control we would need to store the aggregated attached gas in the chunks anyway and so implementing the feature I've described in #1700 (comment) would become easier.