[Protocol] MVP implementation off the on-chain SubmitProof message handling

[Olshansk]

Objective

MVP Implementation of SubmitProof to enable Shannon TestNet.

Origin Document

• [Miner, Supplier] chore: scaffold submit-proof message #44

Goals

• Enable E2E validation of the entire protocol
• Unblock iterative development of the claim & proof lifecycle
• Unblock iterative development of on-chain tokenomics

Deliverables

• A single PR that introduces the business logic for the on-chain SubmitProof message (verification, etc...)
• A single PR that updates the CLI to submit SubmitProof messages
• Introduce make targets to enable development (visibility, triggering, debugging , etc...) of on-chain proofs
• Add extensive unit tests

Non-goals / Non-deliverables

• Account Management (i.e. Burn & Mint) business logic related to the Claim & Proof lifecycle (leave TODOs)
• Governance Params necessary for the Claim & Proof lifecycle (leave TODOs)

General deliverables

• Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.
• Testing: Add new tests (unit and/or E2E) to the test suite.
• Makefile: Add new targets to the Makefile to make the new functionality easier to use.
• Documentation: Update architectural or development READMEs; use mermaid diagrams where appropriate.

---

Creator: @Olshansk
Co-Owners: @bryanchriswhite

[bryanchriswhite]

@Olshansk I'm starting on:

A single PR that introduces the business logic for the on-chain SubmitProof message (verification, etc...)

I've got a happy path unit test already (TDD-ing it).

[Olshansk]

@bryanchriswhite Have you (planning to, considering, open-to) implemented the equivalent of #148 and #151 for proofs?

I created #243 for the work we discussed today and will drive that myself but wanted to know if the above is on your radar.

[bryanchriswhite]

@bryanchriswhite Have you (planning to, considering, open-to) implemented the equivalent of #148 and #151 for proofs?

Yessir! The starting point I was referring to is analogous to #148 + #236 - testutils (which I will endeavor to isolate as reasonable). I think this is the best place to start as it's the most "outside", allowing me to work outside-in. Parts of the #151 analogue may be driven out along the way but otherwise I think it will be quite natural to lay out more isolated PRs for the various pieces.

I created #243 for the work we discussed today and will drive that myself but wanted to know if the above is on your radar.

👍 🙏

[Olshansk]

@bryanchriswhite While I was thinking / organizing notes, I made some small modifications / additions to the SubmitProof validation steps you already had in comments in the codebase.

Putting it here as a reference for both of us, and potentially act as a source for documentation in the future too.

## Actions (error if anything fails)
1. Retrieve a fully hydrated `session` from on-chain store using `msg` metadata
2. Retrieve a fully hydrated `claim` from on-chain store using `msg` metadata
3. Retrieve `relay.Req` and `relay.Res` from deserializing `proof.ClosestValueHash`
	
## Basic Validations (metadata only) 
1. claim.sessionId == retrievedClaim.sessionId
2. proof.sessionId == claim.sessionId
3. msg.supplier in session.suppliers
4. relay.Req.signer == session.appAddr
5. relay.Res.signer == msg.supplier

## Msg distribution validation (governance based params)
1. Validate Proof submission is not too early; governance-based param + pseudo-random variation
2. Validate Proof submission is not too late; governance-based param + pseudo-random variation

## Relay Mining validation
1. verify(proof.path) is the expected path; pseudo-random variation using on-chain data
2. verify(proof.ValueHash, expectedDiffictul); governance based
3. verify(claim.Root, proof.ClosestProof); verify the closest proof is correct