Can we improve on the latestSupportedState API?

[geoknee]

The latestSupportedState API improves on validTransition by expanding the set of support proof types that nitro can support.

In particular, it allows application logic to depart from a simple pairwise transition check, which allows it to depart from "strict turn taking"*. This is important for the streamlined virtual channels of nitro v2 (aka satp), which allow the intermediary to sometimes be required to sign off on state updates, but mostly to not be required to sign when the "end users" want to transact with one another.

In fact, our core protocol currently requires len(participants) signatures in a support proof. This invariant is broken by nitro v2. Hence all of the work in #557.

There do seem to be some deficiencies with latestSupportedState, however.

// In the application:
function latestSupportedState(
        FixedPart calldata fixedPart,
        SignedVariablePart[] calldata signedVariableParts
    ) external pure returns (VariablePart memory) 
    
// In the adjudicator:
VariablePart memory latestVariablePart = IForceMoveApp(fixedPart.appDefinition).latestSupportedState(fixedPart, signedVariableParts);
_requireVariablePartIsLast(latestVariablePart, signedVariableParts);
checkTurnNumberIncreased(latestVariablePart)
setStatus(fixedPart, latestVariablePart)

1. Too much freedom around the "slot" where the latest supported state is supplied.
   It's awkward to supply n variable parts, and have one returned. There's no guarantee that the returned object was in the arguments passed in (it is possible for the application developer to make an error). It's not clear whether it should be (by convention) always in the last slot of the supplied array. It is gas inefficient, to boot.
2. It's not clear why latest is important. The latest supported turn number should be managed by the adjudicator itself, not by the application logic.

My proposal would be to have the following API:

// In the application:
function requireStateSupported(
        FixedPart calldata fixedPart,
        SignedVariablePart calldata candidate
        SignedVariablePart[] calldata proof
    ) external pure returns () 
    
// In the adjudicator:
checkTurnNumberIncreased(candidate)
IForceMoveApp(fixedPart.appDefinition).requireStateSupportedBy(fixedPart, candidate, proof);
setStatus(fixedPart, candidate)
       

1. It's easier for application developers to understand which state they are trying to construct a proof for.
2. It is harder for them to make a mistake by messing up indices
3. The code in the adjudicator becomes simpler (also less bug prone).
4. Gas is saved by not copying and passing around structs.
5. We can fail quickly and more cheaply by checking the turn number before we call into application code.
6. (negative) It is a bit awkward that the proof doesn't contain the candidate state nor the signatures on it. We could play with some other names -- for example "support" (as in "supporting evidence").

---

• In fact our current support proof system allows for "shortcutting", but the applications of this don't seem to extend far beyond allowing "unanimous consent" (everyone signs a single state).

[andrewgordstewart]

The two options seem semantically equivalent to me:

• latestSupportedState has an implicit candidate, defined by the application rules. Convention may dictate that the candidate is signedVariableParts[-1].
• requireStateSupported has an explicit candidate. Convention could dictate that candidate == proof[-1] should hold, or instead that proof are predecessor states to candidate (what you seem to be suggesting, which makes sense).

Assuming that, if we look at the benefits of requireStateSupported, 1,3,4 stand out to me as meaningful improvements. I don't see how it is easier or harder for app developers to make mistakes in either case. (Couldn't an app developer mistakenly require a proof of the wrong length?)

I don't think 6 is much of a negative. One way to test this is to ask, what does the code look like for requireStateSupported vs latestSupportedState? Thinking through the canonical "Consensus" -> "A or B moved" -> "A and B moved", the turn-taking logic in requireStateSupported might look like:

def requireStateSupported(fixedPart, candidate, proof) {
  alice, bob = fixedPart.participants[0], fixedPart.participants[1]
  if candidate.type == Consensus {
    require(proof.length == 0) // optional?
    require(candidate.signedBy(alice, bob)) // everybody signed
  }

  if candidate.type == AMoved {
    require(proof.length == 1)
    require(candidate.signedBy(alice))
    require(proof[0].signedBy(bob))
    require(candidate.turnNum = proof[0].turnNum+1
  }

  if candidate.type == AMoved {
    require(proof.length == 1)
    require(candidate.signedBy(alice))
    require(proof[0].signedBy(bob))
    require(candidate.turnNum = proof[0].turnNum+1
  }

  if candidate.type == BothMoved {
    require(proof.length == 1)
    aThenB = proof[0].signedBy(alice) and candidate.signedBy(bob) 
    bThenA = proof[0].signedBy(bob) and candidate.signedBy(alice) 
    require(aThenB or bThenA)
    require(candidate.turnNum = proof[0].turnNum+1
  }
}

To me, that reads basically the same as it would for latestSupportedState.

[geoknee]

Thanks for the pseudocode. IMO it is cleaner that the equivalent code satisfying latestSupportedState.

I agree the two approaches are semantically equivalent. But I think if we have the opportunity to make something explicit (which is currently implicit) we should do so.

[nksazonov]

The idea of latestSupportedState not returning anything is great (and thus the new naming).

I really like an explicit candidate, although it doubtfully is more gas efficient as to separate it from the rest of the proof supplied to ForceMove, we would need to copy the whole proof:

proof = SignedVariableParts[:-1]
candidate = SignedVariableParts[-1]

Another approach would be to extend the requireStateSupported API to ForceMove, such so challenge, checkpoint and conclude would also require an explicit candidate to be supplied. We need a decision on this.

Moreover, having a separate candidate would allow DApp developers to have some peculiar logic, where candidate is not a successor of proof (by passing SignedVariableParts to ForceMove in a special order).

It is also worth mentioning that having a separate proof and its successor candidate somewhat complicates the simplicity of traversing the whole proof in ForceMoveApp. Nevertheless, this small downside is fully justified by resolving the naming ambiguity (last vs latest) and removing a weak point of the candidate index (you mention it as 2) by explicitly requiring to supply the candidate.

[geoknee]

Thanks @nksazonov. In my opinion both APIs (ForceMove and ForceMoveApp) should make use of the explicit candidate / proof variables.

[nksazonov]

Perfect. Then the changes we are to implement are the following:

1. Rename latestSupportedState to requireStateSupported
2. Supply proof and candidate separately to both requireStateSupported and ForceMove external functions
3. Change StrictTurnTaking accordingly
4. Change the logic in ForceMove to what you have described