4.4FuelVM和EVM, 轻松搞明白(FuelVM vs. EVM, Explained)

FuelVM learns from the EVM, Solana, WASM, Bitcoin, and Cosmos.

FuelVM向EVM、Solana、WASM、Bitcoin和Cosmos学习。

This page is meant to outline the ways the FuelVM differs compared to the EVM in simple terms.

本页旨在以简单的术语概述FuelVM与EVM相比的不同之处。

FuelVM vs. EVM

FuelVM有一个全局共享的内存结构，而不是情景中的本地内存 (The FuelVM has a globally shared memory architecture instead of context-local memory)

The FuelVM has a globally shared memory architecture. Instead of every contract call having its own separate memory space, call data, and return data, all contract call frames share global memory. This chunk of memory is shared amongst all call frames and is globally readable. This allows you to pass data around between contracts without expensive storage and pass chunks of data without having to serialize, copy from call data to memory, etc. Read more about the FuelVM memory model here.

FuelVM有一个全局共享的内存架构。每个合约调用都有自己独立的内存空间、调用数据和返回数据，而不是所有合约调用框架都共享全局内存。这块内存在所有调用框架之间共享，并且是全局可读的。这允许你在合约之间传递数据，而不需要昂贵的存储，传递数据块也不需要序列化和从调用数据复制到内存，等等。这里阅读更多关于FuelVM内存模型的信息。

FuelVM 专为欺诈证明而设计 (The FuelVM is designed for fraud-provability)

The EVM is a complicated machine to construct fraud proofs for. It usually requires a second layer such as WASM or MIPS to be interpreted into a fraud provable system. Check out User Sovereignty with Fraud Proofs and how fraud proofs unlock key functionality.

构建欺诈证明，对EVM 来说就十分复杂。它通常需要第二层，如 WASM 或 MIPS，才能被解释为欺诈可证明的系统。查看带有欺诈证明的用户主权 和 欺诈证明如何解锁关键功能

FuelVM 有多个原生资产 (FuelVM has multiple native assets)

In Ethereum, the only native asset is Ether. It’s the only one that gets first-class treatment in terms of cost and ability to be pushed and pulled through a call. In Fuel, any contract can mint its UTXO-based native asset using a set of easy asset opcodes. All of which can gain the benefits of native-level call and optimization. Read more about support for multiple native assets in the Sway docs, and here.

在以太坊中，唯一的原生资产是以Ether。它是唯一在成本与通过调用来“折腾”的能力两方面，(都)获得一流待遇的产品。在 Fuel 中，任何合约都可以使用一组简单的资产操作码来铸造其基于 UTXO 的原生资产。所有这些都可以获得原生级别调用和优化的好处。查看 Sway 文档 和 此处。

FuelVM使用64位字而不是256位 (FuelVM uses 64-bit words instead of 256-bit)

Modern processors have 64-bit registers, and all of the instruction set operates on 64 bits. Those are the most efficient instructions, and when you deal with 256 bits, you’re dealing with big numbers, and since modern processors aren't made to handle those numbers natively, it means you have to do more in the software.

现代处理器有64位寄存器，所有的指令集都在64位上运行。这些都是最有效的指令，当你处理256位时，你要处理的是大数字，由于现代处理器不是用来处理这些数字的，这意味着你必须在软件中做更多的工作。

FuelVM是基于寄存器而不是基于堆栈的 (The FuelVM is register-based instead of stack-based)

Register-based VMs typically require fewer instructions to do the same work than stack-based VMs. Because every operation is priced, optimizing to reduce the number of operations needed to do the same amount of work has outsized benefits.

与基于堆栈的虚拟机相比，基于寄存器的虚拟机通常需要更少的指令来完成同样的工作。因为每一个操作都是有价的，优化进而减少做同样数量的工作所需的操作数量有很大的好处。

FuelVM从一开始就以原子UTXO范式构建

Fuel uses a system of UTXOs which enable a more efficient system fo transfer and ownership of assets, where the accounts tree doesn't have to be rebuilt every time funds are transferred.

Fuel使用一个UTXO系统，该系统能够实现更有效的资产转移和所有权，账户树不必在每次资金转移时都被重新建立。

The FuelVM移除了 approve, transferFrom (The FuelVM removes approve, transferFrom)

The FuelVM removes the need for approve/transferFrom UX with scripts. Unlike the EVM, the FuelVM has scripts, which allow many actions to happen from an origin sender without a contract being deployed. Read more in the Fuel Specification here.

FuelVM通过脚本消除了对approve/transferFrom用户体验的需求。与EVM不同，FuelVM有脚本，它允许许多行动从原发端发生，而不需要部署合同。在Fuel规范中阅读更多内容这里。

在Fuel中实现的EIPs(EIPs Implemented in Fuel)

The FuelVM implements several EIPs that have been suggested and supported by the community but couldn't be implemented due to the need to maintain backward compatibility. Check out a non-exhaustive list, also available here:

FuelVM实现了几个EIPs，这些EIPs已经被社区建议并支持，但由于需要保持向后的兼容性而无法实现。请看一个非详尽的列表，可以在这里 查询：

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通过拥有代码根而不是代码哈希，实现了这一点。