技术规格

共识

• 转移证明（PoX），如中所述 SIP-007

• 网络将过渡到燃烧证明（PoB），如中所述 SIP-001 在 10 年后。 在 SIP-001 中了解更多关于燃烧证明的信息.

• 威胁模型

  • 51% 的恶意比特币挖矿算力可以重组 Stacks 链或进行双花攻击

  • 如果 Stackers 无法就区块有效性达成 70% 共识，链可能会停止

• 不同参与者及其角色

  • Stacks 矿工将交易打包成区块并向 Stackers 提议

  • Stacks 持有者可以调整区块限制的计算方式（受矿工否决权约束），并可投票在一个奖励周期内禁用转移证明奖励。

  • Stackers 验证并将区块追加到链上，并验证 sBTC 存款和提款交易

转移证明挖矿

• Coinbase 奖励计划：

  • 前 4 年每个区块 1000 STX

  • 接下来 4 年每个区块 500 STX

  • 之后 4 年每个区块 250 STX

  • 此后永久每个区块 125 STX

• Coinbase 奖励会累积用于“错过的排序”：如果某个比特币区块没有排序（在高度 N），那么任何在后续某次排序中挖出的、基于在倒数第二次排序（在高度 N-1）时存在的任一 Stacks 链尖端的 Stacks 区块，都可以领取其 coinbase 奖励。这鼓励矿工即使在比特币手续费很高时也继续挖矿。

• 初始挖矿奖励：这是上述机制的一个特殊情况，旨在激励早期矿工。第一个燃烧区块高度（由独立矿工作为 Stacks 2.0 启动的一部分选择）与第一个排序赢家之间的所有燃烧链区块的 coinbase 将累积，并在一个固定窗口内（待确定）分配给矿工。例如，假设燃烧区块高度为 10,000，第一次排序在区块 10500，分配窗口为 100 个区块，那么前 500 个区块（10,500 - 10,000）的 coinbase 将在随后 100 个区块中平均分配给赢得排序的矿工。

• 奖励成熟期：100 个区块，这意味着领导者将在成功挖出的区块之后 100 个区块获得 coinbase 奖励。

• 区块间隔：Stacks 区块链大约每 10 秒产生一个快速区块，每个比特币区块发生一次矿工任期变更

• BTC 承诺：矿工必须至少承诺 11,000 聪（5,500 sats / UTXO 输出）；每个区块 2 个输出）以避免“尘埃”。

• 更多详情请参见区块生产。

Stacking

1

准备阶段

会选定一个“锚定区块”。合格地址集合（“奖励集合”）根据锚定区块处链的快照确定。准备阶段长度为 100 个区块。该阶段开始前必须确认 Stacking 承诺。

2

奖励阶段

矿工的 BTC 承诺将在奖励集合中分配。奖励周期长度为 2000 个 BTC 区块（约 2 周）。

• 每个区块有两个奖励地址，共计每个奖励周期 4000 个地址。地址使用 VRF（可验证随机函数）选择，因此每个节点都可以确定性地为给定区块得出相同的奖励地址。

• Stacking 门槛：当参与率在 25% 到 100% 之间时，为参与 STX 数量的 0.025%；当参与率低于 25% 时，门槛始终为 STX 流动供应量的 0.00625。

• 委托：一个 STX 地址可以指定另一个地址代表其参与 Stacking。 SIP-007 中的相关部分.

• 合池：单独不满足 Stacking 门槛的 STX 持有者可以联合其持仓来参与 Stacking。为此，STX 持有者必须将（可选的）奖励地址设为“委托地址”。更多详情请参见 此参考资料.

• 支持 Legacy、SegWit、Native Segwit 和 Taproot 地址

账户和地址

• Stacks 区块链上的交易源自账户、由账户支付，并在账户的授权下执行

• 一个账户由其 地址 + nonce + 资产 完整指定

• 地址包含 2 或 3 个字段：1 字节版本、20 字节公钥哈希（RIPEMD160(SHA256(input))）、可选名称（可变长度，最大 128 字节）

• 两类账户：标准账户由一个或多个私钥拥有；合约账户在智能合约被实例化时形成（由上面的可选名称字段指定）

• Nonce 记录账户授权交易的次数。起始为 0，有效授权必须包含 下一个 nonce 值。

• 资产是所有资产类型的映射——STX、由 Clarity 合约指定的任何链上资产（例如 NFT）——到该账户持有的数量。

• 账户无需显式“创建”或注册；所有账户都隐式存在，并在首次使用时实例化。

交易

• 交易类型：coinbase、token-transfer、contract-deploy、contract-call、tenure-change。

• 只有标准账户（不是合约）可以支付交易费用。

• 交易执行受以下因素约束：

1

发起账户

创建、授权并发送交易的账户。

2

支付账户

由领导者计费、用于验证和执行交易成本的账户。

3

发送账户

标识当前正在执行交易的账户：这可以在交易执行过程中通过 as-contract Clarity 函数发生变化。

• 交易可以批量打包或流式写入区块。其行为可由交易的锚定模式控制。通过流式（微区块），可以实现更快的确认时间。

• 两种授权类型：标准授权中，发起账户与支付账户相同。 赞助式 授权中，发起账户与支付账户不同。例如，开发者或服务提供商可以为用户调用其智能合约支付费用。

• 对于赞助式授权，用户首先使用发起账户签名，然后赞助者使用支付账户签名。

• 并发待处理交易的 mempool 上限为每个账户 25 个

• 待处理的 mempool 交易将被垃圾回收 在接收后 256 个区块。若目标区块时间为 10 分钟，这相当于约 42 小时

• 在 SIP-005 中了解更多关于交易编码的信息

• 交易签名和验证在 SIP-005 中有描述

• 所有影响账户余额的交易都是原子的，一次转账操作不能在不减少另一账户余额的情况下增加某一账户的余额。不过，执行多个账户操作的交易（例如，从多个账户转账）可能会部分完成。

• 交易可以包含一段 memo 字符串（最大 34 字节）