Stellar与Solana鳄梨的州档案可扩展性

Solana的State Compression设计（鳄梨）存在根本性的设计缺陷：

RPC节点应存储所有压缩的帐户和帐户数据。没有协议保证压缩帐户数据的可用性，因此压缩数据可能会丢失或被审查。一些验证器仍然需要存储所有压缩的帐户。交易量将增加，验证器套利垃圾邮件将加剧Solana的拥堵问题。

Stellar网络上的State Archive更高效、更可扩展：

交易量或垃圾邮件没有增加。通过公共历史档案的验证器快照保证了存档数据的可用性。没有验证器需要存储所有存档的帐户。RPC节点可以分片归档状态，降低成本。

一定要加入@gttyson（恒星发展基金会）和@aeyakovenko（Solana的联合创始人）即将到来的推特空间，以获得对国家膨胀解决方案的看法

‎

国家膨胀问题是区块链房间里最大的大象。每天，在Stellar和Solana等公共区块链上创建数百万个新条目，每个验证器都需要无限期地存储所有这些状态。无论信息实际使用的频率有多高，甚至是否被使用，每个NFT模因、hello world测试合约和垃圾邮件令牌都需要永远保存。随着越来越多的用户和用例来到区块链，这个问题只会越来越严重，导致网络在试图跟上所有这些膨胀时变得更慢、更昂贵。

这不是一个新问题。Vitalik于2021年开始与以太坊的“State Expirey”计划进行对话，两年前恒星开发基金会开始为恒星网络设计“State Archive”解决方案。Solana的联合创始人Anatoly Yakovenko是最新加入该党的人，几周前介绍了Solana的“鳄梨”项目。虽然关于如何解决国家膨胀有很多想法，但Vitalik和Anatoly的设计都有重大的根本缺陷。例如，我发现以太坊的状态过期提案存在一个双重支出漏洞，其修复与以太坊路线图中的其他计划（如弱无状态和强无状态）根本不兼容。当我专注于安全性时，我将在第3部分中更多地谈论以太坊，但现在，让我们谈谈Solana和可扩展性问题。

在较高的层次上，Solana的“索引压缩”和“状态档案”在恒星上的工作方式相似。每个账户都为在分类账上保持活跃而支付租金。每当租金用完时，账户就会被存档（Stellar）或压缩（Solana），任何涉及存档账户的交易都会失败。已存档的帐户将从验证器中删除，并存储在Merkle树的链下。为了取消存档和重用这些帐户，RPC节点生成Merkle风格的证明，验证器验证该证明，并将条目添加回实时分类账状态。

虽然高层战略相似，但魔鬼在细节中。我将解释Avocado如何引入比解决更多的问题，包括数据可用性差、网络性能下降和费用增加。我还将讨论如何通过Stellar上的State Archive解决所有这些问题。

Solana协议不保证数据可用性

Avocado的“状态压缩”对压缩的帐户数据没有数据可用性保证。当账户数据用完时，它会被替换为哈希值，该哈希值由验证器持久化，而数据本身会被删除。为了恢复（或解压缩）这些数据，事务会上传原始数据，验证器会根据持久哈希进行检查。

问题是，Solana协议只保留并维护哈希的可用性，而不是数据本身。哈希值不能反转以获得原始数据，因此虽然协议可以验证数据是否正确，但它实际上无法存储或生成数据。相反，提交交易的用户有责任提供原始数据。问题是，用户如何才能真正找到这些数据？

该提案没有讨论数据可用性。与Avocado的“索引压缩”部分不同，帐户数据不存储在Merkle树中，而且似乎没有任何机制在协议级别维护数据。我认为这一责任将留给RPC节点（Solana上的一种常见设计）。问题是，Solana RPC节点目前的运行成本已经很高（因为512 GB的RAM很昂贵），这将给他们带来更多负担。很容易想象，这样的成本最终会转嫁给用户，使解压缩变得昂贵。

