5

Currently, Astar network's transaction volume has increased drastically and we are having some trouble prioritizing the tx queue.

With EVM, there are many RPCs like eth_gasPrice,eth_feeHistory, and EIP-1159 to understand more or less what is the optimal gas price for the transaction to pass within a large tx queue. However, from what I understand, Substrate does not have this kind of RPC for native transaction tips, meaning that the tip value is completely up to the user's arbitrary input. And if we consider that the EVM transaction also has its own gas value with transaction priorities, how will this work with the native transaction pool?

So my questions are as the following:

  1. Is there a way to calculate the optimal way to calculate the ideal tip value?
  2. Will the EVM transaction affect the tx priority for native transactions (I assume it does)? If so, will the EIP-1159 method of calculating the gas cost affect the required tip value for native transactions?
  3. Would it be reasonable to directly use the EIP-1159 gas station and use the optimal gas price as the tip value for the native transaction?

Edit: I noticed that there is a function called get_priority and storage called NextFeeMultiplier in the transaction-payment pallet. Could this be related to the solution?

Improve this question

1 Answer 1

Reset to default
6

The Substrate transaction queue uses solely the transaction priority passed via the SignedExtension API to prioritise which transactions make it into a block.

I'm not at all familiar with EIP-1159 and the Ethereum transaction queue. However this really shouldn't impact Substrate: you are presumably using a SignedExtension impl which understands the concept of gas and gas-price for your transactions which result in an EVM execution. This impl would calculate a priority based on gas/gas-price. You'll need to analyse how this priority is determined based on gas/gas-price, and then compare to how priority is determined based on tip (which can be found in ChargeTransactionPayment). By combining these two equations, you can calculate a tip which provides (approximately) the same priority as any given gas/gas-price.

For what it's worth, the regarding the tips, the priority is calculated as:

priority := max_fitting_in_a_block * (tip + 1)

max_fitting_in_a_block := min(tx_weight_per_block, tx_size_per_block)

tx_weight_per_block := max_block_weight / tx_weight
tx_size_per_block := max_block_size / tx_size

This is a little complex, but basically increasing the tip by 1 will increase the priority by the maximum number of these transactions which will fit in a block (limited by either the maximum block weight or size). I'm not against revising this in order to play better with alternative prioritisation systems. See https://github.com/paritytech/substrate/issues/11405 for my current thinking.

Improve this answer
1
  • Thanks for the insightful answer. I guess if we want to avoid having the native tx always having a higher priority over EVM or vice versa, reverse engineering and creating a universal fee/tip calculator is the best solution. Adding the tip by 1 is the solution we were using now, but understanding when to increment it again was the challenge since at some point the queue will fill up with 1 tip
    – Hoon Kim
    Commented May 12, 2022 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.