You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
txpool submit as Brandon said should return the result of tx inclusion inside txpool. When somebody wants to submit a signed transaction it needs to be sure that the transaction is already checked and with submit the user tell us it's the intention to commit, it is mostly a point of no return because tx is going to be broadcasted to the network.
There is an idea of the pending block, where the Block producer will every N second take best T transactions and with its best ability create pending block so that users know what to expect (this is just usability, it shouldn't have any effect on consensus) and can inspect executed transactions.
There should be the ability to dry run tx (or maybe even a list of tx if they are dependent) so that users can see gas used and calculate the gas limit. Dry run over the pending block or dry run over the best block. This can be even extended to: with this gas_price where is this transaction going to land inside the block and what amount of gas is going to be used, there are some MEV vibes here but seems like a topic for the future.
The text was updated successfully, but these errors were encountered:
This is different, it gives you best guess on next block that is going to be created and it better reflects changes that are going to be merged into canon chain.
dry-run is still needed for gas estimations, testing, getters etc.. but this dry-run is agains pending block not agains best known block, and user can chose if he want pending, best or past block to dry-run agains.
txpool submit as Brandon said should return the result of tx inclusion inside txpool. When somebody wants to submit a signed transaction it needs to be sure that the transaction is already checked and with submit the user tell us it's the intention to commit, it is mostly a point of no return because tx is going to be broadcasted to the network.
There is an idea of the pending block, where the Block producer will every
N
second take bestT
transactions and with its best ability create pending block so that users know what to expect (this is just usability, it shouldn't have any effect on consensus) and can inspect executed transactions.There should be the ability to dry run tx (or maybe even a list of tx if they are dependent) so that users can see gas used and calculate the gas limit. Dry run over the pending block or dry run over the best block. This can be even extended to: with this gas_price where is this transaction going to land inside the block and what amount of gas is going to be used, there are some MEV vibes here but seems like a topic for the future.
The text was updated successfully, but these errors were encountered: