区块链交易如何运作？从构造到状态变更

区块链交易是获得授权的网络状态变更请求

区块链交易并不是价值穿过某条看不见的通道，而是一组结构化数据，用于请求网络执行特定变更。这种变更可能是转移原生币、调用智能合约、转移代币、创建资产，或者更新账本中的其他记录。

首先，钱包根据目标网络的规则构造交易对象；然后，由必要的签署者使用数字签名授权。签名后的数据被广播给网络节点，由节点依据协议规则独立验证，再决定是否将其纳入被接受的区块或有序批次。

只有被网络接受的执行才会改变共享状态。在此之前，交易只是一个提议。即使它已经被广泛传播、可以查询且符合基本规则，也未必已经在规范账本中改变余额、控制权或合约存储。

比特币交易消耗以前的输出并创建新输出；以太坊将交易视为账户发起的加密签名指令；Solana 将签名和一条或多条指令打包为交易；TON 则在账户处理消息并改变状态时记录交易。数据结构不同，但核心过程具有共性。

用户表达意图，钱包负责生成交易对象

用户通常只会提出简单目标：发送 0.01 BTC、转账 50 USDT、兑换代币或与合约交互。区块链无法直接执行人的意图；钱包或应用必须将其转换为目标网络能够识别的精确交易格式。

这种转换十分重要，因为简洁的操作界面隐藏了多项技术决策。比特币钱包需要挑选可花费输出并计算找零；以太坊钱包需要确定 nonce 并估算 gas；Solana 和 TON 的钱包还要准备各自要求的账户、区块引用和消息。

因此，交易不只是付款指令，而是一份机器可读的声明：什么需要改变、谁有权批准、可以使用哪些资源，以及必须遵循哪些网络规则。

不同网络使用不同字段，但交易都需要足够的验证信息

不存在适用于所有区块链的统一交易格式。不过，多数交易都有共同要素：可用资源、目标结果、必要授权、防重放或排序规则，以及发送者愿意承担的执行成本。

比特币交易开发指南解释了输入如何引用旧输出，以及新输出如何定义未来的花费条件。以太坊交易文档介绍收款方、金额、数据、nonce、gas 限额和费用参数等字段。

数字签名授权的是准确的交易数据，并不会单独转移资金

钱包利用一个或多个私钥，对交易数据的特定表示进行签名。网络参与者可以用对应的公钥或花费条件验证签名，从而确认所需密钥批准了交易，而不需要获知私钥本身。

签名证明的是授权，不是人的真实身份。有效签名说明有人控制协议要求的密钥，但不能证明签署者是谁，也不能确认商业协议成立，或收款方就是企业本来想支付的对象。

签名覆盖的字段同样重要。如果修改受保护的金额、目的地址、指令或其他已签字段，签名将失效。这也是中间方通常无法在保留原授权的情况下修改已签名转账的原因。

UTXO 模型与账户模型以不同方式描述可支配状态

交易格式由账本模型决定。比特币采用未花费交易输出（UTXO）模型：交易消耗指定的旧输出并生成新输出。网络不会更新一个全局比特币账户余额；钱包通过查找其密钥能够花费的输出，计算可用余额。

以太坊采用账户模型。外部拥有账户具有余额和 nonce，交易依照 nonce 顺序执行，可能修改余额、合约代码和存储。以太坊账户文档说明 nonce 如何阻止同一笔已签名交易被反复执行。

Solana 交易会列出程序指令要读取或写入的账户。程序执行指令并更新可写账户。近期区块哈希限制交易保持有效的时间。Solana 官方交易文档介绍签名、指令、账户公钥和近期区块哈希。

TON 以消息驱动。传入消息可触发一个账户上的交易，改变其状态，并生成发往其他账户的消息。TON 消息与交易文档对这一关系作了说明。

广播传播候选交易，并不等于全网已经达成一致

签名完成后，钱包将序列化的交易发送给节点或服务。接收节点先检查一些基本条件，再决定是否接收并转发；其他节点不断重复，使交易逐步传播。

传播既不是瞬时的，也不是完全同步的。各节点的连接情况、软件策略、资源上限和本地账本视图均有差异。一个浏览器可能已经显示待处理交易，而另一个服务尚未发现；某些节点拒收的交易，也可能仍被其他节点保留。

