2.2Fuel是什么? (What is Fuel?)

Fuel v1 began as a layer-2 (L2) scalability technology for a monolithic Ethereum. It was the first optimistic rollup on mainnet Ethereum, deployed at the end of 2020.

Fuel v1 最初是作为单片以太坊的第 2 层 (L2) 可扩展性技术。这是 2020 年底部署在以太坊主网上的第一个 optimistic rollup。

Today, Fuel is the fastest modular execution layer. Fuel delivers the highest security and flexible throughput, with a focus on a superior developer experience.

如今，Fuel 是最快的模块化执行层。 Fuel 提供最高的安全性和灵活的吞吐量，专注于卓越的开发者体验。

Here’s how we do it:

我们做了什么：

• Parallel transaction execution 并行交易执行

• Fuel Virtual Machine (FuelVM) Fuel虚拟机 (FuelVM)

• Developer tooling with Sway Language and Forc 使用 Sway 语言和 Forc 的开发人员工具

并行交易执行 (Parallel Transaction Execution)

Fuel delivers unmatched processing capacity through its ability to execute transactions in parallel by using strict state access lists in the form of a UTXO model. This enables Fuel to use far more threads and cores of your CPU that are typically idle in single-threaded blockchains. As a result, Fuel can deliver far more compute, state accesses, and transactional throughput than its single-threaded counterparts.

Fuel 通过如下方式获得无与伦比的处理能力：使用 UTXO 模型形式的严格状态访问列表来并行执行交易。这使 Fuel 能够使用更多的线程和 CPU 内核，而这些线程和内核通常在单线程区块链中处于空闲状态。因此，Fuel 可以提供比单线程同类产品更多的计算、状态访问和交易吞吐量。

With the EVM, it is difficult to know if, and where there are dependencies between transactions, so you are forced to execute transactions sequentially.

使用 EVM，很难知道交易之间是否存在依赖关系，以及在哪里存在依赖关系，因此您必须按顺序执行交易。

The FuelVM uses the UTXO model, enabling parallel transaction execution by identifying transaction dependencies through what is known as state access lists. With the FuelVM, Fuel full nodes identify the accounts that a transaction touches, mapping out dependencies before execution.

FuelVM 使用 UTXO 模型，通过所谓的状态访问列表识别交易依赖，来实现并行交易执行。使用 FuelVM，Fuel 全节点识别交易涉及的账户，在执行前映射依赖关系。

Fuel(虚拟机) FuelVM

The FuelVM learns from the Ethereum ecosystem, implementing improvements that were suggested to the Ethereum VM (EVM) for many years but couldn’t be implemented due to the need to maintain backward compatibility.

FuelVM 从以太坊生态系统中学习，实施了多年来向以太坊 VM (EVM) 建议但由于需保持向后兼容而无法实施的改进。

Here are some EIP that have been implemented in the FuelVM:

下面是一些已经在 FuelVM 中实现的 EIP：

