Nano-node: RPC - Find receive block for given send block

[arranHarty123]

Provide a block RPC call to find a receive block (if processed) for a given send block.

I believe the passed hash parameter (of the send block) would be the ‘link’ value for a receive block.

In terms of the requirement:

As a Nano Visualisation Developer, I want to efficiently grab the receive block for a send hash so that I create key links in an account visualisation.

[clemahieu]

Right now we don't normalize this data because it's unnecessary to ledger processing i.e. there's no simple way to query this.

I do see a compelling reason for people to want to query this though so it's a use-case/space efficiency tradeoff.

We could implement this in a couple of ways, one would be whole-chain searching from frontier back to genesis to see if it's been received. This could potentially be a long operation for deep accounts. You can also do this now by finding the frontier of an account, calling the "chain"/"block" rpc to get previous blocks, and then querying their contents.

We could also store this information per-entry. Send blocks point to their receive, receive blocks point to their send. If it's not associated with another block, a sentinel value. This would require a database upgrade or maybe a lazy-constructed table which would be less space-efficient.

We already have precedent for storing information like this i.e. successor, which isn't needed for ledger processing but it speeds up a common query.

We'll take a look.

[Srayman]

I always thought it strange that for a send block the “link” is the receiver account but for a receive block the “link” is the send block hash.

I would be in favor of changing the “link” to always be the connecting block between send/receive, but not sure if that’s the best option, considering the magnitude of 3rd party changes that might be required as a result.

Another option could be similar to the account_history account_filter optional parameter but also add a local_timestamp filter so it retrieves blocks > timestamp filtered for the sending account which should narrow the blocks to check.

[cryptocode]

@Srayman I think it's because the RPC field names mirror the nomenclature used in state blocks where link is source block hash when receiving and account when sending. In state blocks sends, link has to be account since there is no receiving block hash yet.

[Srayman]

That makes sense and I understand the reasoning. Was just confusing when I first started working with the RPC’s having the same field mean different things, but makes sense considering how send/receives are processed at different times.

Also the link_as_account in block_info for receive blocks is confusing since it doesn’t point to anything meaningful, while it points to the receiving account for send blocks. Not sure if that’s a bug or intended to be that way.

Not trying to say the link has to change, but if there’s opportunity to make it more consistent, just adding my 2 cents from when I first looked at it.