Open dnkolegov opened 2 years ago
If you mean pulling a light client implementation into the orchestrator? That seems unnecessarily complex.
The orchestrator is expected to be run against a trusted full node (as are all applications that accept any sort of rpc url)
So the idea is to use the last committed event nonce from the majority.
For example, there are 4 validators called A, B, C, D: A, B, C agreed that the last nonce is X, and D's last nonce is Y (intentionally or not).
If the target relayer gets the last nonce from D then he gets Y, if the relayer gets the last nonce from B, he gets X. Then the result will depend on is X > Y - replay - or X < Y - the sent message will not be committed by the majority.
Now the question is what are the requirements for relayers.
For example, one of the requirements to relayers in IBC that
Packet relay liveness properties of IBC should depend only on the existence of at least one correct, live relayer.
*
Some questions to clarify the settings:
How many live and correct relayers do you suppose?
What do you mean by trusted node? Does that mean that the adversary is not Byzantine?
The orchestrator is expected to be run against a trusted full node
My understanding is that even if a node is trusted that doesn't mean that it is correct. In this case, correctness
means to know real last event nonce
.
A relayer gets the last event nonce from the corresponding validator - https://github.com/LeastAuthority/althea-net-gravity-private/blob/775df9bcf64950811cd77717937169d9f88e851b/orchestrator/orchestrator/src/ethereum_event_watcher.rs#L114
Isn't it better to get the agreed nonce using Cosmos consensus API (Tendermint)?