📢 Last Call Meta

SIP-7723: Network Upgrade Inclusion Stages

Overview of the various stages Core SIPs go through before their activation in network upgrades.

Authors	Tim Beiko (@timbeiko), Alex Stokes (@ralexstokes), Ansgar Dietrichs (@adietrichs), Nixo (@nixorokish), Parithosh Jayanthi (@parithosh)
Created	2024-06-12
Last Call Deadline	2025-04-01

This SIP is in the process of being peer-reviewed. If you are interested in this SIP, please participate using this discussion link.

Abstract
Motivation
Specification
Rationale
Backwards Compatibility
Security Considerations
Copyright

Abstract

Defines the stages that SIPs go through in the process of planning network upgrades: Proposed for Inclusion, Considered for Inclusion, Scheduled for Inclusion, Declined for Inclusion and Included.

Motivation

This SIP proposes definitions for the various stages SIPs go through when planning network upgrades. It also provides context and guidelines around when and how SIPs should be moved from one stage to the next.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

All SIP stages apply to a single network upgrade. SIPs must be Proposed, Considered, Declined or Scheduled separately for each network upgrade. While an SIP cannot be Included in two network upgrades, an SIP being Declined for Inclusion in a previous upgrade does not prevent it from being Proposed, Considered, Declined or Scheduled for inclusion in any future upgrade.

The stages below are generally defined for Standards Track - Core SIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core SIPs may also be assigned these stages. The differences in the process and implications for non-Core SIPs are noted in each stage’s definition.

Upgrade Meta SIPs

Anyone MAY draft a Meta SIP to list SIPs for a network upgrade. This Meta SIP SHOULD include four categories in its specification section: Proposed for Inclusion, Declined for Inclusion, Considered for Inclusion and Scheduled for Inclusion. Even if a category is TBD, it SHOULD be included in the initial draft for clarity.

When the Upgrade Meta SIP is moved to Review, the Proposed for Inclusion and the Declined for Inclusion list SHOULD be removed. When it is moved to Last Call, Considered for Inclusion lists SHOULD be removed, leaving only the Scheduled for Inclusion list.

Before the Upgrade Meta SIP is moved to Final, the Scheduled for Inclusion stage MUST be renamed to Included and contain only SIPs that were activated with the upgrade.

Upgrade Devnets

When preparing a network upgrade, client developers typically implement SIPs first on an ephemeral test network (upgrade devnet) to verify client interoperability before deploying to long-lived test networks. These upgrade devnets follow a naming convention of upgradeName-devnet-version (e.g. pectra-devnet-0 for the first upgrade devnet of the Pectra network upgrade, dencun-devnet-1 for the second upgrade devnet of the Dencun update, etc).

Since client developers’ ability to include SIPs in a network upgrade is constrained by what can be implemented and tested in these upgrade devnets, the Considered for Inclusion and Scheduled for Inclusion sections below propose aligning these statuses with SIPs’ implementation status in upgrade devnets.

Proposed for Inclusion

To propose an SIP for inclusion, someone MUST open a pull request to add it to the Proposed for Inclusion (PFI) section of the Upgrade Meta SIP. The proposer of an SIP SHOULD serve as the primary point of contact for that SIP for the duration of the upgrade cycle or SHOULD designate another person to serve in that role. Reasonable pull requests SHOULD be merged in a timely fashion by the Upgrade Meta SIP author.

At this stage, implementation teams SHOULD review the SIP. For Core SIPs, this should be in the context of including it in the said upgrade. For non-Core SIPs, this should be in the context of supporting Core SIPs before the network upgrade is activated.

Note that SIPs must be Proposed for Inclusion for each network upgrade. In other words, proposals do not “carry over” to the next upgrade if an SIP is not included in the one it was first proposed for.

Considered for Inclusion

Once client developers have reviewed an SIP which was Proposed for Inclusion, they MAY move it to the Considered for Inclusion (CFI) stage. Once a decision is made by client teams to move an SIP to Considered for Inclusion, the Upgrade Meta SIP SHOULD be updated to reflect this.

Considered for Inclusion signals that client developers intend to attempt to include the SIP in devnets. The All Core Devs Execution (ACDE) and Consensus (ACDC) call facilitators should work with the testing teams to propose a priority ordering of CFI SIPs to be reviewed by client developers, and then reflect this prioritization in the Meta SIP. This prioritization should inform which SIPs should be included in upcoming devnets, with some flexibility if circumstances change.

Assuming it meets all the requirements for sila-mainnet deployment it MAY be included in the network upgrade. This stage is similar to “concept ACK” in other open source projects, and is not sufficient to result in deployment to sila-mainnet.

