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?