support a param on SubmitEvidence to inform whether to advance

[turadg]

What is the Problem Being Solved?

Currently the Fast USDC contract advances every transaction that it learns about (if it can). The problem is some transactions are too risky.

We need the oracles to assess the risk using the chainPolicy and include information for the Advancer to decide.

We also need the reasons to be logged and written to vstorage for the end user to see in the transaction dashboard.

Description of the Design

A second parameter to submitEvidence, riskAssessment. For now it will just have one property risksIdentified?: string. That means the risks identified so far. Over time the riskAssessment can include other properties and the contract can identify new risks or excise ones identified upstream.

It's possible that oracles provide different riskAssessment values. It's unlikely but one might update to a new policy faster than another and the system should accept that. Differing evidence we treat as failure because they conflict and the system can't know what to trust. For risksIdentified it can and should take the union.

If the advance is deemed to risky (for now risksIdentified?.length > 0) then it should transition to a new state, AdvanceSkipped, writing that status along with the risksIdentified to vstorage. The settler should treat AdvanceSkipped the same as AdvanceFailed (the advance didn't start).

The README should be updated:

stateDiagram-v2
  Observed --> AdvanceSkipped : Risks identified
  Observed --> Advancing : No risks, can advance
  Observed --> Forwarding : No risks, Mint deposited before advance
  Forwarding --> Forwarded
  Advancing --> Advanced
  Advanced --> Disbursed
  AdvanceSkipped --> Forwarding : Mint deposited
  AdvanceFailed --> Forwarding : Mint deposited
  Advancing --> AdvanceFailed
  Forwarding --> ForwardFailed

Loading

For rationale:
✔️ How should the contract handle conditional advancing?

Security Considerations

This empowers the oracles to prevent advancing. Technically it is only advisory and the contract can change to ignore it or expect other information.

Scaling Considerations

none

Test Plan

Contract tests will suffice in CI. It should verify that when the info is included it's written to vstorage.
We'll also need to cover this in UI integration testing with oracle operators.

This should be covered in the C18 requirement test.

Upgrade Considerations

not yet deployed

[samsiegart]

Trying to hash out the design more...

A second parameter to submitEvidence, riskAssessment. For now it will just have one property skipAdvance: boolean. Over time it can include other info from the oracles so that the contract can decide by its own logic.

I don't see submitEvidence but there's this attest function which seems like what we're talking about. It doesn't do much more than track quorum then publish the CctpTxEvidence, so I assume we should publish the riskAssessment along with the CctpTxEvidence there, maybe it should just be included in the CctpTxEvidence type?

Now, I assume if skipAdvance is false or riskAssessment is missing altogether the advancer should handle business as usual. I'm not sure what to do in the case where skipAdvance is true. I assume we should not do the advance. Do we set the status as AdvanceFailed so the settler will do the slow transfer?