⛓️

F3 proofs and catch-up design jam

Creator

Alex North

Created

Nov 1, 2023 6:03 PM

Project

Cross-chain interoperability

What is a finality proof/certificate?

Signatures from majority of power for same (epoch, tipset) tuple
Power table of previous final tipset (recursive)

What is a power table?

Collection of pairs of (node ID, pubkey, power)

// Kinda like a block header in a chain of finality certs.
struct FinalityCertificate {
  // The finality decision being claimed.
  ECEpoch: int64
  ECTipset: CID
  NewPowerTableRoot: CID

	// The trust base for the decision: the previous finalised epoch.
  // Defines the eligible committee and weight threshold.
  PrevECEpoch: int64
  PrevECTipset: CID // Is this necessary?
  // CID of Vec<(ActorID, PubKey, Power)> pairs (or a merkle tree?)
  // Must match NextPowerTableRoot from prev certificate.
	PrevPowerTableRoot: CID

  // Digest of the evidence for the decision.
  // CID of Vec<ActorID> of the signers
  Signers: CID
  // Aggregate of sigs over SignaturePayload for each signer
  Signatures: BLSAggregate

}

// Kinda like the “messages” in a “blockchain”
// Should this be just exactly a Granite DECIDE message?
// Verifier must be able to reconstruct this message for each signer
// from the verification inputs (FinalityFullBlock below).
struct SignaturePayload {
  Signer: ActorID
  ECEpoch: int64
  ECTipset: CID
  PrevPowerTableRoot: CID
  NextPowerTableRoot: CID
}

// All the information required to validate, 
// assuming prev finalised power table is known.
struct FinalityFullBlock {
  Certificate: FinalityCertificate // ~320B
  Signers: Vec<ActorID>. // ~750-1KB at current scale. Use RLE bitfield?
  // List of changes to PrevPowerTable to create NextPowerTable 
  NextPowerTableDeltas: Vec<(ActorID, Option<PubKey>, Power)> // ???
}

// Is there any point separating the certificate "header" from the full
// "block" information if this isn't an actual blockchain?
// The certificate isn't signed by anyone nor chained to a previous one,
// so maybe just always distribute the full evidence.

Questions

Should this be a real blockchain?

Add hash of previous FinalityCertificate, add a block producer who signs the block.
This would mean that nodes need to reach consensus on exactly the same evidence of finality. At present, nodes might have different collections of signatures that add up to majority QAP, and that’s ok.
If it’s not an actual blockchain, does that introduce attacks where adversary can release protocol-violating sigs in the past and produce safety violations that make deterministic catch-up hard?

Is EC chain self-finalising if it includes built-in actor that verifies finality certificates?

I.e. if fully validating the EC chain, don’t need to also validate the finality chain, because that logic is included in an actor.
Yes?

Is finality verification efficient enough for a smart contract?

Construct signature payloads
Verify BLS aggregate
Compute power table delta

Is it reasonable for a smart contract to store power table in its state, and process deltas?

An alternative is that power table is a merkle tree (or better vector commitment). Then SC stores only the root, and a finality certificate needs to include inclusion proofs for all the signers

The merkle proofs might be larger and more expensive
Anca’s VC would be way more efficient - multi-openings for single lookup cost. Ideal, but would take longer to implement.

To check: is BLS aggregate over different msg or exactly same message?