rippled 账本处理机制深入解析生命周期、账本流、数据结构与账本清理器【免费下载链接】rippledDecentralized cryptocurrency blockchain daemon implementing the XRP Ledger protocol in C项目地址: https://gitcode.com/GitHub_Trending/ri/rippled导读本文以 rippledXRP Ledger 服务器实现的 Ledger Process 文档 为核心系统讲解账本从开放、关闭到共识、验证、发布、回溯的完整生命周期阐述账本数据在网络中获取与组装的优先级机制、FetchPack 传输协议梳理账本核心数据结构AccountRoot、RippleState、LedgerHashes、DirectoryNode 等的字段语义并给出账本清理器Ledger Cleaner的完整运维命令与参数说明。阅读本文后你将能够理解 rippled 账本子系统的整体架构掌握ledger_cleaner等运维工具的实际用法并能对照源码定位关键实现。一、账本生命周期Ledger Life Cycle1.1 从开放账本到共识提案rippled 服务器在任何时刻都维护着一个开放账本Open Ledger所有新收到的交易都会先应用到开放账本上。开放账本不会立即关闭它必须同时满足两个条件才允许进入关闭流程前一个账本已经完成共识开放账本中至少包含一笔交易或者账本的关闭时间已经到达。在开放账本关闭的瞬间其中的交易集合就构成了服务器的初始提案initial proposal。验证节点validator会把这份提案广播到网络非验证节点则不会广播提案——这是验证节点与普通服务器在共识阶段唯一的实质性差异。1.2 共识、构建新账本与 rebase账本关闭后所有服务器通过雪崩式avalanche的共识过程就候选交易集candidate transaction set与关闭时间达成一致。共识达成后服务器以上一个已关闭账本previous last closed ledger为起点应用共识交易集构建出新的已关闭账本。需要注意在整个共识过程中开放账本始终保持开放并持续接收新的交易。这些新交易很可能与共识交易集存在重叠。共识期间收到的新有效交易只会出现在开放账本中而不会出现在新的已关闭账本里。共识完成后验证节点会对新的已关闭账本发布验证validation。随后服务器从已关闭账本构建新的开放账本过程分两步先应用上一轮共识中候选但未进入共识集的交易再应用当前开放账本中的交易覆盖上一轮共识期间收到的交易。这一步在代码中被称为rebase重定基——既然现在已经知道了真实的历史就把当前的开放账本重新对齐到已关闭账本之上。对应实现可参考 OpenLedger::accept它基于新关闭账本创建新的开放视图并依次应用 retriable 交易、当前开放视图中的交易与本地交易locals。开放账本有两个核心用途构成共识期间初始提案的基础用于判断能否在不转发的情况下直接拒绝某笔交易减少无意义的网络传播。1.3 拜占庭故障Byzantine Failures的应对如果网络中存在一个超级多数supermajority账本那么少数派验证节点会发现共识轮次正在一个与自己认知不同的账本上推进。这些节点会进入desynced失步状态转而采取尽力获取共识账本的策略。如果不存在多数账本则下一个共识轮次将无法就已关闭账本达成共识此时会重新启动一轮新的雪崩过程。对应的状态与回退逻辑可见 LedgerMaster.h 中对当前账本、正在关闭账本与账本历史的跟踪设计。1.4 验证节点与普通服务器的唯一区别文档 明确指出验证节点与普通服务器唯一的实质性区别就是验证节点会向网络发送提案proposal与验证validation普通服务器不发送。除此之外两者在账本处理的其余环节上行为完全一致。二、账本流The Ledger Stream2.1 账本优先级共识账本与最新已验证账本对于一个 xrpld 服务器有两本账本最为重要共识账本consensus ledger最新已验证账本last validated ledger。如果服务器缺少这两者中的任何一个都会以最高优先级去获取并且当它们到达时会替换掉之前对应的旧版本。LedgerMaster对象承担了账本流的核心协调职责它跟踪最新发布的账本last published ledger最新已验证的账本last validated ledger账本历史ledger history。因此LedgerMaster是获取历史账本数据的中心枢纽。从源码看它内部通过LedgerHolder closedLedger_、LedgerHolder validLedger_、pubLedger_以及RangeSetstd::uint32_t completeLedgers_分别维护关闭账本、已验证账本、已发布账本与本地完整账本区间见 LedgerMaster.h。其中LedgerMaster::doAdvance()是触发历史数据获取、并控制账本获取状态机的核心方法实现。2.2 连续发布与回填Backfill策略服务器会尽力向客户端发布连续的已验证账本流。假设服务器完成追赶后处于账本 500 的结算阶段它会尽最大努力依次发布已验证的 500、501、502……直到关机。但加载压力或网络波动可能中断这条流。例如服务器发布了已验证的 600随后收到 603 的验证——此时它需要回填 601 和 602。回填的优先级规则如下优先跟上当前账本只有当前账本已跟上、且没有更高优先级的任务时才尝试回填历史回填顺序从最新的缺失账本开始缺 601、602 时先请求 602再回填 601目的是优先扩大本地最近账本的连续区间历史数据有上限例如当前在 603但缺失 4 号账本时可能不值得去请求。在doAdvance()的实现中只有当满足未处于本地负载isLoadedLocal()为假、旧账本发布任务少于 10、已发布账本与已验证账本序列一致、已验证账本年龄小于 1 分钟、节点存储写负载低于 8192等一系列条件时服务器才会以InboundLedger::Reason::HISTORY的原因获取历史账本见 LedgerMaster.cpp。是否值得获取由shouldAcquire()决定候选账本若可能是当前账本、或处于配置的ledger_history范围内、或不低于minimumOnline阈值才会被获取shouldAcquire 实现。[ledger_history]配置项控制启动时获取的历史账本数量与运行期间维持的最小数量默认 256详见 cfg/xrpld-example.cfg[fetch_depth]则控制愿意向其他对等节点提供多少历史账本默认 full不推荐低于 128见 cfg/xrpld-example.cfg。对应的解析逻辑支持full/none/数字三种取值在 Config.cpp。2.3 账本组装Assembling a Ledger当来自对等节点的账本数据到达时服务器不一定能立即应用因此会调度一个任务线程来应用数据。若任务启动前又有新数据到达则把新数据追加到该任务中直到该账本的所有已到达数据都被处理完才发起新的数据请求——这样可以用最少的数据请求精准补齐缺失部分从而降低网络流量并减轻数据提供节点的负载。如果收到的是当前未在构建中的账本数据服务器不会直接丢弃尤其是AccountStateNodes状态树节点因为它们可以跨账本复用。这些数据会暂存在内存而非数据库中供获取流程acquire process使用。InboundLedger类就是正在尝试获取的账本的载体其成员如haveHeader_、haveState_、haveTransactions_、byHash_记录了账本组装的进度见 InboundLedger.h。2.4 数据到达顺序按可验证性排序对等节点会按照数据可被验证的顺序交付账本数据具体如下账本头的哈希ledger header hash账本头ledger header交易树与状态树的根节点root nodes状态树的非根下层节点lower nodes交易树的非根下层节点lower nodes。内层节点先于外层节点到达这允许请求方服务器按照数据到达的顺序逐步挂接并验证。如果上述流程失败服务器还可以按哈希请求整本账本数据而不是按节点逐个请求。按哈希请求效率较低但对等节点无需把数据组装成树也能返回——只要持有原始数据即可。2.5 选择向哪个对等节点请求对等节点会随着网络状态变化而经历状态迁移并把自己的状态告知直连对等节点。通过监视每个连接对等节点的状态服务器可以判断哪个对等节点持有自己所需的信息。因此当服务器遭遇拜占庭故障时它能判断出哪些对等节点没有遭受同样的故障从而知道该向谁请求缺失数据。此外对等节点还会报告自己连续的账本区间contiguous range of ledgers这也是选择数据来源的重要依据。还有一种间接查询indirect queries机制如果获取账本数据时发生超时服务器可能发起间接查询收到间接查询的服务器会把它转发给可能持有数据的其他对等节点。这在网络发生拜占庭故障时尤为重要也有助于保护验证网络——例如一个验证节点需要从其他验证节点获取对等节点集合间接查询能提高成功率。2.6 获取账本的触发原因InboundLedger::Reason枚举定义了三种获取账本的触发场景见 InboundLedger.hHISTORY获取过去的账本GENERIC其他通用原因CONSENSUS共识轮次需要该账本。账本清理器Ledger Cleaner触发获取时使用GENERIC原因见 LedgerCleaner.cpp。三、FetchPack对等节点间的账本数据传输3.1 普通 FetchPackFetchPack是对等节点之间传输部分账本数据、使接收方能够重建账本的方式。一个普通normalFetchPack 是一个按哈希索引的节点桶bucket of nodes indexed by hash。构建 FetchPack 的服务器会把接收方可能需要的信息放进去通常包含补齐一本账本所需的全部缺失节点。从实现看FetchPack 由LedgerMaster::makeFetchPack()构造核心逻辑是populateFetchPack()它通过want.visitDifferences(have, ...)遍历请求方想要但与请求方已有数据不同的节点序列化后逐个加入协议对象见 LedgerMaster.cpp。接收到的 FetchPack 会缓存于fetchPacks_容量 65536、TTL 45 秒的TaggedCache见 LedgerMaster.cpp并通过哈希校验sha512Half确保数据完整性getFetchPack。3.2 紧凑 FetchPackCompact FetchPack紧凑compactFetchPack只包含叶节点不包含内部节点。由于缺少内部节点账本信息在组装过程中无法被逐步验证服务器必须暂时信任 FetchPack 的准确性先完整组装账本再对整本账本做整体验证。如果验证失败整个 FetchPack 只能被丢弃——因为无法保留其中任何一部分。3.3 反向 FetchPack 与前向 FetchPack展望上述 FetchPack 都只提供历史数据可以称为反向 FetchPackreverse FetchPack。文档还设想了前向 FetchPackforward FetchPack的用途包含从前一账本构建新账本所需的信息。一个前向紧凑 FetchPack 需要包含新账本的账本头header交易树的叶节点如有状态树中被删除节点的索引状态树中新增节点的索引与数据状态树中被修改节点的索引与新数据。四、核心术语定义Definitions以下是文档对账本系统中关键术语的权威定义术语定义开放账本Open Ledger服务器应用所有新进入交易的那本账本。最新已验证账本Last Validated Ledger服务器确定将永远保留在永久公开历史中的最新账本。最新已关闭账本Last Closed Ledger服务器认为网络已达成共识的最新账本。不同服务器可能得出不同结论这是拜占庭故障的后果验证validation的目的就是消除服务器间的分歧就哪本已关闭账本具有权威性达成共识。共识Consensus一种分布式一致性协议XRPL 用共识过程解决双重支付问题。验证Validation一条签名声明表示节点在共识过程中构建了特定账本。提案Proposal一份签名声明表示节点认为哪些交易应被纳入下一个共识账本。账本头Ledger Header哈希到账本哈希的数据块包含序列号、父哈希、前一账本哈希、状态树根节点哈希等。账本基Ledger Base账本获取过程中一种特定类型的查询与响应包含账本头也可能包含状态树根节点等其他信息。五、账本数据结构Ledger Structures账本中的状态条目SLE具有LedgerEntryType字段标识类型。文档详细说明了以下几种核心结构相关类型定义与序列化字段可对照 include/xrpl/protocol 下的 LedgerFormats、SField 等头文件。5.1 Account Root账户根Account160 位账户 ID。Balance账户余额。Flags标志位文档标注待补充。LedgerEntryTypeAccountRoot。OwnerCount账户拥有、需要计费的项目数量。挂单offer会计费信任线可能计费但不一定。OwnerCount 决定账户的储备金reserve。PreviousTxnID该账户上一笔交易的 256 位索引。PreviousTxnLgrSeq该账户上一笔交易所处账本的序列号。Sequence账户要处理一笔有效交易时该值必须为 1。初始值与签署交易的账户的状态树序列号一致执行交易的过程会递增该序列号——这正是 rippled 防止同一笔交易被重复执行的机制。index该 AccountRoot 的 256 位哈希。5.2 Trust Line信任线 / RippleState信任线是连接两个账户的边由 HighNode 和 LowNode 分别代表的账户构成。哪个账户是高、哪个是低由两个 160 位账户 ID 的数值大小决定——账户 ID 较小的一方永远是低账户。这种排序保证账户 A 与 B 之间的信任线哈希与 B 与 A 之间的信任线哈希相同保证方向无关性。Balancecurrency标识合法货币的字符串如BTCissuer实际上没有发行人该条目为NoAccountvalue余额数值。Flags标志位文档标注待补充。HighLimitcurrency与 Balance 相同issuer160 位账户 IDvalue该发行人愿意接受的该货币的最大金额。HighNode删除提示deletion hint。LedgerEntryTypeRippleState。LowLimit结构与 HighLimit 一致value为该发行人愿意接受的该货币的最大金额。LowNode删除提示。PreviousTxnID该账户上一笔交易的 256 位哈希。PreviousTxnLgrSeq上一笔交易所在账本的序列号。index该 RippleState 的 256 位哈希。5.3 Ledger Hashes账本哈希列表Flags标志位文档标注待补充。Hashes前 256 个账本的哈希列表。LastLedgerSequence最后账本序列号。LedgerEntryTypeLedgerHashes。index该 LedgerHashes 条目的 256 位哈希。5.4 Owner Directory所有者目录列出与某账户关联的所有挂单和信任线。Flags标志位文档标注待补充。Indexes账户所拥有项目的哈希列表。LedgerEntryTypeDirectoryNode。Owner所有者账户的 160 位 ID。RootIndex根索引。index所有者账户的哈希。5.5 Book Directory订单簿目录列出具有**相同兑换率quality**的一个或多个挂单。如果某一对 Currency 与 Issuer 字段全为零则该对处理的是 XRP。文档特别指出当前代码并不识别 Currency 和 Issuer 字段是货币与发行人因此这些值以十六进制呈现而非账户与货币形式。文档将其标注为一个应被修复的 bug。ExchangeRate64 位数值前 8 位是指数exponent其余位是尾数mantissa。其格式保证更大的 64 位值总是代表更高的兑换率。每种类型都可以计算自己的哈希。Book Directory 的哈希的最低 64 位包含兑换率——这意味着若多个几乎相同但兑换率不同的 Book Directory 存在它们会在账本中相邻排列最优兑换率会排在 Book Directory 序列的最前面这对订单簿扫描的效率至关重要。Flags标志位文档标注待补充。Indexes与该 BookDirectory 的兑换率和货币匹配的挂单的 256 位哈希。LedgerEntryTypeDirectoryNode。RootIndex始终与 index 相同。TakerGetsCurrencytaker 收到的货币类型。TakerGetsIssuerGetsCurrency 的发行人。TakerPaysCurrencytaker 支付的货币类型。TakerPaysIssuerPaysCurrency 的发行人。index256 位哈希其高 192 位由 TakerGetsCurrency、TakerGetsIssuer、TakerPaysCurrency、TakerPaysIssuer 计算得出低 64 位为兑换率。六、账本发布Ledger Publication6.1 概述XRPL 服务器允许客户端订阅连续的、完全验证过的账本流发布代码负责维护这条流。服务器会尽力维持连续性一旦落后太多就跳到当前完全验证的账本再尝试恢复连续流。6.2 实现LedgerMaster::doAdvance在可能需要向客户端发布账本时被调用它会循环执行直到无法取得进一步进展do { ... } while (advanceWork_)见 LedgerMaster.cpp。工作流程为首先调用LedgerMaster::findNewLedgersToPublish若最新完全验证账本的序列号大于最后已发布账本的序列号则尝试发布这些账本必要时先从网络获取。若没有新账本可发布doAdvance判断是否可以回填历史。如果发布尚未跟上则不尝试回填以节省资源——对应代码中的一系列保护条件见上文 2.2 节。若可以回填历史先获取缺失账本中序列号最高的一本。若该历史账本被获取到且其前驱账本已在数据库中则调用tryFill更新本地驻留账本列表。发布路径上的关键调用为setFullLedger(ledger, true, true)与app_.getOPs().pubLedger(ledger)——前者将账本完整写入本地后者通过 NetworkOPs 通知订阅客户端。6.3 两个值得注意的常量在 LedgerMaster.cpp 中定义了两个影响历史获取行为的常量kMaxLedgerAgeAcquire{1}分钟超过该年龄的账本不再因历史原因获取kMaxWriteLoadAcquire{8192}节点存储写负载超过该值时不获取历史避免加重磁盘压力。七、账本清理器The Ledger Cleaner7.1 概述账本清理器用于检查和修复 SQLite 账本数据库与交易数据库也可以检查某个账本在节点后端node back end中缺失的部分并触发账本获取。它只能通过人工请求启动绝不会自动运行LedgerCleaner基类的职责声明见 LedgerCleaner.h。源码注释说明了其要解决的两类问题见 LedgerCleaner.cpp旧版本可能让 SQLite 账户与交易数据库处于不一致状态清理器识别并修复这些不一致按请求检查账本缺失节点并触发获取。7.2 操作行为清理器可以处理单个账本或一段账本区间它始终验证账本链本身确保 SQLite 数据库包含从最新已验证账本一直回溯到数据库起始处的一致账本链按请求可额外修复每个被检查账本中 SQLite 交易条目——这主要用于修复一个现已修复的bug 产生的错误条目该 bug 可能让来自非完全验证账本的交易与正确账本的交易一同出现在 SQLite 数据库中按请求可额外检查账本在账户状态树与交易树中是否缺失条目为避免占满可用 I/O 带宽、并用古老信息过度污染缓存清理器会自我限速不追求快速完成。从实现看doLedgerCleaner()每处理完一本账本都会sleep(100ms)成功或sleep(2s)失败并在本地负载过高时等待 5 秒见 LedgerCleaner.cpp。它从maxRange_向minRange_方向逐个处理账本处理成功后从两端收缩区间。7.3ledger_cleanerRPC 命令清理器通过ledger_cleanerRPC 命令控制与监控RPC 注册见 Handler.cpp处理函数见 LedgerCleaner.cppRPC其核心就是调用app.getLedgerCleaner().clean(context.params)。不带参数调用时该命令报告清理器状态被要求处理的账本区间、正在执行的检查、发现的错误数量对应实现中onWrite输出的status、min_ledger、max_ledger、check_nodes、fix_txns、fail_counts等字段见 LedgerCleaner.cpp。带参数调用时可启动、停止或改变清理器的行为参数语义如下参数解析见 LedgerCleaner.cpp参数类型说明stop布尔优雅停止清理器。实现上把minRange_与maxRange_均置为 0清理循环随即退出。ledger整数按序列号清理指定的单个账本。实现中同时把fix_txns_与check_nodes_置为true即单账本清理默认执行全量检查。min_ledger/max_ledger整数设置或修改要清理的账本区间。若都不指定默认清理所有账本即完整已验证区间。full布尔对指定账本执行全部操作。实现中fix_txns_ checkNodes_ full。fix_txns布尔是否无条件替换 SQLite 交易条目。check_nodes布尔是否检查指定账本在后端节点存储中是否缺失节点。值得说明的默认行为ledger_cleaner默认会执行清理器认为必要的清理fix_txns_与check_nodes_默认均为false仅在显式开启full、ledger、fix_txns或check_nodes时才会执行相应操作。RPC 调用示例使用rippled命令行客户端命令均为人工运维触发服务器不会自动运行# 查看清理器当前状态 rippled ledger_cleaner # 清理单个账本自动附带 full 检查 rippled ledger_cleaner {ledger: 1234567} # 清理一段区间并修复交易条目 rippled ledger_cleaner {min_ledger: 1000000, max_ledger: 1100000, fix_txns: true} # 对一段区间执行全量检查 rippled ledger_cleaner {min_ledger: 1000000, max_ledger: 1100000, full: true} # 优雅停止清理 rippled ledger_cleaner {stop: true}注意ledger_cleaner属于管理类 RPC通常需要管理员权限并通过本地或受信任连接调用执行清理时请关注服务器 I/O 负载清理器虽然自带限速但大范围修复仍会消耗磁盘资源。八、总结从账本生命周期到账本流管理从 FetchPack 数据交换到账本清理器运维rippled 的账本子系统围绕一个核心目标设计让网络中的每台服务器以最高概率达成一致的账本结论。LedgerMaster作为历史数据获取与发布的状态机中枢配合InboundLedger的按序组装、OpenLedger的 rebase 与重试机制以及LedgerCleaner的人工修复能力构成了完整闭环。对于开发者与运维者本文提供的配置项[ledger_history]、[fetch_depth]、RPC 命令ledger_cleaner与源码路径LedgerMaster.h、OpenLedger.h、LedgerCleaner.cpp可以直接作为进一步排查问题、优化节点配置的起点。【免费下载链接】rippledDecentralized cryptocurrency blockchain daemon implementing the XRP Ledger protocol in C项目地址: https://gitcode.com/GitHub_Trending/ri/rippled创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考