比特币点对点网络指南介绍完整节点之间如何交换交易。因此，“已广播”仅意味着钱包开始发送候选交易，不意味着所有参与者已经接受同一个规范结果。

节点会同时验证交易数据及其拟执行时的账本状态

验证签名只是众多检查中的一步。节点还会检查序列化格式、字段取值、引用的资源和排序要求，再根据自己当前掌握的账本状态测试请求。

对比特币而言，被引用的输出必须存在且未花费；解锁数据应满足花费条件；输入价值需要覆盖输出价值与隐含手续费。试图花费已使用输出的交易，在对应链状态下无效。

对以太坊而言，签名必须正确识别发送者，nonce 必须符合账户顺序。发送账户还应负担转账金额及最高执行成本，交易类型也必须符合当前规则。合约执行还会进行额外检查，并可能发生回滚。

Solana 检查必要签名、近期区块哈希、账户锁、指令结构、手续费余额和运行时规则。TON 则验证传入消息，并按协议规定的阶段处理账户。

候选交易
├─ 数据结构正确吗？
├─ 所需签名有效吗？
├─ 输入或账户状态可用吗？
├─ 顺序 / nonce / 区块哈希符合要求吗？
├─ 费用与资源充足吗？
└─ 协议允许该操作吗？
   ├─ 否 → 拒绝或不再转发
   └─ 是 → 保留为待入块候选

有效性取决于执行时的上下文。一笔交易可能在签名时有效，却在入块前失去可用性：别的交易花费了相同的比特币输出、以太坊较低 nonce 的交易仍然缺失，或 Solana 的近期区块哈希已经过期。

有效的待处理交易只是被本地接收，还没有规范入账

很多网络维护通过初步检查但尚未入块的本地交易池。“内存池（mempool）”是方便的称呼，但通常不存在单一的全球待处理池：各节点根据自己的视图和政策管理候选集合。

区块生产者从自己能够看到的交易中挑选。处理容量、手续费激励、交易依赖、账户顺序和执行约束都会影响选择。因此有效交易可能持续待处理、被其他交易替换、超过有效期限，或从某些节点的池中消失。

OxaPay 的内存池详解说明了交易为何竞争有限处理容量，以及入块时间为何变化。这里仅从生命周期角度理解内存池；手续费市场和区块空间竞争需要另外的深入分析。

纳入区块为交易确定其在已接受历史中的执行位置

矿工、验证者、领导节点或排序器选取交易并提出有序区块或批次。其他网络参与者按协议验证提案。被接受后，区块成为当前规范历史的一部分，或者成为随后可获得更强确认承诺的已接受候选历史。

顺序非常重要，因为交易可能依赖前一状态。两笔交易可能争夺同一资源；合约调用在不同顺序下可能得到不同结果；账户 nonce 要求顺序执行；Solana 的账户锁还会影响并行执行。

因此，入块并非只是添加时间戳，而是把交易放在状态转换序列中的特定位置：它在此前操作之后、此后操作之前进行判断与执行。

执行按照确定性规则将前置状态转换为后置状态

交易到达其执行顺序时，网络应用相应规则。从概念上，可以用状态转换函数表示：

post_state = transition(pre_state, ordered_transaction, protocol_rules)

在比特币中，成功验证会从 UTXO 集合中移除已花费输出并添加新输出。在以太坊中，成功执行可以改变余额、增加发送者 nonce、部署合约、修改合约存储并产生日志。以太坊执行规范测试明确比较执行前状态和期望的执行后状态。

在 Solana 中，每条指令使用声明的账户调用程序，账户状态变化具有原子性：交易整体成功，或者其状态更改被回滚。在 TON 中，处理消息可以修改一个账户，并发出之后触发其他账户交易的消息。

代币转账说明交易与价值转移并非同一概念。在许多智能合约链上，原生交易调用代币合约；合约更新其内部记载的余额，并可能发出转账事件。并不存在一件独立的“代币物体”从一个地址穿行到另一个地址。

收据、日志、事件和执行追踪提供过程证据，但它们并不都等于状态本身。应用可以通过事件发现代币转账，仍需要明确哪些结果代表自己所需的权威状态变化。

