You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8da6fd9
Browse filesBrowse the repository at this point in the historyBrowse files
* To operate as a Signer, [here](https://app.gitbook.com/s/4cpTb2lbw0LAOuMHrvhA/run-a-signer).
9
-
* To view a full list of active Signers, [here](https://explorer.hiro.so/signers?chain=mainnet).
14
+
* To operate as a signer, see [Run a Signer](https://docs.stacks.co/operate/run-a-signer).
15
+
* To view a full list of active signers, see the [Explorer's signers page](https://explorer.hiro.so/signers?chain=mainnet).
10
16
{% endhint %}
11
17
12
18
#### The Big Picture
13
19
14
-
* Signers validate and sign proposed Stacks blocks.
15
-
* They are selected from eligible Stackers each cycle.
16
-
* A 70% threshold of signatures is required for a block to be accepted.
17
-
* They verify block correctness before signing.
18
-
* Signing helps prevent invalid or conflicting blocks.
19
-
* Their role strengthens finality and network security.
20
+
* Signers validate and sign proposed Stacks blocks before they can join the chain.
21
+
* The signer set is fixed each reward cycle: every signer-manager with at least 50,000 STX staked to it.
22
+
* A signer's voting weight is proportional to the STX staked through it.
23
+
* Accepting a block requires signatures carrying at least 70% of total signer weight.
24
+
* Signing prevents forks and anchors Stacks history to Bitcoin.
20
25
21
26
***
22
27
23
-
## Intro
28
+
###Intro
24
29
25
-
Stackers, that also operate as a Signer, play an essential role in the Stacks network (post-Nakamoto upgrade) that had previously been the responsibility of miners. Before, miners both decided the contents of blocks, and decided whether or not to include them in the chain (i.e. by deciding whether or not to confirm them). In this system each actor has the following responsibilities necessary to make the system function reliably without forks:
30
+
Signers play a role in the Stacks network that had previously belonged to miners. Before the Nakamoto upgrade, miners both decided the contents of blocks and decided whether blocks joined the chain. Since Nakamoto, each actor holds one of those responsibilities:
26
31
27
32
***Miners** decide the contents of blocks.
28
-
***Signers** decide whether or not the block is included in the chain.
33
+
***Signers** decide whether a block is included in the chain.
34
+
35
+
The bulk of the complexity in the Nakamoto changes went into separating these two concerns while keeping both mining and staking open-membership. Anyone can become a miner and anyone can become a staker. [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) describes the design as it was introduced.
36
+
37
+
Signers are required to acknowledge and validate a miner's block before it can be appended to the chain. To do so, they must first agree on the canonical chain tip, then apply the block on that tip to determine its validity. Once enough signers agree that the block is both canonical and valid, their signatures accompany the block as it replicates to the rest of the Stacks peer network, and only at that point do nodes append it to their chain histories.
29
38
30
-
The bulk of the complexity of the Nakamoto changes is in separating these two concerns while ensuring that both mining and Stacking remain open-membership processes. **Crucially, anyone can become a miner and anyone can become a Stacker, just as before.** The most substantial changes are in getting miners and Stackers to work together in their new roles to achieve this proposal's goals.
39
+
This behavior prevents forks from arising. If a miner builds a block atop a stale tip, signers refuse to sign it. If signers cannot agree on the canonical Stacks tip, no block is appended in the first place. The failure mode this creates, a chain that halts while signers disagree, is mitigated by keeping the signer set large and diverse enough that quorum is met at all times, and by paying signers through PoX rewards to stay online.
31
40
32
-
The key idea is that Stackers, as Signers, are required to acknowledge and validate a miner's block before it can be appended to the chain. To do so, Stackers must first agree on the canonical chain tip, and then apply (and roll back) the block on this chain tip to determine its validity. Once Stackers agree that the block is both canonical and valid, they collectively sign it and replicate it to the rest of the Stacks peer network. Only at this point do nodes append the block to their chain histories.
41
+
***
42
+
43
+
### How Signers Are Selected
33
44
34
-
This new behavior prevents forks from arising. If a miner builds a block atop a stale tip, Stackers will refuse to sign the block. If Stackers cannot agree on the canonical Stacks tip, then no block will be appended in the first place. While this behavior creates a new failure mode for Stacks -- namely, the chain can halt indefinitely if Stackers cannot agree on the chain tip -- this is mitigated by having a large and diverse body of Stackers such that enough of them are online at all times to meet quorum and incentivizing them via PoX rewards to act as such.
45
+
Under PoX-5, a signer is a signer-manager contract bound to one signer key. The binding happens once: the signer-key holder signs a [SIP-018](https://github.com/stacksgov/sips/blob/main/sips/sip-018/sip-018-signed-structured-data.md) grant naming the manager, and the manager submits it through `grant-signer-key`and registers with `register-signer`. The key holder can revoke the grant at any time with `revoke-signer-grant`, which stops the manager accepting new stake while existing positions wind down.
35
46
36
-
## Stacker Signing
47
+
During each prepare phase, the last 100 Bitcoin blocks of a reward cycle, the signer set for the upcoming cycle is fixed: every registered signer-manager with at least 50,000 STX (`SIGNER_SET_MIN_USTX`) staked to it in aggregate. A signer's voting weight for that cycle is proportional to the total STX staked through it, counting the STX in STX-only stakes and the STX side of protocol bonds together. The BTC side of a bond carries no signing weight: signing weight, like governance weight, is a function of locked STX alone.
37
48
38
-
The means by which Stackers agree on the canonical chain tip and agree to append blocks is tied to PoX. In each reward cycle, a Stacker clinches one or more reward slots; there are at most 4,000 reward slots per reward cycle. Stackers vote to accept blocks by producing a weighted threshold signature over the block. The signature must represent a substantial fraction of the total STX locked in PoX (the threshold), and each Stacker's share of the signature (its weight) is proportional to the fraction of locked STX it owns.
49
+
The signer software detects from chain state whether its manager is in the upcoming cycle's signer set. Staking transactions are sent manually; everything the signer does with that information is automatic.
39
50
40
-
The weighted threshold signature is a Schnorr signature generated through a variation of the [FROST protocol](https://eprint.iacr.org/2020/852.pdf). Each Stacker generates a signing key pair, and they collectively generate an aggregate public key for nodes to use to verify signatures computed through a distributed signing protocol. This signing protocol allocates shares of the associated aggregate private key to Stackers proportional to the number of reward slots they clinch. No Stacker learns the aggregate private key; Stackers instead compute shares of the private key and use them to compute shares of a signature, which can be combined into a single Schnorr signature.
51
+
#### The relationship between stakers and signers
41
52
42
-
When a miner produces a block, Stackers execute a distributed signing protocol to collectively generate a single Schnorr signature for the block. Crucially, the signing protocol will succeed only if at least X% of the reward slots are accounted for in the aggregate signature. Nakamoto is currently set to use a 70% signing threshold -- at least 70% of the reward slots (by proxy, 70% of the stacked STX) must sign a block in order to append it to the Stacks blockchain.
53
+
<divdata-with-frame="true"><figure><imgsrc="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2FlvBLhI7D2ThkIs3oW5jR%2Fstaking-and-signing.svg?alt=media&token=4ccaf8db-6e07-4cf3-b378-e19584a49526"alt="Manual staking transactions feeding the reward phase, and the signer software acting automatically once its manager is in the signer set"><figcaption></figcaption></figure></div>
43
54
44
-
Nakamoto uses the [WSTS protocol with the FIRE extension](https://trust-machines.github.io/wsts/wsts.pdf), which admits a distributed key generation and signature generation algorithm pair whose CPU and network bandwidth complexity grows with the number of distinct Stackers. The FIRE extension enables WSTS to tolerate byzantine Stackers.
55
+
* Stakers are not signers. Signing is done by the key granted to the signer-manager they stake to, and running that signer is the manager operator's job.
56
+
* Every signer is backed by staked STX. To be in the signer set, a manager must represent at least the 50,000 STX aggregate threshold, and its weight grows with the stake it represents.
45
57
46
-
#### The relationship between Stackers and Signers
58
+
***
47
59
48
-
Here is a diagram outlining the relationship between signing and stacking.
When a miner proposes a block, each signer validates it independently and signs it with its granted signer key. The block carries the resulting set of signatures, and a node accepts it only when the signatures are valid, free of duplicates, ordered consistently with the signer set, and together carry at least 70% of the total signer weight for the cycle. The threshold is a consensus constant in the node ([`NAKAMOTO_SIGNER_BLOCK_APPROVAL_THRESHOLD`](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/core/mod.rs)).
51
63
52
-
* Not all stackers are signers \
53
-
→ because stackers can **delegate** their participation (including signing responsibilities)
54
-
* All signers are backed by **their own STX** or **delegated STX**\
55
-
→ to be in the signer set, you must represent **stacked STX weight**
64
+
Weight, in this protocol, is stake: a signer-manager representing 10% of all staked STX carries 10% of the vote on every block. Blocks are accepted by an economic majority of the locked capital, which is what ties block production back to the staking described on the [Staking page](stacking.md).
56
65
57
66
***
58
67
59
-
## Validating and Appending New Blocks
68
+
###Validating and Appending New Blocks
60
69
61
-
When miners are selected for a new tenure, they begin building new blocks from transactions in the mempool. They then send those blocks to signers for approval. Signers must approve the blocks with a quorum of at least 70% for them to be appended to the chain.
70
+
When miners are selected for a new tenure, they begin building blocks from transactions in the mempool and send them to signers for approval. Signers must approve a block with at least 70% of signer weight for it to be appended to the chain.
62
71
63
-
Signers will approve a block based on several properties:
72
+
Signers approve a block based on several properties:
64
73
65
74
* The block is well-formed
66
75
* It has the correct version and mainnet/testnet flag
@@ -71,19 +80,17 @@ Signers will approve a block based on several properties:
71
80
* The transaction Merkle tree root is consistent with the transactions
72
81
* The state root hash matches the MARF tip root hash once all transactions are applied
73
82
* The block header has a valid ECDSA signature from the miner.
74
-
* The block header has a valid WSTS Schnorr signature from the set of Stackers.
75
-
* All Bitcoin transactions since the last valid sortition up to (but not including) this tenure's block-commit’s Bitcoin block have been applied to the Stacks chain state\*
83
+
* The block header carries signer signatures meeting the 70% weight threshold.
84
+
* All Bitcoin transactions since the last valid sortition up to (but not including) this tenure's block-commit's Bitcoin block have been applied to the Stacks chain state\*
76
85
* In the case of a tenure start block:
77
86
* The first transaction is the `TenureChange` transaction.
78
87
* The first transaction after the `TenureChange` transaction is a `Coinbase`.
79
88
80
-
The properties marked with \* are collectively how Stacks ensures Bitcoin finality. By adhering to these properties, it ensures that miners are only able to append blocks if they build atop the correct chain tip, which also anchors the history to Bitcoin.
89
+
The properties marked with \* are collectively how Stacks ensures Bitcoin finality. By adhering to them, miners can only append blocks that build atop the correct chain tip, which also anchors the history to Bitcoin.
81
90
82
-
Signers, by validating these rules, ensure Bitcoin finality.
91
+
### Conducting Miner Tenure Changes
83
92
84
-
## Conducting Miner Tenure Changes
85
-
86
-
The other primary signing responsibility in block production involves conducting tenure change transactions. As discussed in the mining section, miners will submit a `block-commit` transaction on the Bitcoin chain to initiate mining. If they are selected, stackers will detect that and create a `tenure-change` transaction.
93
+
The other primary signing responsibility in block production is conducting tenure change transactions. As discussed in the mining section, miners submit a `block-commit` transaction on the Bitcoin chain to initiate mining. If a miner is selected, signers detect that and create a `tenure-change` transaction.
87
94
88
95
This tenure change transaction includes:
89
96
@@ -94,19 +101,32 @@ This tenure change transaction includes:
94
101
| burn view consensus hash | Current consensus hash on the underlying burnchain. Corresponds to the last-seen sortition. | 20 bytes |
95
102
| previous tenure end | The index block hash of the last Stacks block from the previous tenure. | 32 bytes |
96
103
| previous tenure blocks | The number of blocks produced since the last sortition-linked tenure. | 4 bytes, big-endian |
97
-
| cause | <p>A flag to indicate the cause of this tenure change<br>- <code>0x00</code> indicates that a sortition occurred, and a new miner should begin producing blocks.<br>- <code>0x01</code> indicates that the current miner should continue producing blocks. The current miner’s tenure execution budget is reset upon processing this transaction.</p> | 1 byte |
104
+
| cause | <p>A flag to indicate the cause of this tenure change<br>- <code>0x00</code> indicates that a sortition occurred, and a new miner should begin producing blocks.<br>- <code>0x01</code> indicates that the current miner should continue producing blocks. The current miner's tenure execution budget is reset upon processing this transaction.</p> | 1 byte |
98
105
| pubkey hash | The ECDSA public key hash of the current tenure. | 20 bytes |
99
106
100
-
This tenure change transaction is then sent to the newly elected miner and they must include it as the first transaction in their first block, otherwise stackers will not approve it.
107
+
This tenure change transaction is then sent to the newly elected miner, who must include it as the first transaction in their first block, otherwise signers will not approve it.
108
+
109
+
This process repeats as new miners are elected for tenures.
110
+
111
+
[SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) has a detailed description of what happens under the hood during these processes.
112
+
113
+
***
101
114
102
-
This process is then repeated over and over as new miners are elected for tenures.
115
+
### If You Knew Signing Under PoX-4
103
116
104
-
Be sure to take a look at [SIP-021](https://github.com/stacksgov/sips/blob/feat/sip-021-nakamoto/sips/sip-021/sip-021-nakamoto.md) to get a detailed description of exactly what happens under the hood during these processes.
117
+
The corrections to the old model, in one place:
105
118
106
-
Next up, let's dig a little deeper into this idea of Bitcoin finality and how the Stacks block production mechanism achieves it.
119
+
* Stackers registered a block-signing key with every stacking or delegate-stack transaction. That is gone: a signer-manager holds one signer key through a one-time grant, revocable by the key holder.
120
+
* Reward slots are gone, and with them the cap of 4,000 slots per cycle. The signer set is the set of qualifying signer-managers, and weight comes from staked STX rather than slots clinched.
121
+
* Delegation is gone, so the old distinction between stackers who sign and stackers who delegate their signing no longer describes anything. Signing belongs to the key granted to the signer-manager a staker stakes to.
122
+
* SIP-021 specifies signing with an aggregate Schnorr signature generated through the WSTS protocol, including a distributed key generation round each cycle. The node validates blocks against a set of individual signer signatures weighted by stake, as described above. Read the WSTS material in SIP-021 as design history.
0 commit comments