For example, initially the ledger state version goes like 1 - 2 - 3. At this point, the validators collectively agree to make a fork based on version 2. So the ledger history now looks like 1 - 2 - 3’ - 4’.
Before the fork, a client already has knowledge about state version 3. Now it queries the network and gets a new state 4’. How can it detect the fork and find out 4’ is not a successor of 3?
Hi @the729! In this case, the client would perform a query with a “known version” of 3. This would result in a proof coming back relative to this known version. Let’s say that you have seen 3 which has a hash of 0x1234. Now you will get a proof of 4’ relative to 3’ (because the validator is returning a proof relative to what it thinks is version 3). Based on the resultant proof, you will be able to detect that the returned values do not match up to the hash you expected to occur at 3 (0x1234 in this case).
Is this logic currently implemented?
I didn’t see any difference in the responses to whatever client_known_version I gave to UpdateToLatestLedgerRequests.
The response only includes ledger info with signatures from the validators. And I don’t see any code verifying the relativity from client_known_version to the current version.
You are correct that it is not yet implemented. It’s on our roadmap but hasn’t yet been finished
I see you have implemented Waypoint and LedgerConsistancyProof. It’s time to bring up this question again.
According to #1384, Waypoint properties and debate #2: “…if we suspect that there might be a fork in the current epoch it means we don’t trust the current validator set and we should absolutely move to the next epoch anyway.”
My question: Could you elaborate this statement a bit?
To make use of LedgerConsistancyProof, the client needs to keep track of not only the root hash of the current known version, but also the hashes of frozen subtrees.
Waypoint is simple and short, and easy to use, but does not contain the subtrees to prove consistancy within an epoch.
My suggestion: Include frozen subtrees into LedgerInfos at epoch boundaries, so that these information also gets hashed into the Waypont and returned with ValidatorChangeProof, along with next validator set. Thus, by verifying a Waypoint, a client can also learn the frozen subtrees, with which it can make use of LedgerConsistancyProof and detect forks in the current epoch.