本文深入探索原生状态Rehydration、状态最小化技术以及状态最小化交易模型。

最近，我在数次关于状态增长的演讲中，以及在X平台上的更多讨论中，深感此话题的重要性。因此，我想借此机会扩展我的演讲内容，并分享我们在Fuel团队采用的方法。

首先，让我们了解背景。区块链面临的一个主要挑战是“状态增长”问题，如果不加以控制，这一问题可能会威胁到区块链网络的可扩展性和效率。接下来，我们将深入探讨状态增长的含义、其成为问题的原因，以及为了保持区块链在扩展过程中的精简和高效，我们提出的解决方案。

理解区块链的处理瓶颈

在深入探讨状态增长的复杂性之前，先了解一下区块链的三个核心组成部分，这些部分通常是网络扩展的主要瓶颈：

1. 执行。负责同步、验证以及未来区块的创建。✅ 已解决：我们有了众多解决方案，如高效虚拟机（包括FuelVM、Stylus、SVM、MoveVM）和并行交易执行（利用所有CPU核心），以及优化的预编译（在VM中预设功能）。

2. 数据（包括存储和可用性）。交易数据推动状态转换，使其他节点与区块链网络同步，并为rollup提供欺诈或有效性证明。✅ 已解决：我们有了多种解决方案，例如EIP-4844、分片设计和外部数据可用性层（如Celestia、EigenDA和Avail）。

3. 状态。存储在本地数据库中的活动信息，确保链的正确验证和状态转换。这通常是区块链处理的“热点”，需要大量随机磁盘访问和产生大量IO，也是签名和哈希之外最慢的处理区域。❌ 未解决。

这些组件在区块链运作中起着至关重要的作用。但我们特别关注的是“状态”，及其在讨论增长问题时的重要性。

状态增长的挑战

状态增长指的是区块链网络中节点必须持续存储和管理的数据量不断增加的现象。随着状态的不断增长，通常被视为一个“未来的问题”。然而，当状态增长像雪球一样达到阈值时，节点运行被严重拖累，成为可扩展性的瓶颈。这种现象在它妨碍更广泛的采用和减缓创新时，证明是致命的。

状态增长导致区块链膨胀，交易时间延长和存储成本上升成为常态，这反过来又限制了网络的可扩展性和可访问性。听起来很熟悉吗？解决状态增长问题将是推动rollup经济的下一个催化剂，这与之前的问题——吞吐量——一样，激发了rollup革命。

EVM链上流行的状态大小近似值。

（数据仅供参考，仅用于说明目的）

但是，rollup真的解决了状态增长问题吗？

Rollup为以太坊打开了向“新事物”发展的大门。现有解决方案专注于解决执行层面的问题，而一些模块化解决方案则进一步解决了数据可用性问题。然而，如果这些新方案没有解决状态的核心问题，那么我们又回到了起点。今天设计的任何区块链，无论是rollup还是非rollup，如果没有针对状态增长的策略，最终都将受到状态膨胀的限制，不论其执行或数据环境如何。

Arbitrum和Optimism上的活跃地址数量（虽然与状态大小不同，但应该存在一定的相关性）。数据来源：Etherscan。

对比不同的状态设计

为了更清楚地说明这一点，让我们对比一下比特币和以太坊在状态管理方面的不同：

• 比特币状态：采用UTXO（未使用的交易输出）集，管理起来更简单，传统上也更易于处理，但程序性有限。
• 以太坊状态：涵盖账户余额、智能合约代码以及智能合约状态——这包括代币余额、授权等。

比特币的状态管理模型虽然简单，但功能有限。其状态是通过个别交易输出来管理的，这些输出要么可用于未来的交易，要么已被使用并因此存档在区块链历史中。UTXO模型通过这种方式维持了一个清晰的状态，使得其管理相对更加简便，并确保状态不会因每笔交易而无限增长。但这种简化的代价是，与以太坊的图灵完备系统相比，比特币的程序性受限。

相比之下，以太坊的状态模型是一个丰富的生态系统，包含了账户余额、智能合约代码和众多合约状态——每次互动都像在不断增长的数据挂毯上添上新的一笔。虽然这种不断的状态演进证明了以太坊的多功能性，但也带来了显著的可扩展性挑战。随着每次智能合约的执行和交易，状态不断膨胀，导致了网络的膨胀，增加了存储需求和处理时间，这反过来又阻碍了创新和用户采用。

比特币和以太坊对状态管理的对比突显了区块链设计中的一个基本权衡：状态管理的简单性和效率与链上操作的复杂性和潜力。

提出的解决状态增长的解决方案