Non-Core SIPs that are Considered for Inclusion SHOULD be supported prior to the network upgrade being activated.

An SIP MAY be moved from Considered for Inclusion to Declined for Inclusion if client teams are against including the SIP in the network upgrade.

An SIP SHOULD have a Python implementation accompanied by tests in execution-specs submitted as an open PR. The SIP writer is encouraged to reach out to the maintainers of execution-specs for assistance with implementation. Client developers MAY decide to allow an SIP to be moved to Considered for Inclusion without either implementation, being aware that the absence of these implementations could lead to delays in the testing cycle.

Any updates to an SIP that is already at this stage SHOULD be accompanied by the appropriate updates to its implementation and tests in execution-specs if deemed necessary by client developers.

Declined for Inclusion

At any time during the network upgrade planning process, client developers MAY move SIPs from any other stage to the Declined for Inclusion (DFI) stage if client teams are against including the SIP in the network upgrade. Once a decision is made by client teams to move an SIP to Declined for Inclusion, the Upgrade Meta SIP SHOULD be updated to reflect this.

Declined for Inclusion signals that client developers wish to exclude the SIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade. An SIP which was Declined for Inclusion in a particular upgrade MAY still be Proposed for Inclusion in a subsequent upgrade. In exceptional circumstances, client developers MAY choose to move an SIP from Declined for Inclusion to Considered for Inclusion or Scheduled for Inclusion.

Scheduled for Inclusion

An SIP can be moved to Scheduled for Inclusion (SFI) when core developers:

Agree upon a strong intent to include the SIP in the next network upgrade.
Agree that an SIP’s specifications and implementations have reached a certain level of maturity.

I.e., an SFI status signals that the SIP is on track for inclusion barring unforeseen issues.

The following critieria can be applied to ascertain whether an SIP is mature (stable) enough to move to SFI:

It has been included in a devnet that has demonstrated stability (e.g., high participation, no critical bugs for ≥1 week).
The SIP specification is close to final (no placeholder values or pending design decisions).
It has minimal interactions with other CFI SIPs, OR those interactions have been tested in the same devnet.
Testing coverage is adequate (clients pass consensus tests, no known divergence across clients).

All Core Devs Testing (ACDT) calls may review SIPs to determine SFI eligibility. Status changes will then be ratified on ACDE or ACDC before assigning SFI status.

Scheduled for Inclusion signals that the SIP is on track for inclusion barring unforeseen issues. SIPs with incomplete specs or untested interactions should remain CFI until these conditions are met. The latest Upgrade Devnet must contain all Scheduled for Inclusion Core SIPs.

An SIP MAY be moved from Scheduled for Inclusion to Declined for Inclusion if circumstances necessitate removal, as agreed by client teams. An SIP MAY also be moved from Scheduled for Inclusion to Considered for Inclusion if client teams remain in favor of including the SIP in the network upgrade but cannot commit to including it in the next Upgrade Devnet.

An SIP MUST have a Python implementation accompanied by tests in execution-specs, submitted as an open PR or merged to the devnets/upgradeName/version branch of the repository. Client developers MAY decide to allow an SIP to be moved to Scheduled for Inclusion without an execution-specs implementation, but the tests are strictly mandatory.

Any updates to an SIP that is already at this stage MUST be accompanied by appropriate updates to its implementation and tests in execution-specs if deemed necessary by client developers.

Included

After network upgrade activation, all included Core SIPs and activated non-Core SIPs MUST be moved to Included in the Meta SIP. All other status lists MUST be removed from the Meta SIP.

Included signals that the SIPs have been activated as part of the network upgrade.

Rationale

Formalizing the Proposed for Inclusion, Considered for Inclusion, Scheduled for Inclusion, Declined for Inclusion and Included stages provides better legibility to both protocol maintainers and the broader Sila community.

The specification tries to minimize steps that MUST be followed to align with Sila’s “rough consensus” governance model.

Assuming it is adopted, the process outlined in this SIP should be used for at least one full network upgrade cycle before moving to Last Call and at least two full network upgrade cycles before moving to Final. This way, the SIP can be updated to reflect changes made to the process over time.

Backwards Compatibility

This SIP does not directly change the Sila protocol. It formalizes parts of the current network upgrade planning process.

Security Considerations

None.

Copyright

Citation

Please cite this document as:

Tim Beiko (@timbeiko), Alex Stokes (@ralexstokes), Ansgar Dietrichs (@adietrichs), Nixo (@nixorokish), Parithosh Jayanthi (@parithosh), "SIP-7723: Network Upgrade Inclusion Stages [LAST CALL]," Sila Improvement Proposals, no. 7723, June 2024. Available: https://sips.sila.org/SIPS/sip-7723.