> For the complete documentation index, see [llms.txt](https://docs.stacks.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stacks.co/learn/zh/network-fundamentals/technical-specifications.md).

# 技术规范

### 共识

* 证明转移（PoX），在 [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md) 中引入，如今已是第五个版本 PoX-5，如 [SIP-045](https://github.com/stacksgov/sips/blob/main/sips/sip-045/sip-045-pox-5-bitcoin-staking.md)
* 威胁模型
  * 重组 Stacks 链需要控制当前质押 STX 的至少 70%。比特币挖矿算力无法单独重组 Stacks，尽管它可以审查 sortition，但比特币重组仍会使锚定到它的 Stacks 任期失去连接
  * 如果 Stackers 无法就区块有效性达成 70% 共识，链可能会停止
* 不同参与者及其角色
  * Stacks 矿工将交易打包进区块，并将其提议给 stackers
  * Stackers 验证并将区块追加到链上
  * sBTC 签名者是一个独立集合，由其在 [SIP-028](https://github.com/stacksgov/sips/blob/main/sips/sip-028/sip-028-sbtc_peg.md)下各自的注册合约治理，并验证 sBTC 存款和取款交易

### 证明转移挖矿

* coinbase 奖励：每个比特币区块 1,000 STX，没有计划中的递减。它从创世起就是 1,000 STX，在 SIP-029 下于比特币高度 945,000 时降至 500 STX，并在 SIP-045 下激活 Epoch 4.0 时于比特币高度 960,230 时恢复为 1,000 STX。SIP-045 将 1,000 STX 费率描述为 PoX-5 引导阶段的临时方案，重新评估推迟到 PoX-6
* coinbase 奖励会累积于“错过的 sortition”：如果某个比特币区块没有 sortition（在高度 N），那么在随后某次 sortition 中挖出的、基于在倒数第二次 sortition（在高度 N-1）时存在的任意 Stacks 链尖的 Stacks 区块可以领取其 coinbase。这鼓励矿工即使在比特币手续费很高时也继续挖矿。
* 奖励成熟窗口：100 个任期，意味着矿工在成功挖出该任期后的 100 个任期后获得 coinbase 奖励。一个任期就是一次获胜的 sortition，因此这大致相当于 100 个比特币区块，而不是 100 个 Stacks 区块
* 区块间隔：Stacks 在矿工的任期内连续出块，区块间隔约为十秒。协议层没有目标出块时间；节点强制区块之间至少间隔一秒。新的任期通常在每个比特币区块时开始
* BTC 承诺：一次 block-commit 恰好有一个 commit 输出，支付到奖励周期的 sBTC 存款地址，并携带完整配置的 `burn_fee_cap`。共识只要求该金额非零。该输出仍必须满足比特币自身的 dust relay policy 才能传播
* 更多详情请参见 [区块生产](/learn/zh/block-production.md).

### 质押

{% stepper %}
{% step %}
**奖励阶段**

矿工的 BTC 承诺为奖励池提供资金，奖励池通过收益瀑布进行分配。奖励阶段长度为 2,000 个区块。
{% endstep %}

{% step %}
**准备阶段**

将选择一个“锚定区块”，并根据该区块时链的快照确定下一周期的签名者集合。准备阶段长度为 100 个区块。质押承诺需要在此阶段开始前确认。
{% endstep %}
{% endstepper %}

* 一个奖励周期为 2,100 个比特币区块（约 2 周）：先是 2,000 个区块的奖励阶段，然后是 100 个区块的准备阶段
* 在 PoX-5 下，矿工 BTC 不再支付给一组 stacker 奖励地址。每次 block-commit 都会向奖励池支付一个单一输出，该奖励池会自动桥接到 sBTC，并通过三层瀑布式分配：先是活跃协议债券，然后是仅 STX 的质押者，最后是储备基金
* 质押最低额度：50,000 STX（`u50000000000`），按每个签名者的总量计算。没有单个质押者最低额度
* 向你未运行的签名者进行质押取代了 PoX-4 的委托。质押者调用 `stake` 针对一个签名者管理合约，该合约会在一笔交易中将他们注册到其所有已质押周期中
* 单独持有低于签名者最低额度的 STX 持有者可以向共享签名者管理器进行质押以参与

### 账户和地址

* Stacks 区块链中的交易源自账户，由账户支付，并在账户的授权下执行
* 一个账户由其地址 + nonce + 资产完全定义
* 一个地址由 1 字节版本号加 20 字节公钥哈希（RIPEMD160(SHA256(input))) 组成。合约主账户再加上 1 到 40 字节的合约名称。为向后兼容在该限制设定前编写的合约主账户，最长 128 字节的名称也能解析，但交易中不能携带超过 40 字节的名称
* 两种账户类型：标准账户由一个或多个私钥拥有；合约账户在智能合约实例化时生成（由上面的合约名称指定）
* nonce 记录账户已授权交易的次数。起始值为 0，有效授权必须包含 *下一个* nonce 值。
* 资产是所有资产类型——STX、任何由 Clarity 合约指定的链上资产（例如 NFT）——到该账户所拥有数量的映射。
* 账户不必显式“创建”或注册；所有账户都隐式存在，并在首次使用时实例化。

### 交易

* 交易类型：coinbase、token-transfer、contract-deploy、contract-call、tenure-change。第六种类型 poison-microblock 存在于线格式中，但不能提交，并且在 Nakamoto 之后已失效
* 只有标准账户（不是合约）可以支付交易费用。
* 交易执行受以下因素约束：

{% stepper %}
{% step %}
**发起账户**

创建、授权并发送该交易的账户。
{% endstep %}

{% step %}
**支付账户**

由 leader 按验证和执行交易的成本向其计费的账户。
{% endstep %}

{% step %}
**发送账户**

标识当前正在执行该交易的账户：随着交易通过……执行，这一账户可能会改变 `as-contract?` Clarity 函数。
{% endstep %}
{% endstepper %}

* 两种授权类型：标准授权是指发起账户与支付账户相同。 *赞助式* 授权是指发起账户和支付账户不同。例如，开发者或服务提供商可以为用户调用其智能合约付费。
* 对于赞助式授权，用户先使用发起账户签名，然后赞助者使用支付账户签名。
* nonce 链式限制：提交交易的 nonce 最多可比账户链上 nonce 超前 26。该限制对发起方和赞助方分别适用，并且是对你可提前排队多少的窗口，而不是对待处理交易的上限
* 待处理的内存池交易在收到后 42 小时 40 分钟会被垃圾收集。参见 [`MEMPOOL_MAX_TRANSACTION_AGE`](https://github.com/stacks-network/stacks-core/blob/4.0.3/stackslib/src/core/mempool.rs#L72)
* [在 SIP-005 中了解更多关于交易编码的信息](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-encoding)
* [交易签名和验证在 SIP-005 中有说明](https://github.com/stacksgov/sips/blob/main/sips/sip-005/sip-005-blocks-and-transactions.md#transaction-signing-and-verifying)
* 所有影响账户余额的交易都是原子的，转账操作不可能在不减少另一个账户余额的情况下增加某个账户的余额。不过，执行多个账户操作的交易（例如，从多个账户转账）可能会部分完成。
* token-transfer 交易可以包含一个恰好 34 字节、以零填充的 memo 字段


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.stacks.co/learn/zh/network-fundamentals/technical-specifications.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.