今年币圈链圈一个重大事件就是：EOS在6月正式发布，但是还有非常多的人从未阅读过EOS技术白皮书。在此我准备做一个通读EOS白皮书系列，主要是翻译官方原文并加入个人解释的形式展现，水平有限，欢迎大家讨论交流。
微信公众号：blockd-public
微信号：点击查看
脚本和虚拟机
EOS.IO软件会成为第一个并且主要的用于协调认证消息（也叫操作）分发的平台。 脚本语言和虚拟机具体实现独立于EOS.IO技术。任何具有确定性且具足够性能的以沙盒形式运行的语言或者虚拟机都可以集成EOS.IO软件接口。
解释：EOS作为平台，要提供通用性，定义标准，不能定义具体实现 方式。
模式定义消息
所有账户之间发送的消息都是通过模式定义的，这个模式也是区块链共识状态的一部分。这个模式允许在二进制和JSON格式之前无缝转换。
模式定义数据库
数据库状态也使用相似的模式定义。这样确保了应用存储的所有消息是某种格式存储，这种格式可以翻译成人类可读的JSON数据格式，而且又以高效的二进制进行存储和操作。
解释：电脑善于处理二进制数据，人类善于处理JSON格式数据。EOS在设计的时候考虑了不同场景下使用数据的行为。
通用多索引数据库API
开发智能合约需要定义一个数据库模式用来跟踪、存储和查找数据。通常开发者需要对同样的数据以多个字段进行排序索引，并且维护索引之间的一致性。
应用程序认证分离
为了最大化并行机会，同时最小化根据交易日志从恢复应用状态的计算债务， EOS.IO 软件把验证逻辑分成三部分：
- 验证消息内部是否具有一致性；
- 验证所有前置条件是否可用；
- 修改应用程序状态。
验证消息的内部一致性是一种只读行为，需要不能访问区块链的状态，这意味着可以最大化并行执行。验证前置条件，例如必须的余额，是一种可只读行为，因此也有利于并行化。只有修改应用程序状态需要写入权限，并且必须每个应用按顺序处理。
身份认证是校验消息可以被应用的一个只读过程。实际上是应用程序就在做这个事情。这两种计算都需要实时处理，然而，一旦有一笔交易打包进区块链就再也不需要进行身份认证操作。
原文如下
Scripts & Virtual Machines
The EOS.IO software will be first and foremost a platform for coordinating the delivery of authenticated messages (called Actions) to accounts. The details of scripting language and virtual machine are implementation specific details that are mostly independent from the design of the EOS.IO technology. Any language or virtual machine that is deterministic and properly sandboxed with sufficient performance can be integrated with the EOS.IO software API.
Schema Defined Actions
All Actions sent between accounts are defined by a schema which is part of the blockchain consensus state. This schema allows seamless conversion between binary and JSON representation of the Actions.
Schema Defined Database
Database state is also defined using a similar schema. This ensures that all data stored by all applications is in a format that can be interpreted as human readable JSON but stored and manipulated with the efficiency of binary.
Generic Multi Index Database API
Developing smart contracts requires a defined database schema to track, store, and find data. Developers commonly need the same data sorted or indexed by multiple fields and to maintain consistency among all the indices.
Separating Authentication from Application
To maximize parallelization opportunities and minimize the computational debt associated with regenerating application state from the transaction log, EOS.IO software separates validation logic into three sections:
- Validating that an Action is internally consistent;
- Validating that all preconditions are valid; and
- Modifying the application state.
Validating the internal consistency of a Action is read-only and requires no access to blockchain state. This means that it can be performed with maximum parallelism. Validating preconditions, such as required balance, is read-only and therefore can also benefit from parallelism. Only modification of application state requires write access and must be processed sequentially for each application.
Authentication is the read-only process of verifying that an Action can be applied. Application is actually doing the work. In real time both calculations are required to be performed, however once a transaction is included in the blockchain it is no longer necessary to perform the authentication operations.