Skip to content

cip-0000.md

Latest commit

 

History

History
287 lines (194 loc) · 21.4 KB

cip-0000.md

File metadata and controls

287 lines (194 loc) · 21.4 KB

CIP 0000

  CIP: 0000
  Title: Canton Improvement Process for the Global Synchronizer on Canton Network
  Author: 
   Wayne Collier
   Stanislav German-Evtushenko
   Amanda Martin
   Taras Katrichenko 
   Itai Segall 
  Comments-Summary: 
  Status: Approved
  Type: Process
  Created: 2024-01-03
  Approved: 2025-03-03
  License: dual-licensed under the Open Publication License and BSD 2-clause

Abstract

Summary of the CIP process:

  • Draft your CIP Draft
  • Send the text of the CIP to the CIP Discuss mailing list
    • Work with a CIP editor for refinement and finalize as a Pull Request
    • Iterate until the CIP has a sponsor and endorser on cip-discuss
  • Send contact info for all parties involved in the CIP to operations@sync.global, including at least email addresses and a link to the CIP.
  • Send the CIP to the cip-vote mailing list Proposed
  • If Approved, the CIP moves to the Active status immediately if no other steps are required
    • If onchain steps are required, the CIP becomes Final once a ⅔ majority of Super Validator Node Operators implement the CIP onchain, either through an onchain vote, or by adopting new software versions that implement the CIP.

img

Specification

This defines a standard process for Canton Improvement Proposals.

Canton Improvement Proposals for the Global Synchronizer on Canton Network (CIPs) define new operating procedures for the Global Synchronizer, both onchain and off.

Draft

The CIP process begins with a new idea for the Global Synchronizer. Each potential CIP must have an author -- someone who writes the CIP using the style and format described below, shepherds the discussions in the forum at cip-discuss mailing list, and attempts to build community consensus around the idea. Any member of the public may join the cip-discuss mailing list and author a CIP. Small enhancements or patches to a particular piece of software often don't require standardisation across all Super Validators and Validators; these don't need a CIP and should be added in the relevant project-specific (e.g., Splice or Canton) development workflow.

To gauge the interest of the GSF Community, the author submits a draft CIP to the cip-discuss mailing list. This gives the author a chance to flesh out the draft CIP, and to address concerns about the proposal. CIP authors are responsible for collecting community feedback on both the initial idea and the CIP before submitting it for review.

During discussions, and before proposing the CIP for a vote, the proposal should be submitted to the cips git repository as a pull request.

This draft must be written in CIP style as described below, and named with an alias such as "CIP-johndoe-A-Better-Global Synchronizer" until an editor has assigned it a CIP number (authors must not self-assign CIP numbers).

A single CIP should contain a single key proposal or new idea. The more focused the CIP, the more successful it tends to be. If in doubt, split your CIP into several well-focused ones.

CIP Editors

The Author works with a CIP editor to finalize the CIP.

CIP editors subscribe to the mailing list. Authors may also reach out to CIP editors directly.

Editors read the CIP to check if it is ready. The ideas must make technical sense, even if they don't seem likely to be accepted. They also check that:

  • The CIP title accurately describes the content
  • The CIP has been sent to the mailing list for discussion.
  • For software, the defined Layer header has been correctly assigned for the given specification.
  • The CIP is organized in the correct format, described below
  • The copyright is appropriate for the CIP.

The CIP editor then assigns the CIP a number, labels it as Standards Track, Governance, Tokenomics, Process or Informational, and updates the CIP Index.

If the Author has not yet created a pull request the Editor will create a one in the cips git repository, where it may get further feedback.

The CIP author may update the draft as necessary in the cips git repository. Updates to drafts should also be submitted by the Author or Editor as pull requests.

The CIP Editors are intended to fulfill administrative and editorial responsibilities. The CIP Editors monitor CIP changes, and update CIP headers as appropriate. CIP editors may also unilaterally make and merge strictly-editorial changes to CIPs, such as correcting misspellings, fixing broken links, etc.

The current CIP editors are:

CIP format

CIPs should be written in markdown format. There are two templates to use. For the standard CIP use cip-XXXX, for governence only please usecip-XXXX