但比价格更令人担忧的是，没有保证或要求RPC节点忠实地存储这些信息。一旦删除，就不需要帐户数据有效负载来达成共识，因此“复制证明”等方法将不起作用。Solana网络无法保证RPC节点确实保存了删除的数据。RPC提供者可以选择忽略压缩数据，因为它的存储成本太高，或者可能会选择只存储有足够价值的压缩数据来盈利。想想看：如果协议没有强制RPC存储所有数据，并且存储数据的成本越来越高，RPC提供商可能会寻求削减成本来盈利。如果RPC提供商面临存储您认为会丢失的NFT或鲸鱼的USDC余额的选择，人们可以开始猜测哪些数据将被优先处理。

如果你想在数据存档后取回数据，可以在Stellar上构建。虽然Stellar上的链下RPC节点缓存了存档状态，但所有数据都得到了协议级保证的支持。验证器通常会发布“归档快照”，其中不仅包含数据的哈希值，还包含数据本身。每个一级验证器都会维护这些快照，并通过恒星网络历史档案公开免费提供。谁在存储这些档案？不仅是区块链领域最值得信赖的一些公司，还有传统金融公司，包括财富500强公司富兰克林邓普顿。

在Solana上，完整验证器不作为协议的一部分提供存档快照，存档的帐户状态也不存储在Merkle树中，允许RPC节点选择要存储的存档状态。Stellar网络通过将存档的帐户状态存储在Merkle树中，保证您的数据始终被复制并随时可用，即使它已经存档，该Merkle树需要定期完整地发布到历史档案馆。这些历史档案是可审计的、可验证的，并且可以免费向公众开放，以分散的方式保证存档数据的可用性。

TPS↓网络拥塞↑

Solana在历史上曾有过高交易下降率的时期，例如在2024年4月，机器人交易活动造成了太多的拥堵，Solana的网络层无法跟上交易量。虽然Solana能够在补丁中改善这种情况，但就性能而言，区块链基本上是网络受限的，随着用户、验证器和TPS数量的增加，网络拥塞将继续成为一个问题。有了鳄梨，拥堵只会变得更糟。

如今，用户（和机器人）必须烧钱才能提交交易。这些费用有助于防止网络拥塞，因为没有这些费用，攻击者和机器人交易者可能会用垃圾邮件淹没网络。费用起到了威慑作用，使此类攻击在财务上过于昂贵，不切实际。

然而，即使对交易收取费用，索拉纳也存在严重的拥堵问题，鳄梨也会火上浇油。根据这一提议，验证器将获得报酬以发送更多交易。让我再说一遍。Solana是一个已经存在交易导致严重拥堵问题的网络，它提议为发送新类别交易的验证器支付费用，从而激励已经不堪重负的网络上进行更多交易。

当帐户用完租金时，它不会像帐户状态那样自动删除。相反，“压缩事务”使用零知识证明删除帐户并将其添加到Merkle二进制trie中。该trie包含所有压缩的帐户，但验证器只需要存储trie的根（种类）。为了使用压缩帐户，用户必须提交一笔交易，并附上从完整trie生成的条目证明。

虽然“技术上”验证器只需要存储trie的根来参与共识，但RPC节点需要存储完整的trie来生成证明。此外，验证器可以通过存储完整的trie并提交压缩事务来赚取额外的钱，网络依赖于这些验证器来确保压缩正常工作。

这似乎是一个糟糕的设计权衡。Solana已经存在一个问题，即当交易需要花钱时，交易太多，通过这一变化，验证器将因发送额外的非用户交易而获得补偿。你可能会认为这没那么糟糕。毕竟，这只是一笔压缩多个账户的交易。交易量不会比其他情况多，但你可以节省这么多存储空间！

问题是，Solana正在协议级别直接将套利垃圾邮件设计到他们的网络中。由于验证器通过发送这些交易赚钱，因此当首次启用此“功能”时，验证器可能不会花太长时间压缩所有预先存在的过期帐户。一旦所有旧帐户都被压缩，验证器将不断搜索新的过期帐户。每当新帐户到期时，所有验证器都会争先恐后地压缩它以获得奖励。这意味着，每当一个账户的租金用完时，每个验证器都会提交一笔交易，试图成为第一个赢得压缩奖励的人，从而导致大量冗余交易，所有这些交易都试图压缩同一个账户。这些冗余事务将占用有限的网络带宽，否则这些带宽本可以用于用户事务，从而降低整体TPS。

