Transaction status query routing

[bowenwang1996]

We previously removed the routing for queries and in the process deprecated requests for receipt outcomes. Even though we did not remove transaction status query routing, it is effectively broken: if the transaction is first executed on the shard that the node tracks and later on sent to a shard that the node does not track to be further executed, it will trigger a request for receipt execution outcome, which we already deprecated (the response is removed from RoutedMessage). Given this, should we deprecate tx status query routing altogether? @frol

[frol]

@bowenwang1996 does this mean that to get tx status you need to have a node that tracks all the shards? This sounds unfortunate 🤔

[bowenwang1996]

Yes potentially. I thought we agreed on something like this a while ago. Did something change?

[bowenwang1996]

Alternatively, we could build a separate communication protocol for rpc nodes to route requests between a predefined set of peers. Then you can run one node that tracks each shard.

[frol]

I vaguely remember the conversation, but I feel uneasy making light-client-related decisions. That is a complex topic and I need to wrap my head around all the concerns in the space to make a tradeoff decision.

[frol]

@bowenwang1996 in the light of sharding, if we deprecate transaction status query routing, we effectively deprecate tx status endpoint from PRC since if we assume that no single computer can track all the shards, we won't be able to resolve tx status in general case.

It always felt suboptimal to me to use p2p to "query" data, so I see the following solution to the problem:

We can break apart the tx endpoint into small ones (get_transaction, get_transaction_outcome, get_receipt, get_receipt_outcome), and let JSON RPC clients to resolve the tx status on the client side.

Pros:

• JSON RPC server logic is much simpler (the data is either exist in the local db or not, and you just return it immediately instead of broadcasting a query through p2p and awaiting some result blindly)
• We can drop p2p support for this cumbersome tx status query

Cons:

• JSON RPC client gets more involved
• It might be less efficient due to network latency (on the other side it might be faster since the client will be able to pull out the information while the transaction is still getting executed, and we can also leverage load balancer to query receipts from several nodes)
• JSON RPC client now has to know where to query the data from (if RPC nodes do not track all the shards)

It is still not clear to me what role our light-client node should play. Without p2p routing for queries and tx status the only use for the light-client node I see is broadcasting new transactions. Can you shed some light on the light-client node role?

/cc @miraclx @volovyk-s @thisisjoshford (this decision will affect DevX and near-api-js / near-api-rs implementations)

[bowenwang1996]

Can you shed some light on the light-client node role?

I don't think light client is super relevant here. They can be used to verify the existence of transactions/receipts with proofs, but not really related to query routing.

[frol]

Just for the record, I created a tracking issue (it was half-written already): #4404