Standard CIPs should have the following sections:

  • Preamble -- Headers containing metadata about the CIP (see below).
  • Abstract -- A short (~200 word) description of the issue being addressed.
  • Specification -- The specific governance change or tokenomics change requested, and/or the syntax and semantics of protocol changes or new features. The specification should be detailed enough to allow Super Validator node operators to determine whether a given implementation or on-chain vote proposal matches the specification.
  • Motivation -- A brief description of why this CIP was raised. Protocol changes, governance changes and tokenomics changes require a motivation. Motivations should clearly explain why the existing configuration or protocol is inadequate to address the problem that the CIP solves, or why governance or tokenomics should change.
  • Rationale -- The rationale fleshes out the specification by describing what motivated the proposal and why particular decisions were made. In the case of governance or tokenomics changes, the rationale should explain the recommendation for the specified configuration or SV weight, rather than some other. In the case of software designs, the rationale should describe alternate designs that were considered, and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
  • Backwards compatibility -- All CIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The CIP must explain how the author proposes to deal with these incompatibilities.
  • Reference implementation -- Required for changes to Daml models and the Canton protocol. This reference implementation must be completed before any Standards-track CIP is given status "Final", but it need not be completed before the CIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Global Synchronizer.
  • Copyright -- The CIP must be explicitly licensed under acceptable copyright terms(see below).

CIP header preamble

Each CIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.

  CIP: 
* Layer: 
  Title: 
  Author: 
* Discussions-To: 
* Comments-Summary: 
  Comments-URI: 
  Status: 
  Type: 
  Created: 
  Aprroved: 
  License: 
* License-Code: 
* Post-History: 
* Requires: 
* Replaces: 
* Superseded-By:

Contents of the Preamble

CIP

The CIP number, assigned by an Editor

Layer

The Layer header (only for Standards Track CIPs) documents which layer of the Global Synchronizer ecosystem the CIP applies to.

Author

The Author header lists the names of all the authors/owners of the CIP.

If there are multiple authors, each should be on a separate line (following RFC 2822 continuation line conventions).

Discussions-To

While a CIP is in private discussions (usually during the initial Draft phase), a Discussions-To header may indicate the mailing list or URL where the CIP is being discussed. No Discussions-To header is necessary if the CIP is being discussed privately with the author, on the cip-discuss mailing list, or in comments on the pull request in GitHub.

Comments-Summary

The CIP Preamble may be updated with a summary of the comments made on the CIP. Summaries may be chosen from the following, but this CIP does not intend to cover all possible nuances and other summaries may be used as needed:

  • No comments yet.
  • Unanimously Recommended for implementation
  • Unanimously Discourage for implementation
  • Mostly Recommended for implementation, with some Discouragement
  • Mostly Discouraged for implementation, with some Recommendation
Comments-URI

If the CIP has also involved discussion in a separate forum outside of the cip-discuss mailing list and GitHub comments on the PR,

Status

Status records the progression of the CIP through the CIP Process

img

Authors of a CIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. A CIP editor may also change the status to Deferred when no progress is being made on the CIP.

A CIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, and has support from at least two Super Validators to recommend it for a vote.

Types

The Type header specifies the type of CIP: Standards Track, Governance, Tokenomics, Process or Informational.

  • A Standards Track CIP describes any change that affects most or all Global Synchronizer implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using the Global Synchronizer. Standards Track CIPs consist of two parts, a design document and a reference implementation.
  • A Governance CIP defines Super Validator rights owners and their weights, or modifies basic rules about governance of the Global Synchronizer, including the onchain voting process.
  • A Tokenomics CIP modifies the reward structures for Super Validators, Validators, or Application Providers, alters fees for use of Canton Coin, or changes the synchronizer traffic fee.
  • A Process CIP describes a process related to the Global Synchronizer, or proposes a change to (or an event in) a process. Process CIPs are like Standards Track CIPs but apply to areas other than the Global Synchronizer protocol itself. They may propose an implementation, but not to the Splice or Canton code bases. They often require community consensus, and unlike Informational CIPs, they are more than recommendations; users are typically not free to ignore them. Examples include changes to the CIP process, and changes to the tools or environments used in Global Synchronizer deployment and operations. Any meta-CIP (a CIP about other CIPs) is also considered a Process CIP.
  • An Informational CIP describes a Global Synchronizer design issue, or provides general guidelines or information to the Global Synchronizer community, but does not propose a new feature. Informational CIPs do not necessarily represent a Global Synchronizer community consensus or recommendation, so users and implementers are free to ignore Informational CIPs or follow their advice.
Created

The Created header records the date that the CIP was assigned a number. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14.

Approved

The Approved header records the data that the CIP was approved by vote of the Super Validators. Some CIPs include conditions that must be met within a given time after the date of approval.

Other headers

CIPs may have a Requires header, indicating the CIP numbers that this CIP depends on.

CIPs may also have a Superseded-By header indicating that a CIP has been rendered obsolete by a later document; the value is the number of the CIP that replaces the current document.

The newer CIP must have a Replaces header containing the number of the CIP that it rendered obsolete.

Approved

A Proposed CIP progresses to Approved status by vote of the Super Validator node operators. An Approved CIP is ready to be ratified onchain.

Deadlines for proposing a CIP for vote after it is introduced to cip-discuss are:

  • Standards Track: Three (3) months
  • Governance: One (1) month
  • Tokenomics: One (1) month
  • Process: One (1) month
  • Informational: Two (2) weeks

