Skip to content

Do a good old fashioned human rewrite of the terminology section in ledger state ZIP#11

Open
shielded-nate wants to merge 1 commit into
zip-crosslink-first-draftfrom
zip-crosslink-nate-ledger-terminology-pass
Open

Do a good old fashioned human rewrite of the terminology section in ledger state ZIP#11
shielded-nate wants to merge 1 commit into
zip-crosslink-first-draftfrom
zip-crosslink-nate-ledger-terminology-pass

Conversation

@shielded-nate

Copy link
Copy Markdown
Owner

Maybe the overview ZIP should consolidate concepts and security property goals?

…be the overview ZIP should consolidate concepts and security property goals?

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR rewrites and expands the Terminology section of the Crosslink ledger-state ZIP, aiming to clarify consensus-related concepts (ledger state, objective verification, rosters, finality certificates) and add a small “protocol constants” section.

Changes:

  • Reworked terminology definitions (ledger state, objective verification, rosters, finality/certificates, final ledger state) and added an “Anti-Terminology” subsection.
  • Updated document header credits.
  • Added a “Protocol Constant Parameters” section defining ACTIVE_ROSTER_SLOTS = 100.

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

Comment on lines +35 to +38
The full state computable from a given history implied by a PoW block hash,
provided all of that history is objectively verifiable as consensus
compatible. This ZIP shortens this, unambiguously to "ledger" after introducing
the concept. Typically we focus only on the subset of computable state required
The Most-Recent Final Ancestor is the most recent ancestor of a given PoW block
which has objectively verifiable finality. This is often shortened to "final
ancestor", and this is relatively safe and unambiguous, given that a more recent
final state supercedes any previous known final state in terms of verifying
Comment on lines +79 to +83
Crosslink Finality is a term capturing the five specific characteristics of
finality which Crosslink aspires to provide. [FIXME: see the overview ZIP, or
should we be consolidating these terms in a single ZIP?] Because this bundle
of characteristics is specific to this project, as far as we are aware, we
disambiguate with the "Crosslink" prefix. An example of how this is important
Comment on lines +111 to +112
FIXME: Is there a term for this kind of simplifying constraint that enables
better static safety reasoning?
an external authority. By contrast "validator" may carry the connotation of an
external authority vouching, attesting to, or designating a history "valid".

Descriptively, for Crosslink itself, the active participants in BFT decisions are _only_ agreeing on the BFT finality status of
2 a : to support or corroborate on a sound or authoritative basis
b : to recognize, establish, or illustrate the worthiness or legitimacy of

-- Merriam-Webster: https://www.merriam-webster.com/dictionary/validator
-- Merriam-Webster: https://www.merriam-webster.com/dictionary/validator


product and definitions with "legal" or "official"
========

This ZIP specifies the Crosslink ledger-state changes required by RSM-SL-v1.
This ZIP specifies the Crosslink ledger state changes required by RSM-SL-v1, and by implication the transaction changes and overall ledger state consensus semantics. Ledger-state consensus
Comment on lines +329 to +330
- ``ACTIVE_ROSTER_SLOTS = 100``, the maximum number of finalizers which participate
in producing a BFT Finality Certificate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants