Address review: Crosslink Finality terminology, operator definitions, bounded availability semantics, divergences appendix

[Copilot]

• Inspect current branch and repository state
• Fetch full history and main from https://github.com/zcash/zips
• Rebase PR branch onto fetched upstream main
• Verify rebased branch using nix develop -c make all (blocked: nix is not installed in this environment)
• Run CodeQL check and report status

[zooko]

This diff seems to use the term "assured finality". We had previously discussed using that term and had agreed instead to use the term "crosslink finality", as documented here: https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#crosslink-finality

Crosslink Finality
Crosslink provides a kind of finality which we call crosslink finality. Crosslink finality has these properties:

It is [accountable](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) because the chain contains explicit voting records which indicate each participating [finalizer](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME)'s on-chain behavior.
It is [irreversible](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) within the protocol scope. The only way to "undo" a final block is to modify the software to do so, which requires intervention by the user. Note that because a [finality safety violation](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) is always theoretically possible, this implies the only recovery from such a violation is out-of-band to the protocol and requires human intervention.
It is [objectively verifiable](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) because it is possible to determine finality from a local block history without any out-of-band information.
It is [globally consistent](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) meaning that all nodes which have received a sufficient number of valid blocks agree on the finality status, and also can rely on all other nodes in this set arriving at the same conclusion.
It provides [asymmetric cost-of-attack defense](https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) (TODO: Describe this better.)

Or maybe this diff doesn't mean "crosslink finality" where it says "assured finality". Maybe it means "irreversible finality" or one of the other properties instead.

[shielded-nate]

@copilot, please update the text to use the terminology from this comment.

Also, whenever the different sources seem to diverge or disagree, prioritize the https://github.com/ShieldedLabs/zebra-crosslink repo's book/src text, and then note the divergence between that source versus other sources in a new appendix section which summarizes the difference between references.

[shielded-nate]

@copilot, please see my review request here.

[Copilot]

Pull request overview

This PR adds two new draft ZIP documents describing Shielded Labs Crosslink v1: an informational architecture overview and a consensus ZIP specifying the CCC-SL hybrid consensus construction that cross-links Zcash PoW with a BFT finality protocol.

Changes:

• Added an informational draft ZIP defining Crosslink v1 terminology, motivation, architecture, and component interactions.
• Added a consensus draft ZIP specifying CCC-SL parameters, cross-referencing fields, derived functions, local finalization update rules, stalled-mode policy, and security property sketches.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
zips/draft-shieldedlabs-crosslink-overview.rst	New informational ZIP describing Crosslink v1 goals, terminology, architecture, and component interfaces.
zips/draft-shieldedlabs-crosslink-construction.rst	New consensus ZIP specifying the CCC-SL construction (cross-references, local finalization, stalled mode, and security claims).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Added explicit definitions for all three in the Terminology section in commit e93f04c:

• ≼_bc (bc-prefix relation): A ≼_bc B iff the bc-chain with tip A is a prefix of the bc-chain with tip B.
• C.truncate_bc(k): the bc-chain with the last k blocks removed; tip is the block at depth k from C.
• lastCommonAncestor(A, B): the deepest bc-block that is an ancestor of both A and B (tip of the longest common prefix).

[Copilot]

The gap > L threshold is correct and intentional (matching the TFL book's finality_depth(H) > L → isStalledBlock(H)). The earlier "reaches L" wording was inconsistent. Fixed in commit e93f04c by:

1. Rewriting the Bounded Availability requirement to state the correct invariant: "the finality depth of any non-stalled bc-block MUST NOT exceed L" (stalled blocks may accumulate beyond L).
2. Fixing the proof sketch to match: gap > L → must be stalled, so all non-stalled blocks have tip_height − fin_height ≤ L.

[shielded-nate]

@copilot, please address the requested change

[shielded-nate]

@copilot I'm quoting this other review and have the same change request:

This diff seems to use the term "assured finality". We had previously discussed using that term and had agreed instead to use the term "crosslink finality", as documented here: https://github.com/ShieldedLabs/zebra-crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#crosslink-finality

Crosslink Finality
Crosslink provides a kind of finality which we call crosslink finality. Crosslink finality has these properties:

• It is [accountable](https://github.com/ShieldedLabs/zebra crosslink/blob/6d02a1b80f896d08f923e39b2505f0565efb5787/book/src/design/terminology.md#FIXME) because the chain contains explicit voting records which indicate each participating finalizer's on-chain behavior.
• It is irreversible within the protocol scope. The only way to "undo" a final block is to modify the software to do so, which requires intervention by the user. Note that because a finality safety violation is always theoretically possible, this implies the only recovery from such a violation is out-of-band to the protocol and requires human intervention.
• It is objectively verifiable because it is possible to determine finality from a local block history without any out-of-band information.
• It is globally consistent meaning that all nodes which have received a sufficient number of valid blocks agree on the finality status, and also can rely on all other nodes in this set arriving at the same conclusion.
• It provides asymmetric cost-of-attack defense (TODO: Describe this better.)

@copilot, please update this PR to rely on this quoted definition of Crosslink Finality rather than "assured finality".

[Copilot]

Done in commit e93f04c. All occurrences of "assured finality" have been replaced with "Crosslink Finality". The full 5-property definition from terminology.md (accountable, irreversible, objectively verifiable, globally consistent, asymmetric cost-of-attack defense) is now included in both ZIPs' Terminology sections, citing the zebra-crosslink terminology.md as the authoritative source.

[Copilot]

@copilot, please update the text to use the terminology from this comment.

Also, whenever the different sources seem to ...

Done in commit a4e0baf. Here's what was addressed:

• Terminology: Replaced all occurrences of "assured finality" with "Crosslink Finality" (the term from zebra-crosslink terminology.md), including a full 5-property definition in the overview ZIP's Terminology section.
• Authoritative source: The appendix explicitly states that zebra-crosslink book/src is the authoritative source for terminology and design decisions when sources diverge.
• Appendix added to the overview ZIP: "Appendix: Divergences Between Reference Sources" — documents the four known divergences: (1) finality terminology ("Crosslink Finality" vs "Assured Finality" vs "Irreversible Finality" across sources), (2) Stalled Mode (present in CCC-TFLv2/CCC-SL, explicitly omitted from zebra-crosslink), (3) finality_depth naming differences, (4) construction name ("CCC-SL" vs "Crosslink 2"/"CL2").

I'm going to merge this into shielded-nate or shieldedlabs repos and do further changes as future PRs.

[shielded-nate]

Good enough to merge; more changes in future PRs.