Further clarify proofs of invalid erasure coding

[liamsi]

Summary

The node types section only states who (which node type) is able to generate proofs of invalid erasure coding. Nowhere is explained what happens after generating them. This leaves a lot of room for interpretation. Who should care about those proofs and how will they be propagated (to who)?

Consumers of fraud proofs would be anyone that just does DAS. I guess that could be made more explicit.

Also, do they trigger slashable events? If yes, who will be slashed?

In terms of what penalities fraud proofs are associated with, that's more of a consensus/evidence concern.

Action Items

These should be separate issues that should be handled successively:

• [ ] specify the data structure for these fraud proofs
• [ ] specify the flow of events and the underlying assumptions
  • [ ] clarify grace period to light clients to wait for erasure coding fraud proofs and implications for light clients (wait for fraud proofs?)
  • [ ] specify penalties / slashing (if any)

related issue about evidence types: https://github.com/lazyledger/lazyledger-specs/issues/23 also related: celestiaorg/celestia-specs#110

[liamsi]

I've put this in the MVP project board. Although we don't need this fro implementing the MVP, this should be clarified in all detail before we start the implementation (devnet).

[Wondertan]

Do I understand correctly that this is just a spec/docs issue?

[liamsi]

yes

[Bidon15]

Grooming 01/11/2022:

@liamsi from node side, we have already got an ADR and implementation in the repo Still, docs side we have no info, so is it relevant to pass this issue on docs explanation to devRel? wdyt?

[Wondertan]

@liamsi, bong