EIP	Description 描述	Implementation 实施
Easy Parallelizability	Allow transactions in the EVM to be processed in parallel by specifying what addresses they can access. 允许 EVM 中的交易通过指定其许可的地址来并行处理	Fuel can execute transactions in parallel by using strict state access lists with our UTXO model. This allows Fuel to use of all the threads and cores of your CPU to validate transactions. Fuel 可以通过我们的 UTXO 模型使用严格的状态访问列表来并行执行交易。这允许 Fuel 使用您 CPU 的所有线程和内核来验证交易。
EIP-2098: Compact Signature Representation	Reduce signatures from 65 bytes to 64 bytes to simplify handling transactions in client code, reduce gas costs, and reduce transaction sizes. 将签名从 65 字节减少到 64 字节，以简化客户端代码中的交易处理，降低 gas 成本，并削减交易大小。	Fuel compresses signature data by a byte, from 65 to 64 bytes. Fuel 按字节压缩签名数据，从 65 字节到 64 字节。
EIP-3074: AUTH and AUTHCALL opcodes	Introduces two EVM instructions, AUTH and AUTHCALL, to enable batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond. 引入了两个 EVM 指令，AUTH 和 AUTHCALL，进而启用批处理功能，允许gas赞助、过期、脚本甚至更多。	Fuel has scripts and predicates that, when combined, allow the execution of multiple calls in a single batch. Fuel 具有脚本和谓词，当它们组合在一起时，允许在一个批次中执行多个调用。
EIP-3102: Binary Trie Structure	Introduces binary structure and merkelization rule for the account and storage tries, which are merged into a single “state” trie. Binary tries make for smaller (~4x) proofs than hexary tries, making it the design of choice for a stateless-friendly Ethereum. 为帐户和存储尝试引入二进制结构和默克尔化规则，它们被合并到一个“状态”字典树。二进制字典树证明比六进制字典树的更小（~4x），使其成为无状态友好以太坊的首选设计。	Fuel uses a binary Sparse Merkle Trie instead of a Patricia Merkle Trie, which makes for smaller proofs and results in better performance. Fuel 使用二元Sparse Merkle Trie 而不是 Patricia Merkle Trie，这使得证明更小，性能更好。
EIP-4758: Deactivate SELFDESTRUCT	Rename SELFDESTRUCT opcode to SENDALL, and only immediately move all ETH in the account to the target; no longer destroying code or storage or alters the nonce. Disabling SELFDESTRUCT will be a requirement for statelessness. 将SELFDESTRUCT操作码重命名为SENDALL，只立即将账户中的所有ETH移动到目标；不再破坏代码或存储或更改随机数。禁用 SELFDESTRUCT 是无状态的要求。	The FuelVM doesn't have a SELFDESTRUCT opcode which can complicate client implementations. FuelVM 没有会使客户端实现复杂化的 SELFDESTRUCT 操作码。
EIP-5027: Remove the limit on contract code size	Remove the limit on the code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts. With the dramatic growth of decentralized applications, the functionalities of smart contracts are becoming more and more complicated, and thus, the sizes of newly developed contracts are steadily increasing. As a result, we are facing more issues with the 24576-bytes contract size limit. 取消对代码大小的限制，这样用户就可以部署一个大代码的合约，而不用担心将合约拆分成几个子合约。随着去中心化应用的急剧增长，智能合约的功能越来越复杂，因此，新开发的合约的大小也在稳步增加。因此，我们在24576字节的合约大小限制方面面临更多问题。	FuelVM doesn't have a limit on the size of a single contract below their physical limits. We have an instruction that allows you to load bytecode from another contract into the current execution context, allowing you to use it as a single contract even if you have to split bytecode across multiple transactions. It'll have a single monolithic bytecode and one state. In EVM, if you spit a contract across two transactions, it's two separate contracts, and you have to do things like delegate calls to share the state between the two contracts and can't do things like jump between bytecode on each contract. FuelVM对单个合约的大小没有限制，低于其物理限制。我们有一条指令，允许你从另一个合约中加载字节码到当前的执行情景中，即使你必须在多个交易中分割字节码，也允许你将其作为一个单一合约使用。它将有一个单一的字节码和一个状态。在EVM中，如果你将一个合约分为两笔交易，它就是两个独立的合约，你必须做一些事情，比如委托调用，在两个合约之间共享状态，且不能做一些事，比如在每个合约的字节码之间跳转。
EIP-5065: Instruction for Transferring Ether	Add a new instruction that transfers ether to a destination address without handing over the flow of execution to it. Ethereum currently has no ideal way to transfer ether without transferring the execution flow. People have come up with reentrancy guards and similar solutions to prevent some types of attacks, but it’s not an ideal solution. 增加一条新指令，将以太坊转移到一个目标地址，而不将执行流移交给它。以太坊目前没有理想的方法来转移以太坊而不移交执行流。人们已经想出了重入防护和类似的解决方案来防止某些类型的攻击，但这不是一个理想的解决方案。	The FuelVM has an instruction called TR, short for transfer, which transfers a native asset to a contract but doesn't allow the receiving contract to execute logic. You might want to do this to ensure the receiving contract cannot reenter. This doesn't exist as a native, first-class instruction in the EVM- you can do this by self-destructing a contract but it's a messy workaround that only works for ETH. FuelVM 有一条名为 TR 的指令，是转移的缩写，它将原生资产传输到合约，但不允许接收合约执行逻辑。您可能希望这样做法来确保无法重新输入接收合约。这在 EVM 中并不作为原生的一流/一级指令存在——您可以通过自毁合约来做到这一点，但这是一种仅适用于 ETH 的混乱解决方案。
EIP-86: Abstraction of Transaction Origin and Signature and EIP-2938: Account Abstraction	Implements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism currently hard-coded into transaction processing. 实施了一系列变化，达到了 "抽象化 "签名验证和非授权检查的综合目的，允许用户创建 "账户合约"，执行任何需要的签名/非授权检查，而不是使用目前硬编码的交易处理机制。	FuelVM has stateless account abstraction, enabling application-layer logic to configure validity rules of transactions. On Ethereum today, a transaction is valid if the user has enough Ether, the nonce is correct, and signature is valid. With account abstraction, the user can change the validity of the transaction logic without a hard fork. This could mean changes to the signature scheme or natively locking an account behind a multisig. FuelVM拥有无状态账户抽象，使应用层逻辑能够设置交易有效性规则。在今天的以太坊上，如果用户有足够的以太币，随机数是正确的，并且签名有效，那么交易就是有效的。通过账户抽象，用户可以改变交易逻辑的有效性，而不需要硬分叉。这可能意味着签名方案的改变，或者在多签后面原生地锁定一个账户。
EIP-1051: Overflow Checking for the EVM	This EIP adds overflow checking for EVM arithmetic operations and two new opcodes that check and clear the overflow flags. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation. 这个EIP为EVM的算术操作增加了溢出检查，以及两个新的操作码，用于检查和清除溢出标志。由于EVM在2^256模整数上操作，并且没有提供内置的溢出检测或预防，这就需要对每个算术操作进行手动检查。	Overflow checking is built into the FuelVM and can be optionally disabled. 溢出检查是内置在FuelVM中的，可以选择禁用。
EIP-2803: Rich Transactions	If a transaction has a to of address x, then the data of the transaction will be treated as EVM bytecode, and it will be executed from the context of the CALLER of the transaction (aka: the transaction signer). Many Ethereum DApps require users to approve multiple transactions to produce one effect. This results in a poor user experience and complicates the experience of interacting with DApps. 如果一个交易有一个地址为x 的 to，那么该交易的数据将被视为EVM字节码，它将从交易的CALLER（又名：交易签署者）的情景中执行。许多Ethereum DApps要求用户批准多个交易以产生一个效果。这导致了糟糕的用户体验，并使与DApps互动的体验变得复杂。	The FuelVM has scripts that implement this. FuelVM 有脚本来实现。
EIP-2926: Chunk-based Code Merkelization	Bytecode is currently the second contributor to block witness size after the proof hashes. Transitioning the trie from hexary to binary reduces the hash section of the witness by 3x, thereby making code the first contributor. By breaking contract code into chunks and committing to those chunks in a Merkle tree, stateless clients would only need the chunks that were touched during a given transaction to execute it. 目前，字节码是继证明哈希之后对区块见证大小的第二大贡献者。将字典树从十六进制过渡到二进制，可以将见证的哈希部分减少3倍，进而使代码成为第一贡献者。通过将合约代码分解成块，并在Merkle树中对这些块进行提交，无状态客户端将只需要在给定的交易中接触到的区块来执行。	To get a code hash on Ethereum, you hash together all the byte code. The problem is that if you want to do things with statelessness or fraud proofs, to show that this hash is valid, you have to provide all the byte code, up to 24KB per contract. This EIP suggests we should merkalize it instead of hashing. The FuelVM implements this by having code roots instead of code hashes. 为了在以太坊上得到一个代码哈希，你把所有的字节码哈希化。问题是，如果你想做无状态或欺诈证明的事情，为了证明这个哈希值是有效的，你必须提供所有的字节码，每个合约最多24KB。这个EIP建议我们应该把它合并，而不是哈希化。FuelVM通过拥有代码根而不是代码哈希，实现了这一点。