为了管理状态增长，提出了几种策略：

1. 放任状态增长，以换取更大的带宽使用。这并非理想选择，因为它对全节点提出了更高的要求，限制了网络的去中心化。

2. 状态租金，即对存储状态数据收取费用，但可能引发“树腐烂”等问题。

3. 无状态性，即全节点不需要存储状态，依赖于交易和区块中包含的状态证明。这实际上是将状态从第一层链转移到rollup。以太坊正在朝这个方向发展，但如何实现高效和可维护性仍有许多未解决的问题。

4. 取消Merkle化状态，这是一种以不同方式管理状态数据的技术方法，完全忽略状态树。

5. 应用层状态压缩，即使用调用数据技术来压缩状态数据。本质上是用带宽来交换状态。虽然这提高了带宽需求，但对基础设施的鲁棒性和效率权衡产生了显著影响。

例如，Uniswap V3 staker的案例展示了这一点。在这里，状态必须通过带宽重新水合。这种设计极大地最小化了状态，并且在以太坊上，调用数据比存储更加经济。另一个例子是压缩NFT，这涉及将NFT所有权数据进行Merkle化并将根存储在状态中。

现在，让我们讨论原生状态再水合。

Fuel的状态哲学

通过采用UTXO模型，我们可以获得几个“免费的好处”：

• 本地状态树：没有全局状态树，只有每个智能合约的局部状态树。
• 原生资产：所有资产转移只触及一个状态元素。原生资产可以用来表示非价值状态（例如，NFT代表所有权）。这些不需要Merkle化，简化了状态。
• 无需批准的状态：消除了来自approve和transferFrom函数的不必要状态变化。

UTXO模型在保留丰富的加密轻客户端和可验证性的同时，允许实现以上所有这些，创造了真正互操作性的“快速模式”（有关此将在未来文章中详述）。Fuel方法背后的核心思想是：使用更多的带宽和执行，而使用更少的状态。但如何实现这一点？

原生状态再水合

原生状态再水合描述了一种Fuel开发者可以用来脱水或隔离状态的方法。通过带宽重新水合事务，以便在需要时重新访问状态。这与以太坊的传统方法（“一切都用智能合约”）形成对比，后者使用合约状态查找。

新方法包括：

• 只存储根哈希/状态变化。
• 通过带宽呈现数据以“重新水合”状态。
• 为开发者提供状态最小化技术，以便利用这一点。

状态最小化技术

专注于带宽和执行，而不是状态存储。Fuel为开发者提供了许多除智能合约存储之外的方式：

• 脚本：交易中包含的临时逻辑，不存储在状态中。与EVM交易不同，后者可以直接调用合约（但只能调用一个合约），Fuel交易执行脚本，可以调用零个或多个合约。
• 谓词：轻量级、无状态合约。谓词是一种新的、纯净的交易授权机制。谓词只能访问交易中的数据，不能查看当前链状态。谓词可用于启用原生（无状态）账户抽象。

了解更多关于Ryan Sproule的谓词文章：谓词不是智能合约，但仍允许用于花费硬币的自定义授权逻辑。这意味着谓词可以在没有私钥的情况下被花费，不像任何EVM交易。实际上，这意味着用户可以构建可以完全无需许可地花费的谓词。当与Fuel的脚本概念结合时，与智能合约的交互用户体验得到极大提升。

状态最小化交易模型

将状态最小化技术与UTXO模型结合，允许我们创建了一个新的灵活交易模型。这种模型支持构建复杂的多方交易，而不需要智能合约来访问状态。

Fuel基于UTXO的交易模型。

在实际应用中，这会是怎样的一个情形？举例来说：

• 智能合约钱包：仅有一个32字节的状态元素。
• 合约状态存储在UTXO中的单个根哈希中。
• 需要时通过带宽重新水合状态。
• UTXO确保了轻客户端的可验证性，无需全局Merkle树。
• 只需要一次IO读取。
• 当状态UTXO被消费时，状态可以改变。
• 与以太坊相比，不会丧失智能合约钱包的功能。
• 优先考虑带宽和执行而不是状态。
• 所有操作都在原生层面（谓词）完成。

Fuel的架构设计旨在结合所有这些功能，以及状态最小化执行，创建一个专为以太坊rollup设计的解决方案。Fuel为以太坊生态系统带来了新的能力，同时通过最终在以太坊上结算来保持安全。

虽然对抗状态增长的战斗仍在继续，但像Fuel这样的工具和策略为一个可扩展且高效的未来提供了希望。正如谚语所说：“需求是发明之母”，在区块链世界中，征服状态增长的必要性确实催生了许多创新的解决方案。