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

---

内部区块链通信

EOS.IO软件是设计成提倡区块链内部通信。这通过简单的生成消息存在证明和消息序列证明来完成。这些证明与围绕着消息传递设计的架构相结合，可使区块链内部通信和证明的验证被应用开发者隐藏。

用于轻客户端验证的默克尔证明

如果客户端不需要处理所有交易，那么与其他区块链集成就会更容易。毕竟，一个交易所只关心资金转入转出。理想情况是交易所链可以利用存款的轻量级默克尔证明，而不用必须完成相信他自己的区块生产者。至少也是一个链上的区块生产者们希望在与另一个区块链同步时只要维护最小的开销。

轻客户端验证的目标是，生成一个相对轻量的存在证明（任何人都可以通过跟踪一份相对轻量的数据来验证的）。 这种情况下目标就是要证明一笔特定的交易包含在一个特定的区块，并且这个区块包含在一个验证过的特定区块链历史中。

比特币支持交易验证，是假设所有节点都有权访问每年大小为4MB的区块头信息的完整历史记录。 当每秒产生10笔交易时，一个有效的证明需要大约512个字节。对于10分钟一个区块周期时没什么问题，但是对3秒一个区块周期的区块链就不再“轻量”。

EOS.IO 软件可以为任何人提供轻量级证明，这些人是指在交易打包之后拥有不可逆转的头信息的人。使用链式哈希结构可以用一个小于1024字节的证明来证明交易的存在。

对于区块链中的区块而言，给定任一一个区块id和一个可信的不可以逆的头信息。就可以证明区块包含在区块链中。这个证明采用ceil(log2(N))签名路径，这里N代表链上的区块数。给定一个SHA256签名算法，就可以用864个字节证明任一个区块的存在存在于含有1亿个区块的链上。

使用恰当的哈希链结构生产区块带来的增量开销很小，也意味要没有理由不使用这种方式产生区块。

需要验证其他链上的证据时，对于时间、空间、带宽可以做多种优化。跟踪所有区块头信息（每年420MB）会保持证据体积较小。只跟踪最近的头信息要在证据大小和最小长期存储之间做出折中。另外，区块链也可以使用懒评估方法，即记录过去证据的中间值。新证明只需要包含指向已知sparse树。确切的方法必然取决于包含了Merkle 证明引用的交易所在的外部区块的比例。

有了一定相互关联的密度之后，会更有效的简化一条链包含加一条链的完全区块历史并且一起消除所有证据的需要。由于性能原因，理想的是最小化链间证据的频率。

链间通信延迟

当与其他外部区块链通信时，区块生产者必须等到100%确定一笔交易已经被其他区块链确认过不可逆转时，才可以把这笔交易当成有效输入。使用基于EOS.IO的区块链，0.5秒出块的DPOS，0.5秒增加拜占庭容错不可逆。如果哪个区块生产者没有等到不可逆转特性，那么这有可能是交易所创建的一笔稍后可能逆转的充值，可能会影响到区块链共识的可用性。EOS.IO软件使用同时使用DPOS和拜占庭容错算法提供快速不可逆转特性。

完备性证明

当使用来自外部区块链的默克尔证明时，知道所有的处理过的交易是可用的 与 知道没有交易被跳过或者忽略 有一个重要的区别。然而不可能证明所有近期的交易都是已知的，但是可以证明在交易历史上没有空档。EOS.IO软件通过给每一笔发送到账户的交易做序号排列来促成证明。用户可以使用这些序号来证明所有目标消息都参已经处理了并且是按顺序处理的。

隔离见证

隔离见证的概念就交易签名与打包进区块链的交易不相关。当不可改变的签名数据被精简之后，其他人还可以推导出现有的状态。固为签名占用了多数交易信息的很大比例，所以隔离会节省大量磁盘空间和同时的时间。

同样的根据可以用在区块链间通信的默克尔证明。一旦证明被接受并且不可逆的记录在区块链上，SHA256哈希值占用的2KB数据不再用来推导区块链的状态了。对这样情况下，可以比普通签名节省超过32倍空间。

另一个隔离见证的例子就是Steem博客的文章。在这种模型下，一篇 发布文章只包含一个博客内容的SHA256签名，而博客内部会存在隔离见证的数据上。区块生产者会验证内容的存在性以及给定的哈希值，但是来从区块链日志中恢复状态的博客内容不需要存储。这可以在不必须永久存储垃圾信息的情况下验证内容。

解释：简单说，隔离见证就是把验证信息与要传送的信息分隔。这样在不需要改变出块时间和区块大小，就可以增加传递的信息，缓解网络拥堵现象。

总结

EOS.IO软件的设计源于验证过的概念以及最佳实践，同时也代表了区块链技术的根本进步。此软件也是全球性可扩展区块链社会蓝图的一部分，体现着去中心化应用程序可以轻松的部署与管理。

解释：这是牛逼的软件。

---

原文如下

Inter Blockchain Communication

EOS.IO software is designed to facilitate inter-blockchain communication. This is achieved by making it easy to generate proof of Action existence and proof of Action sequence. These proofs combined with an application architecture designed around Action passing enables the details of inter-blockchain communication and proof validation to be hidden from application developers, enabling high level abstractions to be presented to developers.

Merkle Proofs for Light Client Validation (LCV)

Integrating with other blockchains is much easier if clients do not need to process all transactions. After all, an exchange only cares about transfers in and out of the exchange and nothing more. It would also be ideal if the exchange chain could utilize lightweight merkle proofs of deposit rather than having to trust its own block producers entirely. At the very least a chain's block producers would like to maintain the smallest possible overhead when synchronizing with another blockchain.

The goal of LCV is to enable the generation of relatively light-weight proof of existence that can be validated by anyone tracking a relatively light-weight data set. In this case the objective is to prove that a particular transaction was included in a particular block and that the block is included in the verified history of a particular blockchain.

Bitcoin supports validation of transactions assuming all nodes have access to the full history of block headers which amounts to 4MB of block headers per year. At 10 transactions per second, a valid proof requires about 512 bytes. This works well for a blockchain with a 10 minute block interval, but is no longer "light" for blockchains with a 0.5 second block interval.

The EOS.IO software enables lightweight proofs for anyone who has any irreversible block header after the point in which the transaction was included. Using the hash-linked structure shown it is possible to prove the existence of any transaction with a proof less than 1024 bytes in size.

Given any block id for a block in the blockchain, and the headers a trusted irreversible block. It is possible to prove that the block is included in the blockchain. This proof takes ceil(log2(N)) digests for its path, where N is the number of blocks in the chain. Given a digest method of SHA256, you can prove the existence of any block in a chain which contains 100 million blocks in 864 bytes.

There is little incremental overhead associated with producing blocks with the proper hash-linking to enable these proofs which means there is no reason not to generate blocks this way.

When it comes time to validate proofs on other chains there are a wide variety of time/ space/ bandwidth optimizations that can be made. Tracking all block headers (420 MB/year) will keep proof sizes small. Tracking only recent headers can offer a trade off between minimal long-term storage and proof size. Alternatively, a blockchain can use a lazy evaluation approach where it remembers intermediate hashes of past proofs. New proofs only have to include links to the known sparse tree. The exact approach used will necessarily depend upon the percentage of foreign blocks that include transactions referenced by merkle proof.

After a certain density of interconnectedness, it becomes more efficient to simply have one chain contain the entire block history of another chain and eliminate the need for proofs all together. For performance reasons, it is ideal to minimize the frequency of inter-chain proofs.

Latency of Interchain Communication

When communicating with another outside blockchain, block producers must wait until there is 100% certainty that a transaction has been irreversibly confirmed by the other blockchain before accepting it as a valid input. Using an EOS.IO software-based blockchain and DPOS with 0.5 second blocks and the addition of Byzantine Fault Tolerant irreversibility, this takes approximately 0.5 second. If any chain's block producers do not wait for irreversibility it would be like an exchange crediting a deposit that was later reversed and could impact the validity of the blockchain's consensus. The EOS.IO Software uses both DPOS and aBFT to provide rapid irreversibility.

Proof of Completeness

When using merkle proofs from outside blockchains, there is a significant difference between knowing that all transactions processed are valid and knowing that no transactions have been skipped or omitted. While it is impossible to prove that all of the most recent transactions are known, it is possible to prove that there have been no gaps in the transaction history. The EOS.IO software facilitates this by assigning a sequence number to every Action delivered to every account. A user can use these sequence numbers to prove that all Actions intended for a particular account have been processed and that they were processed in order.

Segregated Witness

The concept of Segregated Witness (SegWit) is that transaction signatures are not relevant after a transaction is immutably included in the blockchain. Once it is immutable the signature data can be pruned and everyone else can still derive the current state. Since signatures represent a large percentage of most transactions, SegWit represents a significant savings in disk usage and syncing time.

This same concept can apply to merkle proofs used for inter-blockchain communication. Once a proof is accepted and irreversibly logged into the blockchain, the 2KB of sha256 hashes used by the proof are no longer necessary to derive the proper blockchain state. In the case of inter-blockchain communication, this savings is 32x greater than the savings on normal signatures.

Another example of SegWit would be for Steem blog posts. Under this model a post would contain only the sha256(blog content) and the blog content would be in the segregated witness data. The block producer would verify that the content exists and has the given hash, but the blog content would not need to be stored in order to recover the current state from the blockchain log. This enables proof that the content was once known without having to store said content forever.

Conclusion

The EOS.IO software is designed from experience with proven concepts and best practices, and represents fundamental advancements in blockchain technology. The software is part of a holistic blueprint for a globally scalable blockchain society in which decentralized applications can be easily deployed and governed.