Fuel手册-更新中 (The Fuel Book)-updating
  • 0.Fuel手册 (The Fuel Book)
  • 1. 开发者快速上手 (Developer Quickstart)
    • 1.1构建智能合约 (Building A Smart Contract)
    • 1.2 构建前端 (Building a Frontend)
  • 2.准备开始 (Getting Started)
    • 2.1为什么是Fuel (Why Fuel)
    • 2.2Fuel是什么? (What is Fuel?)
      • 2.2.1 Fuel工具链 (The Fuel Toolchain)
    • 2.3 模块化运动 (Modular Movement)
      • 2.3.1 单片架构 (Monolithic Architecture)
      • 2.3.4 什么是模块化执行层 (What is a Modular Execution Layer)
    • 2.4 Fuel设置 (Fuel Configurations)
      • 2.4.1 作为汇总的Fuel (Fuel as a roll-up)
      • 2.4.2 作为L1的Fuel (Fuel as an L1)
      • 2.4.3 作为状态通道的Fuel (Fuel as a state channel)
      • 2.4.4 作为侧链的Fuel (Fuel as a sidechain)
  • 3. 技术 (Technology)
    • 3.1 并行交易执行(Parallel Transaction Execution)
    • 3.2欺诈证明 (Fraud Proofs)
  • 4. Fuel虚拟机 (The FuelVM)
    • 4.1合约和调用模型(Contract and Call Model)
    • 4.2内存模式 (Memory Mode)
    • 4.3多重原生资产(Multiple Native Assets)
    • 4.4FuelVM和EVM, 轻松搞明白(FuelVM vs. EVM, Explained)
  • 5.Sway语言 (Sway Language)
    • 5.1 Sway设计哲学 (Sway Design Philosophy)
    • 5.2 Sway的安全性 (Sway Safety)
  • 6.开发者看这里(For Developers)
    • 6.1Sway程序示例 (Sway Application Examples)
    • 6.2 网络 (Networks)
      • 6.2.1 `beta-3`测试网 (The `beta-3` testnet)
      • 6.2.2 `beta-2`测试网 (The `beta-2` testnet)
      • 6.2.3 `beta-1` 测试网 (beta-1 testnet)
    • 6.3 运行一个本地Fuel节点 (Running a local Fuel node)
    • 6.4 Sway语言 (Sway Language) 🌴
    • 6.5 Typescript SDK
    • 6.6 Rust SDK
    • 6.7 Fuel索引器 (Fuel Indexer)
    • 6.8 水龙头和区块浏览器 (Faucet and Block Explorer)
    • 6.9 Fuelup
    • 6.10 Fuel GraphQL API
  • 7. Fuel术语 (Fuel Glossary)
Powered by GitBook
On this page
  1. 3. 技术 (Technology)

3.1 并行交易执行(Parallel Transaction Execution)

Previous3. 技术 (Technology)Next3.2欺诈证明 (Fraud Proofs)

Last updated 2 years ago

Ethereum processes transactions sequentially (i.e. one after the other). With modern processors becoming increasingly multi-threaded but stalling on single-core speedups, being able to execute transactions in parallel (i.e. multiple transactions at once) is a highly desirable property.

以太坊按顺序处理交易(即一个接一个)。随着现代处理器变得拥有越来越多的多线程,但在单核加速上却停滞不前,加入能够并行执行交易(即一次执行多个交易)就会是一个非常理想的属性。

Without a mechanism for determining and handling between transactions, executing transactions in parallel is a race condition and would result in non-deterministic execution. There have been attempts to add logic to Ethereum, but show inconsistent performance benefits and moreover only work in non-adversarial conditions.

如果没有一种机制来确定和处理交易之间的,并行执行交易就是一种竞赛条件,就会导致非确定性的执行。已经有人尝试将逻辑添加到以太坊,但只显示出不一致的性能优势,且只能在非对抗条件下工作。

proposed to add access lists to transactions, i.e. a list of shared state that would be touched by each transaction. With such a list, clients can partition transactions into sets with disjoint access lists and execute transactions across each set in parallel. However, the EIP was never implemented, in part due to implementation and design inefficiencies that resulted in state accesses being the bottleneck rather than compute.

提议为交易添加 访问列表,即每个交易将触及的共享状态的列表。有了这样一个列表,客户可以将交易划分为具有互补隶属的访问列表的集合,并在每个集合中并行执行交易。然而,EIP从未被实施,部分原因是实施和设计效率低下,导致状态访问成为瓶颈,而不是计算(成为瓶颈)。

状态访问列表和UTXO (State Access Lists and UTXOs)

Fuel supports parallel transaction execution through strict (i.e. mandatory) access lists, similar to EIP-648. Each transaction must specify which contracts the transaction may interact with; if a transaction attempts to access a contract not in this list then execution will revert. With these access lists, execution can be done in parallel across transactions that touch disjoint sets of contracts. See for additional context.

Fuel通过严格的(即强制性的)访问列表支持并行交易的执行,类似于EIP-648。每个交易必须指定该交易可以与哪些合约进行交互;如果一个交易试图访问不在这个列表中的合约,那么执行将 返回。有了这些访问列表,执行可以在触及不相交的合约集的交易中并行进行。参见 来了解更多的情况。

Access lists are implemented with UTXOs. UTXOs give other nice properties, but for the purposes of parallel transaction execution serve simply as .

访问列表是用UTXO实现的。UTXO给出了其他很好的属性,但对于并行交易执行的目的来说,它只是作为。

dependencies
optimistic concurrent execution
依赖关系
乐观的并发执行
EIP-648
EIP-648
here
此处
strict access lists
严格的访问列表