在看本文前,最好先了解区块链相关概念:比特币,以太坊,钱包,智能合约,秘钥等
本节将EOS技术白皮书第7节【治理】、第8节【脚本和虚拟机】一起学习,对照前面的文章配合学习,有助于更好的理解EOS。
EOS 是为商用分布式应用设计的一款区块链操作系统,以后EOS上会有很多应用,应用多了难免会有许多不可预见的问题,而这些问题不可能完全在系统软件层面被解决。所以,在遇到这方面问题的时候,EOS提前做好了解决方案。而目前存在的区块链产品没有这部分解决方案,例如我们熟悉的比特币和以太坊,因为没有这样的解决方案,社区经常因为一些原因分裂,导致分叉。2017年比特币已经被分叉无数次了,以太坊也已经出现了数次分叉,而这样的结果就是没有考虑到那些在软件层面之外的问题所造成的。
下面我们来学习下EOS是怎么做的?
EOS认识到,治理的权力应该给Token持有者,而不应该是区块生成者。所以EOS的做法是,Token持有者可以将自己的权利代理给区块生成者,这样区块的生成者就有了相应的权限(冻结账户、更新有缺陷的应用程序、提出对底层协议硬分叉的改变等)。当然权限代理出去后,并不是说区块生成者就可以随便乱用权限,那些权限是受限的、被监督、被检查的。 可以用下面的结论总结这种权力: 所有的区块链变更都需要区块生产者同意,如果区块生产者拒绝Token持有人想要的变更,那么他将被投票出局,如果区块生产者的变更没有经过Token持有人的同意,那么其他非区块生产者的全节点会拒绝该改变。
什么情况下需要冻结账户? 一个智能合约可能会出现异常,比如说因为bug的原因导致行为不正确或者资源消耗不在一个合理的范围内,这时候区块生产者就有权力冻结账户,冻结后这个账户所作的行为就没用了。当然也不是随便就能冻结,冻结账户需要21分之17的区块生产者同意才行,如果区块生产者滥用权力,解决方案也很简单,就是将他投票出局,这样被冻结的账户就会被解冻。
如果“冻结账户”已经不能解决问题,不可预知的代码(病毒)已经造成了破坏,此时EOS可以支持在不需要硬分叉的前提下修改账户代码。这有点类似于交易的回滚。当然与冻结账户类似,也需要21个中的17个区块生产者同意才行。
EOS操作系统可以用区块链技术在签名用户之间建立P2P服务协议或约束性合约,也就是所谓的“宪法”。宪法内容定义了仅依靠代码无法完全执行的用户间义务,同时结合相互间的公认规则,确立司法权和适用法律。每一个在网络中签名广播的交易,其签名信息中必须包含宪法的哈希值,以明确约束合约签名者。
关于这一块,也是为了解决当遇到代码无法解决的关于法律法规的问题时的做法。因为EOS是全球性的,每个国家都有不同的法律,那么在EOS上的软件或智能合约就需要遵循当地的法律。EOS把那些法律条款记录在哈希值里,当用户执行某些智能合约的时候,必须选择一个法律条款,通过这样的方式来约束合约签名者。
我们都知道“宪法”会随着当地环境的变化而变化,所以EOS也提供了修改的方法。 EOS操作系统使用源代码定义宪法和协议,同时也定义了宪法及协议的更新方法。对宪法或协议进行变更,需要完成以下步骤:
1.区块生产者(译注:miner/delegate/witness,因此没有译作矿工)提交一个宪法变更动议,并获得17/21以上的赞成票; 2.区块生产者将17/21以上的赞成票维持连续30天; 3.要求所有用户都使用新宪法的哈希值确认交易; 4.区块生产者采用修改源代码的方式反映宪法变更,使用git提交的哈希值将变更提交到区块链上; 5.区块生产者继续将17/21以上的赞成票维持连续30天; 6.变更的代码7天后生效,源代码修改通过后,将有1周的时间来对所有节点的进行升级; 7.所有没有升级为新代码的节点将自动关闭。
根据EOS操作系统的默认配置,更新区块链来添加新功能这一进程需要2到3个月时间,而修复那些不需要更改宪法的非关键性漏洞需要1到2个月时间。 一般情况下变更所花费的时间比较久,当遇到特殊情况的时候,EOS也提供了解决方案。
面临一个损害用户利益的有害漏洞或安全漏洞时,区块生产者可以加速宪法变更过程。一般来说,加速新特性更新过程或修复无害漏洞,都是违反宪法的行为。
本节是EOS技术白皮书第8节,主要讲第三方开发者基于EOS系统的开发机制,相关脚本和虚拟机。
1.EOS操作系统将首先作为一个传递账户间已认证信息的平台 2.脚本语言和虚拟机的实现将独立于EOS操作系统技术 3.任何开发语言或虚拟机,只要有适当的、性能足够的沙箱,都可以通过API与EOS集成在一起。
上面说“只要有适当的、性能足够的沙箱,都可以通过API与EOS集成在一起”,这就有点像我们常用的短信接口,微信接口一样的。例如要在微信上开发小程序,就需要遵循微信提供的接口,开发好后就可以在微信上运行了。
模式定义的消息
在账户之间发送的所有消息都是由区块链共识状态的一个模式定义的,该架构允许消息在二进制和JSON格式之间的无缝转换。
账户和账户之间发送消息使用的是二进制的方式发送,这样更高效和易操作性,但是二进制人类是看不懂的,所以EOS支持数据可以转化为Json格式的字符串,这样我们就看的懂了。
模式定义的数据库
数据库状态也使用类似的模式定义,这确保所有应用程序存储的数据都以一种格式呈现,同时具备JSON的人类可读性,以及二进制格式的高效率存储和易操作性。
这点和上面相同,使用二进制存储数据,但是支持转换成json格式,供人类理解。
将身份验证与应用程序分离
为了最大化并行运算,为了将(从程序日志中重新生成应用程序状态的)计算任务降至最低。 EOS操作系统将验证逻辑分为三个部分: 1.确认消息在内部是一致的; 2.确认所有的前置条件都是有效的; 3.修改应用程序状态。 验证消息的内部一致性是只读的,不需要访问区块链状态,这意味着它可以最大化并行运算来执行。验证前置条件(例如需求平衡)也是只读的,因此也可以从并行运算中获益。只有对应用程序状态进行修改才需要写访问,并且需要按顺序对每个应用程序进行处理。 身份验证是验证消息是否可以应用的只读过程,应用程序实际上就是在做这项工作。实时的计算都需要执行,但交易一旦被包含在区块链中,就不再需要执行身份验证操作了。
这里和之前学过的“应用程序的确定性并执行”讲的内容相似,可以回顾之前的内容进行理解。
虚拟机独立架构
EOS操作系统软件的目的是可以支持多种虚拟机,同时可以随着时间推移持续按需求增加新的虚拟机。出于这个原因,本文不会讨论任何特定语言或虚拟机的细节,但即便如此,目前也已经有三种虚拟机正在评估接入EOS系统。
这应该和window上vm虚拟机差不多吧,意思就是在EOS这个系统中可以安装其他系统,这个其他系统就是在虚拟机上运行的。
Wren
Wren(http://wren.io)是一种小型的、快速的、基于类别的编程语言。Wren的开发人员将其描述为“就像是把小型tak文件装进lua大小的软件包,再加上一点Erlang特性,再包进一个熟悉的、现代的语法里面”。之所以选择Wren语言和虚拟机,是因为它的短小精悍、易于文档记录和理解的代码库。它还具有非常好的性能,并且可以很容易地嵌入C++应用程序中。
Web Assembly【web 组件】(WASM)
WASM是构建高性能Web应用程序的新兴Web标准,通过少量适配就可以被明确定义和沙箱化。WASM的好处在于业界广泛支持,因此可以用熟悉的语言开发开发智能合约,例如C或C++。
以太发人员已经开始适配WASM,以提供适当的沙箱并使用以太坊WASM定义(https://github.com/ewasm/design)。这种方法很容易改编后用于EOS系统软件集成。
以太虚拟机(EVM)
这个虚拟机已经被用于大多数现有的智能合约,并且可以在EOS系统区块链上使用。可以想象,在EOS操作系统区块链上,EVM合约可以在内部沙箱中运行,只需要少量适配就可以与其他EOS应用程序交互。
配合学习笔记系列文章一起读会更好理解哦 本文首发于微信公众号:lin-mingtan 欢迎关注交流 ^.^
本文为林明潭原创文章,转载无需和我联系,但请注明来自林明潭的博客blog.umaske.com
最新评论