spec: Detector refactor

[josef-widder]

Following a discussion with @OStevan about #446, I am going to refactor the supervisor and detector spec in #479 so that the supervisor maintains a lightstore that only contains lightblocks that have been cross-checked, (or the once that have been verified with the primary that resulted in a cross-checked state).

To do so, we need to

• pass auxPrimaryLightStore into VerifyToTarget
• pass a trusted and the latest verified into the detector
• update the supervisor lightstore once we finished cross checking (insert the auxPrimaryLightStore)

This will allow us to ignore the state of lightblocks in the supervisor lightstore, as they all have been cross checked. This defines a cleaner interface: All lightblocks in the supervisor lightstore can be used by the user. All lightblocks in the supervisor lightstore are on a chain that lead to a cross-checked (trusted) lightblock.

[ebuchman]

This will allow us to ignore the state of lightblocks in the supervisor lightstore, as they all have been cross checked. This defines a cleaner interface: All lightblocks in the supervisor lightstore can be used by the user. All lightblocks in the supervisor lightstore are on a chain that lead to a cross-checked (trusted) lightblock.

I agree with being able to ignore "state" of headers and having a store that only has headers that can be used by the user. But I also think we're going to need a more nuanced view of what can be "trusted" / put into the supervisors light store / used by the user, and our thinking about the problem is I think a bit muddled by having a static set of peers. The problem right now is that with a static set of peers and assuming at least one is correct, we don't even need to do verification, we could just be comparing headers (until there's a conflict, then we need verification to figure out whats bogus or realize there's a genuine fork).

I think we want to move towards a model that functions more like the on-chain IBC light client, where we assume that eventually, within the trusting period, we will hear from a correct node (relayer in the IBC case). The basic version is to always trust (ie. "expose to the user") the first thing that gets verified, but to still be on the lookout for potential conflicts, that you might only discover later.

Even if we start with a static set in the implementation, we should probably be formulating the problem as if there were a dynamic set, and with more alignment with how the on-chain ibc client operates.

This may mean that we expose a new time parameter to the users which is effectively "how long after verifying a header do you want to trust it". For the light node, this would give it time to talk to more nodes, find new ones, look for conflicts, etc., while for the on-chain IBC client, it would give other relayers a chance to submit conflicts before anyone can use the latest verified state. Of course this will make relayer logic even more complicated because they'll have to wait these timeouts before they can submit proofs based on them (unless we support more optimistic execution on chain)

Of course users could set this timeout to 0, which means they trust the header right away, but are always open to finding out later that it was wrong as fork detection continues.

It might also be practical to have some hybrid between time and number of full nodes to cross-check with.

There's been some prior discussion on Stores that I would flag as likely related as well, #428, #420. And I thought @OStevan raised an issue about making some functions less store based and more functional but I can't find that now.

[ebuchman]

I should have read the latest #479 before writing the above comment :) But I guess the important addition is the idea of a new time parameter. I actually had this sketched out in Rust last September, the following comment:

This module builds up a map from peers to chains.
After the same header has been seen across some number of peers
and over some amount of time, it can be trusted.

This might more naturally capture the concurrent structure of a light client, ie. running the light client independently for each node, but presumably not re-verifying common headers (ie. we could cache signature validation so the same signature is never verified twice), and waiting some amount of time to detect conflicts.

[josef-widder]

tendermint/spec#164 closes this one.