Malfeasance V2: Publisher and Handler

[fasmat]

Description

For spacemeshos/pm#331 a new publisher and handler for malfeasance proofs needs to be implemented. Compared to V1 handling and publishing malfeasance proofs needs to be more generic and less tightly coupled to the individual domains that we create malfeasance proofs for.

Malfeasance publisher

The new malfeasance publisher needs to be implemented with an additional layer of abstraction. Each domain that can produce malfeasance proofs needs to have its own publisher and handler. Here is the general structure as an example for the ATX domain:

1. The ATX handler detects an invalid ATX
2. It creates a malfeasance proof from the ATX wire representation of the ATXs relevant to proof contextual invalidity.
   For this every type of malfeasance proof has helper functions in the activation/wire package to create and validate the associated proof.
3. The proof is serialized as []byte with the associated type of proof (e.g. Double Publish) in a generic type like this:

   type ProofVersion byte
   
   type ATXProof struct {
   	// Version is the version identifier of the proof. This can be used to extend the ATX proof in the future.
   	Version ProofVersion
   	// ProofType is the type of proof that is being provided.
   	ProofType ProofType	
   
   	// Proof is the actual proof. Its type depends on the ProofType.
   	Proof []byte `scale:"max=1048576"` // max size of proof is 1MiB
   }

4. The domain specific publisher serializes this domain specific proof to bytes and forwards it to the generic malfeasance proof publisher
5. The generic malfeasance proof handler puts the bytes received from the domain publisher into a generic malfeasance type like this:

   type ProofVersion byte
   
   type MalfeasanceProofV2 struct {
   	// Version is the version identifier of the proof. This can be used to extend the malfeasance proof in the future.
   	Version ProofVersion
   
   	// Certificates is a slice of marriage certificates showing which identities belong to the same marriage set as
   	// the one proven to be malfeasant. Up to 1024 can be put into a single proof, since by repeatedly marrying other
   	// identities there can be much more than 256 in a malfeasant marriage set. Beyond that a second proof could be
   	// provided to show that additional identities are part of the same malfeasant marriage set.
   	Certificates []ProofCertificate `scale:"max=1024"`
   
   	// Domain encodes the domain for which the proof was created
   	Domain ProofDomain
   	// Proof is the domain specific proof. Its type depends on the ProofDomain.
   	Proof []byte `scale:"max=1048576"` // max size of proof is 1MiB
   }

6. This is serialized as bytes and used for gossip / sync.

Implementation hints

• The malfeasance publisher should be designed to be called by the ATX handler directly, not requiring to return the created proof all the way up the call stack to decide if it should be gossiped or not. Instead the publisher should be aware if they should gossip the proof (when ATX synced) or just validate and store it in the DB (when not yet ATX synced).

Malfeasance handler

1. The generic malfeasance handler deserializes the bytes to the MalfeasanceProofV2 type above.
2. It calls the domain specific malfeasance handler with the Proof bytes.
3. The domain specific malfeasance handler deserialized and validates the proof and returns the NodeID of the identity proven to be malfeasant.
4. The generic malfeasance handler checks if the returned NodeID is already known to be malfeasant
5. The generic malfeasance handler confirms that the provided proof certificates belong to the same equivocation set and possibly extends the list of certificates and/or updates the local information about the equivocation set
6. The proof is persisted for all identities that belong to the same equivocation set (after updating the equivocation set and proof with possibly additional information)