区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载本文以 GrinMimblewimble 协议的极简实现官方的状态与存储文档为主体结合仓库源码深入讲解 Grin 区块链的全量状态由哪些数据构成、如何通过四重校验保证状态可信、输出 MMR / 范围证明 MMR / 内核 MMR 的哈希内容与剪枝原理以及底层基于内存映射的追加式文件存储与压缩compaction机制。读完本文你将能理解 Grin 节点在最重链most worked chain锚定下如何组织、校验并持久化全部链状态并能在源码中定位对应的实现与测试。Grin 的状态构成Grin 的链状态与比特币式的UTXO 数据库 区块数据不同它把交易历史的可验证摘要集中组织在四类数据中。根据官方文档 doc/translations/state_JP.md英文原版见 doc/state.md一条 Grin 链的全量状态由以下数据组成全部未花费输出UTXO集合每个输出对应的范围证明range proof全部交易内核transaction kernel为上述三类数据各维护一棵 MMRMerkle Mountain Range——唯一的例外是输出 MMR 中包含的是全部输出的哈希而不仅仅是未花费的 UTXO。此外链中所有区块头都必须以有效的 PoW工作量证明锚定上述状态即状态始终对应工作量最大的那条链。这是 Grin 状态一致性的顶层约束只有最重链的区块头里所携带的 MMR 根才被认定为当前有效状态。文档还特别指出一个重要的存储优化结论一旦每个范围证明都被验证过、且所有内核承诺的总和已经计算完毕范围证明与内核对于节点的正常运行就不再是严格必需的。这正是后续剪枝pruning得以成立的依据——它们只服务于验证而非当前状态本身。从源码结构看这三类数据与三棵 MMR 的对应关系被明确实现在 chain/src/txhashset/txhashset.rs 中存储根目录下分别使用output、rangeproof、kernel三个子目录加上txhashset顶层目录共同构成完整的状态存储单元源码常量TXHASHSET_SUBDIR、OUTPUT_SUBDIR、RANGE_PROOF_SUBDIR、KERNEL_SUBDIR。状态的验证四项核心校验文档指出只要拥有完整的 Grin 状态就能对状态本身执行以下四项验证从而在不依赖区块历史全文的情况下证明整条链是合法的内核签名有效性每个内核的签名必须相对于其承诺commitment即公开密钥有效。这证明该内核是合法构造的。在源码中内核core/src/core/transaction.rs由features、excess承诺和excess_sig签名组成签名验证在 chain/src/txhashset/txhashset.rs 的verify_kernel_signatures中以每 5000 个一批KERNEL_BATCH_SIZE批量完成。总供应量守恒所有内核承诺之和必须等于所有 UTXO 承诺之和 − 总供应量total supply。这证明了内核与输出承诺全部有效且没有凭空铸造出任何意外的币。其实现位于 core/src/core/committed.rs 的verify_kernel_sums分别计算utxo_sum与内核 excess 之和 kernel offsetkernel_sum_plus_offset两者不相等则返回KernelSumMismatch错误。MMR 成员与根正确性所有 UTXO、范围证明、内核的哈希都必须存在于各自对应的 MMR 中且这些 MMR 能够哈希出正确的根。对应源码为 chain/src/txhashset/txhashset.rs 的validate_mmrs对三棵 MMR 逐一调用validate()以及validate_roots将当前 MMR 根与最新区块头中记录的根比对。最重链锚定在某一时刻已知的、工作量最大的区块头必须包含这 3 棵 MMR 的根。这一条同时验证了 MMR 的正确性并证明全部状态是由最重链产生的防止攻击者用一条低工作量侧链的状态冒充主链状态。这四项校验被完整地组织在TxHashSet::validate入口中chain/src/txhashset/txhashset.rs先做 MMR 内部校验、根校验、尺寸校验validate_sizes比对 header 中记录的output_mmr_size、kernel_mmr_size等再计算内核总和最后在非快速验证fast_validation模式下逐批验证全部范围证明verify_rangeproofs默认每 1000 个一批与内核签名。MMR 与剪枝叶子节点的哈希内容每个 MMR 的叶子节点由位置信息 具体数据哈希构成。官方文档明确了三棵 MMR 各自的叶子哈希来源MMR叶子哈希内容输出 MMRoutput MMR特征字段feature field与创世块以来所有输出的承诺commitment的哈希范围证明 MMRrangeproof MMR每个范围证明的完整数据whole range proof data的哈希内核 MMRkernel MMR每个内核的全部字段的哈希特征feature、手续费fee、锁高度lock height、剩余承诺excess commitment、剩余签名excess signature对照源码可以印证这些字段输出由特征 承诺构成OutputIdentifier见 core/src/core/transaction.rs其上的范围证明存放在Output.proof字段core/src/core/transaction.rs内核的五个字段在TxKernel结构体core/src/core/transaction.rs中均有对应成员KernelFeatures枚举core/src/core/transaction.rs则定义了 Plain普通内核带手续费、Coinbasecoinbase 内核、HeightLocked锁定高度内核、NoRecentDuplicateNRD 相对高度约束内核等特征类型。文档强调了一个容易被忽略的实现约束所有输出、范围证明和内核都必须按照其在各自区块中出现的顺序被追加进对应的 MMR这也是区块数据必须排序的原因。从代码看Extension结构体chain/src/txhashset/txhashset.rs同时持有output_pmmr、rproof_pmmr、kernel_pmmr三个 PMMR 实例在新块应用时按同一顺序写入三棵 MMR保证了三者的位置一一对应——这是后续删除日志位置与 MMR 节点位置天然对齐这一设计能够成立的根本前提。剪枝规则当某个输出被花费后其承诺与范围证明数据都可以被删除与此同时对应的输出 MMR 与范围证明 MMR 也可以被剪枝。注意内核 MMR 与内核数据不在剪枝范围内——因为内核承担着总供应量守恒的验证职责且文档已指出内核验证完毕后虽非必需但剪枝的收益主要来自体积较大的范围证明。状态存储追加式文件 内存映射 删除日志文档对 Grin 状态存储的概括非常精炼输出、范围证明、内核的数据存储是简单的追加式append-only文件 内存映射memory-mapped数据访问。具体机制分三步追加写入新数据只允许追加到文件末尾天然适配 MMR 与区块的单调增长特性删除日志当输出被花费时不会立即物理删除文件内容而是由删除日志remove log记录哪些位置可以被移除。由于所有数据都按同一顺序插入这些位置与 MMR 节点位置完美对齐压缩compaction当删除日志变得过大时周期性执行重写——把文件中尚未被删除的部分重新写出依然是追加式并清空删除日志从而把对应文件压缩紧凑。在源码中这一设计体现在两层追加式文件store/src/types.rs 定义了AppendOnlyFileT其核心成员除了文件句柄外还有一个memmap::Mmap用于读取时的内存映射访问以及一个未落盘字节缓冲buffer——写入先进入缓冲、flush 时再追加到文件保证读性能与写吞吐。可剪枝 PMMR 后端store/src/pmmr.rs 的PMMRBackendT把文档中的抽象落地为 4 个配套文件源码常量见 store/src/pmmr.rspmmr_hash.bin哈希文件固定 32 字节/条追加式pmmr_data.bin叶子数据文件定长或变长元素变长时辅以pmmr_size.bin记录每条长度pmmr_leaf.binLeafSet即删除日志的现代实现——一个基于 roaring bitmap 的紧凑位图记录当前未剪枝的叶子位置见 store/src/leaf_set.rspmmr_prun.binPruneList记录被剪枝pruned/compacted的根节点位置用于在读文件时做位置平移shift换算见 store/src/prune_list.rs。文档所说删除日志变小时不动作、变大时重写压缩的过程对应PMMRBackend::check_compactstore/src/pmmr.rs根据 cutoff 位置与回滚位图计算待移除的叶子与节点位置将哈希文件和数据文件写出临时剪枝副本write_tmp_pruned再用replace_with_tmp原子替换原文件最后更新PruneList并落盘。上层由TxHashSet::compactchain/src/txhashset/txhashset.rs调度对输出与范围证明两个可剪枝后端执行同样的压缩流程。状态目录结构真实落盘布局将上面的机制落到磁盘上一个 Grin 节点的txhashset目录结构源码中的文件清单见 chain/src/txhashset/txhashset.rs大致如下txhashset/ ├── output/ │ ├── pmmr_hash.bin # 输出 MMR 的节点哈希追加式 │ ├── pmmr_data.bin # 输出feature commitment数据 │ ├── pmmr_leaf.bin # 未剪枝叶子位置位图LeafSet │ └── pmmr_prun.bin # 已剪枝根位置PruneList ├── rangeproof/ │ ├── pmmr_hash.bin │ ├── pmmr_data.bin # 范围证明数据 │ ├── pmmr_leaf.bin │ └── pmmr_prun.bin └── kernel/ ├── pmmr_data.bin ├── pmmr_hash.bin └── pmmr_size.bin # 内核为变长元素时的大小索引仓库的测试数据目录 chain/tests/test_data/chain_compacted 与 chain/tests/test_data/chain_raw 正好提供了上述三种 MMR 文件布局的完整样例可作为理解目录结构的直观参考前者是压缩后的状态后者是未压缩的原始状态。状态同步与打包txhashset 快照与存储密切相关的还有状态同步机制在 P2P 快速同步state sync场景下节点需要把某个高度附近的三棵 MMR 状态整体打包传输。源码实现了这一能力打包zip_readchain/src/txhashset/txhashset.rs将txhashset目录按file_list白名单复制进临时目录并打成txhashset_snapshot_hash.zip快照文件保留最近 24 小时代码中按 24 小时清理旧 zip。解包zip_writechain/src/txhashset/txhashset.rs只接受file_list明确列出的文件白名单外的路径一律忽略从而保证状态包内容的严格可控。替换txhashset_replacechain/src/txhashset/txhashset.rs在解包后把新状态原子地替换旧状态目录。注意快照白名单中包含了针对特定 header 回卷rewound的output/pmmr_leaf.bin.hash与rangeproof/pmmr_leaf.bin.hash文件——这正对应文档所述的删除日志与 MMR 位置对齐以及LeafSet::copy_snapshot在 store/src/pmmr.rs 中的回卷恢复逻辑。小结Grin 的状态与存储设计可以概括为一句话用UTXO 集合 范围证明 内核 三棵 MMR承载全部可验证状态用最重链区块头中的 MMR 根锚定其唯一性用追加式文件 内存映射 删除日志 周期压缩实现高效、可剪枝的持久化。官方文档 doc/state.md以及 日文版、韩文版、简体中文版给出了这一设计的完整描述而 chain/src/txhashset/txhashset.rs、store/src/pmmr.rs、core/src/core/committed.rs 等源码则提供了每一处机制的精确实现证据。理解这套状态 验证 存储的三角结构是深入 Grin 节点实现、参与交易池与链同步开发的基础。赞分享区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载相关推荐Grin 的 Merkle 结构与 sum-MMR 设计面向剪枝的 Mimblewimble 状态承诺机制Grin 的 Merkle 结构与 sum MMR 设计面向剪枝的 Mimblewimble 状态承诺机制 Mimblewimble 协议的核心目标之一是用区块链Web3Grin 的 Merkle 结构与 Sum-MMR可修剪的 UTXO 状态承诺机制Grin 的 Merkle 结构与 Sum MMR可修剪的 UTXO 状态承诺机制 Grin 基于 Mimblewimble 协议设计其核心诉求是让验证者仅区块链Web3Grin 区块链数据修剪Pruning完全指南Mimblewimble 状态压缩原理与实现Grin 区块链数据修剪Pruning完全指南Mimblewimble 状态压缩原理与实现 本文围绕 GrinMimblewimble 协议的极简实现区块链Web3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考