Light protocol get_tx_info() validation

[yangzhe1990]

There is a FIXME in get_tx_info about not having non-existence proof.

The current situation is, that we have existence proof, however a block may contain the same transaction for two times, one executed fail due to incorrect nonce, the other succeed. We can also have the same transaction in multiple blocks in the same epoch, or in different epochs.

To summarize I think there are several issues:

1. Positive get_tx_info returned with a zero transaction execution gas should be dropped; An honest node never return such non-executed transaction.

2. For a non-existent reply from peer, the light node can only request another peer. If the light node maintains the most recent blocks, it's possible that the light node check for all epochs where the transaction is packed into, however to check if the transaction is executed, the light node must check the executed nonce of the sender by getAccount, then also rule out other transactions from the same sender with the same nonce by getting receipts for other transactions.

3. To update the reputation of the peer, keep in mind that the status of the transaction can only change after the epoch where transaction is executed. Where is the executed epochs of the peer? Is an attack taking place so that different peer see different pivot chain? The rpc request must be bounded with an epoch range.

We should figure out:

a) How is get_tx_info useful for the light node. Is it only required to answer client rpc request;
b) Shall we remove the support of transaction receipt for light node? User should connect to a trusted full node for this feature;
c) It seems that the best solution to this problem is to maintain block receipts in a hash based receipts trie for a defined number of epochs and include the root into the block hash. However it's will be hard fork to support this because it changes block structure definition.
d) Should we implement 2)? It's significant amount of work to implement, but it seems to solve the problem of retrieving information and figuring out malicious peer without a hard fork.

[yangzhe1990]

A clear formulation of 2) is, for each get_tx_receipt request, the request should mention the epoch hash range (root_now, epoch_range_back). We first check if root_now is on our pivot chain. and if we are willing to serve state request for height(root_now) - epoch_range_back. Denote the concerned tx's nonce as target_tx_nonce.

Light node / Full node should serve "get_executed_transaction(sender, nonce, root_now, epoch_range_back)".

There are 4 cases:

1. the transaction is executed within the range (root_now, epoch_range_back);
2. the transaction is executed earlier than (root_now, epoch_range_back).
3. the transaction is not yet executed.
4. Unable to serve the range (root_now, epoch_range_back) for different reasons. e.g. pivot chain mismatch, range too old.

For case 1. The full node must reply exactly one transaction, The light node should check if the transaction matches the rpc query.
For case 2. The full node should reply with the sender.nonce at the state of root_now - epoch_range_back epochs ago, and sender.nonce must > target_tx_nonce .
For case 3. The full node should reply with the sender.nonce at the state of root_now.
For case 4. Light node can perform a check, if passed forward the full node's response.

[Thegaram]

Thank you for bringing this up, this is definitely something that needs to be improved.

I will look at your suggestions and add my thoughts. I think a straightforward approach would be to request tx info from multiple peers by default; if the node is not eclipsed, this minimizes the risk. There is still some risk though, and this approach might also add a lot of network overhead.