区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载本指南以 Grin 仓库 doc/pruning.md 为主线深入讲解 Mimblewimble 区块链各类型数据在链上的实际规模、剪枝的动机与场景以及完全剪枝状态下全节点如何仅凭最小数据集完成加密学层面的完整验证。读完本文你将掌握 Grin 各类链上数据的字节构成、剪枝后节点所需的最少数据清单以及验证逻辑在源码chain、core模块中的具体落点可直接用于理解 Grin 的存储模型与快速同步state sync / PIBD机制。一、Mimblewimble 的空间效率为什么剪枝是核心卖点Mimblewimble 协议最主要的吸引力之一是其理论上的空间效率。对于一个受信任或已完成预验证的完整区块链状态节点真正需要的仅仅是未花费的交易输出UTXO集合而这个集合理论上可以做到非常小。剪枝Pruning正是把这一理论优势落到工程实现的关键手段。Grin 的 READMEREADME.md中明确指出该项目追求Clean and minimal implementation简洁最小化实现并采用隐藏金额与可扩展性优势的 Mimblewimble 协议、Cuckoo Cycle 工作量证明、约一分钟的出块时间。在这种设计下剪枝不仅是节省磁盘的优化更是轻节点快速可用的基础能力。二、Grin 链上数据的构成与字节规模剪枝的前提是先弄清楚链上到底存了哪些数据、各自多大。Grin 区块链包含以下四类数据假定读者已具备 Mimblewimble 协议基础数据类型组成单条大小交易输出Output一个 Pedersen 承诺 一个范围证明Range Proof承诺 33 字节范围证明目前超过 5KB交易输入Input对某个输出的引用32 字节交易证明Kernel交易的超额承诺和excess commitment sum 用该超额生成的签名超额 33 字节签名平均 71 字节区块头Block HeaderMerkle 树与工作量证明等约 250 字节这些数据结构在源码中都有明确对应Outputcore/src/core/transaction.rs中的Output结构体由identifier内含OutputFeatures与Commitment和proof: RangeProof两部分组成注释明确指出range proof guarantees the commitment includes a positive value without overflow and the ownership of the private key范围证明保证承诺包含正值、不会溢出并证明私钥所有权。TxKernel同一文件中的TxKernel结构体包含featureskernel 特性、excess: Commitment交易所有承诺的余数若交易格式正确金额部分应归零超额即为有效公钥以及excess_sig证明超额是有效公钥的签名签署交易费用字段。InputInput结构体本质是被花费输出的引用并携带OutputFeatures以支持对 coinbase 输出的成熟度maturity检查。OutputFeaturesPlain 0普通输出与Coinbasecoinbase 输出等变体剪枝后验证新块时输出特性output features正是此处所定义。百万区块规模估算文档给出了一组假定条件下的近似规模区块链共一百万个区块、1000 万笔交易平均每笔 2 个输入、2.5 个输出、10 万个未花费输出。各口径下的数据量估算如下口径近似大小交易数据输入 输出总量约 128GB交易证明Kernel数据约 1GB区块头数据约 250MB全链总量未剪枝、未 cut-through约 130GB经过 cut-through 后含区块头约 1.8GBUTXO 集合大小约 520MB不含范围证明的全链总量约 4GB不含范围证明的 UTXO 集合约 3.3MB对照可见范围证明Range Proof占了 UTXO 集合体积的绝大部分。去掉了范围证明后UTXO 集合从 520MB 骤降到 3.3MB——这正是剪枝能带来数量级收益的根本原因。文档明确强调一旦链完成完整验证严格来说一个节点正常运转只需要 UTXO 承诺集合。需要说明以上为文档在特定假设百万区块、千万交易、十万 UTXO下的估算值实际网络规模与参数演进后数字会变化但其相对量级关系——范围证明占大头、UTXO 集合远小于全链——始终成立。三、什么场景下需要剪枝三种典型情况剪枝并非只有省磁盘一种目的文档归纳了三种典型上下文完全验证节点主动瘦身一个已对历史数据完成验证的全节点可以丢弃部分已验证数据来释放磁盘空间部分验证节点类似 SPV这类节点从一开始就不关心也不保留全部数据新节点加入网络时的临时轻量行为新节点可以先以部分验证节点的姿态快速进入可用状态之后再升级为完全验证节点。第三种场景正是 Grin 快速同步fast sync / state sync的实现基础新节点通过txhashset快照一次性获得最小必要状态而不是逐块重放全部历史。chain/src/txhashset/txhashset.rs中的TXHASHSET_ZIP: str txhashset_snapshot常量即对应同步时打包发送的 txhashset 压缩快照。四、完全剪枝状态的验证加密学层面的五条核心要求剪枝必须尽可能多地移除数据同时保留 Mimblewimble 式完整验证的全部保证。这既是为了让剪枝节点状态保持健全sane也是首次快速同步时只向新节点发送最小数据的前提。要完整验证链状态必须满足以下五条要求所有 kernel 签名都能针对其公钥验证通过即每个TxKernel.excess_sig都由对应的excess公钥正确签署所有 UTXO 承诺之和减去总供应量supply后是一个有效公钥即可以用它对空字符串签名所有 kernel 公钥之和等于所有 UTXO 承诺之和减去总供应量UTXO PMMR、范围证明 PMMR 与 kernel MMR 的根哈希必须匹配一条具有有效工作量证明PoW链的区块头所有范围证明均有效。源码中的验证落点这套验证逻辑在chain/src/txhashset/txhashset.rs的TxHashSet::validate()中逐项实现chain/src/txhashset/txhashset.rsvalidate_mmrs()对 output、rangeproof、kernel 三个 PMMR 逐一调用validate()校验树内全部哈希与内部和值validate_roots(header)将三个 PMMR 的根roots()返回TxHashSetRoots含output_roots、rproof_root、kernel_root与最新区块头核对validate_sizes(header)核对 header 中记录的output_mmr_size、kernel_mmr_size与实际 MMR 大小一致validate_kernel_sums()验证kernel 超额之和 未花费输出之和 − 总供应量内部调用Committed::verify_kernel_sums()非快速验证fast_validation false时还会执行verify_rangeproofs()逐个验证未花费输出的范围证明与verify_kernel_signatures()批量验证全部 kernel 签名。其中第 2、3 条承诺求和的核心逻辑定义在 core/src/core/committed.rs 的verify_kernel_sums()先对输入/输出/超额费用承诺求和得到utxo_sum再对 kernel 超额计入kernel_offset求和得到kernel_sum_plus_offset两者必须相等否则返回Error::KernelSumMismatch。文档中的UTXO 承诺之和减去供应量等于 kernel 公钥之和即该等式在链级尺度上的体现——供应量对应链级total_overagekernel offset 则由区块头累积。core/src/core/block_sums.rs中的BlockSums记录每块utxo_sum与kernel_sum的滚动总量则提供了一条快速完整验证路径不必遍历全部 UTXO 与 kernel只需将新块应用apply到上一块的BlockSums上即可验证全量 kernel 和值这正是 chain/src/txhashset/txhashset.rs 注释中significantly faster way of validating full kernel sums所指的实现。批量验证的性能细节kernel 签名verify_kernel_signatures()以KERNEL_BATCH_SIZE 5_000为批次调用TxKernel::batch_sig_verify()批量验证chain/src/txhashset/txhashset.rs范围证明verify_rangeproofs()默认每批1_000个调用Output::batch_verify_proofs()批量验证且强制要求输出与对应范围证明必须同时存在任一缺失即返回Error::OutputNotFound或Error::RangeproofNotFoundchain/src/txhashset/txhashset.rs。五、接受新块所需的额外数据为什么需要输出特性仅验证链状态与能够接受并验证新块是两回事。要持续接收新块还需要一项额外数据输出的特性Output Features这使得全部 UTXO 的完整输出数据成为必需。原因在于新块中的输入是对旧输出的引用节点需要根据被花费输出的OutputFeatures判断其是否为 coinbase 输出并执行成熟度maturity检查coinbase 输出有锁定高度。若剪枝时只保留 33 字节承诺而不保留特性标记就无法正确验证输入是否满足花费条件。源码中Input携带features: OutputFeatures正是为此设计见 core/src/core/transaction.rs其注释明确写道We will check maturity for coinbase output。六、剪枝节点所需的最少数据清单综合上述要求一个既能完整验证链状态、又能继续接受新块的剪枝节点至少需要以下数据完整区块头链header chain全部 kernel且按链上包含顺序排列——这也允许重建 kernel MMR全部未花费输出UTXOUTXO MMR 与范围证明 MMR用于获知被剪枝数据的哈希。其中第 1 项保证 PoW 链的延续性与各 MMR 根的锚定第 2、3 项支撑 kernel 求和与 UTXO 求和验证第 4 项则保证被剪掉的叶子leaf仍能通过其哈希参与 Merkle 根验证。剪枝在 MMR 层的实现机制MMRMerkle Mountain Range结构天然支持保留内部节点哈希、删除叶子数据的剪枝core/src/core/pmmr/pmmr.rs的PMMR::prune(pos0)仅允许对叶子位置执行删除删除前先确认该叶子哈希存在已删则返回false随后调用后端remove(pos0)移除叶子core/src/core/pmmr/pmmr.rsPMMR::validate()遍历所有父节点用get_from_file()从原始文件中读取左右子哈希即使子节点已被移除重新计算父哈希并比对从而在剪枝后依然能校验整棵树的完整性core/src/core/pmmr/pmmr.rs后端抽象core/src/core/pmmr/backend.rs的Backendtrait 提供get_from_file忽略移除日志按原始插入位置取哈希、leaf_pos_iter遍历当前未剪枝、未移除的叶子位置、n_unpruned_leaves未剪枝叶子数、remove等原语同时支持append_pruned_subtree——PIBD分段同步时可将已剪枝的子树整体追加进本地 MMR而无须底层叶子节点core/src/core/pmmr/backend.rs。剪枝时机的工程化阈值同样有据可查core/src/consensus.rs中CUT_THROUGH_HORIZON WEEK_HEIGHT一周的区块高度用于界定 cut-through 回溯深度而MAX_BLOCK_WEIGHT 40_000输入权重 1、输出权重 21、kernel 权重 3决定了块内输入/输出/kernel 的数量上限进而约束了可剪枝数据的构成比例core/src/consensus.rs。七、进一步剪枝的可能性随机抽样验证范围证明文档指出还可以进一步压缩只要求验证节点随机选取一部分范围证明进行验证而非全部。其安全直觉是范围证明的核心作用是防止凭空造币承诺隐藏了负数或溢出金额而一旦发生这类伪造影响的是整条链的金额守恒若验证节点以随机子集抽验攻击者无法预知哪些范围证明会被检查伪造被发现的概率随抽验比例提升。这一思路与完全验证 概率抽查的轻量验证哲学一致但它属于可选的工程权衡——文档仅作为进一步剪枝的可行性方向提出并未给出既定参数。八、仓库中的相关实现路径速查关注点路径剪枝概念主文档本文源头doc/pruning.md中文译本doc/translations/pruning_ZH-CN.mdOutput / TxKernel / Input / OutputFeatures 结构定义core/src/core/transaction.rs、core/src/core/transaction.rskernel 求和验证Committed traitcore/src/core/committed.rs每块滚动求和快速验证core/src/core/block_sums.rstxhashset 完整验证流程validate / roots / sizes / rangeproofs / kernel 签名chain/src/txhashset/txhashset.rsMMR 剪枝与完整性校验core/src/core/pmmr/pmmr.rsMMR 存储后端抽象core/src/core/pmmr/backend.rs区块权重与剪枝水平线常量core/src/consensus.rs剪枝相关测试chain/tests/test_txhashset.rs、chain/tests/test_txhashset_archive.rs结语Grin 的剪枝设计回答了 Mimblewimble 从理论空间效率到工程现实的关键一跳通过 MMR 的可剪枝结构与保留哈希、删除叶子的存储抽象节点可以在只保留区块头链、全量 kernel、UTXO 集合以及两个 MMR 根的前提下完成等价的完整加密学验证——其中范围证明是体积大头也是可进一步以随机抽样方式压缩的唯一环节。理解这套数据构成与验证矩阵是深入 Grin 存储层、同步机制与剪枝节点运维的起点。赞分享区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载相关推荐Grin 节点区块链数据修剪Pruning原理与实现深度解析从存储格式、状态验证到链压缩Grin 节点区块链数据修剪Pruning原理与实现深度解析从存储格式、状态验证到链压缩 Grin 是 Mimblewimble 协议的最小实现其核心卖区块链Web3Grin 区块链数据修剪Pruning完全指南Mimblewimble 状态压缩原理与实现Grin 区块链数据修剪Pruning完全指南Mimblewimble 状态压缩原理与实现 本文围绕 GrinMimblewimble 协议的极简实现区块链Web3Grin 链状态与存储机制解析UTXO 集合、三棵 MMR 树与 Pruning 压缩原理Grin 链状态与存储机制解析UTXO 集合、三棵 MMR 树与 Pruning 压缩原理 本文以 Grin 仓库中的官方文档 State and Stora区块链Web3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/13 12:28:52 · 阅读 1.2k Grin 区块链数据剪枝（Pruning）深度指南：从 UTXO 集压缩到全节点状态验证
区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载本指南以 Grin 仓库 doc/pruning.md 为主线深入讲解 Mimblewimble 区块链各类型数据在链上的实际规模、剪枝的动机与场景以及完全剪枝状态下全节点如何仅凭最小数据集完成加密学层面的完整验证。读完本文你将掌握 Grin 各类链上数据的字节构成、剪枝后节点所需的最少数据清单以及验证逻辑在源码chain、core模块中的具体落点可直接用于理解 Grin 的存储模型与快速同步state sync / PIBD机制。一、Mimblewimble 的空间效率为什么剪枝是核心卖点Mimblewimble 协议最主要的吸引力之一是其理论上的空间效率。对于一个受信任或已完成预验证的完整区块链状态节点真正需要的仅仅是未花费的交易输出UTXO集合而这个集合理论上可以做到非常小。剪枝Pruning正是把这一理论优势落到工程实现的关键手段。Grin 的 READMEREADME.md中明确指出该项目追求Clean and minimal implementation简洁最小化实现并采用隐藏金额与可扩展性优势的 Mimblewimble 协议、Cuckoo Cycle 工作量证明、约一分钟的出块时间。在这种设计下剪枝不仅是节省磁盘的优化更是轻节点快速可用的基础能力。二、Grin 链上数据的构成与字节规模剪枝的前提是先弄清楚链上到底存了哪些数据、各自多大。Grin 区块链包含以下四类数据假定读者已具备 Mimblewimble 协议基础数据类型组成单条大小交易输出Output一个 Pedersen 承诺 一个范围证明Range Proof承诺 33 字节范围证明目前超过 5KB交易输入Input对某个输出的引用32 字节交易证明Kernel交易的超额承诺和excess commitment sum 用该超额生成的签名超额 33 字节签名平均 71 字节区块头Block HeaderMerkle 树与工作量证明等约 250 字节这些数据结构在源码中都有明确对应Outputcore/src/core/transaction.rs中的Output结构体由identifier内含OutputFeatures与Commitment和proof: RangeProof两部分组成注释明确指出range proof guarantees the commitment includes a positive value without overflow and the ownership of the private key范围证明保证承诺包含正值、不会溢出并证明私钥所有权。TxKernel同一文件中的TxKernel结构体包含featureskernel 特性、excess: Commitment交易所有承诺的余数若交易格式正确金额部分应归零超额即为有效公钥以及excess_sig证明超额是有效公钥的签名签署交易费用字段。InputInput结构体本质是被花费输出的引用并携带OutputFeatures以支持对 coinbase 输出的成熟度maturity检查。OutputFeaturesPlain 0普通输出与Coinbasecoinbase 输出等变体剪枝后验证新块时输出特性output features正是此处所定义。百万区块规模估算文档给出了一组假定条件下的近似规模区块链共一百万个区块、1000 万笔交易平均每笔 2 个输入、2.5 个输出、10 万个未花费输出。各口径下的数据量估算如下口径近似大小交易数据输入 输出总量约 128GB交易证明Kernel数据约 1GB区块头数据约 250MB全链总量未剪枝、未 cut-through约 130GB经过 cut-through 后含区块头约 1.8GBUTXO 集合大小约 520MB不含范围证明的全链总量约 4GB不含范围证明的 UTXO 集合约 3.3MB对照可见范围证明Range Proof占了 UTXO 集合体积的绝大部分。去掉了范围证明后UTXO 集合从 520MB 骤降到 3.3MB——这正是剪枝能带来数量级收益的根本原因。文档明确强调一旦链完成完整验证严格来说一个节点正常运转只需要 UTXO 承诺集合。需要说明以上为文档在特定假设百万区块、千万交易、十万 UTXO下的估算值实际网络规模与参数演进后数字会变化但其相对量级关系——范围证明占大头、UTXO 集合远小于全链——始终成立。三、什么场景下需要剪枝三种典型情况剪枝并非只有省磁盘一种目的文档归纳了三种典型上下文完全验证节点主动瘦身一个已对历史数据完成验证的全节点可以丢弃部分已验证数据来释放磁盘空间部分验证节点类似 SPV这类节点从一开始就不关心也不保留全部数据新节点加入网络时的临时轻量行为新节点可以先以部分验证节点的姿态快速进入可用状态之后再升级为完全验证节点。第三种场景正是 Grin 快速同步fast sync / state sync的实现基础新节点通过txhashset快照一次性获得最小必要状态而不是逐块重放全部历史。chain/src/txhashset/txhashset.rs中的TXHASHSET_ZIP: str txhashset_snapshot常量即对应同步时打包发送的 txhashset 压缩快照。四、完全剪枝状态的验证加密学层面的五条核心要求剪枝必须尽可能多地移除数据同时保留 Mimblewimble 式完整验证的全部保证。这既是为了让剪枝节点状态保持健全sane也是首次快速同步时只向新节点发送最小数据的前提。要完整验证链状态必须满足以下五条要求所有 kernel 签名都能针对其公钥验证通过即每个TxKernel.excess_sig都由对应的excess公钥正确签署所有 UTXO 承诺之和减去总供应量supply后是一个有效公钥即可以用它对空字符串签名所有 kernel 公钥之和等于所有 UTXO 承诺之和减去总供应量UTXO PMMR、范围证明 PMMR 与 kernel MMR 的根哈希必须匹配一条具有有效工作量证明PoW链的区块头所有范围证明均有效。源码中的验证落点这套验证逻辑在chain/src/txhashset/txhashset.rs的TxHashSet::validate()中逐项实现chain/src/txhashset/txhashset.rsvalidate_mmrs()对 output、rangeproof、kernel 三个 PMMR 逐一调用validate()校验树内全部哈希与内部和值validate_roots(header)将三个 PMMR 的根roots()返回TxHashSetRoots含output_roots、rproof_root、kernel_root与最新区块头核对validate_sizes(header)核对 header 中记录的output_mmr_size、kernel_mmr_size与实际 MMR 大小一致validate_kernel_sums()验证kernel 超额之和 未花费输出之和 − 总供应量内部调用Committed::verify_kernel_sums()非快速验证fast_validation false时还会执行verify_rangeproofs()逐个验证未花费输出的范围证明与verify_kernel_signatures()批量验证全部 kernel 签名。其中第 2、3 条承诺求和的核心逻辑定义在 core/src/core/committed.rs 的verify_kernel_sums()先对输入/输出/超额费用承诺求和得到utxo_sum再对 kernel 超额计入kernel_offset求和得到kernel_sum_plus_offset两者必须相等否则返回Error::KernelSumMismatch。文档中的UTXO 承诺之和减去供应量等于 kernel 公钥之和即该等式在链级尺度上的体现——供应量对应链级total_overagekernel offset 则由区块头累积。core/src/core/block_sums.rs中的BlockSums记录每块utxo_sum与kernel_sum的滚动总量则提供了一条快速完整验证路径不必遍历全部 UTXO 与 kernel只需将新块应用apply到上一块的BlockSums上即可验证全量 kernel 和值这正是 chain/src/txhashset/txhashset.rs 注释中significantly faster way of validating full kernel sums所指的实现。批量验证的性能细节kernel 签名verify_kernel_signatures()以KERNEL_BATCH_SIZE 5_000为批次调用TxKernel::batch_sig_verify()批量验证chain/src/txhashset/txhashset.rs范围证明verify_rangeproofs()默认每批1_000个调用Output::batch_verify_proofs()批量验证且强制要求输出与对应范围证明必须同时存在任一缺失即返回Error::OutputNotFound或Error::RangeproofNotFoundchain/src/txhashset/txhashset.rs。五、接受新块所需的额外数据为什么需要输出特性仅验证链状态与能够接受并验证新块是两回事。要持续接收新块还需要一项额外数据输出的特性Output Features这使得全部 UTXO 的完整输出数据成为必需。原因在于新块中的输入是对旧输出的引用节点需要根据被花费输出的OutputFeatures判断其是否为 coinbase 输出并执行成熟度maturity检查coinbase 输出有锁定高度。若剪枝时只保留 33 字节承诺而不保留特性标记就无法正确验证输入是否满足花费条件。源码中Input携带features: OutputFeatures正是为此设计见 core/src/core/transaction.rs其注释明确写道We will check maturity for coinbase output。六、剪枝节点所需的最少数据清单综合上述要求一个既能完整验证链状态、又能继续接受新块的剪枝节点至少需要以下数据完整区块头链header chain全部 kernel且按链上包含顺序排列——这也允许重建 kernel MMR全部未花费输出UTXOUTXO MMR 与范围证明 MMR用于获知被剪枝数据的哈希。其中第 1 项保证 PoW 链的延续性与各 MMR 根的锚定第 2、3 项支撑 kernel 求和与 UTXO 求和验证第 4 项则保证被剪掉的叶子leaf仍能通过其哈希参与 Merkle 根验证。剪枝在 MMR 层的实现机制MMRMerkle Mountain Range结构天然支持保留内部节点哈希、删除叶子数据的剪枝core/src/core/pmmr/pmmr.rs的PMMR::prune(pos0)仅允许对叶子位置执行删除删除前先确认该叶子哈希存在已删则返回false随后调用后端remove(pos0)移除叶子core/src/core/pmmr/pmmr.rsPMMR::validate()遍历所有父节点用get_from_file()从原始文件中读取左右子哈希即使子节点已被移除重新计算父哈希并比对从而在剪枝后依然能校验整棵树的完整性core/src/core/pmmr/pmmr.rs后端抽象core/src/core/pmmr/backend.rs的Backendtrait 提供get_from_file忽略移除日志按原始插入位置取哈希、leaf_pos_iter遍历当前未剪枝、未移除的叶子位置、n_unpruned_leaves未剪枝叶子数、remove等原语同时支持append_pruned_subtree——PIBD分段同步时可将已剪枝的子树整体追加进本地 MMR而无须底层叶子节点core/src/core/pmmr/backend.rs。剪枝时机的工程化阈值同样有据可查core/src/consensus.rs中CUT_THROUGH_HORIZON WEEK_HEIGHT一周的区块高度用于界定 cut-through 回溯深度而MAX_BLOCK_WEIGHT 40_000输入权重 1、输出权重 21、kernel 权重 3决定了块内输入/输出/kernel 的数量上限进而约束了可剪枝数据的构成比例core/src/consensus.rs。七、进一步剪枝的可能性随机抽样验证范围证明文档指出还可以进一步压缩只要求验证节点随机选取一部分范围证明进行验证而非全部。其安全直觉是范围证明的核心作用是防止凭空造币承诺隐藏了负数或溢出金额而一旦发生这类伪造影响的是整条链的金额守恒若验证节点以随机子集抽验攻击者无法预知哪些范围证明会被检查伪造被发现的概率随抽验比例提升。这一思路与完全验证 概率抽查的轻量验证哲学一致但它属于可选的工程权衡——文档仅作为进一步剪枝的可行性方向提出并未给出既定参数。八、仓库中的相关实现路径速查关注点路径剪枝概念主文档本文源头doc/pruning.md中文译本doc/translations/pruning_ZH-CN.mdOutput / TxKernel / Input / OutputFeatures 结构定义core/src/core/transaction.rs、core/src/core/transaction.rskernel 求和验证Committed traitcore/src/core/committed.rs每块滚动求和快速验证core/src/core/block_sums.rstxhashset 完整验证流程validate / roots / sizes / rangeproofs / kernel 签名chain/src/txhashset/txhashset.rsMMR 剪枝与完整性校验core/src/core/pmmr/pmmr.rsMMR 存储后端抽象core/src/core/pmmr/backend.rs区块权重与剪枝水平线常量core/src/consensus.rs剪枝相关测试chain/tests/test_txhashset.rs、chain/tests/test_txhashset_archive.rs结语Grin 的剪枝设计回答了 Mimblewimble 从理论空间效率到工程现实的关键一跳通过 MMR 的可剪枝结构与保留哈希、删除叶子的存储抽象节点可以在只保留区块头链、全量 kernel、UTXO 集合以及两个 MMR 根的前提下完成等价的完整加密学验证——其中范围证明是体积大头也是可进一步以随机抽样方式压缩的唯一环节。理解这套数据构成与验证矩阵是深入 Grin 存储层、同步机制与剪枝节点运维的起点。赞分享区块链Web3【免费下载链接】grinMinimal implementation of the Mimblewimble protocol.项目地址https://gitcode.com/gh_mirrors/gr/grin点击查看免费下载相关推荐Grin 节点区块链数据修剪Pruning原理与实现深度解析从存储格式、状态验证到链压缩Grin 节点区块链数据修剪Pruning原理与实现深度解析从存储格式、状态验证到链压缩 Grin 是 Mimblewimble 协议的最小实现其核心卖区块链Web3Grin 区块链数据修剪Pruning完全指南Mimblewimble 状态压缩原理与实现Grin 区块链数据修剪Pruning完全指南Mimblewimble 状态压缩原理与实现 本文围绕 GrinMimblewimble 协议的极简实现区块链Web3Grin 链状态与存储机制解析UTXO 集合、三棵 MMR 树与 Pruning 压缩原理Grin 链状态与存储机制解析UTXO 集合、三棵 MMR 树与 Pruning 压缩原理 本文以 Grin 仓库中的官方文档 State and Stora区块链Web3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考