EOS.IO

权威资料

1. 共识算法 (DPOS)
2. 帐户
3. 应用程序的确定性并行执行
4. Token 模型与资源使用
5. 治理 (治理是人们在主观问题上达成共识的过程，而这无法完全用软件算法来捕获。)
6. 脚本 & 虚拟机
   EOS.IO 首先会是一个平台用于协同用户间认证消息的传递。 脚本语言和虚拟机的具体实现与 EOS.IO 技术的设计是分离的。 任何语言或者虚拟主机，只要确定并适合沙盒，带有足够的运行效率均可以和 EOS.IO 软件 API 对接。
7. 跨链通信

与ethereum的比较

一些点

EOS代币的所有者给予用户按比例的网络带宽、存储空间、和运算能力。

到底是怎样做到的。

EOS如何做到并行

区块链共识取决于确定性 (可重现的) 的行为。 这意味着所有的并行计算必须是不能互斥或者具有其他锁特性的。 没有了锁就必须有一些方式可以确保所有的帐户只可以读取和写入他们自己的私有数据库。 这也意味着每个帐户处理消息是顺序的，而并发只能在帐户层面进行。

In an EOS.IO software-based blockchain, it is the job of the block producer to organize message delivery into independent threads so that they can be evaluated in parallel. 每个帐户的状态由且只由发送给它的消息决定。 进度表由区块生产者输出并且会被确定性的执行，但是生成进度表的过程却不一定是确定性的。 这意味着区块生产者可以使用并发算法来调度交易。

并行执行的一方面意味着当一个脚本生成了一个新的消息，它不会立即被发送，而被安排在下一个轮训中发送。 不能立马发出的原因是接受者可能在另一个线程中活跃的变更自己的状态。

虚拟机独立架构

It is the intention of the EOS.IO software-based blockchain that multiple virtual machines can be supported and new virtual machines added over time as necessary. 因此，本文并不讨论任何特定的语言或者虚拟机。 That said, there are two virtual machines that are currently being evaluated for use with an EOS.IO software-based blockchain.

Web 组建 (WASM) ?

网络组建是一种为了构建高性能的 web 应用而新兴的 web 标准。 只需要进行少量的更改 Web 组建就可以被制作为确定性的和沙盒化的。 Web 组建的好处是它有着广泛的产业支持并且它可以让智能合约使用熟知的语言进行开发，比如 C 或 C++。

以太访开发者已经开始更改 Web 组建来提供合适的沙盒与确定性在他们的以太访式 Web 组建 (WASM)。 这种方式让 EOS.IO 很容易的与之适配和对接。

以太访虚拟机 (EVM)

这个虚拟机已经被众多已有的智能合约所采用并且可以通过适配应用与 EOS.IO 区块链中。 It is conceivable that EVM contracts could be run within their own sandbox inside an EOS.IO software-based blockchain and that with some adaptation EVM contracts could communicate with other EOS.IO software blockchain applications.

用于轻客户端的 Merkle 证明 (LCV) ?

如果客户端不需要处理所有的交易会让多区块链间的整合更为轻松。 毕竟，一个交易所只需要关心交易所的入账和出账，别无他求。 如果交易所链条可以使用资金的轻量 merkle 证明，而不必非要完全依赖对它区块生产者的信任会是一个不错的主意。 至少一个链的区块生产者在与其他区块链同步时更乐意保持尽可能小的开销。

LCV 的目标能产生相对轻量存在性证明，使得任何追踪相对轻量数据集的人可以验证其有效性。 在这种情况下，目的是为了证明一个特定的交易是包含在一个特定的区块中，区块包含在一个特定的区块链的已验证历史中。

比特币支持通过全节点的完整记录获取每年 4MB 大小的区块头信息来验证交易。 每秒 10 个交易，一个有效的证明需要 512 个字节。 这对于有 10 分钟间隔的区块链没有问题，但是对于 3 秒间隔区块链就显得不那么“轻量”了。

EOS.IO 软件使得任何一个人只要他拥有包含交易所对应区块之后的随意一个不可逆的区块头，他就可以进行轻量证明。 使用下面展示的哈希链结构就可以使用少于 1024 字节的大小来完成任意交易的存在性证明。 如果假设校验节点在过去几天内所有的区块头一直增长 (2MB 的数据)，那么验证这些交易将只需要 200 字节就够了。

将生产的区块与恰当的哈希链做关联使得开销增幅很小，这意味着没有理由不使用这种方式来生成区块。

当需要验证其他链时，有譬如 时间/ 空间/ 带宽 的多样化优化可以做。 追踪全部区块头 (420 MB/年) 将保持证明体积的轻巧。 只追踪最近的头可以提供最小长期存储和证明大小来获得。 另外，一个区块链可以使用懒惰的评估方法，即它记住过去证明的中间值哈希。 新证明只需要包含指向已知稀疏树的链接。 确切的方法将取决于那些包含对 Merkle 证明引用的交易所在的外部区块的比例。

一定密度的联系后，将变得更为高效，一个链会包含另一个链整个区块的历史和消除证据一起，这样就不需要通信便可以验证了。 出于性能原因，应最小化的跨链证明的频率。

将身份验证与应用程序分离

为降低资源消耗，EOS操作系统将身份验证和应用程序进行分离，验证逻辑分为三个阶段:
1.确认消息在内部是一致的;内部一致就无需访问区块链状态，对外就是只读的。可以并行进行。
2.确认所有的前置条件都是有效的;同样前置条件也是只读的，也可以并行。
3.修改应用程序状态。这里就是写入操作，串行对每个程序进行处理。
交易进入区块之前是需要身份验证的，但交易一旦被包含在区块链中，就不再需要执行身份验证操作了。

DPOS 如何做自治的管理，我认为有两层，一层是协议层面的治理，比如进化和改变一致性算法，一层是应用层面的治理，比如应用有bug，我们需要回滚，你可以帮我们探讨下这两层的自治么?

第一层实际上是软件层面的宪法，是有所有的节点上跑的软件决定的。持票者选择区块生产者，决定什么时间去硬分叉。EOS是不会有硬分叉的，当整个网络决定是升级的时候，那些节点不知道怎么去做升级的会被自动关闭。而区块的生产者，也会等到升级后再生产区块，所以即使在你升级的时候，你也不会错失任何一个区块。steem 过去每个月都会有一个大的升级，过去大概进行了18次升级，没有一次会有硬分叉。EOS的一条哲学是，事物需要改变，最适者生存，而不是最强者生存。这也是自由市场的原则，长期来看，如果你不改变，那你就会被淘汰。所以eos被设计为一条可以持续不停进化的链。 这就是第一层的治理。

对于第二层治理，比如开发者开发了一个DAO，那里有一个bug，所有的资金都被偷走了，发行者拥有在没有硬分叉的前提下，升级合约的权利。区块生产者，有审查区块的权利。完美的代码是不可能的，Bug始终会发生，这是EOS认识到的，而其他的平台可能没有意识到的一个问题。即使代码被安全运行了多年，里面还是可能有隐藏的bug。之前一段时间，bts就有这样的一个隐藏bug，非常微妙的情况下，会把所有的生产者给冻结。我们都依赖的SSL，所有的电脑都在用，实际上也是有不安全的问题。代码不是完美的，我们需要有恢复的手段，我们围绕这点做设计。这种方式允许开发者，自己去建立自己的治理层，他们可以创建投票为是否可以更新代码。在其他的一些区块链上，身份和财产是分离的，拥有私钥这个身份，即使你通过hack电脑获得了私钥，并不意味着，你就真的是这个财产的所有人。身份和财产权，是系统想要去保护的，期望完整符合法律，而不是9/10的复合法律。

更多

1. https://www.jianshu.com/p/bc489db794ce