X2 is Stacks 2.0, whereas
id is Stacks 1.0.
X2 has five extant operations:
- VRF key registers (
- Block commits (
- Stack-STX (
- Transfer-STX (
- PreSTX (
- User burn supports (not implemented, but documented in SIP-001)
The first to operations are concerned with mining. A miner registers a VRF public key once when it comes online, and uses the VRF private key to generate VRF seeds for blocks. The Stacks block must contain VRF proofs generated from this private key. Once its VRF key is registered, the miner proceeds to mine blocks by sending block-commit transactions (which encode the block hash, the parent/child linkage, the height, etc.).
Block-commit transactions can have either two PoX outputs, or a single burn output. The former is only accepted during a reward phase – the first 2000 Bitcoin blocks of a 2100-block reward cycle. The latter is only accepted during a prepare phase – the last 100 Bitcoin blocks of the reward cycle. The reason for this is that prepare-phase block-commits elect the reward set (the set of PoX payout addresses) for the next reward cycle by confirming a block-commit before the prepare phase, which makes it so determining which Stacks block (if any) encodes the reward set does not depend on the node having processed any prior Stacks blocks. This is important, because validating PoX block-commits in a reward phase depends on the node knowing which Stacks block to look at in order to determine the correct set of BTC addresses.
If no reward set was chosen in a prepare phase (i.e. no Stacks block received enough confirmations), then all block-commits in the subsequent reward cycle substitute two burn addresses in place of the two PoX outputs. Moreover, if a miner does not have the Stacks block whose block-commit was elected to chose the reward set, it will be unable to validate PoX block-commits that may arise in this reward cycle. To recover, it will instead (1) build blocks off of an ancestor of this block, and (2) substitute two burn addresses for the PoX outputs, and in doing so, mine a fork which does not depend on the missing block. If the block is truly missing, then subsequent reward cycles will confirm the absence of this block, and thereby prevent a “late-arriving” block from triggering a chain-wide reorg that would otherwise cause unprocessable PoX block-commits to become valid.
The remaining three operations are concerned with empowering users to transfer and Stack their STX in the presence of network censorship. The PreSTX transaction simply registers a UTXO that must be consumed by a subsequent Transfer-STX or Stack-STX. These two operations will cause a
stx-transfer or a
stack-stx to occur, respectively, in a Stacks block selected in the subsequent Bitcoin block. The Stacks block selected in this subsequent Bitcoin block must include state-transitions for these operations as if they were Stacks transactions; otherwise the block will be invalid. This ensures that STX holders have a way of “routing around” uncooperative ISPs and STX miners – the Bitcoin transactions cannot be ignored for free.