拒绝、丢弃、替换、过期和回滚发生在不同层次

“失败交易”这一说法过于笼统。格式错误或未授权的交易可能在传播前被拒绝；有效交易可能因为未被选中而待处理、被竞争交易替换或过期；智能合约调用也可能已经入块，却在执行时回滚。

查看区块链浏览器时必须区分这些情况。以太坊交易即使已入块，也可能显示执行失败且消耗 gas。没有进入当前规范链的比特币交易，如果仍然有效并再次广播，之后可能重新出现。Solana 交易则可能因近期区块哈希失效而过期。

交易哈希标识数据，但不能解释交易的全部含义

交易标识符通常根据序列化数据生成，使节点、浏览器、钱包和应用能够在不重复完整数据的情况下引用特定交易。具体哈希方法和标识规则因网络而异。

OxaPay 关于加密交易 ID 的指南解释了商户如何用 TXID 验证交易和处理客户支持。区块链浏览器可以显示地址、金额、手续费、区块位置、执行状态和确认数。

但交易哈希无法告诉商家它对应哪个订单，也不知道预期资产、正确网络、发票金额、付款期限、客户身份或交付政策。它是网络引用，不是完整的商业记录。

生命周期相似，但交易语义和保障机制取决于具体公链

不同网络都会从拟议操作走向被接受的状态，但内部机制不同。比特币处理输出花费；以太坊既能转 ETH 又能调用合约；Solana 将指令作用于明确列出的账户；TON 则以消息和单账户处理为核心。

这些差异影响手续费、交易大小、排序、并行执行、过期、代币识别，以及“成功”的含义。支付系统也必须据此解读数据：ERC-20 付款可通过合约执行和日志识别；比特币原生付款通过交易输出识别；TON Jetton 转账可能需要追踪多个合约之间的消息链。

仅凭资产名称还不够，商家必须同时确认资产与网络。OxaPay 支持币种文档提供币种及相应网络信息，同一个代币符号在不同网络上可能需要不同的交易解析逻辑。

区块链交易只是完整支付系统中的一条记录

付款请求首先包含商业上下文：订单、金额、选定资产、网络、收款目的地、有效期以及业务参考编号。区块链交易记录付款人实际上发送的内容；支付系统则将预期条件与观察到的交易进行比对。

OxaPay 的付款信息接口展示了这种分离。付款记录可能包含跟踪标识、订单内容和整体付款状态；交易层数据则可能包含哈希、金额、币种、网络、地址、状态和确认次数。

网络交易与商业付款状态有关联，但不能互换。OxaPay 付款状态表列有等待、付款中、已付款、少付、退款中、已退款和已过期等商业状态。这些含义不是区块链本身产生的。

商业付款请求
订单 + 预期金额 + 资产 + 网络 + 时限
           ↓
区块链交易
哈希 + 输入/账户 + 指令 + 签名 + 执行结果
           ↓
付款解释
匹配 + 确认策略 + 异常规则 + 商业状态

因此，即使支付网关处理了协议细节，商户仍然需要理解交易。这样才能区分网络证据和付款完成，并排查错误网络、金额不符、入块延迟、执行失败及无法匹配的转账。

通过七个步骤理解任何区块链交易

1. 意图：用户或应用定义想达到的结果。
2. 构造：钱包将意图转化为网络专用交易对象。
3. 授权：必要密钥对准确数据或花费条件进行签名。
4. 传播：节点接收、检查并转发候选交易。
5. 接收与选择：有效候选根据本地政策、容量、顺序和费用等待处理。
6. 入块与执行：交易获得确定顺序，在前置状态上执行。
7. 被接受的状态：结果进入网络历史，随着时间推移获得更强的确认与承诺。

很多人把“已发送”当作“状态已变更”。这一模型说明，在账本反映结果之前，交易仍需经过构造、授权、验证、排序和执行。

本分析使用的协议文档与权威资料

• 比特币开发者指南 — 交易
• 比特币开发者指南 — 点对点网络
• 以太坊文档 — 交易
• 以太坊文档 — 账户
• 以太坊执行规范测试 — 状态转换
• Solana 文档 — 交易
• TON 文档 — 消息与交易