EOS从入门到精通（四）

大家好，非常感谢参加《EOS从入门到精通》系列课程，我是王巨，今天是EOS技术白皮书解读的第四讲。我们来解读EOS白皮书的最后几部分。今天的内容相对于上一节课会简单一些，主要讲EOS的治理，然后简单讲一下虚拟机；跨链通讯部分我会在高级篇重点解读

image.png

image.png

我们先来看治理部分，所谓的治理我的理解就是管理那些没法完全使用软件算法实现的共识。在我们熟悉的区块链产品比特币和以太坊中是没有这部分共识的，这样就造成了一个非常严重的问题，社区经常因为一些原因分裂，导致分叉。2017年比特币已经被分叉无数次了，以太坊也已经出现了数次分叉，而这样的结果就是没有管理好非代码共识所造成的。

EOS认识到区块链的权力来源应该是Token持有人，而不应该是矿工，Token持有人将自己的权力通过投票的方式委托给区块生产者，这样区块生产者就具备了冻结账户、更新有缺陷的应用程序、提出对底层协议硬分叉的改变的权力。当然这种权力是受限的、是被检查的。可以用下面的结论总结这种权力：
所有的区块链变更都需要区块生产者同意，如果区块生产者拒绝Token持有人想要的变更，那么他将被投票出局，如果区块生产者的变更没有经过Token持有人的同意，那么其他非区块生产者的全节点会拒绝该改变。

image.png

一个智能合约可能会出现异常比如说因为bug的原因导致行为不正确或者资源消耗不在一个合理的范围内，在这种情况下区块生产者有权力纠正这种情况，纠正的方式就是冻结账户，冻结账户的概念就是所有与待冻结账户有关的变更都不打包。冻结账户需要21分之17的区块生产者同意才行，如果区块生产者滥用权力，解决方案也很简单，就是将他投票出局，这样被冻结的账户就会被解冻。

image.png

如果冻结账户已经不能解决问题，不可预知的代码已经造成了破坏，此时EOS可以支持在不需要硬分叉的前提下修改账户代码。我的理解这有点类似于交易的回滚。当然与冻结账户类似，也需要21个中的17个区块生产者同意才行。

image.png

这里的宪法不知道翻译的准不准确，我的理解是这样的，智能合约也是要遵循法律法规的，很多事情是没有办法通过代码来进行约束的，同时由于EOS是全球性的，那么合约遵循哪里的法律法规就成了一个问题。这块EOS是怎么做的呢，就是将这些法规数字化，然后进行Hash签名，后面所有交易都要选一个宪法来绑定到合约中，这样就能解决管辖权和法律选择带来的争端。这个理解不一定是对的，因为白皮书上我的感觉也是写的不太清楚。

image.png

EOS还规定了升级协议和宪法的流程，我们可以看一下，如果要对宪法进行修改，需要区块生产者提出，并获得至少17个区块生产者的批准，并且连续30天保持批准，然后所有用户都使用新的宪法hash来签署交易。升级代码协议也是类似的流程。按照EOS的默认配置，添加新特性的升级流程大概需要2-3个月，修复一般bug需要1-2个月。对于出现了严重的有害bug或安全漏洞，区块生产者可能会加快修复，当然这一般来说是违反宪法的。具体如何权衡这个白皮书里面没有讲，我猜这应该需要社区的努力了。治理这部分，对于需要长期稳定运行的区块链产品是非常必要的，如果没有这部分，那么就没法避免分叉带来的危害。EOS在这方面我认为是当前做的最好的。

image.png

image.png

好的我们简单讲一下脚本和虚拟机，我们从上面可以看到，EOS首先给自己的定位是一个平台，用于协调向账户传送已认证的消息。而具体的脚本语言和虚拟机的细节都是特定于实现的细节的，这些细节大多数独立于EOS的技术设计。也就是说，任何具有足够性能的确定性和正确的沙箱化的语言或虚拟机都可以与EOS API集成。

image.png

image.png

模式定义的消息和模式定义的数据库，这两个我们放在一起讲，这两个概念从字面意思上不是很好理解，我的理解是，所有的消息或数据存储其实在实现上是使用二进制的方式发送或存储的，但是为了人类可读，他们都可以被解码成Json字符串。

image.png

分离授权与应用，这段出现在白皮书的这个地方我认为有点怪，我理解这部分应该出现在性能和并行计算部分。不管怎么说我们将这部分再讲一下：

为了最大限度的实现并行计算，并最大限度的减少与事物日志中重新生成应用程序状态相关的计算债务，EOS将验证逻辑分成三部分：1、验证消息是否内部一致；2、验证所有先决条件都是有效的；第三步才是修改应用程序状态。验证消息的内部一致性是只读的，而且不需要访问区块链状态，这意味着它可以以最大的并行度来执行；验证先决条件也是只读的，因此也可以从并行性中受益；修改应用程序状态才需要写权限，并且必须顺序处理每个应该程序。身份认证是一个验证消息可被使用的只读过程。 应用程序实际上在发挥作用。 实时计算时两者都需要被计算，然而一旦消息被包含进区块它就不再需要进行消息验证的操作了。

image.png

我们再来看一下虚拟机独立架构，上面的简介我们说了，理论上只要符合性能、确定性、正确性和沙箱化这几个条件的任何虚拟机都可以跟EOS进行对接，也就是说EOS的架构是独立于虚拟机的，所以叫虚拟机独立机构。白皮书上没有任何虚拟机的技术细节，就讲了两个虚拟机Web Assembly和以太坊虚拟机。Web Assembly是一个新兴的、高性能的虚拟机，它拥有llvm的编译后端，因此理论上可以支持所有支持llvm编译的众多编程语言，包括c和c++等。当前EOS的测试网络仅支持Web Assembly，也仅支持C和C++编程语言开发智能合约。EOS规划中也会支持以太坊虚拟机，以太坊虚拟机其实跟Web Assembly有点像，移植起来比较容易。当然支持以太坊虚拟机的重点不在于技术上的难易程度。试想一下，如果以太坊上的智能合约只要稍作修改就能在EOS上运行，那原来很多在以太坊上的项目就可以比较平滑的迁移到性能更高的EOS上。这对EOS的生态建设会有很大助力，当然以太坊也是一个不小的打击。

image.png

关于跨链通讯，我今天不准备跟大家讲细节，白皮书上的内容其实远远不够，只是跟大家同步一下，通过Merkle证明可以实现轻量级客户端，并且还能比较容易的实现跨链通讯。我会在高级篇重点讲解跨链通讯技术。

好了今天就讲到这里，经过四节课程我们终于将EOS的白皮书讲完了，非常感谢大家的参与。关于EOS白皮书的任何问题大家都可以提问了，我会挑选我能回答的问题回答。

---

作者：王巨
链接：https://www.jianshu.com/p/3bd18bad8049
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。