I need to execute some list of signed extrinsics in order, but because of the randomness that can exist in the transaction pool I have no way to actually ensure that they will execute in the proper order, another option would be to wait until one is included in a block and then send the next one, but this takes way to much time. enter image description here

Is there a way to create a pallet extrinsic that has a batch of already signed extrinsics for a different pallet. And then have this batched extrinsic dispatch the list of signed extrinsics to the proper pallet all inside the execution of the batched extrinsic?

enter image description here

This would ensure the order of execution of this signed transactions. What would be the best approach for this??

enter image description here

  • I think you can create a storage entry in the Some_Pallet to store all extrinsics (ordered by an index). Once that storage hits a target length your pallet goes ahead and execute all extrinsics (or you can create another extrinsic to do that), something like what the pallet-scheduler does. Another approach would be adding timestamp to the equation here, but then you'd need to tweak the transaction pool logic. Aug 15 at 16:26
  • What are you actually trying to do? Sure the transaction pool has some randomness, but this is completely orthogonal to the runtime TX acceptance criteria. And how is the trust assumption? Since currently as soon as the user signs a TX, he signals that it is good to include immediately. Does the users have to trust this batcher? Aug 15 at 17:24
  • The goal is to perform a transaction replay to recreate the state of an already existing chain. Now in order to do this all transactions need to be sent in order. One way to do this is to send a transaction for each block that way we can ensure that it will be in order, the downside is that is way to slow. So I am looking for alternatives to send the transactions in order Aug 24 at 17:41
  • do you want to exactly recreate the state? Bear in mind that as soon as there is a timestamp component/input in the relevant blockchain, just having the same transaction order since genesis is not enough (goes without saying that every other parameter has to be exactly the same too). Why can't you simply do a snapshot / copy of the original chain and take it from there?
    – Iker
    Aug 28 at 9:51
  • We have already taken the timestamp into account and we have some measures to deal with this. The chain that we need to migrate is an EVM based chain that we will be migrating to Frontier. Snapshot migrations was the best option and we had a working solution for that but sadly this strategy would mean that there will be a big downtime between stopping the original chain, extracting the state and putting it inside the new chain, so we are looking into other alternatives. Tx replay will allow for minimal downtime compared to snapshot migration Aug 28 at 14:01


Your Answer

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

Browse other questions tagged or ask your own question.