Changes to PoX and Clarity
PoX Contract Changes
PoX Failure
In the event that PoX does not activate, the chain halts. If there are no Stackers, then block production cannot happen.
Changes to PoX
To support tenure changes, Nakamoto uses a new PoX contract, .pox-4
. The .pox-4
contract would be altered over the current PoX contract (.pox-3
) to meet the following requirements:
Stackers register a WSTS signing key when they call
stack-stx
or a delegate provides the signing key withdelegate-stack-stx
.
In addition, a .stackers
boot contracts will be created which carries out the following tasks:
The
.stackers
contract will expose each reward cycle's full reward set, including the signing keys for each stacker, via a public function. Internally, the Stacks node will call a private function to load the next reward set into the.stackers
data space after it identifies the PoX anchor block. This is required for some future Stacks features that have been discussed.The
.stackers
contract will expose two private functions to update the signing set for the following reward cycle.update-signer-set
: will update the reward set for the upcoming reward cycle. It will take in a list of at maximum size 4096 of signer pubkeys.update-current-signer
: will update the the specified signer with their corresponding key-ids.
The
.stackers
contract will expose a function to vote on the aggregate public key used by the Stackers to sign new blocks in the current tenure.vote-for-aggregated-public-key
takes the key of the signer calling the contract, the reward cycle number, the round number, and the list of all tapleaves.
New Stacks-on-Chain Rules
The stack-stx
Stacks-on-Chain transaction will be extended to include the Stacker’s signing key, as follows:
The new field, signing key
, will contain the compressed secp256k1 ECDSA public key for the stacker.
In addition, the following two new Stacks-on-Chain transactions are added:
Delegate-Stack-STX
In Nakamoto, it will now be possible for a stacking delegate to lock up their delegated STX via a Bitcoin transaction. It shall contain an OP_RETURN with the following payload:
Where op
= +
, uSTX to lock
is the number of microSTX to lock up, num-cycles
is the number of reward cycles to lock for. The field has-pox-addr?
can be 0x00
or 0x01
. If it is 0x01
, then index
is treated as a 4-byte big-endian integer, and is used as an index into the transaction outputs to identify the PoX address the delegate must use. The value 0
refers to the first output after the OP_RETURN. The output’s scriptPubKey
is then decoded and converted to the PoX address. If index
points to a nonexistent transaction output or if scriptPubKey
cannot be decoded into a PoX address, then this transaction is treated as invalid and has no effect. If has-pox-addr?
is 0x00
instead, then index is not decoded and the delegate may choose the PoX address.
Stack-Aggregation-Commit
In Nakamoto, it will now be possible for a stacking delegate to commit delegated STX behind a PoX address. It shall contain an OP_RETURN with the following payload:
Where op
= *
, and as with delegate-stack-stx
above, index
is a big-endian 4-byte integer which points to a transaction output whose scriptPubKey
must decode to a supported PoX address. The reward cycle
field is a 4 byte big-endian integer which identifies the reward cycle
for which to aggregate the stacked STX.
Changes to Clarity
Nakamoto produces Stacks blocks occur at a much greater frequency than in the past. Many contracts rely on the block-height
primitive to approximate a time assuming that a block takes, on average, 10 minutes. To release faster blocks while preserving the functionality of existing contracts that make this block frequency assumption, Nakamoto will use a new version of Clarity, version 3, which includes the following changes.
A new primitive
stacks-block-height
that indicates the block height under NakamotoA new Clarity global variable
tenure-height
will be introduced, which evaluates to the number of tenures that have passed. When the Nakamoto block-processing starts, this will be equal to the chain length.The clarity global variable block-height will continue to be supported in the existing Clarity 2 contracts by returning the same value as
tenure-height
, but usage of block-height in a Clarity 3 contract will trigger an analysis error.
Last updated