-
Notifications
You must be signed in to change notification settings - Fork 238
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
9c52a59
commit be8185b
Showing
6 changed files
with
81 additions
and
20 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
# Nakamoto Rollout Plan | ||
|
||
This covers the testnet and mainnet rollout sequencing for the Nakamoto upgrade. There are several key steps, each of which brings more features live in a safe, step-by-step process that will give builders and partners time to integrate and test. | ||
|
||
#### **TL;DR:** | ||
|
||
> As [shared in January](https://stacks.org/nakamoto-launch-window), the Nakamoto upgrade will begin rolling out between April 15 - 29 (Instantiation window) which will kick off a period of at least one month for Signer onboarding. After Signers are onboarded, Nakamoto rules will go live in the Activation window between May 15 - 29, completing the launch! | ||
### Two-Step Release and Signer Onboarding | ||
|
||
Core Developers and Working Groups have regularly engaged with builders and key integration partners as pieces of the codebase are wrapped up and going to audit. This ongoing dialog led to the two-step release process described here, which will afford partners, many of whom are new to Stacks, ample time to register on mainnet, troubleshoot their setups if necessary, and be ready to sign blocks upon Activation. New signers need to fully test their setup on mainnet before they can become active validators. | ||
|
||
I know folks may have been expecting the full set of Nakamoto features being released all at once in the April 15-29 launch window, but a two-step release that follows the steps taken on [testnet](testnets/) has quickly become the preferred path given how much is happening as part of this upgrade. | ||
|
||
### Step 1, Step 2: Instantiation & Activation | ||
|
||
The rollout will follow this two-step process, each of which is implemented via hard fork. Breaking the Nakamoto release into two forks reduces risk by allowing Core Developers an opportunity before full activation to make any final adjustments or bug fixes as they observe pox-4 in the wild and as Signers come online. | ||
|
||
This strategy is the same one being used on the testnet and the rollout of the testnet is already in progress (at Step 1, Instantiation). | ||
|
||
1. **Step 1 - Instantiation:** The pox-4 contract and the majority of the Nakamoto code are shipped, but Nakamoto rules are inactive. This is so other aspects of the contract can be tested before layering on the complexity that comes with the testnet (and later mainnet) being dependent on it. Importantly, this phase also allows time for Signers to register without the network being dependent on them to sign blocks. | ||
2. **Step 2 - Activation:** Nakamoto rules turn active, enabling the full set of Nakamoto features including Signer-based functions, fast blocks, and Bitcoin finality. In other words, ‘the switch is flipped’! | ||
|
||
It’s important to note the heaviest lift of any hard fork is historically the sync from genesis. With the two Nakamoto forks, one goal is not to require this, making the upgrade more akin to a push-button software update and much simpler for all node operators. | ||
|
||
<details> | ||
|
||
<summary><strong>What are ‘Nakamoto Rules’?</strong></summary> | ||
|
||
Nakamoto rules are the logic that makes Nakamoto different than the version before it called Stacks 2.4. The key difference is that under Nakamoto, block validation logic requires Signers to sign the blocks to be confirmed as anchor blocks. At Step 1 (Instantiation), this logic, or the ‘Nakamoto Rules’ remains inactive, meaning the network follows the block validation rules of Stacks 2.4. Once the testnet (and later mainnet) reaches Activation, the network switches to running these Nakamoto rules and all the features we’re excited about go live for everybody. | ||
|
||
</details> | ||
|
||
### Mainnet Rollout | ||
|
||
As [shared in January](https://stacks.org/nakamoto-launch-window), mainnet rollout **will begin some time between April 15 and 29** which is currently roughly aligned with Stacking cycle 82. | ||
|
||
Once instantiated (Step 1), a period of at least 2 Stacking cycles will be afforded to Signers and other integration partners to register with pox-4. During this time they will ensure their Signers are ready for the progression to Activation (Step 2) where the network will depend on Signers actively validating blocks. | ||
|
||
This means that assuming there are no major bugs or issues, full Nakamoto features will activate in mid to late May with some of that depending on how quickly Signers are onboarded. The BD Working Group has noted that they expect 20+ Signers to be ready for mainnet launch, so we have every reason to believe this rollout to mainnet will be smooth on this front and we know the lineup features some of the [industry’s infrastructure leaders](https://figment.io/insights/figment-to-enable-bitcoin-l2-rewards-with-upcoming-support-of-the-stacks-layer/). | ||
|
||
### Visualizing the rollout | ||
|
||
<figure><img src="../.gitbook/assets/image (12) (1).png" alt=""><figcaption></figcaption></figure> | ||
|
||
**Note about sBTC Rollout:** Previous [updates](https://stacks.org/halving-on-horizon-nakamoto) mentioned targeting a launch of sBTC 2-3 months after Nakamoto Mainnet is live and stable. Once Nakamoto reaches Step 1 (Instantiation) in April, many Core Developers will turn their focus to sBTC and produce a more detailed rollout plan to share. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,13 @@ | ||
# Testnets | ||
|
||
There are two testnet releases of Nakamoto for developers to experiment with: Neon and Argon. | ||
As the work on Nakamoto has progressed, there have been different versions of testnet, often referred to by their noble gas names like Neon, Argon, etc. However, those distinctions have been more geared toward sprints and projects the core devs have broken down work into. You can still call them that if you like, but going forward, it is simpler to look at the two testnets based on what they offer. | ||
|
||
Neon is a controlled testnet (only a single block producer) designed to get the minimum functionality of Nakamoto running for people to experiment with. | ||
The two testnets are: | ||
|
||
Argon is a much more fully-featured testnet release that will allow developers and users to test out Nakamoto functionality much more like what the final release will be. | ||
{% content-ref url="neon.md" %} | ||
[neon.md](neon.md) | ||
{% endcontent-ref %} | ||
|
||
{% content-ref url="argon.md" %} | ||
[argon.md](argon.md) | ||
{% endcontent-ref %} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters