今年币圈链圈一个重大事件就是：EOS在6.1日正式发布，但是还有非常多的人从未阅读过EOS技术白皮书。在此我准备做一个通读EOS白皮书系列，主要是翻译官方原文并加入个人解释的形式展现，水平有限，欢迎大家讨论交流。
微信公众号：blockd-public
微信号：点击查看

---

最小化通讯延迟

延迟时间指的是一个账户向另一个账户发送消息并收到响应的这段时间。目标是让两个账户在一个区块中交换消息，不必每条消息之间等待3秒。想要实现这个目标，EOS.IO 软件把每个区块分成多个周期。每个周期分成线程，每个线程包含一系列交易。每笔交易包含一组要发送的消息。这种结构可以看成是树状结构，串行并行交替处理。

  区块 Block

    周期 Cycles (串行sequential)

      线程 Threads (并行parallel)

        交易 Transactions (串行sequential)

          消息 Messages (串行sequential)

            接收账户和被通知账户 Receiver and Notified Accounts (并行parallel)

解释：解释一下并行操作：一个人可以同时吃饭和看电影，但是一个人不能同时吃饭和吹气球。因为眼睛和嘴没有冲突，但是吃饭和吹气都要用嘴，同时进行会发生冲突 。
EOS.IO中有产生延迟时间这个过程中，是有一些操作可以并行执行（以空间换时间），有些步骤只能顺序执行（以时间换空间）。上图就展示了哪些可以并行哪些必须串行。

一个周期内产生的交易可以发送到任意一个后续周期或区块中。区块生产者会持续向区块中添加周期直到最大时钟时间已过或者没有新的交易要发送。

可以通过区块静态分析来校验一个指定的周期没有两个线程含有修改同一个账户的交易。只要可以保证这点不变，那么区块就能并行运行所有线程。

解释：只要保证好没有竞争同一资源，就可以并行运算。

只读消息处理器

某些账户可以用一个是否通过的开关处理消息而不用改变内在状态。如果是这种情况，那么这些处理程序就可以并行执行，只要特定账户的只读消息在一个特定周期内包含在一个或多个线程中。

解释：只读的处理程序可以同时运行。就像可以同时多个播放器播放同一部电影。

多账户的原子交易

有些时候 ，需要确保多条消息被送到多个账户并被接收的原子性。在这种情况下，所有的消息都会被放在同一笔交易中，所有的账户会被放到一个线程，消息按顺序应用。这种情形下性能不会很理想，当遇到“账单”用户使用时，他们到根据一笔交易中涉及到的唯一账户数量来统计。

出于性能与成本考虑，最好是最大程度减少涉及两个以上重度使用账户的原子化操作。

解释：原子性就是说不可分割特性。对于多个操作，这些操作要么全部执行，要么全都不执行。

区块链状态的部分评估

可伸缩的区块链技术必须是模块化组件。每个人不必运行所有东西，特别是当他们只需要一个应用的小部分子集时。

解释：不要小车拉大车费力又没效果，就像没必要40度的夏天还穿着过冬的衣服。

交易所应用开发者运行全节点是为了向他的用户们展示交易状态。而这个应用没必要去关联社会应用。EOS.IO 软件可以让任一全节点选择应用的任意子集来运行，发给到其他应用的消息可以被安全的忽略，因为一个应用的状态只和他们接收到的消息有关。

解释：做一个应用选择适合自己的功能，砍刀臃肿无用功能，才是一个好产品。EOS可以直接“安全”过滤那么没有使用到的功能的消息。

这种事情在与其他账户通信的时候会有重大影响。最重要的影响就是不能认为同一机器上的其他账户是可以访问的。也意味着当尝试“上锁”让一个账户同步调用另一个账户，当其他账户不在内存时这种设计模式会出现问题。

解释：看原文，我自己都觉得不像人话-_-!

所有账户间的状态通信必须通过链上的消息进行。

自主最优调度

EOS.IO 软件不会强制区块生产者向任何账户发送消息。每个块生产者对处理交易所需的计算复杂性和时间做出自己的主观计算。无论是用户生成的还是脚本自动生成的交易都适用。

在一个已经启动的EOS.IO软件的区块链，在网络层面，所有的交易都需要支付固定的计算带宽成本，无论是执行交易用了0.01毫秒还是10毫秒。不过，每个独立的区块生产者都可以使用自己的算法与计算方式统计资源使用率。 当区块生产者得出一笔交易或一个账户消耗了大量不匹配的计算能力时，在他们生产自己的区块时可以拒绝这笔交易。然后，如果其他的区块生产者都认为这笔交易有效，他们依然要处理这笔交易。