使用Stellar上的State archive解决方案，所有验证器都可以按照给定的时间表确定地归档相同的条目，因此不需要发送额外的交易。这一点非常重要，因为网络是区块链性能的主要瓶颈。Anatoly考虑了确定性压缩，但决定反对：

“如果所有验证器都必须确定地执行此操作，那么它们都必须维护二进制trie中当前的内容，这意味着整个状态都必须是快照的一部分。”

虽然这可能适用于Solana的Merkle二进制trie，但Stellar网络结构更有效地存档了状态。Stellar网络不是使用一个大型trie来存储所有存档信息，而是将存档状态存储在一组小型、不可变的Merkle树中。这意味着验证器可以通过仅存储最近存档的条目的小树来存档新条目，而大部分存档状态在历史档案中卸载：

恒星验证器只需要存储一个最近存档状态的小Merkle树。有关更多信息，请参阅本系列的第1部分。

至关重要的是，这允许Stellar验证器按照确定性的时间表存档条目，这样State archive就不需要额外的事务，这意味着用户事务的带宽更大，TPS更高。

鳄梨增加了网络成本

State Archive的全部目的是减少需要存储的州区块链节点的数量。这不仅包括验证器，RPC节点也应该从State Archive中受益。不幸的是，Anatoly决定使用一个trie来存储所有压缩的帐户状态。这很贵。总结一下，以下是需要存储整个压缩帐户状态的人：

RPC节点（用于生成解压缩证明）从压缩事务中赚取额外资金的验证器

唯一不必存储完整状态的实体是不发送压缩事务的验证器。存储压缩状态对于网络的长期可持续性来说成本太高，因此Solana的解决方案是让RPC节点和许多验证器存储压缩状态。

正如你所看到的，Solana的状态压缩真的没有节省成本。网络费用仍将增加，以补偿需要存储完整trie以生成压缩证明的验证器的奖励。链下费用也将继续增加，因为RPC节点的运行成本与以前一样高，甚至更高。虽然一些验证器不需要存储存档trie，但网络仍然依赖于存储它的验证器。这似乎不是一个显著的好处，尤其是以更高的费用、更高的复杂性和更多的网络拥塞为代价。

问题是，通过使用单个trie，档案状态不能被分片。任何与压缩或解压缩交互的节点都需要存储所有压缩状态，无论是生成证明的RPC节点还是提交压缩事务的验证器。

Stellar网络的设计更具可扩展性。因为Stellar上的State Archive使用一组小的、不可变的Merkle树，而不是一个大的、可变的trie，所以长期存储归档状态要便宜得多。RPC节点不需要存储所有存档状态来生成证明，但可以在多个节点之间对树进行分片，或者选择只存储包含某些相关存档状态的分片。虽然历史档案馆必须保持完整的档案状态以实现数据可用性和去中心化，但运营商还可以在多个节点上分片树，并将档案状态存储在廉价的网络支持存储设备上。Solana的单个trie不能共享，而且由于它是可变的，必须存储在昂贵的本地NVMe驱动器上。

结果是，通过Stellar的国家档案设计，网络实际上变得更便宜了！没有验证器或RPC实例需要存储所有存档状态，因此构建者将看到性能和成本节约的好处！

如果你想在Stellar上阅读更多关于State Archive设计的信息，请查看此处的接口规范（自2月起在主网上发布）和此处的证明实现细节（今年晚些时候将在主网发布）。我们还建议Solana联合创始人Anatoly Yakovenko和Stellar的高级软件工程师Garand Tyson加入即将到来的推特空间。与此同时，如果您正在探索一个可扩展的智能合约平台来构建您的下一个dApp，请考虑Stellar。