4

We recently had a sale of node licenses. Sales were handled through our NodeStore program, and started at a specific point in time. So we saw a lot of transactions in the first few seconds, and the price went up quickly.

Now, looking at these transactions in the Explorer, I can only see the block time and slot number, but no sequence within the block.

Is it possible to inspect on the blockchain in what order transaction inside a block got executed?

If so, how?

1 Answer 1

6

Technically there is a sub-block transaction execution unit called an Entry. Transactions in an Entry have data dependencies and are executed serially. However the Entrys themselves are independent and may be executed in parallel, with no guarantee on ordering between validators. The RPC API does not expose Entry information and even if it did, this information is not valuable as it is only the execution ordering of a single validator.

TL;DR, it doesn't matter. Blocks should be considered atomic units of execution and the transactions they include having been executed at the same "time"

6
  • 1
    Oh wow that is interesting. However, in our case, our transactions "grab" some objects (called "nodes" in our case), that are stored in PDA accounts, increments the number of nodes that are taken (in a counter in a PDA), and then the price for folks that come later goes up. So for us, and our customers, the sub-block order matters A LOT :-) I was assuming my transactions (which are single instruction transactions in our case) were atomic so that if a node is "taken" it is "taken", and nobody can take it afterwards. Now it seems like it can? On a different validator? Jul 16, 2022 at 19:51
  • 1
    After reading again, here's what I think: All our node purchase transaction must be together in an entry, because they have data dependencies. These are executed serially, phew. Only DIFFERENT entries can run in any order. Is it documented (i.e. decodable from the block) in what serial order the individual transactions (that have data dependencies) got executed within the entry? I hope so and believe so... Would be a great addition for an explorer to output that info? Jul 16, 2022 at 19:56
  • 1
    it sounds like those would be the serially executed transactions with data dependencies that i mentioned. they'd all be in the same entry and ordering preserved. RPC just flatmaps the entries into a vector of transactions, so I'd assume all of your program's transactions that share the same counter PDA will be roughly consecutive in the RPC response and ordered as executed
    – trent.sol
    Jul 16, 2022 at 19:59
  • 1
    That's what I guessed after reading twice, thank you. My situation is: I have a bunch of people (rightfully) asking why they paid $700 for a node while others got it for $100. It all happened in a few seconds. So I want to show them in what order they were executed, and everything went legit. Is there some document that describes the binary format of a block, so that I can figure out how to find the information there? I.e. for each transaction the Entry number, as well as the intra Entry serial number? Any hint that points me in the right direction is appreciated! Jul 16, 2022 at 20:04
  • the code is probably the best documentation in this case. like i said, RPC elides the Entry information, so that won't be a viable data source. you'll need to get raw ledger archive snapshots, and likely hack up solana-ledger-tool to do what you want. this method is probably a good start
    – trent.sol
    Jul 18, 2022 at 18:43

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.

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