Sway语言 (Sway Language)

Sway is a domain-specific language (DSL) for the Fuel Virtual Machine (FuelVM), a blockchain-optimized VM designed for the Fuel blockchain. Sway is based on Rust and includes syntax to leverage a blockchain VM without a needlessly verbose boilerplate.

Sway 是 Fuel 虚拟机 (FuelVM) 的特定领域语言 (DSL)，FuelVM 是为 Fuel 区块链设计的区块链优化的虚拟机。 Sway 基于 Rust 并包含语法来撬动区块链的虚拟机，而无需不必要的冗长样板。

Sway was created alongside the FuelVM and designed for the high-compute Fuel environment. Check out the Sway docs here.

Sway 是与 FuelVM 一起创建的，专为高计算 Fuel 环境而设计。在此处查看 Sway 文档。

开发工具 (Developer Tooling)

Fuel Labs is developing a suite of developer tooling to create a seamless developer experience. By creating everything in-house, Fuel Labs guarantees the maintenance of the toolchain, avoiding the pitfalls of a fragmented developer ecosystem.

Fuel Labs 正在开发一套开发工具，来打造无缝的开发体验。通过在内部创建所有内容，Fuel Labs 保证了工具链的维护，避免了碎片化的开发者生态系统的陷阱。

Fuel provides a powerful and sleek developer experience with our own domain-specific language, called Sway, and a supportive toolchain, called Forc (the Fuel Orchestrator). Our development environment retains the benefits of smart contract languages like Solidity, while adopting the paradigms introduced in the Rust tooling ecosystem. Now, developers can have a completely vertically-integrated experience where every component from the virtual machine through to the CLI works in harmony.

Fuel 使用我们自己的领域特定语言（称为 Sway）和支持工具链（称为 Forc（Fuel Orchestrator））提供强大而流畅的开发人员体验。我们的开发环境保留了 Solidity 等智能合约语言的优势，同时采用了 Rust 工具生态系统中引入的范例。现在，开发人员可以获得完全垂直集成的体验，其中从虚拟机到 CLI 的每个组件都可以协调地工作。

The Fuel Toolchain: Forc: build, run tests, launch a local instance of a block explorer, format.

Fuel 工具链：Forc：构建、运行测试、启动区块浏览器的本地实例、格式。

Check out the Fuel Toolchain here.

在此处 查看Fuel 工具链。

Coming Soon: A suite of auditing facilities, from fuzzing and formal verification to code coverage and runtime gating.

即将推出：一套审计工具，从模糊测试和形式验证到代码覆盖和运行时门。