---
title: "区块链：状态、共识与验证"
description: "区块链是一套版本化协议，让多个副本对状态转换进行排序和验证。哈希链接只是其中一个组件；信任还取决于共识、权限、独立验证、数据可用性、治理和恢复机制。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 区块链：状态、共识与验证
> 仅用于协议教育分析。区块链标签、有效的哈希链或成功交易本身不能证明去中心化、输入真实、数据可用、最终性、法律所有权或投资价值。
## 直接回答
区块链是一种版本化协议，允许多个副本对提议的交易进行排序、验证状态转换并在规定的共识和网络假设下收敛到可接受的历史记录。区块是协议定义的容器，其中包含交易或其他数据以及对先前历史记录和结果状态的承诺；链或定向历史通过加密承诺链接接受的容器。
哈希链接可以检测到未经授权的历史更改，但不能单独使系统去中心化、不可变或正确。这些属性取决于谁可以提议和验证、用户能否独立验证、分叉选择与最终性规则、数据可用性、客户端多样性、治理、密钥控制、激励和恢复程序。
区块链可以使用 UTXO、账户、对象或特定于应用程序的状态模型；工作量证明、权益证明、拜占庭容错投票或许可共识；以及概率或基于检查点的最终性。因此，“区块链”一词指的是一个广泛的架构系列，而不是一种安全保证或一种数据库产品。
## 它是如何运作的
1. 固定正在测试的链、网络、协议版本、权限模型、状态模型和声明。记录创世或可信检查点、链标识符、客户端实现和升级权限。
2. 构建准确的交易字节和授权。在广播之前检查发送者或输入所有权、nonce 或未花费输出引用、金额、目的地址、费用限制、有效期、签名和应用调用。
3. 通过对等点或网关传播交易。区分本地准入和内存池政策与共识有效性；节点可能会拒绝、延迟、替换或永远不会接收区块中可能有效的交易。
4. 提议者选择交易、确定顺序并装入候选区块，对父区块、交易、收据、状态或数据根等协议字段作出承诺。交易顺序会影响执行结果、费用、清算和可提取价值。
5. 独立节点反序列化区块，验证共识授权和每个所需的状态转换，重新计算承诺并根据其规则拒绝无效或不可用的输入。生产者签名或工作证明不会覆盖失败的验证。
6. 分叉选择是在竞争的有效历史中进行选择，而确认、投票或检查点会随着时间的推移改变重组风险。 “包含”、“安全”和“最终确定”是不同的状态，并且仍然特定于协议。
7. 将协议状态与应用意图、托管、桥或平台账务及归档要求核对。保留交易字节、区块哈希、高度或时隙、收据、日志、状态证明、最终性状态、客户端版本和独立端点证据。
## 工作示例
- **账户状态核对。** 账户初始有 `10 ETH`，nonce 为 `41`。nonce 为 `41` 的有效交易转出 `2 ETH` 并消耗 `0.00042 ETH` 手续费，因此简化后的状态为 `10 - 2 - 0.00042 = 7.99958 ETH`；接收方增加 `2 ETH`，发送方 nonce 变为 `42`。仅有有效签名并不能证明前置余额充足或执行成功。
- **UTXO 守恒。** 一笔交易花费 `0.80 BTC` 和 `0.35 BTC` 两个输入，合计 `1.15 BTC`。输出 `1.00 BTC` 和 `0.1496 BTC` 合计 `1.1496 BTC`；差额 `1.15 - 1.1496 = 0.0004 BTC` 是手续费。节点还必须验证每个引用输出存在、尚未花费并满足花费条件。
- **承诺证明大小。** 在具有 `8 leaves` 的说明性平衡二元 Merkle 树中，包含路径需要 `log2(8) = 3 sibling hashes`。对于 `256-bit = 32-byte` 哈希，这些同级在索引和编码之前占用 `3 * 32 = 96 bytes`。该证明将叶子与所声称的根绑定在一起；它不能证明源数据是真实的或当前可用的。
- **权重不等于节点数。** 在一个明确以 `>= 2/3` 权重作为最终性阈值的示例投票协议中，验证者权重为 `30%, 25%, 20%, 15%, 10%`。前三者合计 `30 + 25 + 20 = 75%`，超过阈值；前两者合计 `55%`，未达到阈值。真实阈值、相关性、双重投票和恢复规则必须以具体协议为准。
## 风险
- 使用错误的链、网络、分叉、检查点或链标识符。
- 将品牌名称视为完整的协议或信任模型规范。
- 假设哈希链接本身就可以防止授权或共识批准的重写。
- 将生产者的区块提案与独立节点验证混淆。
- 将内存池接受、广播、包含、执行成功和最终确定视为一种状态。
- 签署与界面显示不同的字节、域或目标。
- 重复使用 nonce、花费过时的 UTXO，或错误计算手续费和找零。
- 信任代币符号、标签、事件或区块浏览器解释，而不是协议标识符和状态。
- 将签名的预言机、桥或文档输入视为链下声明真实性的证据。
- 忽略交易排序、审查、抢先交易以及提议者或构建者的集中度。
- 在不解析常见运算符、权重和基础设施的情况下对节点或验证器进行计数。
- 忽略客户端、云服务商、地域、治理、密钥和软件供应链集中度。
- 假设所有共识模型具有相同的故障阈值或最终语义。
- 忽略网络分区、最终性延迟、重组、双重投票和恢复程序。
- 在没有所需数据可用性假设的情况下接受块头或证明。
- 依赖一个 RPC、浏览器、钱包、索引器或托管平台作为事实来源。
- 将协议占有或控制与法定所有权、追索权或可恢复性混淆。
- 低估状态增长、档案丢失、同步成本和硬件障碍。
- 忽略升级密钥、紧急暂停、社交恢复和有争议的分叉。
- 从区块链标签推断隐私性、可扩展性、投资价值或应用安全性。
## 常见的误解
- **每个区块链都是去中心化且不可变的。** 权限、操作员独立性、分叉选择、治理和恢复决定了谁可以改变或拒绝历史。
- **链上记录的数据必须真实。** 共识可以同意如实记录虚假价格、伪造文件或恶意应用程序输入。
- **有效的交易证明了预期的结果。** 它可能会瞄准错误的地址、消耗费用后恢复、发出误导性事件或依赖于后续的桥接和托管步骤。
- **副本越多就一定越安全。** 由同一运营方、客户端、云服务或密钥控制的副本可能同时失效，也未必提供独立验证。
- **区块链总是比传统数据库更好。** 受信任的运营商、所需的删除、高吞吐量或简单的争议解决可以使传统系统更合适。
## 相关主题
- [共识机制](/zh-cn/crypto/consensus-mechanism/)
- [加密哈希](/zh-cn/crypto/cryptographic-hash/)
- [全节点](/zh-cn/crypto/full-node/)
## 来源
- [区块链技术概述](https://doi.org/10.6028/NIST.IR.8202) - NIST（访问时间：2026-08-18）
- [比特币：点对点电子现金系统](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org（访问时间：2026-08-18）
- [区块链](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin.org（访问时间：2026-08-18）
- [区块](https://ethereum.org/developers/docs/blocks/) - Ethereum.org（访问时间：2026-08-18）
- [交易](https://ethereum.org/developers/docs/transactions/) - Ethereum.org（访问时间：2026-08-18）
- [节点和客户端](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org（访问时间：2026-08-18）
- [共识机制](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org（访问时间：2026-08-18）
- [最终性](https://ethereum.org/developers/docs/consensus-mechanisms/pos/finality/) - Ethereum.org（访问时间：2026-08-18）
Source: https://wiki.fcontext.com/zh-cn/crypto/blockchain/index.mdx