If a CIP does not move to a vote before the deadline it is Withdrawn or Deferred.

To request a vote, the author sends a message to the cip-discuss mailing list requesting a Super Validator to sponsor the CIP and a second Super Validator to endorse the CIP, and linking to the PR. If the author represents a Super Validator, only one endorsing Super Validator is required. If the CIP receives this support, the sponsoring Super Validator sends the CIP to cip-vote mailing list. This list has private membership but a public message archive, allowing the Author to track progress.

Votes proposed to cip-vote have a ten (10) day deadline for completion may be Withdrawn, or move to Rejected status.

Designated representatives of the Super Validator rights owners cast their votes using GitHub Team Voting. The set of designated representatives is maintained by Global Synchronizer Foundation staff. Approvals require a 2/3 majority vote in favor.

Active/Final

An Approved CIP that does not require adoption on chain becomes immediately Active.

An Approved CIP that requires adoption on chain moves to Final status by being adopted on-chain by a 2/3 majority of Super Validators.

When a Final CIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced).

Progression to Final status

When the vote to approve a CIP reaches conclusion, either in favor or by rejection, a member of the GSF staff announces the results in cip-announce and also in cip-discuss. The CIP proposer then links the announcement from cip-announce@lists.sync.global/topics to the PR, and merges the PR.

PRs in Splice and Canton that implement further changes to code associated with Standards Track CIPs are tagged with the PR that introduced the CIP.

On-chain implementation of CIPs requires action by Super Validator node operators, expressed by onchain votes. Super Validator operators discuss and agree on a date for the proposed vote in the Super Validator Operations mailing list. A Super Validator operator then creates a vote proposal, with an expiration and an effectivity. The onchain vote proposal must include a link to the PR that introduced the Approved CIP.

All Super Validators automatically report the result of onchain votes via the Canton Coin Scan API, and in the Canton Coin Scan UI hosted by each.

A hard-fork CIP requires the entire Global Synchronizer community to adopt the relevant software or configuration change, including both Super Validators and Validators, to be considered Final. Adoption must be expressed by de facto usage of the hard-fork in practice (ie, not merely expressing public support).

Motivation

The Super Validators have previously followed an ad-hoc process for proposing, reviewing, voting on and adopting Canton Improvement Proposals for the Global Synchronizer. As participation in the Global Synchronizer has grown, the Super Validators have engaged the Global Synchronizer Foundation (GSF) to manage the CIP process. The GSF and Super Validators created this proposal to make the process transparent and consistent.

Rationale

The rationale for the Canton Improvement Proposal (CIP) process is designed to foster trust, transparency, and collaboration within the Global Synchronizer ecosystem. The Global Synchronizer Foundation (GSF) will use the CIP process to facilitate consistent and reliable governance and operations, helping all participants—whether Super Validators, Validators, or application providers—can engage confidently in the network.

Decentralized systems thrive on shared trust, which emerges not from a single authority but from collective understanding and agreement among participants. Open and inclusive discussion is vital to maintaining this decentralized trust. The CIP process provides a structured platform where ideas can be proposed, debated, and refined in full view of the community, ensuring that decisions are informed by diverse perspectives and do not disproportionately benefit any one group.

A key pillar of this trust is the independence of the (GSF). To uphold its mission of fairness and transparency, the GSF operates independently of any single organization, individual, or entity. This independence ensures that the CIP process and the broader governance of the Global Synchronizer remain impartial, free from undue influence, and focused on the collective benefit of the community. By maintaining neutrality, the GSF reinforces the principles of decentralized governance and trust, providing a stable foundation for all participants to engage confidently.

Ultimately, the CIP process fosters collaboration and innovation by creating a system of decentralized trust.

CIP licensing

Specification

New CIPs may be accepted with the following licenses. Each new CIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below.

For example, a preamble might include the following License header: License: CC0-1.0 GNU-All-Permissive

In this case, the CIP text is licensed under Creative Commons.

Recommended licenses

The default is:

Also recommended is:

Not recommended, but acceptable licenses

Not acceptable licenses

All licenses not explicitly included in the above lists are not acceptable terms for a Global Synchronizer Improvement Proposal unless a later CIP extends this one to add them. However, CIPs predating the acceptance of this CIP were allowed under other terms, and should use these abbreviations when no other license is granted:

Copyright

This CIP, cip-0000, is dual-licensed under the Open Publication License and BSD 2-clause, as it was derived heavily from BIP-0002, which itself was derived from Python's PEP-0001.

Changelog

6 Jan 2025 - Initial Draft 24 Jan 2025 - Modifications 20 Feb 2025 - Condensing and reorganizing sections