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

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 [dependencies](https://en.wikipedia.org/wiki/Parallel_computing#Dependencies) between transactions, executing transactions in parallel is a race condition and would result in non-deterministic execution. There have been attempts to add [optimistic concurrent execution](https://arxiv.org/abs/1901.01376) logic to Ethereum, but show inconsistent performance benefits and moreover only work in non-adversarial conditions.

如果没有一种机制来确定和处理交易之间的[依赖关系](https://en.wikipedia.org/wiki/Parallel_computing#Dependencies)，并行执行交易就是一种竞赛条件，就会导致非确定性的执行。已经有人尝试将[乐观的并发执行](https://arxiv.org/abs/1901.01376)逻辑添加到以太坊，但只显示出不一致的性能优势，且只能在非对抗条件下工作。

[EIP-648](https://github.com/ethereum/EIPs/issues/648) 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-648](https://github.com/ethereum/EIPs/issues/648)提议为交易添加 _访问列表_，即每个交易将触及的共享状态的列表。有了这样一个列表，客户可以将交易划分为具有互补隶属的访问列表的集合，并在每个集合中并行执行交易。然而，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 [here](https://fuellabs.github.io/fuel-specs/master/protocol/tx_validity#access-lists) for additional context.

Fuel通过严格的（即强制性的）访问列表支持并行交易的执行，类似于EIP-648。每个交易必须指定该交易可以与哪些合约进行交互；如果一个交易试图访问不在这个列表中的合约，那么执行将 _返回_。有了这些访问列表，执行可以在触及不相交的合约集的交易中并行进行。参见[此处](https://fuellabs.github.io/fuel-specs/master/protocol/tx_validity#access-lists) 来了解更多的情况。

Access lists are implemented with UTXOs. UTXOs give other nice properties, but for the purposes of parallel transaction execution serve simply as [strict access lists](https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37).

访问列表是用UTXO实现的。UTXO给出了其他很好的属性，但对于并行交易执行的目的来说，它只是作为[严格的访问列表](https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37)。
