`/block/transaction` block_identifier parameter as required parameter

Hi!

We are working on the /block/transacion method implementation. The spec states:

Calling this endpoint requires reference to a BlockIdentifier because transaction parsing can change depending on which block contains the transaction. For example, in Bitcoin it is necessary to know which block contains a transaction to determine the destination of fee payments. Without specifying a block identifier, the node would have to infer which block to use (which could change during a re-org)

We don’t need the block to do any calculation although, as you mention, the transaction might be included in a different block due to a re-org. Shall we check the transaciton is included in the block received as parameter or is that optional?

Thanks!

Hey @alan.verbner, thanks for reaching out!

I would highly recommend that you check that the BlockIdentifier provided in the /block/transaction request contains the requested transaction. This is for 2 reasons (only the second of which sounds like it is applicable to your implementation):

  1. Block requests in Rosetta (all data retrieved for a BlockIdentifier using the /block and /block/transaction endpoints) are considered strictly idempotent (i.e. each request using the same BlockIdentifier must have the same response). If you do not check the request BlockIdentifier and there is a re-org, there is a chance that the transaction you populate incorporates data from a different block (i.e. pays out a reward to a different miner) and breaks this idempotency guarantee. @matheusd put up a PR to clarify this requirement in the specifications:
  1. Checking the BlockIdentifier is a great way to catch any bugs in your implementation (where you direct the client to fetch transactions that aren’t included in a given block) or in the code of clients of your implementation (where transactions are requested on incorrect blocks).

Happy to discuss further if checking for transaction inclusion would incur some significant performance penalty!

Thanks @patrick.ogrady

Yes! definetly our main use case is related to the second item. I’ll add it to the backlog and keep an eye on performance as it might an extra JOIN at least.

Thanks!

1 Like