在此博客文章中，我们将探讨归档器，它是 Solana 的分布式账本存储，用于 PB 级的区块链数据存储。我们在 2017 年了解到 Filecoin 提出的复制证明 (PoRep)。在 2018 年，我们使用 VDF 构建了适用于 Solana 的 PoRep 版本，并针对批量验证进行了优化。
满负荷运行时，Solana 网络每年将产生 1 gb/s * 365 天 = 4 PB 的数据。如果要求网络中的每个节点都存储所有这些数据，那么将只有可维持这种存储容量的少数节点拥有网络成员资格。利用我们的历史证明 (PoHistory)[1] 技术就可以缓解此问题，它允许以快速验证的方式实现复制证明并在全球数百万个归档器节点之间实现账本的比特洪流式分发。归档器不是基于共识的参与者，对硬件的要求非常低。
笼统而言，Solana 归档器网络的工作原理如下：归档器必须向网络发出信号，表明它们有 X 个字节的可用空间来存储数据。网络会按一定的频率，根据复制器标识的数量和可用的总存储空间，将账本历史分成若干部分，以达到一定的复制速率（当前，我们预期目标速率为 100 倍）和容错能力（通过纠删码实现）。完成 Archiver:data 分配后，每个归档器从共识验证者下载各自的数据。归档器需要以一定的频率证明它们正在存储数据，这时它们必须完成复制证明 (PoRep)。归档器将因此获得 3% 左右的通胀率作为奖励。
深入介绍复制证明
复制证明的基本思想是使用 CBC 加密，通过公共对称密钥来加密数据集，然后对加密的数据集进行哈希处理。Filecoin 复制证明技术报告[2]中对此方法进行了详细说明。但此方法有一个问题，就是它容易受到攻击。
例如，不诚实的存储节点可以流式传输加密数据，执行哈希处理后再删除数据。一个简单的解决方案是针对反加密操作强制执行哈希处理，或以随机顺序执行。这确保了在证明生成期间所有数据都存在，并且还要求验证者具有用于验证每个标识的每个证明的完整加密数据。验证所需的空间变为（CBC 密钥数）*（数据大小）。
我们对这种方法进行了改进，以比加密更快的速度随机抽样加密块，并将这些样本的哈希记录到 PoH 账本中。因此，对于每个 PoRep，块保持完全相同的顺序，且验证过程通过一个批次即可流式传输数据并验证所有证明。这样，我们可以同时验证多个证明，且每个证明都在其自己的 CUDA 核心上。
借助最新一代的显卡，Solana 网络可支持每个 GPU 卡最多 1500 个复制标识或对称密钥。验证所需的总空间为（2 个 CBC 块）*（CBC 密钥数），核心计数等于（CBC 密钥数）。CBC 块的大小预计为 1MB。
接下来，我们必须在验证者和归档器之间构建一个”游戏规则”，确保归档器正在生成证明，并且验证者确实在验证 PoRep。
为了开始生成账本的 PoRep，归档器客户端执行以下操作：
客户端定期执行 PoH 哈希签名
签名的作用是为选择账本的一个特定切片提供随机性
签名用于创建对称的 CBC 密钥，客户端使用该密钥对账本的切片进行编码。
由于每个客户端都使用相同的 PoH 哈希，因此签名在所有客户端之间随机分布。然后，客户端连续对加密的样本进行采样：
客户端定期执行 PoH 哈希签名
针对每 1MB 的切片采样 1 个字节，签名在此过程中提供随机性。
使用 SHA256 对样本进行哈希处理
所有客户端都必须使用相同的 PoH 哈希值作为签名。由于签名与 PoH 相关联，因此产生的样本哈希对于该时间点和特定的复制是唯一的。
验证者依次检查各客户端的证明：
验证者根据 GPU 核心数声明可以验证的 PoRep 数
验证者将定期执行 PoH 哈希签名
签名用于选择要验证的账本的一个切片，它也是用于选择要验证的样本（不超过验证者的容量）的掩码
验证者上传验证失败的证明
客户端可以通过捕获惰性验证者，对某个验证者提出质疑，要求其提供失败的证明。为了防止粉碎攻击，客户端必须连续使用相同的密钥对标识。为了防止垃圾邮件，协议中的所有消息均会产生交易手续费。归档器根据成功提交的证明数获得奖励。验证者通过验证证明而获得权益加权奖励，而钓鱼者在发布伪造证明的证据时获得验证者削减的货币作为奖励。
参考链接
[1]
历史证明 (PoHistory): https://solana.com/proof-of-history-a-clock-for-blockchain/
[2]
Filecoin 复制证明技术报告: https://filecoin.io/proof-of-replication.pdf