> For the complete documentation index, see [llms.txt](https://axon-finance.gitbook.io/axon-finance-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://axon-finance.gitbook.io/axon-finance-docs/part-iii-ji-shu-jia-gou/part3-architecture/3-3-consensus-finality.md).

# 3.3 共识、亚秒最终性与性能目标

## 为什么共识决定支付的命运

一条链的共识机制，决定了它能否胜任支付。因为共识回答的正是支付最关心的两个问题：**「这笔交易多久能确定？」** 和 **「确定之后还会不会反悔？」**

对支付而言，第二个问题尤其致命。这就引出了一个必须讲清的概念：**最终性（finality）**。

## 两种最终性：概率的 vs 确定的

并非所有「确认」都一样。区块链有两种截然不同的最终性模型：

{% tabs %}
{% tab title="概率最终性" %}
**概率最终性（Probabilistic Finality）**

典型代表是中本聪式的工作量证明链。一笔交易被打包后，它「被推翻」的概率随着后续区块的累积而指数级下降——但**永远不会严格归零**。

* 你需要「等待 N 个确认」，本质是在等概率足够低；
* 对大额支付，往往要等待很久才「足够安全」；
* 对支付场景，这种「几乎确定」始终留着一丝不确定的尾巴。

**问题**：支付需要的是「确定到账」，而不是「大概率到账」。
{% endtab %}

{% tab title="确定性最终性" %}
**确定性最终性（Deterministic / BFT Finality）**

典型代表是 BFT（拜占庭容错）风格的共识。一旦交易被一个法定多数（quorum）的验证者确认，它就**立即、不可逆地最终确定**——不存在「被更长的链取代」的可能。

* 无需「等待 N 个确认」——确认即最终；
* 最终性可以做到亚秒级；
* 对支付而言，这才是「钱确定到账了」的语义。

**AXON 的选择**：确定性最终性。支付不能建立在概率之上。
{% endtab %}
{% endtabs %}

**AXON 采用高吞吐 PoS + BFT 风格的确定性最终性共识**——因为只有确定性最终性，才能给支付一个明确的「成交」时刻。

## 性能设计目标

现在来谈数字。作为一份诚实的白皮书，我们必须先做一个声明：

| 指标        | 设计目标                                 | 状态              |
| --------- | ------------------------------------ | --------------- |
| 网络吞吐（TPS） | 支付级持续吞吐 **> 10,000 TPS**，架构上向更高量级演进  | `Design Target` |
| 确定性最终性    | **亚秒级（< 1s，目标区间约 400–800ms）**        | `Design Target` |
| 出块 / 区块间隔 | **约 250–500ms**                      | `Design Target` |
| 交易费用      | **亚美分级（目标 < $0.001 / 笔）**，可预测的固定费用模型 | `Design Target` |
| 费用代付      | Paymaster 支持，用户可无需持有 gas 代币完成支付      | 设计              |
| 共识        | 高吞吐 PoS + BFT 风格确定性最终性               | 设计              |
| 去中心化      | 验证者启动规模较小，按路线图（P2）逐步扩大并交由治理接管        | 路线图             |

为什么这些目标区间对支付是合理且必要的：

* **>10,000 TPS**——要承载全球规模的支付与 M2M 微支付流量，吞吐必须留出数量级的余量；
* **亚秒最终性**——支付发生在真实世界的交互里（扫码、点击、机器调用），确定成交必须快到「无感」；
* **\~250–500ms 出块**——决定了从提交到确定的下限，直接影响用户体感；
* **亚美分费用**——按调用付费的 M2M 微支付若单笔成本高于几美分，其经济模型根本不成立。

## 可预测，比「更便宜」更重要

对支付而言，一个常被忽视的点是：**费用的可预测性，往往比费用的绝对高低更重要。** 一个商户可以接受「每笔固定 0.1 美分」，但无法接受「费用随网络拥堵在 0.1 美分到 5 美元之间跳动」——后者让定价、对账与商业模型全部失控。

因此 AXON 的目标不只是「低费」，而是\*\*「低且可预测」\*\*的费用模型：支付的成本应当像一条稳定的基础设施定价，而非一个随市场情绪波动的拍卖价格。这一点，正是通用链在设计上难以提供的。

***

*延伸阅读：*[*3.4 支付最终性与反双花*](/axon-finance-docs/part-iii-ji-shu-jia-gou/part3-architecture/3-4-payment-finality.md) *·* [*附录 B · 参数汇总*](/axon-finance-docs/fu-lu/appendix/b-parameters.md)


---

# 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://axon-finance.gitbook.io/axon-finance-docs/part-iii-ji-shu-jia-gou/part3-architecture/3-3-consensus-finality.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.