惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Proofpoint News Feed
V
V2EX
WordPress大学
WordPress大学
Google DeepMind News
Google DeepMind News
Martin Fowler
Martin Fowler
小众软件
小众软件
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
The Cloudflare Blog
T
Tailwind CSS Blog
H
Help Net Security
腾讯CDC
爱范儿
爱范儿
人人都是产品经理
人人都是产品经理
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
Microsoft Security Blog
Microsoft Security Blog
Stack Overflow Blog
Stack Overflow Blog
D
DataBreaches.Net
C
Check Point Blog
量子位
酷 壳 – CoolShell
酷 壳 – CoolShell
美团技术团队
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com

smallyu的博客

为什么买的加密货币一定要去中心化 RISC-V 虚拟机无法代替 EVM 虚拟机 Polkadot 的 Existential Deposit 机制错在哪里 利息,套利,交易策略,金融市场 LayerZero 从来不挑战比特币的地位 默认参数引起的以太坊节点运行错误 硬件钱包与资产安全 预测市场比币圈更赌场 为什么去中心化的跨链桥不可能实现 我对于 AI 时代的答案 不要投资任何隐私币 区块链技术世界的三大真理 以太坊 AA 钱包的致命问题是什么 基于 AI 语义执行的 MCP 区块链的设计 一个集成 Geth 和 CometBFT 的兼容层 我的加密货币定投策略(二) DeFi 基础: 理解 AMM 定价机制 Go 语言 GMP 调度器的原理是什么 Web3 项目分析计划 对 Psyche Network 项目的分析 continuation 教程: 理解 CPS 如何开发一个比特币符文(Runes)协议 比特币脚本开发教程 我从王垠的计算机科学视频班学到了什么 区块链技术面试题(2025年版) Rust 语言容易让新手困惑的一个“过度优化” Solana 智能合约开发教程 (1) 尝试开发一个最小 EVM 虚拟机 基于 ZK 的链上身份系统设计 一个 Web3 打赏系统的设计
PDP 文件证明的局限性
2023-05-17 · via smallyu的博客

2023-05-17

存储证明

对于一个文件来说,PDP 最基础的用法,就是根据文件内容生成对应的 TAG,然后把文件发送到另一个环境里。接着用保存下来的 TAG 验证对方是否真的储存了文件。如果对方没有储存文件,是不可能通过第一次验证的。在接下来的验证中。因为挑战是随机生成的,会选择文件不同位置的片段,能在概率上提高验证的可靠性。

所以这样的用法,至少能够证明文件储存在对方环境中过。但是这样的证明方式存在疏漏,就是文件不需要完整,或者说缺少对文件完整性的证明。如果文件非常大,而挑战的数量一般是固定的,文件越大,挑战越不全面。虽然挑战的文件片段是随机的,仍然存在可能性,对方不需要完整的文件,而只需要文件的一部分,2/3、1/2、1/3,就足以完成挑战了。

文件完整性证明

要让 PDP 能够证明文件的完整性,可以把 PDP 证明和 Merkle 树的数据结构结合起来。PDP 证明一般需要把文件拆分成数据片段,根据数据片段生成 TAG,并不强调数据片段的序列化方式。

和 Merkle 树结合的地方,就是在把文件拆分为数据片段之后,把数据片段序列化到 Merkle 树中。由于 Merkle 树的特性,父节点的值需要依赖子节点的值才能够推算出来,如果验证了父节点是正确的,就足以说明子节点是全部存在的,也就间接证明了文件的完整性。

在实际的使用中,往往抽取 Merkle 树的一些节点,对 Merkle 节点的路径进行验证。也是验证 Merkle 树完整性的一般方法。在使用了 Merkle 树作为文件的数据结构,并且在验证 PDP 证明的同时验证 Merkle 树的完整性,就能确保文件是完整存在了。

Merkle 树的验证覆盖率也不可能 100%,但通常认为,伪造 Merkle 树节点的成本比真正保留了完整数据的成本还要高。

文件大小证明

PDP 证明本身不包含文件的元信息,它只能证明文件是存在的、文件是完整的,至于是什么样的文件,文件名是什么、文件类型是什么、文件有多大,一概不知。PDP 的证明信息里不包含文件的元信息,而元信息中比较有用的是文件的大小信息。PDP 不是区块链时代的技术,也就没怎么关心这个问题。

有的区块链用磁盘空间的大小来描述节点的算力,或者根据文件大小来让使用者付费,或者根据储存的文件大小来给予存储节点奖励,这些都意味着文件大小的信息至关重要。

那么,对于文件的元信息缺失的问题,一种做法是在 PDP 证明系统之外,将元信息与文件数据关联起来。另一种做法是,对文件进行修改,将元信息附加到文件数据里,只要证明文件数据的完整,就能够确认文件元信息的准确。

然而,无论哪种方式,都不能保证文件元信息的可靠。在区块链的场景下,信任模型发生了一些变化,和 PDP 要解决的问题存在差异。以前的 PDP 是让用户相信存储节点,而现在,是让区块链来相信存储节点。

第一种方式需要额外的机制保证元信息和文件数据之间的映射关系,这会带来很大的开销。第二种方式在实现上是简便的,问题在于将元信息附加到文件数据的步骤,由谁来完成?是可信的吗?如果恶意附加了错误的信息呢?另外,怎么读取这些元信息?要把文件数据或者一部分文件数据下载下来?下载的信息还不能保证是正确的?

总之,在加密学的范畴里,PDP 并不能解决对文件大小的证明。

文件持续性证明

PDP 证明需要不断地发起挑战请求,对方能够完成挑战则说明文件安好。比如现在发起一次挑战,一个小时之后又发起一次挑战,至少能够说明对方在完成挑战的时刻,文件是完整存在的。那在没有进行挑战的时间呢?没有限制。

如果在第一次完成挑战后,就把文件转移到了另外一个地方,等第二次挑战的时候,再把文件拿过来完成挑战,这完全是可以的。PDP 并不也没有能力阻止这样的情况。PDP 无法对文件的持续性提供证明。

这样的能力限制会对区块链造成什么样的影响呢,首先能想到的就是算力换空间。因为在有些区块链的规则里,文件越大,矿工的收益越高。矿工完全可以利用 PDP 的证明间隔,把空间腾给其他文件用,用磁盘的 IO 换取磁盘空间大小。

再就是证明成本的提高。挑战越频繁,文件越安全,这对寻求证明的一方是一种压力。

文件多副本证明

PDP 自然也不具备证明文件有多个副本的能力。如果需要对方存 2 个副本,而对方实际上只存了 1 份,对于 PDP 是没有任何感知的,这很容易理解。

如果想分散文件损失的风险,把文件存到了不同地方,在使用 PDP 作为验证手段的情况下,是无法达到目的的。