Fuel
Fuel 被称为“模块化执行层”，它指的是 Fuel 作为执行层运行，能够进行多种不同的配置，例如作为以太坊的 Op Rollup，或利用 Celestia 进行 DA 和以太坊达成共识和结算。
Fuel 专注于通过模块化执行层来实现长期可扩展性，目标是最小化状态。为了实现这一目标，Fuel 创建了自己的虚拟机（FuelVM），选择重新开始并避免仅在 EVM 内构建的限制。尽管通过这种设计选择退出了 EVM 的强大网络效应，但从长远来看，它可能会为开发人员和用户提供更好的体验。通过最小化状态，Fuel 正在寻求创建一个执行层，为验证者提供足够负担得起的硬件要求，以实现充分的去中心化。
值得注意的是，Fuel V1 于 2020 年部署到以太坊主网。它是一个 Op Rollup，用于支付（不是智能合约平台），具有开放的区块生产、欺诈证明和不可变的智能合约。本文中所提到的 Fuel 均与 Fuel V2 版本相关。
Fuel架构
<u>UTXO Model</u>
未使用的交易输出（UTXO）是一种区块链会计模型。UTXO 区块链没有钱包或账户——硬币和合约作为 UTXO 存在。 这方面的一个例子是比特币区块链。 UTXO 是用户收到的交易的输出，本质上代表了某个地址持有的硬币的余额。 交易消耗 UTXO 并创建反映新状态的新 UTXO。
更简单地说，在比特币上，UTXO 代表用户完成交易后剩余的 BTC 数量。未使用的输出作为输入存回数据库，稍后可用于另一笔交易。比特币 BTC 就是使用 UTXO 模型。
Fuel 的状态由合约和代币 UTXO 表示。每个合约 UTXO 都携带合约的状态和余额，由合约 ID 唯一标识。
值得将 UTXO 模型与大多数其他智能合约链使用的基于账户的会计模型进行比较，例如以太坊。 在此模型中，代币是由私钥或智能合约控制的账户中的余额。 网络需要跟踪所有账户中的所有余额，并通过将交易顺序处理成代表新状态的块来更新状态。 这种设计限制了网络吞吐量，并且不能有效地利用硬件（仅 CPU 的单个线程）。
Fuel 的 UTXO 模型不一定需要能够并行执行的事务的顺序处理（同时发生多个事务）。
UTXO的并发问题
然而，UTXO 的性质让人质疑如何在每笔交易中消费和重新创建复杂的智能合约。 使用 UTXO 模型进行智能合约遇到的困难的一个例子是 Cardano。
Cardano 在 AMM 的 UTXO 模型上遇到了问题。 由于每个 UTXO 只能使用一次，因此只有一个人可以一次与智能合约交互。 DeFi 应用程序通常有多个人同时与智能合约交互。 这意味着对于 UTXO 模型，只有一个事务会成功（并消耗 UTXO），这意味着所有其他事务都会失败。 这称为并发问题。
Fuel是如何解决的？
在 Fuel 上，需要签署交易的不同部分：
- 用户不直接签署 UTXO，而是签署合约 ID——表明他们与合约交互的意图。 因此，用户不会直接改变状态，从而导致 UTXO 被消耗。
- 相反，区块生产者将负责一个区块中的各种交易将如何影响整体状态，从而影响合约 UTXO。 UTXO 被花费并被另一个代表新状态的替换。 在撰写本文时，Fuel 尚未发布有关区块生产者将如何在系统中工作的较低级别的详细信息。
- 已消费的合约 UTXO 创建新的 UTXO，具有相同的核心功能，但更新了存储和余额。
<u>Sway编程语言</u>
Fuel 背后的团队创建了 Sway 编程语言，目标是优化开发人员体验并实现卓越的应用程序。 它是一种受 Rust 启发但专为智能合约设计的领域特定语言。 Sway 旨在最大限度地降低成本并最大限度地提高合同级别的安全性。
- Sway 的语法与 Rust 相似。
- 寻求结合区块链特定的安全检查和零成本抽象，允许开发人员编写可靠和高效的智能合约。
- Fuel 团队专注于构建 Forc - Fuel 的构建系统，为 Fuel 开发人员提供工具和命令。
考虑到该语言的年轻程度，该团队已经建立了一个相对广泛的标准库。 这为 Sway 提供了多种功能，并使编译器能够快速移动。
Fuel 联合创始人 John Adler 使用“类似 iOS 的体验”的类比为开发人员构建了一个广泛的工具包，其中有一个统一且集成的工具链，而不是分散的。 这样做的理由是合理的，如果 Fuel 可以继续为开发人员构建统一的工具包，那么更简单的入职体验将有助于促进生态系统的发展。
<u>Script 和 Predicates</u>
Scripts 和 Predicates 是 Fuel 用来改善用户体验的关键工具。
Scripts: 使单个事务无需路由即可调用多个合约的程序。 一个关键的例子是在转移资金之前无需批准合同； 使用脚本，这可以在单个事务中完成。 脚本的一个关键特性是一旦执行它们就会从区块链中删除，因此不会导致状态膨胀。
Predicates: 不访问状态的合约脚本，用于启用无状态账户抽象。 账户抽象是指将区块链上的两种账户类型（钱包地址和合约）减少为一种——降低用户的复杂性。
<u>Parallelization并行化</u>
Fuel 支持并行执行交易，例如多个事务同时执行。
这与按顺序处理事务的 EVM 不同。这可以通过使用严格的访问列表来实现。使用访问列表，每笔交易都需要指定它可以与哪些合约进行交互。如果交易与未指定的合约交互，那么它将恢复。对于不与相同合约交互的交易（如严格访问列表中所述），并行执行是可能的。这应该使 Fuel 能够利用 CPU 的多个线程和内核同时验证交易。这是值得注意的，因为随着时间的推移，单线程性能改进相对较低，而线程数量却增加了。因此，似乎利用多线程而不是依赖单线程改进是一种更好的策略。
Fuel 尚未公布其潜在可扩展性的估计值，而其他项目经常披露不切实际的每秒交易量估计值。但是，该团队预计规范 Fuel 实例上至少有 1,000 TPS。请注意，不同的 Fuel 实例将具有不同的节点集，从而实现可扩展的吞吐量。随着更多信息的出现，有关 Fuel 潜在可扩展性的更多细节值得关注。
Fuel存在的风险和考虑
开发者的普及
- 虽然 Fuel 可能正在开发一种技术上优于 EVM 和其他竞争虚拟机的虚拟机，但区块链空间已经变得非常拥挤，许多拥有巨额业务开发资金的区块链吸引了开发人员的注意力，而越来越少的 用户。 Fuel 最近筹集的 8000 万美元对于 Fuel 吸引人才在此基础上发展非常重要。
- 在此说明中，TVL 排名前 10 的区块链中有 9 个使用了 EVM。 这是其主导地位的一个明显例子。 然而，这并不是未来成功的指标，构建一个克服其缺点的定制 VM 可以说是一个强有力的策略，因为 EVM 兼容 / 等效空间已经饱和。 构建一个有潜力实现卓越用户和开发人员体验的虚拟机可能是超越人群的更好选择。 如上所述，Fuel 团队专注于打造“类似 iOS”的开发者体验。
- 执行落地的风险：Fuel 是一个令人兴奋的项目，其设计决策背后的基本原理是合理的。 然而，它声称的关键应用场景，尚未经过适当测试，只有时间才能证明它是否能够兑现承诺。
智能合约的风险
Fuel 正在开创一种新的虚拟机和模块化执行层设计。 这种创新水平伴随着可能无法按预期执行的风险。 如果发生这种情况，早期的开发人员可能会从一开始就难以构建完全安全的应用程序。
节选文章：