通常，只要有一个区块生产者认为交易有效并且在符合资源使用限制时，所有其他区块生产者也会接受这笔交易，不过呢，可能需要花上1分钟才能找到合适的区块生产者。
在某此情况下，区块生产者可能创建一个区块含有的交易数量超出可接受范围。在这种情况下，接下来的区块生产者可能选择拒绝这个区块，这种僵持会被第三个区块生产者打破。这与一个大区块引起的的网络传播延迟没什么区别。社区会注意到滥用情况，最终还会移出恶意生产者的投票。

自主的计算成本评估可使区块链不必精确的计算某个事情需要运行多长时间。用这个设计就没有必要精确计算能够不违反共识的情况下大幅增加优化机会的指令。

解释：每个区块生产节点自己评估成本，在不损害别人的情况下选择有利于自己的行为。通过每个节点的自己判断，有点像市场经济。

---

原文如下

Minimizing Communication Latency

Latency is the time it takes for one account to send a message to another account and then receive a response. The goal is to enable two accounts to exchange messages back and forth within a single block without having to wait 3 seconds between each message. To enable this, the EOS.IO software divides each block into cycles. Each cycle is divided into threads and each thread contains a list of transactions. Each transaction contains a set of messages to be delivered. This structure can be visualized as a tree where alternating layers are processed sequentially and in parallel.

  Block

    Cycles (sequential)

      Threads (parallel)

        Transactions (sequential)

          Messages (sequential)

            Receiver and Notified Accounts (parallel)

Transactions generated in one cycle can be delivered in any subsequent cycle or block. Block producers will keep adding cycles to a block until the maximum wall clock time has passed or there are no new generated transactions to deliver.

It is possible to use static analysis of a block to verify that within a given cycle no two threads contain transactions that modify the same account. So long as that invariant is maintained a block can be processed by running all threads in parallel.

Read-Only Message Handlers

Some accounts may be able to process a message on a pass/fail basis without modifying their internal state. If this is the case then these handlers can be executed in parallel so long as only read-only message handlers for a particular account are included in one or more threads within a particular cycle.

Atomic Transactions with Multiple Accounts

Sometimes it is desirable to ensure that messages are delivered to and accepted by multiple accounts atomically. In this case both messages are placed in one transaction and both accounts will be assigned the same thread and the messages applied sequentially. This situation is not ideal for performance and when it comes to "billing" users for usage, they will get billed by the number of unique accounts referenced by a transaction.

For performance and cost reasons it is best to minimize atomic operations involving two or more heavily utilized accounts.

Partial Evaluation of Blockchain State

Scaling blockchain technology necessitates that components are modular. Everyone should not have to run everything, especially if they only need to use a small subset of the applications.

An exchange application developer runs full nodes for the purpose of displaying the exchange state to its users. This exchange application has no need for the state associated with social media applications. EOS.IO software allows any full node to pick any subset of applications to run. Messages delivered to other applications are safely ignored because an application's state is derived entirely from the messages that are delivered to it.

This has some significant implications on communication with other accounts. Most significantly it cannot be assumed that the state of the other account is accessible on the same machine. It also means that while it is tempting to enable "locks" that allow one account to synchronously call another account, this design pattern breaks down if the other account is not resident in memory.

All state communication among accounts must be passed via messages included in the blockchain.

Subjective Best Effort Scheduling

The EOS.IO software cannot obligate block producers to deliver any message to any other account. Each block producer makes their own subjective measurement of the computational complexity and time required to process a transaction. This applies whether a transaction is generated by a user or automatically by a script.

On a launched blockchain adopting the EOS.IO software, at a network level all transactions are billed a fixed computational bandwidth cost regardless of whether it took .01ms or a full 10 ms to execute it. However, each individual block producer using the software may calculate resource usage using their own algorithm and measurements. When a block producer concludes that a transaction or account has consumed a disproportionate amount of the computational capacity they simply reject the transaction when producing their own block; however, they will still process the transaction if other block producers consider it valid.

In general so long as even 1 block producer considers a transaction as valid and under the resource usage limits then all other block producers will also accept it, but it may take up to 1 minute for the transaction to find that producer.

In some cases a producer may create a block that includes transactions that are an order of magnitude outside of acceptable ranges. In this case the next block producer may opt to reject the block and the tie will be broken by the third producer. This is no different than what would happen if a large block caused network propagation delays. The community would notice a pattern of abuse and eventually remove votes from the rogue producer.

This subjective evaluation of computational cost frees the blockchain from having to precisely and deterministically measure how long something takes to run. With this design there is no need to precisely count instructions which dramatically increases opportunities for optimization without breaking consensus.