刚接触Hyperledger Fabric的人，十有八九会在“记账”这两个字上卡住。不是看不懂账本结构，而是搞不清一笔交易从客户端发起之后，中间到底经过哪些节点、哪些阶段、谁的账本先动、谁的后动，最后又是怎么落进区块里的。我自己第一次顺着源码和文档往下捋时，把背书、排序、提交三个环节来回串了好几遍才完全对上。这篇就把整个记账流程拆开揉碎讲清楚，从交易提案一路讲到peer落盘，适合正在上手Fabric、对账本写入链路还比较模糊的开发者参考。
1. 先看懂Fabric账本的两个“存储面”：世界状态与区块日志
1.1 一份账本，两种形态：World State和区块日志各管什么
Fabric的账本物理上被拆成两个层面。第一个层面叫世界状态（World State），本质是一份基于键值结构的当前数据快照，存的是这个通道上所有资产的最新值。你可以把它理解成Excel表格里“当前余额”那一列，查询资产余额时直接读它就行，非常快。第二个层面是区块链日志（Blockchain Ledger），也就是一串按哈希链串联起来的区块文件，每个区块里装着若干交易记录，负责存“过去每一笔流水”。
这两个层面都保存在peer节点本地。世界状态默认用LevelDB或CouchDB存储，区块日志则按文件方式落盘。设计上有明显的分工：世界状态为了快，区块日志为了全。你随时可以从区块日志出发，把某个key的全部历史改动轨迹翻出来；也可以从世界状态出发，一秒得到当前值。日常业务读取走世界状态，审计和溯源走区块日志。
我在读源码时有个体会：Fabric账本的更新顺序是“先区块、后状态”，也就是说，任何一笔交易进了账本，第一步一定是先写入区块链日志，之后再根据交易有效性更新世界状态。这一点理解对了，后面很多细节顺理成章。
1.2 记账的角色分工：四个身份，三条流水线
一笔交易走完记账流程，涉及四类参与方，很多人容易把它们的职责混在一起：
- 客户端（SDK或CLI），负责构造交易提案、收集背书、提交交易；
- 背书节点（Endorsing Peer），收到提案后模拟执行链码，产出读写集并签名；
- 排序节点（Orderer），对交易做全局排序、打包成区块，再广播给通道内的peer；
- 提交节点（Committing Peer），接收区块，完成验证、冲突检查、落盘。
注意一个细节：在Fabric中，同一个peer物理上既可以是背书节点也可以是提交节点，取决于通道的背书策略指定了谁去执行链码。但逻辑职责必须拆开。整个记账流程本质上就是三条流水线串行推进：客户端与背书节点之间的“执行”流水线、排序节点的“排序”流水线、peer提交阶段的“验证与写账本”流水线。这也就是Fabric常说的Execute-Order-Validate架构。
理解这个架构很重要，哪怕不看源码，只要把三条流水线切分清楚，后续遇到交易异常时定位范围就非常快：卡在背书阶段，那是链码或背书策略问题；卡在排序阶段，那是orderer配置或网络问题；卡在提交阶段，那多半是背书检查没过或MVCC冲突。
2. 交易提案与背书节点模拟执行：第一步只是“模拟”，账本还没动
2.1 客户端如何构造一个交易提案
Fabric记账流程的真正起点，是客户端构造一个交易提案（Proposal）。千万不要小看这一步，提案里该装什么字段，直接决定后续背书节点能不能读懂你的意图。
一个标准的提案主要由两部分组成：一部分是通道头部信息（Channel Header），包括通道名、链码名、交易类型、时间戳、随机数nonce，以及客户端身份证书和对头部信息的签名；另一部分是链码调用说明（ChaincodeInvocationSpec），指明要调用哪个链码、哪个方法、传入什么参数。
这里有个极易被忽略的设计：客户端生成的nonce，加上自己的签名，共同起到防重放的作用。如果同一笔提案在通道里被重复提交，排序节点可以通过nonce和交易ID识别出来。交易ID的生成规则就是客户端身份证书加上nonce做哈希，所以同一笔交易在通道内是唯一的，这也是后面查账时筛选重复交易的关键依据。
提案构造好之后，客户端会根据链码部署时指定的背书策略，把提案发给对应的背书节点集合。举例来说，如果策略是OrgA和OrgB各出一个节点背书，那客户端就会把提案同时发给这两个组织的背书节点，而不是只发一个。
2.2 为什么背书节点只“模拟执行”，而不是直接修改账本
背书节点收到提案后，先做一系列校验：验证交易提案格式、验证客户端签名、检查链码是否已在该通道实例化、检查客户端是否有调用权限。全部通过后，背书节点会基于本地世界状态的当前值，在隔离环境中执行一遍链码逻辑，生成一份读写集（Read-Write Set，RW Set）。
核心来了：这个阶段只是“模拟执行”。链码在世界状态上做的所有改动都只会被记录成一个期望的新值，并不会真的写入本地账本。为什么这样设计？因为此时节点并不知道这笔交易最终会不会被系统接受。如果背书阶段就真改了状态，一旦后续排序或验证阶段出现冲突，回滚会非常麻烦。Fabric把“算账”和“定账”彻底分离，背书节点的模拟结果只被当作一个“拟议值”。
这一点有点像你买东西先签意向后付款：签意向书不代表交易完成，意向书上的金额、数量会被记录，最终的成交还要等后续阶段确认。
2.3 读写集长什么样，背书签名代表什么
读写集是背书阶段最重要的产物。读集记录链码执行过程中读取过哪些key以及该key当时的版本号；写集记录链码执行过程中打算把哪些key改成什么新值。如果链码里对同一个key执行了多次写入操作，写集里只保留最后一次写入的结果；读集里如果读同一个key多次，也只保留第一次读到的版本号。
版本号这个设计是Fabric处理并发冲突的基石，后面我会讲。简单说，Fabric中每个key的版本号由两个数字组成：这个key最后一次被修改时所在的区块高度，以及该区块中的交易序号。只要有人更新了这个key，版本号就会变化。
背书节点执行完模拟后，会在背书响应里附上读写集和背书签名，再返还给客户端。客户端收到多个背书节点的响应后，第一件事不是急着提交，而是校验这些签名是否合法、背书数量是否满足背书策略。如果背书不满足，客户端可以直接放弃这笔交易，省得把无效提案交给排序节点浪费时间。
3. 排序节点的职责边界：把到达的业务交易排定唯一顺序
3.1 为什么Fabric要单独抽出一个排序服务
很多从其他单链系统迁移过来的开发者，最初都不理解为什么Fabric还要单独做一个orderer节点。其实道理很朴素：在一个分布式网络中，多个客户端几乎同时发起多笔交易，如果不给它们排定一个唯一顺序，每个peer各自独立记账就会得到完全不同的账本状态。账本必须一致，顺序天然需要共识。
Orderer就是专门用来解决“先后顺序”的组件。它把收到的交易按到达顺序做全局排序，并按配置打包成区块。排序过程中orderer只动交易的“信封”，不改业务数据，也不执行链码。换句话说，排序节点不需要懂你的业务逻辑，它只保证“谁先谁后”这件事在全网一致。
在生产环境里，orderer本身通常以集群方式部署在多个组织中，使用Raft共识协议来保证排序节点之间对交易顺序达成一致。日常开发单机测试时也可以跑单节点排序节点，逻辑一样，只是少了容错冗余。
3.2 区块打包参数：什么时候把一个交易块切出来
排序节点不是来一笔交易就立刻出一个区块，而是按系统通道和子通道上配置的打包策略决定区块的切分时机。需要关注三个关键参数：
MaxMessageCount：一个区块最多容纳多少笔交易；PreferredMaxBytes：区块包含的交易数据总量上限；BatchTimeout：从第一批交易进入batch开始计时，超过这个时间即使没凑够交易数也会直接切块。
这三个参数相互配合。举个例子，测试环境如果把BatchTimeout设成2秒，而MaxMessageCount是500笔交易，那么你只提交一两笔交易时，orderer也要等够2秒才会把区块切出来发给peer。很多开发者在本地跑Fabric时觉得交易有延迟，第一反应以为是网络或节点慢，结果查了半天才发现是batch timeout设太长，纯粹是等待打包造成的延迟。
区块切出来后，orderer会把该通道的配置区块序号、排序节点自己的签名等元数据塞进区块的MetaData区域，然后通过Deliver服务向通道内所有peer广播。到这里，排序阶段的使命就结束了。
3.3 排序节点“无状态设计”背后的安全考量
Orderer之所以不维护业务状态，不参与链码执行，不只是为了性能，更多是安全边界。Fabric里有一个很微妙的原则：orderer负责定序，peer负责校验业务有效性。两者分离，意味着即使排序节点被攻破，黑客最多能影响交易顺序，但无法伪造出能通过背书策略和世界状态检查的合法交易。反过来，如果orderer一旦也执行链码逻辑，攻击面就瞬间扩大，共识节点还得承受智能合约运行风险，稳定性会大打折扣。
这一点在实际运维中很有用：如果怀疑orderer节点崩溃会影响账本数据，你可以放心，账本本身不在orderer上，它只传递区块。orderer挂掉后流程中断，但已经写入peer账本的数据不受任何影响。
4. 提交节点验证与落盘：检查背书、版本和冲突后账本才真正更新
4.1 提交前的三道验证关卡
Peer收到orderer广播过来的区块后，进入记账流程里最重要的“验证与提交”阶段。每一笔交易都要依次过三道关卡：
第一道是背书策略检查。验证交易里附带的背书签名是否满足链码部署时指定的背书策略。这里有个容易忽视的点：背书签名不仅要数量够，签名的身份还必须是背书策略认可的组织。如果交易是伪造的，或者签名人身份不在策略范围内，直接判无效。
第二道是读集版本检查。Peer把RW Set里每个key的版本号与本地世界状态里该key的当前版本号做比对。如果一致，说明模拟执行之后这个key没被其他交易改过，可以放心应用写集。如果不一致，说明这笔交易基于的“旧快照”已经过期，按MVCC冲突处理。
第三道是通道配置检查，确保区块确实来自该通道、创建该区块的orderer合法且有权限。
三道检查全部通过后，交易标记为有效，写集被应用到世界状态。任何一道没通过，交易标记为无效，但注意：无效交易依然会被留在区块中，只是不更新世界状态。很多新手第一次发现区块里出现无效交易时会很困惑，甚至以为节点出错。实际上这是Fabric故意为之。
4.2 为什么无效交易不直接从区块里删除
这个设计反直觉，却非常关键。区块哈希的计算覆盖了该区块内所有交易的原始数据，无论交易有效还是无效。如果提交阶段把无效交易从区块里剔除掉，哪怕只剔一笔，都会导致区块的数据哈希发生变化，整个哈希链从该区块开始就会和orderer签名记录的元数据不一致，账本的完整性验证就彻底失效。
所以，无效交易必须原封不动留在区块里，只是通过区块内每笔交易的TransactionActions结果码（或状态标记）来标明它是否生效。这样账本依然是自洽、可审计的。你可以把这个世界想象成流水账上的“作废章”：单据还在，金额不算。
这个机制也带出一个实用结论：查询账本数据不能只用“这笔交易在不在区块里”来判断成功，必须看交易验证结果。业务系统在做最终确认时，应当依赖提交事件里携带的验证码，而不能只依赖背书成功。
4.3 区块落盘：从区块日志到状态数据库的先后关系
有效交易全部验证完毕后，peer先把区块追加到本地区块链日志文件里，再根据区块内有效交易的写集去更新世界状态数据库。顺序不能颠倒，因为世界状态的新版本号就来源于该交易所处的区块号和交易序号。如果先改状态再写区块，万一写区块失败，状态里的版本号会和真实账本对不上。
区块写入后，peer还会同步维护区块索引，比如按区块高度查询、按交易ID查询、按key查询的倒排索引。这个索引数据也在本地账本存储区，不对外共享。同步更新索引是为了后续peer chaincode query、历史溯源这些功能能快速响应，免得每次查询都把整个区块文件扫一遍。
整个流程走完，peer节点会发出BlockEvent和TransactionEvent通知。客户端通过监听事件才能确认一笔交易真正进了账本。这也是我强烈建议业务系统必做的最后一步：只有监听到交易提交成功，才给用户返回“成功”。
5. 记账流程中的常见误解与排查套路
5.1 误区一：以为Fabric是“先共识，再执行”
很多从传统区块链概念入门的人，天然会把记账流程想象成“共识之后统一执行”。Fabric完全不是这个顺序，它是先由背书节点各自模拟执行一遍，再把模拟结果交给orderer排序，最后由peer验证后提交。背书阶段的读写集只是一个建议值，中间任何一步都可能推翻它。
这个误解带来的后果很实际：有些人写完链码，看到背书节点返回了结果就以为交易已经成功，结果数据库里始终查不到数据，反复排查链码逻辑却找不到问题。真相往往是交易在提交阶段因为MVCC冲突或背书策略不满足被标记为无效了。正确的确认方式始终是监听提交事件，看交易的验证码。
5.2 误区二：以为背书成功就等于写入账本
和上面的误区配套，还有一个高频问题：背书节点模拟执行时明明返回了正确的读写集，为什么账本里就是没数据？一个很容易被忽略的情况是——客户端只把提案发给了背书节点，却压根没有把交易提交给orderer。背书阶段和提交阶段是完全割裂的，客户端必须在收集背书后，自己组装成正式交易再发给排序节点。SDK默认会做这件事，但如果你是自己写底层协议交互，很容易漏掉这一步。
我在本地调试时还遇到过另一个版本：客户端确实提交了，但提交给orderer时选错了通道，交易被orderer直接丢弃，peer始终收不到区块。这类问题在区块链浏览器上往往表现为“交易不存在”，而不是“交易无效”。
5.3 记账链路出问题时的快速排障思路
如果交易卡在流程的某个环节，我建议按下面这套思路排查：
先确定卡在哪个阶段。看客户端日志有没有拿到足够的背书，如果卡在背书阶段，优先检查链码是否已实例化、调用参数是否合法、背书策略是否满足。再看客户端有没有把交易真正提交给orderer，如果卡在提交阶段，用peer channel getinfo -c channel名查看当前区块高度，看是不是根本没新高地。
确认orderer是否正常切块。如果交易已经发给orderer但迟迟不出块，先检查BatchTimeout配置，确认是否只是等待超时的问题。如果批量超时和块大小都正常，才去怀疑orderer共识集群的节点选主问题。
最后检查peer是否完成验证。区块广播到peer后，如果发现区块高度在增长但世界状态里没有对应数据，几乎可以断定是MVCC冲突。这时候去看区块里该笔交易的验证标记，确认是否是无效交易。
我个人实践下来的体会是，Fabric记账流程看似环节多，但每一环的边界都非常清晰，只要画出“交易提案→模拟执行背书→排序打包→区块广播→验证提交→状态更新”这条主线，剩下的细节都能顺着这条线逐个攻破。如果你现在正在被某笔交易搞得很头疼，先冷静下来，按这条线定位卡点在哪一段，大概率一眼就能看出问题所在。
