Skip to content

Commit

Permalink
GITBOOK-34: No subject
Browse files Browse the repository at this point in the history
  • Loading branch information
cuevasm authored and gitbook-bot committed Mar 1, 2024
1 parent 9c52a59 commit be8185b
Show file tree
Hide file tree
Showing 6 changed files with 81 additions and 20 deletions.
Binary file added .gitbook/assets/image (12) (1).png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
5 changes: 3 additions & 2 deletions SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,9 +14,10 @@
* [Changes to PoX and Clarity](nakamoto-upgrade/nakamoto-in-depth/changes-to-pox-and-clarity.md)
* [Financial Incentives and Security Budget](nakamoto-upgrade/nakamoto-in-depth/financial-incentives-and-security-budget.md)
* [What About Microblocks?](nakamoto-upgrade/nakamoto-in-depth/what-about-microblocks.md)
* [Nakamoto Rollout Plan](nakamoto-upgrade/nakamoto-rollout-plan.md)
* [Testnets](nakamoto-upgrade/testnets/README.md)
* [Neon](nakamoto-upgrade/testnets/neon.md)
* [Argon](nakamoto-upgrade/testnets/argon.md)
* [Pre-Launch Testnet](nakamoto-upgrade/testnets/neon.md)
* [Nakamoto Testnet](nakamoto-upgrade/testnets/argon.md)
* [Running a Signer](nakamoto-upgrade/running-a-signer.md)
* [Stacking Flow](nakamoto-upgrade/stacking-flow.md)

Expand Down
46 changes: 46 additions & 0 deletions nakamoto-upgrade/nakamoto-rollout-plan.md
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.
12 changes: 9 additions & 3 deletions nakamoto-upgrade/testnets/README.md
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 %}
16 changes: 12 additions & 4 deletions nakamoto-upgrade/testnets/argon.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,16 @@
# Argon
# Nakamoto Testnet

After Neon, Argon is the next public testnet slated to be released mid-March. While Neon was great for demonstrating the capability of fast blocks, Argon will be much more feature complete and is meant to be a testnet for the full-on Nakamoto hard fork coming in April.
**Primary Usage:** App Developers, Signers

Here are some things you can expect with Argon:
**About:**

* This testnet features the standard one-week accelerated Stacking cycles that Stacks developers are familiar with on the current Stacks Testnet
* This testnet will always run against Bitcoin Testnet
* This testnet will be the ‘main’ Stacks Testnet going forward and maintained into perpetuity alongside mainnet as a service for any developer or partner starting to work with Stacks.

**Status:** This testnet is due on March 25th

**Here are some things you can expect with the Nakamoto Testnet:**

* Nakamoto performance gains with existing Clarity WASM
* All Nakamoto rules in place
Expand All @@ -12,4 +20,4 @@ Here are some things you can expect with Argon:
* Controlled testnet upgraded with performance gains
* Testing and audits on code complete components

Check back here after Argon is released for instructions for using the testnet and getting your applications migrated.
Check back here after the Nakamoto Testnet is released for instructions for using the testnet and getting your applications migrated.
22 changes: 11 additions & 11 deletions nakamoto-upgrade/testnets/neon.md
Original file line number Diff line number Diff line change
@@ -1,23 +1,23 @@
# Neon
# Pre-Launch Testnet

Neon is the first controlled testnet release for Nakamoto and ships with two separate testnets, one with the previous Clarity VM and one with the upcoming Clarity WASM.
**Primary Usage:** Core Developers, (some) App Developers

The primary purpose of these testnets is is performance benchmarking with the new consensus rules.
**About:**

Both testnets allow users and developers to view and interact with Nakamoto block production, meaning each testnet has Nakamoto coinbase transactions, testable VRF, tenure change transactions, and multiple Stacks blocks per Bitcoin block.
* This testnet will exist until the Nakamoto launch is complete and features an accelerated Stacking cycle length of 2 days so that core devs and builders can simulate a lot of blockchain history (and PoX cycles) in a short time.
* This testnet can run against Bitcoin Regtest or Bitcoin Testnet
* Given ongoing audits and testing, this testnet may have bugs, be reset, or run into occasional performance issues as tweaks are made.

Both testnets utilize Bitcoin Regtest and utilize a single miner, this is what is meant by "controlled" testnet. These testnets are producing blocks roughly every 5 seconds, which you can see reflected in the explorer.
**Status:** This is testnet currently live, stable, and producing blocks.\
\
**Next:** The Pre-Launch testnet is set to move to [Step 2 (Activation)](../nakamoto-rollout-plan.md) on March 11th, meaning at that point it will be a complete testnet representation of the network with the Nakamoto rules live (except of course that it moves through blocks much faster).

If non of that makes any sense, be sure to check out the previous pages of this Nakamoto section.

Both testnets ship with functioning APIs and explorers to experiment with

### Controlled Testnet 1 (Clarity VM)
### Pre-Launch Testnet - (Clarity VM Evironment)

* [API](https://api.nakamoto-1.hiro.so/extended/v1/status)
* [Explorer](https://explorer.hiro.so/blocks?chain=testnet\&api=https://api.nakamoto-1.hiro.so)

### Controlled Testnet 2 (Clarity WASM)
### Pre-Launch Testnet - (Clarity WASM Environment)

* [API](https://api.nakamoto-2.hiro.so/extended/v1/status)
* [Explorer](https://explorer.hiro.so/blocks?chain=testnet\&api=https://api.nakamoto-2.hiro.so)
Expand Down

0 comments on commit be8185b

Please sign in to comment.