EOS新闻动态

EOS新闻动态

EOS简介,新闻动态更新
EOS技术讨论

EOS技术讨论

EOS, Bitshares, steem, Graphene技术分析
EOS众筹价格

EOS众筹价格

EOS众筹模式,价格讨论
EOS其他相关

EOS其他相关

其他的关于EOS的问题和话题都在这

EOS从入门到精通(四)

EOS代码分析郑浩 发表了文章 • 0 个评论 • 1409 次浏览 • 2018-01-12 16:10 • 来自相关话题

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










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

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






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






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






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







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











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











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





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

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






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






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

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

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35
  查看全部
原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第四讲。我们来解读EOS白皮书的最后几部分。今天的内容相对于上一节课会简单一些,主要讲EOS的治理,然后简单讲一下虚拟机;跨链通讯部分我会在高级篇重点解读

3115234-6f776e9f780e9285.png


3115234-81c9f05e9049d3ab.png

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

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

3115234-d2bbbd3500190a2a.png


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


3115234-9e0abb9646ca336b.png

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

3115234-939008ee4f884a92.png


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


3115234-72ac8cb7fb2b04d9.png


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


3115234-9ef86e822dabde3d.png


3115234-ce873ccd46052a34.png

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


3115234-727433ad6ec22863.png


3115234-258872573c957ff0.png

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

3115234-8a385993dabea285.png

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

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

3115234-94c8f5eaacc9654b.png


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


3115234-0e13e33a25c423bf.png

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

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

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35
 

EOS从入门到精通(三)

EOS代码分析郑浩 发表了文章 • 0 个评论 • 1993 次浏览 • 2018-01-12 15:52 • 来自相关话题

原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第三讲。今天我们来解读EOS白皮书中的“应用程序的确定性并行”和“Token模型与资源使用”:下面是这两章节的思维导图:










我们先来讲解一下应用程序的确定性并行,这部分在入门篇我们不做重点解读,因为这里面涉及到了很多编程方面的知识,我在这里只跟大家做一下同步,让大家对EOS的高性能有一些感性的认识。





好,我们开始应用程序确定性并行这个章节的解读:该部分从简介、最小化的通讯延迟、只读消息处理、多账户的原子交易、区块链状态的部分评估、自主最优调度这几个方面跟大家讲解EOS并行执行的原理。





我们知道区块链最简单的理解是一个公共的账本,而维护账本共识的核心基础就是行为的确定性,这意味着如果需要并行计算,那么所有的并行计算都不能互斥或加锁,因为锁的状态是不确定的。不加锁,就需要一些方法来保证所有账户只能读写自己的私有数据库。这样每个账户都必须顺序的处理消息,因此EOS的并行级别是账户级别的。

EOS将消息传递 组织成独立的线程,这样可以比较容易的评估线程并行的可能性,因为每个账户的状态只取决于传递给他们的消息。进度表,我这里理解成消息的执行顺序,这个顺序在区块产生后是确定的,而在产生过程中是不确定的,是由区块生产者按照并行算法决定。比如说区块生产者A生产区块,那么消息执行顺序就由A来决定,A产生区块后,生产者B验证区块时要完全按照A的执行顺序来验证。

当脚本产生一个消息后不会被立即传送,而是会被安排到下一个循环,因为接收方当前可能在另一个线程内主动修改自己的状态。







最小通讯延迟,这里的延迟,是指一个账户向另一个账号发送消息并接收响应所需要的时间,EOS的设计目标是能够在一个区块内来回交换消息,那么EOS是如何做到的呢?EOS将区块分成了几个循环,循环又分成了多个线程,每个线程包含一个交易列表,每个交易包含一组要传递的消息。这个结构可以看成为一棵树,在这个树中交替的层被顺序的并行的处理,我们看下面这张图






可以看到,循环是顺序执行的,线程是可以并行的,交易和消息是要顺执行的,而接受者和被通知的账户是可以并行的。为什么接受者这个地方是可以并行呢?这要看一下下面的只读消息处理





只读消息的处理,EOS对于无需更新状态的消息处理是可以并行的,只要特定的只读消息处理程序被包含在特定的循环内的一个或多个线程中就可以。






我们再来看一下多账户的原子交易。有些时候需要确保消息以原子的方式传递给多个账户并需要被其接受。在这种情况下双边的消息会被放在同一个交易中,两边的账户也会被分配在相同的线程,并且消息会被顺序的处理。这样做的目的是为了确保交易成功,而这其实会带来性能上的损耗,而且在成本上也会很高,因此出于性能和成本的考虑,应用程序最好能尽力减少涉及两个或更多使用率高的账户的原子操作。







区块链状态的部分评估,我简单说一下我的理解,不同于以太坊所有的全节点都必须运行所有的合约,EOS具备这种允许完整节点选择要运行的任何程序子集的能力,这样带来一个好处就是如果我仅仅运行一个小应用,那么我可以使用有限资源启动完整节点,比如一个交易所的开发人员运行完整节点,以便向用户展示交易状态,这个程序是不需要与社交媒体的程序有状态关联的。






自主最优调度,我的理解是EOS设计了这样一个调度框架,每个区块生产者都可以根据自己的算法来进行区块的生产。EOS不强制区块生产者将任何消息发送给任何其他账户,每个区块生产者都可以根据处理交易所需的计算复杂性和时间做出自己的主观预测。

在网络层面上,所有的交易都会收取一个固定的计算带宽成本,区块生产者也可以使用自己的算法来测量资源的使用。这里的计算带宽,我的理解应该是广义的,可能包含计算资源,状态存储资源以及网络带宽。

一般情况下只要一个区块生产者认为交易在资源使用的限度内是有效的,那么所有的其他区块生产者也会接受,但是交易可能需要最长1分钟才能找到生产者,为什么是一分钟,因为一分钟内交易可以在21个区块生产者之间流转一遍,如果还没有找到,那么这个交易就不会被打包了。






好了,关于程序确定性和并行执行就讲到这里,我们来看一下TOKEN模型和资源使用。主要从简介、客观与主管的衡量、付费策略、委托能力、分离交易成本与Token的价值、状态存储成本、区块奖励和社区利益应用这几个方面解读。





所有的区块链资源都是有限的,需要系统的防止被滥用,比特币和以太坊是用手续费和Gas来防止资源被无限使用的,那么EOS是怎么防止资源被滥用的呢?

我们先看一下EOS提供的资源有哪些,主要有存储和带宽资源、计算和计算Backlog以及状态存储。先解释一下计算Backlog是什么,可以翻译成计算积压,我的理解是这样的,比如说一个完整节点断网一段时间,等重新联网后需要重新同步未同步的区块,然后对这些新的区块进行重新验算,我理解这些计算任务就叫计算Backlog。

区块生产者发布他们的带宽、计算资源和状态存储资源、每个用户对资源的使用率跟Token持有的比例成正比。持有1%的Token的账户可以使用1%的状态存储资源。

带宽和计算资源由于是瞬时资源没法保存,因此采用的策略是在保留的基础上进行分配,算法类似于Steamit限制带宽的算法,有点像QoS算法。举例来说:假如你持有1%的Token,那么在瞬时资源的使用上,你最少可以使用到1%,如果系统比较空闲,那么你可以使用的更多,如果系统非常繁忙,那么系统至少可以保证有1%的资源是专门给你提供的。






所有的资源使用约束最终都是主观的,由区块生产者根据各自的算法和估计来执行,EOS允许使用客观的根据消息或存储容量来衡量消耗,也可以自己定义主观的衡量算法。我的理解是,EOS给了一个推荐的简单算法,至于区块生产者要不要使用,由他们自己决定。这在EOS上都是允许的。





付费策略,这个我们也早就提过了,应用不能强制用户为使用区块链资源而付费,同样的EOS也不会强制应用的收费策略。






委托能力,我们知道,持有EOS的人不一定是应用开发者,可能不会立即使用链上资源,那么这些人就可以向其他用户提供或出租这些带宽,EOS允许这样做,同时区块生产者能够识别这样的授权,并相应的分配带宽。通过这个设计,将来EOS的持有者通过出租EOS可能就能带来持续的盈利。这就是为什么有人将EOS比作地皮的原因。






分离交易成本与Token的价值,这点非常重要,它的优点就是应用程序的可用带宽仅取决于Token的持有量跟Token的价格没有关系,只要持有一定数量的Token,就可以在固定的状态和带宽使用的情况下永久的用下去。开发者和用户不受Token市值波动的影响。这点是比特币和以太坊做不到的。

EOS区块链使区块生产者能够自然地增加每个Token可用的带宽,计算和存储,而不管Token的价值如何。EOS区块链每次产生区块时都会授予区块生产者Token。Token的价值将影响生产者能够购买的带宽,存储和计算量;这个模型自然会利用上升的Token价值来提高网络性能。






虽然可以委托带宽和计算资源,但应用程序状态的存储将要求开发人员持有Token,直到该状态被删除。如果状态从未被删除,则Token被有效地从流通中移除。每个账户都需要一定的存储空间,因此每个账户都必须保持最低的余额,随着网络存储容量的增加,这个最低要求的平衡将会下降。





块奖励,由所有区块生产上公布的期望收益的中位数决定,EOS可能会配置区块生产者的奖励执行上限,使得Token的供应的年度增长在5%以内。

关于社区利益应用这个章节,说实话我没太看明白,英文和翻译过来的中文都没太理解,这里就不给大家讲了,以免传递错误的信息,好在这个部分看起来不是非常重要。如果有了解的同学可以发消息说一下。

好了,今天的主要内容就讲到这里,总结一下,我们今天讲了两部分内容,并行执行和Token模型与资源使用。重点在Token模型与资源使用的理解上。理解了这个才能明白EOS Token本身的价值所在。我在前段时间写过专门写过一小篇文章介绍EOS的经济系统,可以给大家分享一下。地址是:EOS经济系统分析

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35 查看全部
原文地址大家好,非常感谢参加《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第三讲。今天我们来解读EOS白皮书中的“应用程序的确定性并行”和“Token模型与资源使用”:下面是这两章节的思维导图:

3115234-e2de29b9edfca842.png


3115234-6a8cd6a8a2254d5d.png

我们先来讲解一下应用程序的确定性并行,这部分在入门篇我们不做重点解读,因为这里面涉及到了很多编程方面的知识,我在这里只跟大家做一下同步,让大家对EOS的高性能有一些感性的认识。

3115234-90a06ff3c2fa810e.jpeg

好,我们开始应用程序确定性并行这个章节的解读:该部分从简介、最小化的通讯延迟、只读消息处理、多账户的原子交易、区块链状态的部分评估、自主最优调度这几个方面跟大家讲解EOS并行执行的原理。

3115234-d16b3737cd4b4f70.jpeg

我们知道区块链最简单的理解是一个公共的账本,而维护账本共识的核心基础就是行为的确定性,这意味着如果需要并行计算,那么所有的并行计算都不能互斥或加锁,因为锁的状态是不确定的。不加锁,就需要一些方法来保证所有账户只能读写自己的私有数据库。这样每个账户都必须顺序的处理消息,因此EOS的并行级别是账户级别的。

EOS将消息传递 组织成独立的线程,这样可以比较容易的评估线程并行的可能性,因为每个账户的状态只取决于传递给他们的消息。进度表,我这里理解成消息的执行顺序,这个顺序在区块产生后是确定的,而在产生过程中是不确定的,是由区块生产者按照并行算法决定。比如说区块生产者A生产区块,那么消息执行顺序就由A来决定,A产生区块后,生产者B验证区块时要完全按照A的执行顺序来验证。

当脚本产生一个消息后不会被立即传送,而是会被安排到下一个循环,因为接收方当前可能在另一个线程内主动修改自己的状态。


3115234-92a0e2bb8de68a3d.jpeg


最小通讯延迟,这里的延迟,是指一个账户向另一个账号发送消息并接收响应所需要的时间,EOS的设计目标是能够在一个区块内来回交换消息,那么EOS是如何做到的呢?EOS将区块分成了几个循环,循环又分成了多个线程,每个线程包含一个交易列表,每个交易包含一组要传递的消息。这个结构可以看成为一棵树,在这个树中交替的层被顺序的并行的处理,我们看下面这张图


3115234-907334d8b97f0840.png

可以看到,循环是顺序执行的,线程是可以并行的,交易和消息是要顺执行的,而接受者和被通知的账户是可以并行的。为什么接受者这个地方是可以并行呢?这要看一下下面的只读消息处理

3115234-e3fc42125b6c55a2.jpeg

只读消息的处理,EOS对于无需更新状态的消息处理是可以并行的,只要特定的只读消息处理程序被包含在特定的循环内的一个或多个线程中就可以。

3115234-e7123f9ef376c2d2.jpeg


我们再来看一下多账户的原子交易。有些时候需要确保消息以原子的方式传递给多个账户并需要被其接受。在这种情况下双边的消息会被放在同一个交易中,两边的账户也会被分配在相同的线程,并且消息会被顺序的处理。这样做的目的是为了确保交易成功,而这其实会带来性能上的损耗,而且在成本上也会很高,因此出于性能和成本的考虑,应用程序最好能尽力减少涉及两个或更多使用率高的账户的原子操作。


3115234-969a8c63c4c4cfd9.jpeg


区块链状态的部分评估,我简单说一下我的理解,不同于以太坊所有的全节点都必须运行所有的合约,EOS具备这种允许完整节点选择要运行的任何程序子集的能力,这样带来一个好处就是如果我仅仅运行一个小应用,那么我可以使用有限资源启动完整节点,比如一个交易所的开发人员运行完整节点,以便向用户展示交易状态,这个程序是不需要与社交媒体的程序有状态关联的。


3115234-432e599677e0e9e4.jpeg

自主最优调度,我的理解是EOS设计了这样一个调度框架,每个区块生产者都可以根据自己的算法来进行区块的生产。EOS不强制区块生产者将任何消息发送给任何其他账户,每个区块生产者都可以根据处理交易所需的计算复杂性和时间做出自己的主观预测。

在网络层面上,所有的交易都会收取一个固定的计算带宽成本,区块生产者也可以使用自己的算法来测量资源的使用。这里的计算带宽,我的理解应该是广义的,可能包含计算资源,状态存储资源以及网络带宽。

一般情况下只要一个区块生产者认为交易在资源使用的限度内是有效的,那么所有的其他区块生产者也会接受,但是交易可能需要最长1分钟才能找到生产者,为什么是一分钟,因为一分钟内交易可以在21个区块生产者之间流转一遍,如果还没有找到,那么这个交易就不会被打包了。


3115234-922ffc6c696e7ead.jpeg

好了,关于程序确定性和并行执行就讲到这里,我们来看一下TOKEN模型和资源使用。主要从简介、客观与主管的衡量、付费策略、委托能力、分离交易成本与Token的价值、状态存储成本、区块奖励和社区利益应用这几个方面解读。

3115234-952e0b50986021ae.jpeg

所有的区块链资源都是有限的,需要系统的防止被滥用,比特币和以太坊是用手续费和Gas来防止资源被无限使用的,那么EOS是怎么防止资源被滥用的呢?

我们先看一下EOS提供的资源有哪些,主要有存储和带宽资源、计算和计算Backlog以及状态存储。先解释一下计算Backlog是什么,可以翻译成计算积压,我的理解是这样的,比如说一个完整节点断网一段时间,等重新联网后需要重新同步未同步的区块,然后对这些新的区块进行重新验算,我理解这些计算任务就叫计算Backlog。

区块生产者发布他们的带宽、计算资源和状态存储资源、每个用户对资源的使用率跟Token持有的比例成正比。持有1%的Token的账户可以使用1%的状态存储资源。

带宽和计算资源由于是瞬时资源没法保存,因此采用的策略是在保留的基础上进行分配,算法类似于Steamit限制带宽的算法,有点像QoS算法。举例来说:假如你持有1%的Token,那么在瞬时资源的使用上,你最少可以使用到1%,如果系统比较空闲,那么你可以使用的更多,如果系统非常繁忙,那么系统至少可以保证有1%的资源是专门给你提供的。


3115234-18833c0d2e58223e.jpeg

所有的资源使用约束最终都是主观的,由区块生产者根据各自的算法和估计来执行,EOS允许使用客观的根据消息或存储容量来衡量消耗,也可以自己定义主观的衡量算法。我的理解是,EOS给了一个推荐的简单算法,至于区块生产者要不要使用,由他们自己决定。这在EOS上都是允许的。

3115234-c95b1066a4c4ce43.jpeg

付费策略,这个我们也早就提过了,应用不能强制用户为使用区块链资源而付费,同样的EOS也不会强制应用的收费策略。

3115234-4719dbbd50abd0fc.jpeg


委托能力,我们知道,持有EOS的人不一定是应用开发者,可能不会立即使用链上资源,那么这些人就可以向其他用户提供或出租这些带宽,EOS允许这样做,同时区块生产者能够识别这样的授权,并相应的分配带宽。通过这个设计,将来EOS的持有者通过出租EOS可能就能带来持续的盈利。这就是为什么有人将EOS比作地皮的原因。


3115234-ee6d56fb81761dba.jpeg

分离交易成本与Token的价值,这点非常重要,它的优点就是应用程序的可用带宽仅取决于Token的持有量跟Token的价格没有关系,只要持有一定数量的Token,就可以在固定的状态和带宽使用的情况下永久的用下去。开发者和用户不受Token市值波动的影响。这点是比特币和以太坊做不到的。

EOS区块链使区块生产者能够自然地增加每个Token可用的带宽,计算和存储,而不管Token的价值如何。EOS区块链每次产生区块时都会授予区块生产者Token。Token的价值将影响生产者能够购买的带宽,存储和计算量;这个模型自然会利用上升的Token价值来提高网络性能。


3115234-d691d8cfcc9eb11e.jpeg

虽然可以委托带宽和计算资源,但应用程序状态的存储将要求开发人员持有Token,直到该状态被删除。如果状态从未被删除,则Token被有效地从流通中移除。每个账户都需要一定的存储空间,因此每个账户都必须保持最低的余额,随着网络存储容量的增加,这个最低要求的平衡将会下降。

3115234-a58eff9b0e097704.jpeg

块奖励,由所有区块生产上公布的期望收益的中位数决定,EOS可能会配置区块生产者的奖励执行上限,使得Token的供应的年度增长在5%以内。

关于社区利益应用这个章节,说实话我没太看明白,英文和翻译过来的中文都没太理解,这里就不给大家讲了,以免传递错误的信息,好在这个部分看起来不是非常重要。如果有了解的同学可以发消息说一下。

好了,今天的主要内容就讲到这里,总结一下,我们今天讲了两部分内容,并行执行和Token模型与资源使用。重点在Token模型与资源使用的理解上。理解了这个才能明白EOS Token本身的价值所在。我在前段时间写过专门写过一小篇文章介绍EOS的经济系统,可以给大家分享一下。地址是:EOS经济系统分析

EOS破70了,有打赏EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35

EOS是什么?

默认分类Fs_purple 回复了问题 • 3 人关注 • 2 个回复 • 854 次浏览 • 2018-01-06 16:38 • 来自相关话题

EOS存储系统介绍

EOS代码分析郑浩 发表了文章 • 0 个评论 • 1021 次浏览 • 2017-12-27 20:57 • 来自相关话题

EOS简介


近期 EOS 的团队发布了EOS存储部分的白皮书。根据白皮书上的内容我们可以了解EOS存储部分的设计理念。

首先EOS存储基于IPFS(星际文件系统)之上设计的;

其次不同与一些去中心化的存储方案需要特殊的工具或特殊的浏览器,EOS存储可以提供任意浏览器访问的能力;

EOS存储使用基于EOS发行的token TOK激励区块生产这保证存储的可访问性和带宽。

下面我们详细说一下EOS具体的设计细节
 
IPFS

IPFS是一种去中心化的文件系统,它将文件名和文件内容强关联起来(文件名是文件内容的hash)。也就是说在任意终端上,相同文件内容的文件其名称也一定相同。当你下载一个文件的时候可以通过文件名来校验文件的完整性。IPFS提供了一个p2p的网络传输层用于终端之间基于文件名称发现和分享文件。但是IPFS并不提供和保证文件的存储、托管和带宽。也就是说即使能有文件名,但是有可能找不到对应的文件内容。IPFS团队为了解决这个问题,发布了FileCoin区块链,使用区块链的支付系统来激励拥有剩余存储空间的人帮助提供稳定可靠文件的存储、托管和带宽(具体规则我没有深入研究,按照白皮书上讲的,FileCoin 应该跟 Maidsafe, Siacoin, 和 Storj类似)。

EOS对存储的需求

作为一个可以任意运行智能合约的平台,EOS设计性能需要达到百万级。这个这样的设计如果每秒进行100w次交易,每次交易产生100字节的数据,那么每秒钟就有100M的数据记录。如果每个区块生产节点都要存储一份这样的数据,那时间稍久数据量就是一个天文数字。另外,对于一些智能合约他们天然就有存储数据的需要,比如需要存储文字、图片、声音、视频等等数据。这些数据更不可能存储在区块链上了。

EOS存储的设计

按照EOS的需求,那IPFS+FileCoin是不是就解决了呢?理论上是的,但是有一个问题,FileCoin的经济激励系统是不符合EOS的设计哲学的,它需要终端用户为使用存储和带宽付费。基于这样的考虑,EOS没有选择IPFS+FileCoin的方案。而是基于IPFS自己设计了一套机制。

首先设计了一套文件系统智能合约,发行了一种 token 叫TOK。它允许每个用户定义一个目录结构,这个目录结构下面的所有文件都链接了一个IPFS文件。也就是说TOK只存储IPFS的文件链接和一个人类可读的文件名。

那如何上传一个文件?

用户通过签名一个交易创建一个指向IPFS文件的链接,并将该交易广播的区块链。这个交易包含了用户的home目录和相应的IPFS文件名以及文件大小。同时用户也可以指定文件被存储在哪个TOK 区块生产者上。然后用户将通过标准的restfull api(API由EOS.io定义)上传文件到指定的区块生产者。一旦区块生产者验证文件和文件名匹配,则其会广播交易到整个区块链系统,其他的区块生产会通过IPFS网络复制那个文件。这样用户就成功的上传了一个文件,同时在的home目录下保存了该文件的链接。

我们上面提到了,IPFS是不保证文件的可用性的,那么EOS怎么保证呢?另外每一个人能存储多大体积的文件?如何分配有限的资源呢?这要说一下TOK的作用了。

EOS存储里定义TOK,若用户需要存储空间那必须锁定一部分TOK(这个概念跟我们之前讲的使用EOS资源需要锁定EOS是相同的道理),不同的是其价格里面出现了一个参数叫CRR(Constant Reserve Ratio我翻译成准备金率常数)并且定义了一个公式:价格=余额/(供给*CRR)。

为什么要有这个CRR我一开始也不太理解,想了很长时间才想明白,TOK跟EOS token有一个非常大的区别EOS token只有一个服务商(区块链系统)但是存储系统设计的就不是这样,它可以有很多服务商不同的服务商在均衡服务质量和服务价格方面如何体现自己的竞争力呢?就是靠调整CRR。就是说有些服务商可能提供的服务质量比较高那他们可以将CRR调高一些,而有些服务商可能质量相对一般,那他们为了提高自己的竞争力就会将CRR调低一些。

不良信息的管控

这里就不多讲了,大致上说EOS存储可以任意删除不符合法律规定的内容,由于EOS是国际化的那可能出现内容符合某个法律但是不符合另外一个法律的情况,这就需要社区来进行维护,对于不守规矩的区块生产者就将它票出去。

隐私

EOS存储是一个存储公共信息的平台,如果你想存储私有信息,那需要你在上传之前就自行加密。

去中心化和复制(副本)

区块生产者们代表的是至少20个独立的个人或组织,每一个生产者可以复制和托管全球不同辖区的数据。只要这20个区块生产者有一个在线并提供文件,那么这个文件就可以被提供给所有人。

该方法提供了比其他存储方案更好的可用性,因为区块生产者需要随时更新他们的服务已获得投票并且获得区块生产的报酬。

得票排在25名以后的区块生产者是没有义务存储数据提供服务的,但是他们要展示自己的能力以便能被投票到排名前25。

EOS存储的经济系统

天下没有免费的午餐,那到底是谁在为存储空间和带宽付费呢?

存储的经济系统

存储的经济系统相对简单一些,持有TOK的的人将有每年5%的EOS通胀来支付。其供需逻辑跟我们之前分析EOS token的逻辑是一致的。也就是说最终支付存储费用的是TOK的时间价值。

带宽的经济系统

相对存储,带宽的分配相对复杂一些,因为内容的生产者和内容的消费者是完全不对等的,如果由内容生产者来支付所有消费者的带宽这可能不现实,比如说有个用户上传了一个视频到Youtube上,结果被点击播放了几百万次,这个带宽的费用其实是惊人的。那么怎么处理带宽的激励经济呢?EOS想的办法按照我的理解是对于在EOS系统内的用户不管是上传还是下载数据占用的带宽,都将锁定一小部分TOK(仅在使用时锁定,使用完成后释放),由TOK的时间价值来支付带宽成本。另外区块生产者还需要免费提供一部分带宽给没有在EOS系统注册的用户使用。

另外内容上传者可以提供TOK来补贴带宽,比如部分广告或电影宣传片。

总结

EOS存储的设计理念处处体现着EOS的设计哲学,特别是其经济激励系统,无处不在。在去中心化的世界里提供类似中心化的服务,也许这才是区块链的正确发展方向。

参考资料《EOS storage whitepaper》

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

  查看全部
EOS简介


近期 EOS 的团队发布了EOS存储部分的白皮书。根据白皮书上的内容我们可以了解EOS存储部分的设计理念。

首先EOS存储基于IPFS(星际文件系统)之上设计的;

其次不同与一些去中心化的存储方案需要特殊的工具或特殊的浏览器,EOS存储可以提供任意浏览器访问的能力;

EOS存储使用基于EOS发行的token TOK激励区块生产这保证存储的可访问性和带宽。

下面我们详细说一下EOS具体的设计细节
 
IPFS

IPFS是一种去中心化的文件系统,它将文件名和文件内容强关联起来(文件名是文件内容的hash)。也就是说在任意终端上,相同文件内容的文件其名称也一定相同。当你下载一个文件的时候可以通过文件名来校验文件的完整性。IPFS提供了一个p2p的网络传输层用于终端之间基于文件名称发现和分享文件。但是IPFS并不提供和保证文件的存储、托管和带宽。也就是说即使能有文件名,但是有可能找不到对应的文件内容。IPFS团队为了解决这个问题,发布了FileCoin区块链,使用区块链的支付系统来激励拥有剩余存储空间的人帮助提供稳定可靠文件的存储、托管和带宽(具体规则我没有深入研究,按照白皮书上讲的,FileCoin 应该跟 Maidsafe, Siacoin, 和 Storj类似)。

EOS对存储的需求

作为一个可以任意运行智能合约的平台,EOS设计性能需要达到百万级。这个这样的设计如果每秒进行100w次交易,每次交易产生100字节的数据,那么每秒钟就有100M的数据记录。如果每个区块生产节点都要存储一份这样的数据,那时间稍久数据量就是一个天文数字。另外,对于一些智能合约他们天然就有存储数据的需要,比如需要存储文字、图片、声音、视频等等数据。这些数据更不可能存储在区块链上了。

EOS存储的设计

按照EOS的需求,那IPFS+FileCoin是不是就解决了呢?理论上是的,但是有一个问题,FileCoin的经济激励系统是不符合EOS的设计哲学的,它需要终端用户为使用存储和带宽付费。基于这样的考虑,EOS没有选择IPFS+FileCoin的方案。而是基于IPFS自己设计了一套机制。

首先设计了一套文件系统智能合约,发行了一种 token 叫TOK。它允许每个用户定义一个目录结构,这个目录结构下面的所有文件都链接了一个IPFS文件。也就是说TOK只存储IPFS的文件链接和一个人类可读的文件名。

那如何上传一个文件?

用户通过签名一个交易创建一个指向IPFS文件的链接,并将该交易广播的区块链。这个交易包含了用户的home目录和相应的IPFS文件名以及文件大小。同时用户也可以指定文件被存储在哪个TOK 区块生产者上。然后用户将通过标准的restfull api(API由EOS.io定义)上传文件到指定的区块生产者。一旦区块生产者验证文件和文件名匹配,则其会广播交易到整个区块链系统,其他的区块生产会通过IPFS网络复制那个文件。这样用户就成功的上传了一个文件,同时在的home目录下保存了该文件的链接。

我们上面提到了,IPFS是不保证文件的可用性的,那么EOS怎么保证呢?另外每一个人能存储多大体积的文件?如何分配有限的资源呢?这要说一下TOK的作用了。

EOS存储里定义TOK,若用户需要存储空间那必须锁定一部分TOK(这个概念跟我们之前讲的使用EOS资源需要锁定EOS是相同的道理),不同的是其价格里面出现了一个参数叫CRR(Constant Reserve Ratio我翻译成准备金率常数)并且定义了一个公式:价格=余额/(供给*CRR)。

为什么要有这个CRR我一开始也不太理解,想了很长时间才想明白,TOK跟EOS token有一个非常大的区别EOS token只有一个服务商(区块链系统)但是存储系统设计的就不是这样,它可以有很多服务商不同的服务商在均衡服务质量和服务价格方面如何体现自己的竞争力呢?就是靠调整CRR。就是说有些服务商可能提供的服务质量比较高那他们可以将CRR调高一些,而有些服务商可能质量相对一般,那他们为了提高自己的竞争力就会将CRR调低一些。

不良信息的管控

这里就不多讲了,大致上说EOS存储可以任意删除不符合法律规定的内容,由于EOS是国际化的那可能出现内容符合某个法律但是不符合另外一个法律的情况,这就需要社区来进行维护,对于不守规矩的区块生产者就将它票出去。

隐私

EOS存储是一个存储公共信息的平台,如果你想存储私有信息,那需要你在上传之前就自行加密。

去中心化和复制(副本)

区块生产者们代表的是至少20个独立的个人或组织,每一个生产者可以复制和托管全球不同辖区的数据。只要这20个区块生产者有一个在线并提供文件,那么这个文件就可以被提供给所有人。

该方法提供了比其他存储方案更好的可用性,因为区块生产者需要随时更新他们的服务已获得投票并且获得区块生产的报酬。

得票排在25名以后的区块生产者是没有义务存储数据提供服务的,但是他们要展示自己的能力以便能被投票到排名前25。

EOS存储的经济系统

天下没有免费的午餐,那到底是谁在为存储空间和带宽付费呢?

存储的经济系统

存储的经济系统相对简单一些,持有TOK的的人将有每年5%的EOS通胀来支付。其供需逻辑跟我们之前分析EOS token的逻辑是一致的。也就是说最终支付存储费用的是TOK的时间价值。

带宽的经济系统

相对存储,带宽的分配相对复杂一些,因为内容的生产者和内容的消费者是完全不对等的,如果由内容生产者来支付所有消费者的带宽这可能不现实,比如说有个用户上传了一个视频到Youtube上,结果被点击播放了几百万次,这个带宽的费用其实是惊人的。那么怎么处理带宽的激励经济呢?EOS想的办法按照我的理解是对于在EOS系统内的用户不管是上传还是下载数据占用的带宽,都将锁定一小部分TOK(仅在使用时锁定,使用完成后释放),由TOK的时间价值来支付带宽成本。另外区块生产者还需要免费提供一部分带宽给没有在EOS系统注册的用户使用。

另外内容上传者可以提供TOK来补贴带宽,比如部分广告或电影宣传片。

总结

EOS存储的设计理念处处体现着EOS的设计哲学,特别是其经济激励系统,无处不在。在去中心化的世界里提供类似中心化的服务,也许这才是区块链的正确发展方向。

参考资料《EOS storage whitepaper》

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

 

EOS从入门到精通-账户体系(文字稿)

EOS代码分析郑浩 发表了文章 • 1 个评论 • 1184 次浏览 • 2017-12-27 09:05 • 来自相关话题

本文是王巨老师EOS课程的文字版,首发在简书,经本人同意后转载,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第二讲。今天的课程原本计划讲两部分内容,账户系统和并行执行。但是一天的备课下来,我发现账户系统的内容特别多,而且理解EOS的账号体系对于将来进行智能合约的开发非常有帮助,因此我决定在本次课程中详细给大家讲解一下EOS的账户体系。并行执行这部分放到下一讲跟TOKEN模型放到一起。
另外,上次有同学说没有ppt的问题,我今天也会在讲课的过程中穿插加入ppt。




大家可以先看一下上面这个思维导图,这就是本节课要讲解的大纲。主要分了5个章节,简介、消息和处理程序、基于角色的权限管理、带有强制延时性的消息、恢复被盗窃的密钥。其中今天会重点讲解基于角色的权限管理。

好的,我们开始讲解EOS的权限系统
 



EOS相对于比特币和以太坊只有私钥和地址的概念,EOS的账户体系是相当完备的,从这点来看,比特币和以太坊在可用性上差了EOS一大截。比如说比特币和以太坊没法自定义账户地址,只能用一堆人类没法理解的字符串做地址和私钥。而EOS可以使用一个人类可以阅读的2-32个字符来创建账户。另外在白皮书上强调,创建一个账号需要付出额外的一点点成本,来覆盖账户的存储成本,这一般是由开发者也就是应用提供方来承担。最后,EOS的账户还支持域的概念,比如说:
@domain这个账号的拥有者是唯一能创建@user.domain的人。




好我们继续讲消息和处理程序,讲账户为什么要讲消息和处理程序呢?这是因为账户和消息是EOS只能合约的两个不可或缺的组成部分,而且他们之间有着密切的关联,单独讲哪一个也没法讲清楚他们的本质。我们看看EOS的消息机制就明白了,所谓的消息就是账户与账户之间的沟通语言,每个账户都可以发送结构化的消息给任意其他账户,每个账户都可以定义处理消息的脚本,每个账户还有自己的私有数据库,消息处理脚本也可以给其他账户发消息,最终 消息和消息处理脚本组成了EOS的智能合约。
我来进一步解释一下,发消息很容易理解,消息处理脚本就是在一个账户收到了消息之后怎么处理消息。这个处理脚本本身还可以发消息给其他账户。这个怎么理解呢?我的理解是有些消息是人手工发的,比如说a给b转账50eos,有些消息是可以由处理消息的脚本来发的,比如说b在收到50eos这个消息后有个消息处理脚本会自动向c发送25个eos。这其实就是一个非常简单的合约了。




好的,我们来讲一下今天的重点基于角色的权限管理,这也是BM系区块链的一个特色,权限管理在BTS和Steamit上已经比较完善了,在EOS上还会做更多的优化。我们先来看看权限管理的简介:判断一条消息是否被授权最简单的方式是包含一个签名,当然验证这个签名的前提是要知道这个签名是谁的。一般来说权限是与个体或群组绑定在一起,理论上不会有一种权限跟个体或群组没关系,因为这样是没有意义的。EOS提供了细粒度和高级别的权限控制,可以控制到谁在什么时候做什么事情。认证和权限管理必须标准化,并且与应用程序的业务逻辑分开,这样可以用通用的方式来管理权限,并且为性能优化提供可能。EOS还支持多账户的控制机制,能对账户的安全性提供保障,减少被黑客攻击而造成的资金损失风险。EOS甚至还允许定义什么密钥或账户可以发送特定的消息类型给另一个账户。
举个例子:一个用户的社交媒体账户可以使用一个密钥,而另一个密钥可以用于访问交易所,甚至可以授权其他账户来代表本账户而不是分配一个密钥。

下面我们就详细讲一下EOS的权限管理方案:




首先EOS为权限级别进行了命名比如说Owner、Active、Friend。这些命名可以是系统默认的比如Owner和Active,有些是可以自定义的比如Friend的。我们来看Steamit里面的权限实例:它是硬编码了三个权限级别:Owner、Active、Posting。其中Posting权限只能进行发帖操作投票等社交操作,Active权限可以做除了修改Owner以外的所有事情。Owner可以作为冷备份而存在。EOS本身也囊括了这些概念,而且允许自定义权限的层次结构和分组。




在设计了权限级别之后,EOS还设计了命名的消息处理群组,这个命名的消息处理群组可以在其他帐户配置他们权限级别时被引用。上面有一个简单的例子,在账户名下有一个分组A,分组A下面有个子分组b,它下面有消息类型。一个交易所的交易合约 在这种模式下就可以将订单的创建和取消 分开存取,通过交易合约进行分组 可以方便 交易所用户。




 权限级别和消息处理群组,这两个概念之间就可以做映射了。就是说可以将某个消息处理群组分配到某个权限级别上,或者反过来说,可以在某个权限级别上定义很多消息处理群组。举个例子:一个帐户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。 有了这个映射,任何朋友可以以这一帐户的身份在这一帐户的社交媒体上发帖。 尽管他们将以帐户所有者的身份发帖,他们仍然使用自己的密钥来签名消息。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。




如何进行权限评估,简单的来讲就是从小到大进行逐级匹配,比如:当 @alice 以 "Action" 类型发送一条消息给 @bob 时,首先会检查 @alice 是否为 @bob.groupa.subgroup.Action 定义过权限映射。 如果什么都没有找到,紧接着检查 @bob.groupa.subgroup 映射,然后是 @bob.groupa,最后 @bob 将被检查。 如果都没有找到,那么假定映射为命名的权限群组 @alice.active。
一旦一个映射被识别,则使用相关联的签名验证权限。 如果失败了,则跃迁至父权限,直至拥有者权限@alice.owner。




我们在看一下上面这张图,我简单讲一下:我们先看左侧,可以看到上面带key字符的就是各种权限,底下的三个方框是命名的消息群组,我们可以看到,这个交易的合约被映射到家庭组这个权限上,而提现这个消息被映射到律师这个权限上,也就是说家庭组里面的成员可以进行交易,但是唯独不能进行取现。因为取现最先匹配上的是律师这个密钥。




好,我们看看EOS的默认权限群组,默认的权限组上面我们也有讲到,是Owner和Active,Owner可以做任何事情,这个权限一般来说不用来做具体的工作,一般用来做冷备份,比如说Active权限丢了,就可以是用Owner权限来恢复。Active权限可以做除了修改Owner以外的所有事情,一般业务都是有Active权限来完成。其他的所有权限组也都是从Active权限派生出来的。




权限的并行评估这部分内容,相对来说没有特别重要,我们就简单讲一下。基本上说的是,由于权限的评估是只读的,因此可以进行并行化处理,同时可以提前到交易广播阶段完成,而不是在打包块的过程中。另外在区块链被重新加载重放交易时由于区块的执行肯定是通过了权限验证的,因此可以忽略,以此来提高执行效率。
好了权限管理这部分就讲到这里,我们在看下一部分,带强制性延时的消息




这部分比较简单,主要说的是,时间是安全的重要属性,EOS允许有时间延时的消息,在特别的时间范围内可以取消消息。这点是比特币和以太坊不能实现的,特别是在网络拥堵的情况下,若手续费比较低,往往一笔交易很长时间得不到确认,而用户完全没有办法取消交易。这种延时消息具体延时多长时间完全有消息的敏感程度决定,比如说买咖啡可能是几秒钟,买房可能是几天,转移整个账户可能是一个月,确切的时间取决于应用开发者和用户。




EOS允许恢复被盗窃的密钥,这在比特币和以太坊上是不可能的,在比特币和以太坊上一旦密钥丢失那么整个账户也随之丢失,EOS提供了恢复密钥的机制。具体来说就是可以使用30天内的任意Owner权限的密钥,注意这个密钥可能已经被黑客换过了,但是在这个场景下这个密钥还是可以使用的;使用任意30天内的Owner密钥和指定的合作伙伴才能恢复密钥。这里面合作伙伴不能在没有Owner协助的基础上恢复密钥。合作伙伴也不会参与任何日常交易,这样可以大大降低法律上的风险。EOS破70了,有打赏0.1个EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35 查看全部
本文是王巨老师EOS课程的文字版,首发在简书,经本人同意后转载,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
《EOS从入门到精通》系列课程,我是王巨,今天是EOS技术白皮书解读的第二讲。今天的课程原本计划讲两部分内容,账户系统和并行执行。但是一天的备课下来,我发现账户系统的内容特别多,而且理解EOS的账号体系对于将来进行智能合约的开发非常有帮助,因此我决定在本次课程中详细给大家讲解一下EOS的账户体系。并行执行这部分放到下一讲跟TOKEN模型放到一起。
另外,上次有同学说没有ppt的问题,我今天也会在讲课的过程中穿插加入ppt。
3115234-85357636542086a5.png

大家可以先看一下上面这个思维导图,这就是本节课要讲解的大纲。主要分了5个章节,简介、消息和处理程序、基于角色的权限管理、带有强制延时性的消息、恢复被盗窃的密钥。其中今天会重点讲解基于角色的权限管理。

好的,我们开始讲解EOS的权限系统
 
3115234-24d3a54187816447.jpeg

EOS相对于比特币和以太坊只有私钥和地址的概念,EOS的账户体系是相当完备的,从这点来看,比特币和以太坊在可用性上差了EOS一大截。比如说比特币和以太坊没法自定义账户地址,只能用一堆人类没法理解的字符串做地址和私钥。而EOS可以使用一个人类可以阅读的2-32个字符来创建账户。另外在白皮书上强调,创建一个账号需要付出额外的一点点成本,来覆盖账户的存储成本,这一般是由开发者也就是应用提供方来承担。最后,EOS的账户还支持域的概念,比如说:
@domain这个账号的拥有者是唯一能创建@user.domain的人。
3115234-3d8c59f9edc7c92a.jpeg

好我们继续讲消息和处理程序,讲账户为什么要讲消息和处理程序呢?这是因为账户和消息是EOS只能合约的两个不可或缺的组成部分,而且他们之间有着密切的关联,单独讲哪一个也没法讲清楚他们的本质。我们看看EOS的消息机制就明白了,所谓的消息就是账户与账户之间的沟通语言,每个账户都可以发送结构化的消息给任意其他账户,每个账户都可以定义处理消息的脚本,每个账户还有自己的私有数据库,消息处理脚本也可以给其他账户发消息,最终 消息和消息处理脚本组成了EOS的智能合约。
我来进一步解释一下,发消息很容易理解,消息处理脚本就是在一个账户收到了消息之后怎么处理消息。这个处理脚本本身还可以发消息给其他账户。这个怎么理解呢?我的理解是有些消息是人手工发的,比如说a给b转账50eos,有些消息是可以由处理消息的脚本来发的,比如说b在收到50eos这个消息后有个消息处理脚本会自动向c发送25个eos。这其实就是一个非常简单的合约了。
3115234-70c0601c6aa9f16e.jpeg

好的,我们来讲一下今天的重点基于角色的权限管理,这也是BM系区块链的一个特色,权限管理在BTS和Steamit上已经比较完善了,在EOS上还会做更多的优化。我们先来看看权限管理的简介:判断一条消息是否被授权最简单的方式是包含一个签名,当然验证这个签名的前提是要知道这个签名是谁的。一般来说权限是与个体或群组绑定在一起,理论上不会有一种权限跟个体或群组没关系,因为这样是没有意义的。EOS提供了细粒度和高级别的权限控制,可以控制到谁在什么时候做什么事情。认证和权限管理必须标准化,并且与应用程序的业务逻辑分开,这样可以用通用的方式来管理权限,并且为性能优化提供可能。EOS还支持多账户的控制机制,能对账户的安全性提供保障,减少被黑客攻击而造成的资金损失风险。EOS甚至还允许定义什么密钥或账户可以发送特定的消息类型给另一个账户。
举个例子:一个用户的社交媒体账户可以使用一个密钥,而另一个密钥可以用于访问交易所,甚至可以授权其他账户来代表本账户而不是分配一个密钥。

下面我们就详细讲一下EOS的权限管理方案:
3115234-4908ed9a38ca3081.jpeg

首先EOS为权限级别进行了命名比如说Owner、Active、Friend。这些命名可以是系统默认的比如Owner和Active,有些是可以自定义的比如Friend的。我们来看Steamit里面的权限实例:它是硬编码了三个权限级别:Owner、Active、Posting。其中Posting权限只能进行发帖操作投票等社交操作,Active权限可以做除了修改Owner以外的所有事情。Owner可以作为冷备份而存在。EOS本身也囊括了这些概念,而且允许自定义权限的层次结构和分组。
3115234-419f4031056d82bb.jpeg

在设计了权限级别之后,EOS还设计了命名的消息处理群组,这个命名的消息处理群组可以在其他帐户配置他们权限级别时被引用。上面有一个简单的例子,在账户名下有一个分组A,分组A下面有个子分组b,它下面有消息类型。一个交易所的交易合约 在这种模式下就可以将订单的创建和取消 分开存取,通过交易合约进行分组 可以方便 交易所用户。
3115234-3af156d20070806e.jpeg

 权限级别和消息处理群组,这两个概念之间就可以做映射了。就是说可以将某个消息处理群组分配到某个权限级别上,或者反过来说,可以在某个权限级别上定义很多消息处理群组。举个例子:一个帐户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。 有了这个映射,任何朋友可以以这一帐户的身份在这一帐户的社交媒体上发帖。 尽管他们将以帐户所有者的身份发帖,他们仍然使用自己的密钥来签名消息。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。
3115234-db7bd000104ed61e.jpeg

如何进行权限评估,简单的来讲就是从小到大进行逐级匹配,比如:当 @alice 以 "Action" 类型发送一条消息给 @bob 时,首先会检查 @alice 是否为 @bob.groupa.subgroup.Action 定义过权限映射。 如果什么都没有找到,紧接着检查 @bob.groupa.subgroup 映射,然后是 @bob.groupa,最后 @bob 将被检查。 如果都没有找到,那么假定映射为命名的权限群组 @alice.active。
一旦一个映射被识别,则使用相关联的签名验证权限。 如果失败了,则跃迁至父权限,直至拥有者权限@alice.owner。
3115234-b31e28e27ed297e7.jpeg

我们在看一下上面这张图,我简单讲一下:我们先看左侧,可以看到上面带key字符的就是各种权限,底下的三个方框是命名的消息群组,我们可以看到,这个交易的合约被映射到家庭组这个权限上,而提现这个消息被映射到律师这个权限上,也就是说家庭组里面的成员可以进行交易,但是唯独不能进行取现。因为取现最先匹配上的是律师这个密钥。
3115234-1ef1c9e86f9e22df.jpeg

好,我们看看EOS的默认权限群组,默认的权限组上面我们也有讲到,是Owner和Active,Owner可以做任何事情,这个权限一般来说不用来做具体的工作,一般用来做冷备份,比如说Active权限丢了,就可以是用Owner权限来恢复。Active权限可以做除了修改Owner以外的所有事情,一般业务都是有Active权限来完成。其他的所有权限组也都是从Active权限派生出来的。
3115234-8111c31a9c663d44.jpeg

权限的并行评估这部分内容,相对来说没有特别重要,我们就简单讲一下。基本上说的是,由于权限的评估是只读的,因此可以进行并行化处理,同时可以提前到交易广播阶段完成,而不是在打包块的过程中。另外在区块链被重新加载重放交易时由于区块的执行肯定是通过了权限验证的,因此可以忽略,以此来提高执行效率。
好了权限管理这部分就讲到这里,我们在看下一部分,带强制性延时的消息
3115234-700402bc86da9ce7.jpeg

这部分比较简单,主要说的是,时间是安全的重要属性,EOS允许有时间延时的消息,在特别的时间范围内可以取消消息。这点是比特币和以太坊不能实现的,特别是在网络拥堵的情况下,若手续费比较低,往往一笔交易很长时间得不到确认,而用户完全没有办法取消交易。这种延时消息具体延时多长时间完全有消息的敏感程度决定,比如说买咖啡可能是几秒钟,买房可能是几天,转移整个账户可能是一个月,确切的时间取决于应用开发者和用户。
3115234-93d4e36d8300b5ff.jpeg

EOS允许恢复被盗窃的密钥,这在比特币和以太坊上是不可能的,在比特币和以太坊上一旦密钥丢失那么整个账户也随之丢失,EOS提供了恢复密钥的机制。具体来说就是可以使用30天内的任意Owner权限的密钥,注意这个密钥可能已经被黑客换过了,但是在这个场景下这个密钥还是可以使用的;使用任意30天内的Owner密钥和指定的合作伙伴才能恢复密钥。这里面合作伙伴不能在没有Owner协助的基础上恢复密钥。合作伙伴也不会参与任何日常交易,这样可以大大降低法律上的风险。EOS破70了,有打赏0.1个EOS的吗?我看能收到几个0x078C5AF6C8Ab533b8ef7FAb822B5B5f70A9d1c35

EOS学习笔记4---公共测试网络

EOS代码分析郑浩 发表了文章 • 0 个评论 • 1301 次浏览 • 2017-12-25 21:03 • 来自相关话题

本章包括以下内容:
1.概述
2.测试网络和主网络的区别之处。
3.节点。
4.公共测试网络终端。
5.本地EOSD和公共测试网络的连接。
6.本地EOSC和公共测试网络的连接。
7.测试网络账户。
8.网页钱包。(普通终端用户)
9.命令行(开发者)
 
 
1.概述
     公共测试网络的存在是为了支持已经有自己的独立测试网络的开发人员和测试人员来测试他们的代码,但没有‘主网络’公共生产环境的一些问题和限制。
      公共测试网络允许开发者使用在注册时提供的免费测试代币。注册链接在这里。
 
2.测试网络和主网络的不同之处。
    公共测试网络有一些和主网络不一样的地方,在写这篇文章时,包括以下方面。
   *存在     公共主网络还不存在,公共测试网络已存在。
   *创世区块    主网络的创世区块不同于公共测试网络的创世区块。测试网络的创世区块包含了一个水龙头账户和供核心开发人       员测试用的若干个‘initx’(inita- initu)账户。至少有些initx账户也在对立的私人测试网络中提供创世区块。
   *重置     测试网络为了支持测试有重置的可能。
   *版本     测试网络实际上包括了许多不同地址和重置循环的测试网络,这取决于开发社区的需求。
   *主机     测试网络当前仅核心开发者可以在主机上建立和操作配置产块节点。公共主网络的产块节点是由代币持有人投票选举       产生的。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
3.节点
    测试网络由产块节点和非产块节点组成。
 
4.公共测试网络终端。
    以下是当前可用的公共测试网络:
    * Testnet1
        · HTTP Endpoint:tesnet1.eos.io
        · P2P Endpoint:  p2p-testnet1.eos.io:9876
        · Web Wallet Endpoint: t1wallet.eos.io  ,  t1api.eos.io  ,   t1readonly.eos.io
你也可以使用curl来连接。$ curl testnet1.eos.io/v1/chain/get_info5.本地EOSD和公共测试网络的连接。
为了使你的本地EOSD连接到公共的测试网络,得确保你机器的时间是精确的,同时需要按照以下来调整config.ini的配置。p2p-peer-address = p2p-testnet1.eos.io调整 block-interval-seconds 来匹配测试网络,值为2,否则你的本地eosd节点不会和公共测试网络进行同步。block-interval-seconds = 2

6.本地EOSC和公共测试网络的连接。
你可以使用http终端加主机名和端口来连接测试网络。$ eosc -H ${http_endpoint} -p 80 ${options} ${subcommand}

此外,公共测试网络没有提供任何钱包的功能。为了完成签名交易/推送交易/钱包的操作,你需要使用eosc使你的本地钱包连接到公共测试网络。这样做才能确保本地钱包的正常使用。以下命令会在你当前工作的文件夹产生一个data-dir文件夹,这个文件夹包含了经过钱包密码加密的私钥。$ eos-walletd
# this will create a data-dir folder inside your current working directory, this data-dir folder will contain your private keys encrypted with the wallet password然后指定你本地钱包终端端口,除非你覆盖它,钱包终端将是localhost,端口是8888.$ eosc -H ${http_endpoint} -p 80 ${options} --wallet-host ${wallet_endpoint} --wallet-port ${wallet_port} ${subcommand}


7.测试网络的账户。
在开始前首先你需要一个账户名和EOS的公钥。
    *找到你的账户名
      · 输入你的ETH地址或者EOS公钥来找到创世文件分配给你的账户名称,在这里查找。
      ·如果你的地址不包含在快照中,可以通过这里来申请。
    *准备好你的EOS公钥。
      · 如果你的公钥在快照中,你的EOS公钥就是EOS众筹合约的公钥。
      · 如果你通过水龙头申请的账户,你的EOS公钥就是你提交到水龙头应用的公钥。
一旦你拥有了账户名称,你就可以选择喜欢和方式和EOS进行互动了。
 
8.网页钱包。(普通终端用户)
    *访问测试网页钱包
    *创建账户
    * 注册登陆。
    *点击账户边栏。
    *输入你刚才通过之前步骤获得的账户。
    *输入你的EOS公钥,包括EOS Active Key 和Owner Key。
    *点击添加账户。
 
9.命令行(开发者)
  *你需要eos-walletd 和eosc ,看这里,创建本地环境。
  *连接到公共测试网络
  *使用eosc导入你的私钥,看这里
  *学习如何使用eosc,命令介绍看这里,并综合教程。
 
因为EOS还在不断的开发完善中,所以该文档可能会过时,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
  查看全部
本章包括以下内容:
1.概述
2.测试网络和主网络的区别之处。
3.节点。
4.公共测试网络终端。
5.本地EOSD和公共测试网络的连接。
6.本地EOSC和公共测试网络的连接。
7.测试网络账户。
8.网页钱包。(普通终端用户)
9.命令行(开发者)
 
 
1.概述
     公共测试网络的存在是为了支持已经有自己的独立测试网络的开发人员和测试人员来测试他们的代码,但没有‘主网络’公共生产环境的一些问题和限制。
      公共测试网络允许开发者使用在注册时提供的免费测试代币。注册链接在这里
 
2.测试网络和主网络的不同之处。
    公共测试网络有一些和主网络不一样的地方,在写这篇文章时,包括以下方面。
   *存在     公共主网络还不存在,公共测试网络已存在。
   *创世区块    主网络的创世区块不同于公共测试网络的创世区块。测试网络的创世区块包含了一个水龙头账户和供核心开发人       员测试用的若干个‘initx’(inita- initu)账户。至少有些initx账户也在对立的私人测试网络中提供创世区块。
   *重置     测试网络为了支持测试有重置的可能。
   *版本     测试网络实际上包括了许多不同地址和重置循环的测试网络,这取决于开发社区的需求。
   *主机     测试网络当前仅核心开发者可以在主机上建立和操作配置产块节点。公共主网络的产块节点是由代币持有人投票选举       产生的。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
3.节点
    测试网络由产块节点和非产块节点组成。
 
4.公共测试网络终端。
    以下是当前可用的公共测试网络:
    * Testnet1
        · HTTP Endpoint:tesnet1.eos.io
        · P2P Endpoint:  p2p-testnet1.eos.io:9876
        · Web Wallet Endpoint: t1wallet.eos.io  ,  t1api.eos.io  ,   t1readonly.eos.io
你也可以使用curl来连接。
$ curl testnet1.eos.io/v1/chain/get_info
5.本地EOSD和公共测试网络的连接。
为了使你的本地EOSD连接到公共的测试网络,得确保你机器的时间是精确的,同时需要按照以下来调整config.ini的配置。
p2p-peer-address = p2p-testnet1.eos.io
调整 block-interval-seconds 来匹配测试网络,值为2,否则你的本地eosd节点不会和公共测试网络进行同步。
block-interval-seconds = 2

6.本地EOSC和公共测试网络的连接。
你可以使用http终端加主机名和端口来连接测试网络。
$ eosc -H ${http_endpoint} -p 80 ${options} ${subcommand}

此外,公共测试网络没有提供任何钱包的功能。为了完成签名交易/推送交易/钱包的操作,你需要使用eosc使你的本地钱包连接到公共测试网络。这样做才能确保本地钱包的正常使用。以下命令会在你当前工作的文件夹产生一个data-dir文件夹,这个文件夹包含了经过钱包密码加密的私钥。
$ eos-walletd
# this will create a data-dir folder inside your current working directory, this data-dir folder will contain your private keys encrypted with the wallet password
然后指定你本地钱包终端端口,除非你覆盖它,钱包终端将是localhost,端口是8888.
$ eosc -H ${http_endpoint} -p 80 ${options} --wallet-host ${wallet_endpoint} --wallet-port ${wallet_port} ${subcommand}


7.测试网络的账户。
在开始前首先你需要一个账户名和EOS的公钥。
    *找到你的账户名
      · 输入你的ETH地址或者EOS公钥来找到创世文件分配给你的账户名称,在这里查找。
      ·如果你的地址不包含在快照中,可以通过这里来申请。
    *准备好你的EOS公钥。
      · 如果你的公钥在快照中,你的EOS公钥就是EOS众筹合约的公钥。
      · 如果你通过水龙头申请的账户,你的EOS公钥就是你提交到水龙头应用的公钥。
一旦你拥有了账户名称,你就可以选择喜欢和方式和EOS进行互动了。
 
8.网页钱包。(普通终端用户)
    *访问测试网页钱包
    *创建账户
    * 注册登陆。
    *点击账户边栏。
    *输入你刚才通过之前步骤获得的账户。
    *输入你的EOS公钥,包括EOS Active Key 和Owner Key。
    *点击添加账户。
 
9.命令行(开发者)
  *你需要eos-walletd 和eosc ,看这里,创建本地环境。
  *连接到公共测试网络
  *使用eosc导入你的私钥,看这里
  *学习如何使用eosc,命令介绍看这里,并综合教程
 
因为EOS还在不断的开发完善中,所以该文档可能会过时,我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
 

EOS学习笔记3---EOS词汇表

EOS代码分析郑浩 发表了文章 • 0 个评论 • 662 次浏览 • 2017-12-23 17:49 • 来自相关话题

在EOS的系统中有一些名词需要搞懂其定义。我们来看下官方对其中重要概念的定义。
 Account:账户
     由本地或者自定义权限(由一个或者多个私钥和账户控制)指定的一个链上身份。
 
Authority:权限
      一个抽象的权限,代表了如何在现实中组织权限,这些权限跟一个个体或者一组个体绑定。
 
Block(Blk):区块
     区块链的一个确定的单元。每个区块包含0个或者多个交易,以及和之前区块的密码学连接。一个区块是‘不可逆转的确认’,这是因为绝大多数产块者(Block Producer)都同意一个完整的区块包含了正确的交易。一旦一个区块经过不可逆转的确认后,它就成为了不可改变的区块链的永久的一部分。
 
DAC(Decentralized Autonomous Collective, or Decentralized Autonomous Corporation.)
     分布式自治公司。
 
DAO(Decentralized Autonomous Organization.)
    分布式自治组织。
 
DPoS:(Delegated Proof of Stake,OR   Democracy as Proof of Stake )
    DPos是一个许多共识机制的集成,例如,如何在确认产块者的问题上达成共识,如何确认交易和区块是否‘真实有效’,并且不可逆转的确认和处理。
 
Key pair(keys):密钥对
    一个公钥和它对应的私钥。
 
larimer:(BM的姓名 Daniel Larimer)
    基础货币EOS的1/1000,1 Larimer = 0.0001 EOS
 
Master Password:主密码
    用来解锁和加密钱包文件的密码。
 
Message:(Msg)消息
    区块链的一个变化。一个或多个消息构成交易。
 
Oracle:预言机
  在区块链和智能合约中,预言机是一个代理人,来发现和确认现实世界发生的事情并提交给区块链供智能合约来使用。
 
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
Permission:权限
    一个重量级的安全机制,它通过评估其签字权来确定一个消息是否被正确授权。
 
Pravite Key:私钥
    用来签署交易的密钥。
 
Public Key:(pub key)公钥
    伴随交易传递的公开可用的密钥。
 
Smart Contract:智能合约
    一个智能合约是一个旨在促进,核实或加强合约谈判和履行的计算机协议。
 
Transaction(Tx,Txn):交易
     一个全或无的区块链状态改变。由一个或者多个消息构成。通常是智能合约的执行。
 
Wallet:钱包
    由客户端(比如eosc)生成和管理的一个加密文件,可以管理私钥,用安全的方法促进签署的交易,钱包可能处于开或者关两种状态。
 
Witness:(block producer),见证人,产块者。
    一个当前轮到的节点,为区块链产生即时的区块。或者一组节点的其中一个成员,被选举轮值。见证人和产块者,矿工是一个意思。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
  查看全部
在EOS的系统中有一些名词需要搞懂其定义。我们来看下官方对其中重要概念的定义。
 Account:账户
     由本地或者自定义权限(由一个或者多个私钥和账户控制)指定的一个链上身份。
 
Authority:权限
      一个抽象的权限,代表了如何在现实中组织权限,这些权限跟一个个体或者一组个体绑定。
 
Block(Blk):区块
     区块链的一个确定的单元。每个区块包含0个或者多个交易,以及和之前区块的密码学连接。一个区块是‘不可逆转的确认’,这是因为绝大多数产块者(Block Producer)都同意一个完整的区块包含了正确的交易。一旦一个区块经过不可逆转的确认后,它就成为了不可改变的区块链的永久的一部分。
 
DAC(Decentralized Autonomous Collective, or Decentralized Autonomous Corporation.)
     分布式自治公司。
 
DAO(Decentralized Autonomous Organization.)
    分布式自治组织。
 
DPoS:(Delegated Proof of Stake,OR   Democracy as Proof of Stake )
    DPos是一个许多共识机制的集成,例如,如何在确认产块者的问题上达成共识,如何确认交易和区块是否‘真实有效’,并且不可逆转的确认和处理。
 
Key pair(keys):密钥对
    一个公钥和它对应的私钥。
 
larimer:(BM的姓名 Daniel Larimer)
    基础货币EOS的1/1000,1 Larimer = 0.0001 EOS
 
Master Password:主密码
    用来解锁和加密钱包文件的密码。
 
Message:(Msg)消息
    区块链的一个变化。一个或多个消息构成交易。
 
Oracle:预言机
  在区块链和智能合约中,预言机是一个代理人,来发现和确认现实世界发生的事情并提交给区块链供智能合约来使用。
 
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
Permission:权限
    一个重量级的安全机制,它通过评估其签字权来确定一个消息是否被正确授权。
 
Pravite Key:私钥
    用来签署交易的密钥。
 
Public Key:(pub key)公钥
    伴随交易传递的公开可用的密钥。
 
Smart Contract:智能合约
    一个智能合约是一个旨在促进,核实或加强合约谈判和履行的计算机协议。
 
Transaction(Tx,Txn):交易
     一个全或无的区块链状态改变。由一个或者多个消息构成。通常是智能合约的执行。
 
Wallet:钱包
    由客户端(比如eosc)生成和管理的一个加密文件,可以管理私钥,用安全的方法促进签署的交易,钱包可能处于开或者关两种状态。
 
Witness:(block producer),见证人,产块者。
    一个当前轮到的节点,为区块链产生即时的区块。或者一组节点的其中一个成员,被选举轮值。见证人和产块者,矿工是一个意思。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 

EOS学习笔记2-运行本地节点链接公共测试网络

EOS代码分析郑浩 发表了文章 • 0 个评论 • 924 次浏览 • 2017-12-15 15:01 • 来自相关话题

昨天Dawn2.0发布了公共的测试网络,本文介绍一下如何在本地运行一个节点,链接到公共测试节点,注册账户进行测试。github教程,笔者系统配置,ubuntu16.04,RAM 4G,
1.使用安装脚本安装本地节点,
git clone [url=https://github.com/eosio/eos]https://github.com/eosio/eos[/url] --recursive

cd eos
./build.sh ubuntu  
2.使用脚本运行本地节点连接到公共测试节点
  cd ~/eos/build/scripts
./start_npnode.sh这个命令将使用名称为testnet_np的实例数据文件夹。
你应该会看到以下的回应:
Launched eosd.
See testnet_np/stderr.txt for eosd output.
Synching requires at least 8 minutes, depending on network conditions.
 
使用以下命令来确认eosd的运行和同步:
 
tail -F testnet_np/stderr.txt
使用CTRL-C来推出tail,在同步的过程中,你会看到以下类似的信息:
3439731ms chain_plugin.cpp:272 accept_block ] Syncing Blockchain --- Got block: #200000 time: 2017-12-09T07:56:32 producer: initu
3454532ms chain_plugin.cpp:272 accept_block ] Syncing Blockchain --- Got block: #210000 time: 2017-12-09T13:29:52 producer: initc同步完成后,你会看到以下类似信息:
42467ms net_plugin.cpp:1245 start_sync ] Catching up with chain, our last req is 351734, theirs is 351962 peer ip-10-160-11-116:9876
42792ms chain_controller.cpp:208 _push_block ] initt #351947 @2017-12-12T22:59:44 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] inito #351948 @2017-12-12T22:59:46 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] initd #351949 @2017-12-12T22:59:48 | 0 trx, 0 pending, exectime_ms=0
3.创建钱包,密钥对,申请账号。
cd eosc
./eosc wallet create#创建钱包,记得保持私钥,丢失后将无法解锁你的钱包。

./eosc create key
Private key: 5XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的私钥
Public key: EOSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的公钥./eosc wallet import 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #导入你的私钥现在公共测试网络需要申请来注册账户,申请地址,按照文档步骤填写表格,大概在半个小时我收到了邮件回复。
这个时候查看我的账户,里面有100EOS代币了。
./eosc get account name55

{
"account_name": "name55",
"eos_balance": "100.0000 EOS",
"staked_balance": "0.0001 EOS",
"unstaking_balance": "0.0000 EOS",
"last_unstaking_time": "1969-12-31T23:59:59",
"permissions": [{
"perm_name": "active",
"parent": "owner",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
},{
"perm_name": "owner",
"parent": "",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
}
]
}
这样就可以使用公共测试网络来进行测试,和DAPP的开发部署了。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
 
 
 
 
 
 
 
  查看全部
昨天Dawn2.0发布了公共的测试网络,本文介绍一下如何在本地运行一个节点,链接到公共测试节点,注册账户进行测试。github教程,笔者系统配置,ubuntu16.04,RAM 4G,
1.使用安装脚本安装本地节点,
git clone [url=https://github.com/eosio/eos]https://github.com/eosio/eos[/url] --recursive

cd eos
./build.sh ubuntu
 
2.使用脚本运行本地节点连接到公共测试节点
  
cd ~/eos/build/scripts
./start_npnode.sh
这个命令将使用名称为testnet_np的实例数据文件夹。
你应该会看到以下的回应:
Launched eosd.
See testnet_np/stderr.txt for eosd output.
Synching requires at least 8 minutes, depending on network conditions.

 
使用以下命令来确认eosd的运行和同步:
 
tail -F testnet_np/stderr.txt
使用CTRL-C来推出tail,在同步的过程中,你会看到以下类似的信息:
3439731ms            chain_plugin.cpp:272          accept_block         ] Syncing Blockchain --- Got block: #200000 time: 2017-12-09T07:56:32 producer: initu
3454532ms chain_plugin.cpp:272 accept_block ] Syncing Blockchain --- Got block: #210000 time: 2017-12-09T13:29:52 producer: initc
同步完成后,你会看到以下类似信息:
42467ms            net_plugin.cpp:1245           start_sync           ] Catching up with chain, our last req is 351734, theirs is 351962 peer ip-10-160-11-116:9876
42792ms chain_controller.cpp:208 _push_block ] initt #351947 @2017-12-12T22:59:44 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] inito #351948 @2017-12-12T22:59:46 | 0 trx, 0 pending, exectime_ms=0
42793ms chain_controller.cpp:208 _push_block ] initd #351949 @2017-12-12T22:59:48 | 0 trx, 0 pending, exectime_ms=0

3.创建钱包,密钥对,申请账号。
cd eosc
./eosc wallet create#创建钱包,记得保持私钥,丢失后将无法解锁你的钱包。

./eosc create key
Private key: 5XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的私钥
Public key: EOSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #你的公钥
./eosc wallet import 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #导入你的私钥
现在公共测试网络需要申请来注册账户,申请地址,按照文档步骤填写表格,大概在半个小时我收到了邮件回复。
这个时候查看我的账户,里面有100EOS代币了。
./eosc get account name55

{
"account_name": "name55",
"eos_balance": "100.0000 EOS",
"staked_balance": "0.0001 EOS",
"unstaking_balance": "0.0000 EOS",
"last_unstaking_time": "1969-12-31T23:59:59",
"permissions": [{
"perm_name": "active",
"parent": "owner",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
},{
"perm_name": "owner",
"parent": "",
"required_auth": {
"threshold": 1,
"keys": [{
"key": "EOS6m4QMe38FkRTgChhE9oPHMPKC5MZDsf2NYSCAG7Y9F7ez6n9V5",
"weight": 1
}
],
"accounts": []
}
}
]
}

这样就可以使用公共测试网络来进行测试,和DAPP的开发部署了。
我创建了一个EOS爱好者社区,www.eos.top ,QQ群:499860264,微信群秘:fly258xx  ,欢迎加入讨论关于EOS的任何问题。
 
 
 
 
 
 
 
 
 
 
 
 
 
 

EOS.IO发布黎明2.0版本 & 开发更新

EOS新闻动态郑浩 发表了文章 • 0 个评论 • 452 次浏览 • 2017-12-06 20:59 • 来自相关话题

译者:岳利鹏、许莉,原文:https://steemit.com/eos/%40eos ... pdate




EOS.IO Dawn 2.0 已经发布,此次发布提供了由 block.one 团队维护的一个公开测试网络,对于 2017 年秋季路线图,以及原定于 2017 年 12 月 21 日前完成的大部分功能,此次发布也都提供了 Alpha 实现。正如我们路线图所公布的,“第二阶段 - 最小可行测试网络”将在 2017 年秋季之前展示如下内容:

- P2P 网络代码

- wasm 检测和 CPU 沙盒

- 资源利用跟踪/限制率

- 创世块导入测试

- 链间通信

目前,我们已经完成了大部分功能的初步实现。但是,由于并行开发路线的安排,链间通信的实现在一个单独的分支上进行,所以初始测试网络将不会用上链间通信的功能。

如果您对 EOS.IO Dawn 2.0 的性能测试感兴趣,可以在 Github 仓库找到启动和操作一个私有网络的所有区块链和网络代码。我们的内部测试表明,在普通硬件上,单线程实现可以承受每秒数千次传输和可处理多个块。即便如此,对于一些已知的攻击方式,我们还没有实现对应的解决方案。比如,首次编译新合约可能需要 34 ms,如果被利用,可能导致网络以超过 30 TPS 的交易速率碎片化。

针对这个问题,我们的解决方案是限制合约代码更新的频率,并限制代码更新与处理使用新代码交易之间的时间延迟。这个时间延迟将在 60 秒左右,以期能够让所有的块生产者有时间从 web assembly 中编译/缓存优化后的 x86 指令。

由于这些不可忽视的攻击方式,私有测试网络的其中一项任务仍然是性能测试,但是功能测试现在已经可以在公开测试网上进行了,我们已经将公开测试网人为地限制在 30 TPS,以确保正常的运行时间和访问。

在接下来的 6 个月里,我们将不断对网络进行测试和调试,以提高稳定性和性能。
Dawn 2.0的新特征

初始状态导入测试

我们实现了一个快照工具,它将根据分布在以太坊网络上 EOS ERC-20代币来导入初始状态。我们的测试网络只包含了注册有效EOS公钥的余额。大概有20%的ERC-20代币已经注册到了一个EOS的公钥中。我们的快照还为以太坊账户所有未注册的ERC-20代币提供了一个恢复工具,这个工具可帮我们从已签署的以太坊交易中恢复公钥。这包含了99%的EOS ERC-20代币,但是还将需要你导入你的以太坊私钥到你的EOS.IO的钱包里。

出于安全考虑,我们的测试网络不会要求用户导入他们的以太坊私钥然后通过恢复工具进行恢复。如果你的EOS私钥在测试的时候受到威胁,你可以随时在以太坊网络上注册一个新密钥。
 
代币“水龙头”

我们还实现了一个“水龙头”功能,这样就可以允许那些没有代币或者还没有注册一个有效的EOS公钥的人们进行网络测试。




资源使用和费率限制

我们实现了基本的费率限制和资源使用追踪。它追踪带宽、数据库存储以及计算力使用。这个时候我们的费率限制算法存在着一些已知的bugs,但是这不会影响测试和应用程序的开发。

我们知道有很多人都很关心费率限制相关信息,比如谁将会被收费,还有如何将它们的代币租出去以此换来收益等等。




带宽

所有的交易都会消耗掉区块生产者设置的网络带宽的最大值。拥有交易权的所有账户会根据交易的大小把3天内的流量累加。想获得带宽会要求授权账户(不是合约)抵押代币或由应用程序提供者委托代币。




计算带宽

所有的交易都消耗计算力。计算可以是并行地进行的,所以你可以把它想象成多个车道的高速公路,每个车道都拥有不同的拥挤程度。每个范围(车道)都会有自己独立的速率限制,并且基于最拥挤的程度,用户将针对同时请求的范围(通道)数量和速率限制来计费O(S^2)。




数据库存储

EOS.IO合约有访问内存数据库的权限,它们可以在该数据库存储状态。合约收费是根据它们存储数据的总和以及每个独立数据库条目的固定开销 ,这个内存数据库是独立的并且与EOS.IO的存储协议是分开的,这样做是为了让内存的膨胀不那么集中。




P2P 网络代码

对于mesh网络代码,我们已经有了基本实现,并且这些代码正在公开测试网络中试运行。目前 Block.one 运行了 21 个独立的服务器,每个服务器都配置了一个初始生产者。




EOS黎明3.0

EOS Dawn 3.0将通过安全的区块链间通信,重新解释单链水平扩展和无限扩展。有了这两个特点,对于区块链技术可以建立什么样的东西,以及区块链网络如何去中心化就都没有限制了。




无限扩展与无限去中心化

区块链技术的圣杯是在两个独立区块链之间实现安全通信,而不需要某一区块链验证另一个区块链上的所有内容。这需要使一个区块链成为另一个区块链的轻客户端。

轻客户端只使用块头和Merkle证明来验证交易。 EOS.IO将成为第一个支持轻客户端验证的POS协议。更重要的是,它将能首次产生Proof-of-Completeness。这意味着您可以证明您已经提前收到来自其他链的所有相关消息,无需等待或接受挑战的时间。

而传统的轻客户端必须处理所有的块头,EOS.IO将使轻客户端只需要当出块人改变、或需要一个更近块的新消息时再处理块头。这将使得高效率的频繁通信成为可能。在最坏的情况下,两个区块链每500毫秒一次通信的开销将比发送的消息总数高出约2个交易。

在这种模式下,只要至少有三分之一的生产者是诚实的,通信就会得到保证。此外,即使一个生产者腐败,如果他们签署任何可能破坏轻客户(或者叫外部区块链)的消息,他们会自动受到惩罚。

最后,传递到另一个区块链的往返时间取决于每个链不可逆的最终确定性等待时间。一个基于EOS.IO的链将能够发送一条消息给外部的EOS.IO链,并在3秒内得到一个密码学验证的响应。

这种级别的链间通信和安全性使得能够以非常低的延迟在链之间创建双向挂钩。虽然双向挂钩是最常见的例子,但任何商业之间的通信都可以用同样的方法进行。 




公有/私有通信

通过跨链通信,私有区块链可以与公有区块链进行安全的双向通信。这使得各种不适合公有性质的传统区块链应用成为可能。例如,有人可以创建瑞士银行的区块链,除了银行业主和个人之外,对每个人都是超级秘密。




开发进展

为了交付我们的公共测试网络,我们将开发划分为两条平行路径,以便我们可以重构代码的重要部分以实现可读性、性能和跨链通信。这个重构工作已经在eos-noon分支上开展。

在过去的更新中,我们表示我们打算专注于共享内存架构,以便开发人员可以轻松地与其他合约执行同步读取访问和原子事务。这种方法的后果是丧失了单台高性能机器的水平扩展性。

借助EOS Dawn 3.0,我们将通过使用最多65000个不同的分区region来恢复执行多机横向扩展的能力。所有分区将共享相同的帐户和合约代码,但在内存数据库中是独立的。一个分区内的合同必须使用异步交易与其他分区的合作伙伴进行通信。有了这个架构,一个块生产者可以作为一个集群来实现。




集成苹果的安全硬件

在上次更新中,我们宣布了我们打算支持Apple,Android和许多智能卡使用的椭圆曲线。我们的eos-noon分支现在包括一个全功能的验证概念,在最新的MacBook Pro上使用Touch ID(也包括Face ID)对消息进行签名和验证。类似的代码也适用于本机iPhone应用程序。这意味着基于EOS.IO的移动应用将成为已知最安全的区块链钱包 

此外,eos-noon分支现在已经整合了对多种签名类型的支持,这意味着可以使用安全硬件来签名需要在eos-noon上进行验证的交易。




500毫秒区块确认

在我们的eos-noon分支上,我们对底层的DPOS框架实施了一些改变,以支持500 ms的块(每秒2个块)。这一变化将大大提高去中心化应用程序的响应速度。为了实现这一点,我们在区块调度发生方面进行了一些改变。

同一个生产者将连续生产12块,然后交给下一个生产者。这解决了从生产者到生产者交接的块生产中最大的瓶颈。在新的结构下,意外延迟可能会导致每次切换时都会丢失几个块,但是在切换之间应该有非常快的确认。我们将尝试不同的交接期。交接期时间越长,在正常操作期间丢失的块越少,但是如果单个节点停机,则停机时间越长。在500毫秒的时间内,每隔12个区块,“停机时间”也不会比单个生产者在Steem和BitShares上丢失单个区块时更差。在这种情况下,首次确认可能需要6秒。




去除替补生产者

跨链通信需要轻客户端跟踪活跃生产者集合发生变化的所有区块。“替补生产者名录”造成每分钟会增加或删除一个新生产者,这迫使轻客户每分钟处理至少一个块头。为了减少生产者变更的频率,我们改变了区块调度结构,只包括前21名生产者。我们正在考虑为替补生产者提供某种待命薪酬,但他们实际上不会负责生产区块。




一秒不可逆

每个区块生产者将签署每个区块,只要大于2/3的生产者签署了该区块,这个区块就可以被标记为不可逆的。生产者只能在每个块高度上签署一个块头。这意味着,如果有分叉,生产者不能在两条分叉的相同高度上签名区块。任何这样的签名都是生产者不当行为的密码证明,可以通过多种方法处理,包括自动丧失生产者地位,潜在的抵押损失,以及仲裁可能造成的损害赔偿责任。 

不像其他协议需要在出下一个块之前收集大于2/3的签名,EOS的DPOS流水线允许区块链在“等待状态”中前进而签名收集。这些额外的签名发生在区块链之外,并且在Steem或BitShares的传统DPOS规则下,区块在变得不可逆转之后可以进行修剪。

在这个模型下,有可能实现拜占庭容错,因为任何块不可能接收到大于2/3的非拜占庭节点的密码证据签名。




删除生产者洗牌计划

为了最小化生产者切换期间丢失块数量,我们希望可以最小化两个生产者之间的延迟。如果纽约的生产者计划跟随中国的生产者,在正常情况下(块间隔的50%)可能需要250ms的时间才能接收到该数据块,如果网络拥堵,可能需要更长的时间。另一方面,纽约和得克萨斯州的生产者只有50ms的延迟(块间隔的10%)。这意味着在从纽约到德克萨斯的交接比从纽约到中国的路由丢失的可能性要低得多。

如果我们安排从纽约到德克萨斯州、加利福尼亚州、夏威夷、日本、中国、印度、以色列、意大利、英国、冰岛,然后回到纽约的区块生产,那么从来没有超过50到100ms。但是,如果顺序是随机的,那么平均交接时间将显著增高。

生产者洗牌被引入,以最大限度地减少一个生产者选择后续生产者的潜力。这个风险存在于一个生产者被认为是恶意的世界,但在高度审查公有的生产者与高品质的数据中心的世界里,它不再有意义。如果一个生产者故意伤害他的邻居,会有宪法和可预期的行为流程来解决争端。

在EOS下,生产者将以平均等待时间最小化的方式对生产者排序进行投票,把网络拥塞而导致的总丢失块最小化。




已知的问题

EOS Dawn 2.0 存在一些已知的问题,不过早期版本出现严重的不稳定性也在预料之内。 这次发布的目的在于展示基本功能,在未来的 6 个月,我们的团队将会致力于解决 bug,提高稳定性和性能。

为了支持测试网络的稳定性,我们已经禁止了生产者投票。




结束语

在这里要感谢我们的开发团队,为了开发交付 EOS Dawn 2.0,全球范围内展开了通力工作,,这是一个将成为最强大,性能最高,最分散的应用平台的 alpha 版本。 我们正在按照我们发布的路线图执行,并提供比原计划更多的功能和能力。 我们期待到2018年,并且有信心在EOS令牌分发完成之前,所有功能都将完成并解决错误。
 
转自因特链 查看全部
译者:岳利鹏、许莉,原文:https://steemit.com/eos/%40eos ... pdate




EOS.IO Dawn 2.0 已经发布,此次发布提供了由 block.one 团队维护的一个公开测试网络,对于 2017 年秋季路线图,以及原定于 2017 年 12 月 21 日前完成的大部分功能,此次发布也都提供了 Alpha 实现。正如我们路线图所公布的,“第二阶段 - 最小可行测试网络”将在 2017 年秋季之前展示如下内容:

- P2P 网络代码

- wasm 检测和 CPU 沙盒

- 资源利用跟踪/限制率

- 创世块导入测试

- 链间通信

目前,我们已经完成了大部分功能的初步实现。但是,由于并行开发路线的安排,链间通信的实现在一个单独的分支上进行,所以初始测试网络将不会用上链间通信的功能。

如果您对 EOS.IO Dawn 2.0 的性能测试感兴趣,可以在 Github 仓库找到启动和操作一个私有网络的所有区块链和网络代码。我们的内部测试表明,在普通硬件上,单线程实现可以承受每秒数千次传输和可处理多个块。即便如此,对于一些已知的攻击方式,我们还没有实现对应的解决方案。比如,首次编译新合约可能需要 34 ms,如果被利用,可能导致网络以超过 30 TPS 的交易速率碎片化。

针对这个问题,我们的解决方案是限制合约代码更新的频率,并限制代码更新与处理使用新代码交易之间的时间延迟。这个时间延迟将在 60 秒左右,以期能够让所有的块生产者有时间从 web assembly 中编译/缓存优化后的 x86 指令。

由于这些不可忽视的攻击方式,私有测试网络的其中一项任务仍然是性能测试,但是功能测试现在已经可以在公开测试网上进行了,我们已经将公开测试网人为地限制在 30 TPS,以确保正常的运行时间和访问。

在接下来的 6 个月里,我们将不断对网络进行测试和调试,以提高稳定性和性能。
Dawn 2.0的新特征

初始状态导入测试


我们实现了一个快照工具,它将根据分布在以太坊网络上 EOS ERC-20代币来导入初始状态。我们的测试网络只包含了注册有效EOS公钥的余额。大概有20%的ERC-20代币已经注册到了一个EOS的公钥中。我们的快照还为以太坊账户所有未注册的ERC-20代币提供了一个恢复工具,这个工具可帮我们从已签署的以太坊交易中恢复公钥。这包含了99%的EOS ERC-20代币,但是还将需要你导入你的以太坊私钥到你的EOS.IO的钱包里。

出于安全考虑,我们的测试网络不会要求用户导入他们的以太坊私钥然后通过恢复工具进行恢复。如果你的EOS私钥在测试的时候受到威胁,你可以随时在以太坊网络上注册一个新密钥。
 
代币“水龙头”

我们还实现了一个“水龙头”功能,这样就可以允许那些没有代币或者还没有注册一个有效的EOS公钥的人们进行网络测试。




资源使用和费率限制

我们实现了基本的费率限制和资源使用追踪。它追踪带宽、数据库存储以及计算力使用。这个时候我们的费率限制算法存在着一些已知的bugs,但是这不会影响测试和应用程序的开发。

我们知道有很多人都很关心费率限制相关信息,比如谁将会被收费,还有如何将它们的代币租出去以此换来收益等等。




带宽

所有的交易都会消耗掉区块生产者设置的网络带宽的最大值。拥有交易权的所有账户会根据交易的大小把3天内的流量累加。想获得带宽会要求授权账户(不是合约)抵押代币或由应用程序提供者委托代币。




计算带宽

所有的交易都消耗计算力。计算可以是并行地进行的,所以你可以把它想象成多个车道的高速公路,每个车道都拥有不同的拥挤程度。每个范围(车道)都会有自己独立的速率限制,并且基于最拥挤的程度,用户将针对同时请求的范围(通道)数量和速率限制来计费O(S^2)。




数据库存储

EOS.IO合约有访问内存数据库的权限,它们可以在该数据库存储状态。合约收费是根据它们存储数据的总和以及每个独立数据库条目的固定开销 ,这个内存数据库是独立的并且与EOS.IO的存储协议是分开的,这样做是为了让内存的膨胀不那么集中。




P2P 网络代码

对于mesh网络代码,我们已经有了基本实现,并且这些代码正在公开测试网络中试运行。目前 Block.one 运行了 21 个独立的服务器,每个服务器都配置了一个初始生产者。




EOS黎明3.0

EOS Dawn 3.0将通过安全的区块链间通信,重新解释单链水平扩展和无限扩展。有了这两个特点,对于区块链技术可以建立什么样的东西,以及区块链网络如何去中心化就都没有限制了。




无限扩展与无限去中心化

区块链技术的圣杯是在两个独立区块链之间实现安全通信,而不需要某一区块链验证另一个区块链上的所有内容。这需要使一个区块链成为另一个区块链的轻客户端。

轻客户端只使用块头和Merkle证明来验证交易。 EOS.IO将成为第一个支持轻客户端验证的POS协议。更重要的是,它将能首次产生Proof-of-Completeness。这意味着您可以证明您已经提前收到来自其他链的所有相关消息,无需等待或接受挑战的时间。

而传统的轻客户端必须处理所有的块头,EOS.IO将使轻客户端只需要当出块人改变、或需要一个更近块的新消息时再处理块头。这将使得高效率的频繁通信成为可能。在最坏的情况下,两个区块链每500毫秒一次通信的开销将比发送的消息总数高出约2个交易。

在这种模式下,只要至少有三分之一的生产者是诚实的,通信就会得到保证。此外,即使一个生产者腐败,如果他们签署任何可能破坏轻客户(或者叫外部区块链)的消息,他们会自动受到惩罚。

最后,传递到另一个区块链的往返时间取决于每个链不可逆的最终确定性等待时间。一个基于EOS.IO的链将能够发送一条消息给外部的EOS.IO链,并在3秒内得到一个密码学验证的响应。

这种级别的链间通信和安全性使得能够以非常低的延迟在链之间创建双向挂钩。虽然双向挂钩是最常见的例子,但任何商业之间的通信都可以用同样的方法进行。 




公有/私有通信

通过跨链通信,私有区块链可以与公有区块链进行安全的双向通信。这使得各种不适合公有性质的传统区块链应用成为可能。例如,有人可以创建瑞士银行的区块链,除了银行业主和个人之外,对每个人都是超级秘密。




开发进展

为了交付我们的公共测试网络,我们将开发划分为两条平行路径,以便我们可以重构代码的重要部分以实现可读性、性能和跨链通信。这个重构工作已经在eos-noon分支上开展。

在过去的更新中,我们表示我们打算专注于共享内存架构,以便开发人员可以轻松地与其他合约执行同步读取访问和原子事务。这种方法的后果是丧失了单台高性能机器的水平扩展性。

借助EOS Dawn 3.0,我们将通过使用最多65000个不同的分区region来恢复执行多机横向扩展的能力。所有分区将共享相同的帐户和合约代码,但在内存数据库中是独立的。一个分区内的合同必须使用异步交易与其他分区的合作伙伴进行通信。有了这个架构,一个块生产者可以作为一个集群来实现。




集成苹果的安全硬件

在上次更新中,我们宣布了我们打算支持Apple,Android和许多智能卡使用的椭圆曲线。我们的eos-noon分支现在包括一个全功能的验证概念,在最新的MacBook Pro上使用Touch ID(也包括Face ID)对消息进行签名和验证。类似的代码也适用于本机iPhone应用程序。这意味着基于EOS.IO的移动应用将成为已知最安全的区块链钱包 

此外,eos-noon分支现在已经整合了对多种签名类型的支持,这意味着可以使用安全硬件来签名需要在eos-noon上进行验证的交易。




500毫秒区块确认

在我们的eos-noon分支上,我们对底层的DPOS框架实施了一些改变,以支持500 ms的块(每秒2个块)。这一变化将大大提高去中心化应用程序的响应速度。为了实现这一点,我们在区块调度发生方面进行了一些改变。

同一个生产者将连续生产12块,然后交给下一个生产者。这解决了从生产者到生产者交接的块生产中最大的瓶颈。在新的结构下,意外延迟可能会导致每次切换时都会丢失几个块,但是在切换之间应该有非常快的确认。我们将尝试不同的交接期。交接期时间越长,在正常操作期间丢失的块越少,但是如果单个节点停机,则停机时间越长。在500毫秒的时间内,每隔12个区块,“停机时间”也不会比单个生产者在Steem和BitShares上丢失单个区块时更差。在这种情况下,首次确认可能需要6秒。




去除替补生产者

跨链通信需要轻客户端跟踪活跃生产者集合发生变化的所有区块。“替补生产者名录”造成每分钟会增加或删除一个新生产者,这迫使轻客户每分钟处理至少一个块头。为了减少生产者变更的频率,我们改变了区块调度结构,只包括前21名生产者。我们正在考虑为替补生产者提供某种待命薪酬,但他们实际上不会负责生产区块。




一秒不可逆

每个区块生产者将签署每个区块,只要大于2/3的生产者签署了该区块,这个区块就可以被标记为不可逆的。生产者只能在每个块高度上签署一个块头。这意味着,如果有分叉,生产者不能在两条分叉的相同高度上签名区块。任何这样的签名都是生产者不当行为的密码证明,可以通过多种方法处理,包括自动丧失生产者地位,潜在的抵押损失,以及仲裁可能造成的损害赔偿责任。 

不像其他协议需要在出下一个块之前收集大于2/3的签名,EOS的DPOS流水线允许区块链在“等待状态”中前进而签名收集。这些额外的签名发生在区块链之外,并且在Steem或BitShares的传统DPOS规则下,区块在变得不可逆转之后可以进行修剪。

在这个模型下,有可能实现拜占庭容错,因为任何块不可能接收到大于2/3的非拜占庭节点的密码证据签名。




删除生产者洗牌计划

为了最小化生产者切换期间丢失块数量,我们希望可以最小化两个生产者之间的延迟。如果纽约的生产者计划跟随中国的生产者,在正常情况下(块间隔的50%)可能需要250ms的时间才能接收到该数据块,如果网络拥堵,可能需要更长的时间。另一方面,纽约和得克萨斯州的生产者只有50ms的延迟(块间隔的10%)。这意味着在从纽约到德克萨斯的交接比从纽约到中国的路由丢失的可能性要低得多。

如果我们安排从纽约到德克萨斯州、加利福尼亚州、夏威夷、日本、中国、印度、以色列、意大利、英国、冰岛,然后回到纽约的区块生产,那么从来没有超过50到100ms。但是,如果顺序是随机的,那么平均交接时间将显著增高。

生产者洗牌被引入,以最大限度地减少一个生产者选择后续生产者的潜力。这个风险存在于一个生产者被认为是恶意的世界,但在高度审查公有的生产者与高品质的数据中心的世界里,它不再有意义。如果一个生产者故意伤害他的邻居,会有宪法和可预期的行为流程来解决争端。

在EOS下,生产者将以平均等待时间最小化的方式对生产者排序进行投票,把网络拥塞而导致的总丢失块最小化。




已知的问题

EOS Dawn 2.0 存在一些已知的问题,不过早期版本出现严重的不稳定性也在预料之内。 这次发布的目的在于展示基本功能,在未来的 6 个月,我们的团队将会致力于解决 bug,提高稳定性和性能。

为了支持测试网络的稳定性,我们已经禁止了生产者投票。




结束语

在这里要感谢我们的开发团队,为了开发交付 EOS Dawn 2.0,全球范围内展开了通力工作,,这是一个将成为最强大,性能最高,最分散的应用平台的 alpha 版本。 我们正在按照我们发布的路线图执行,并提供比原计划更多的功能和能力。 我们期待到2018年,并且有信心在EOS令牌分发完成之前,所有功能都将完成并解决错误。
 
转自因特链

EOS 编译、测试指南(五) --EOS 节点分类浅析

EOS代码分析郑浩 发表了文章 • 0 个评论 • 580 次浏览 • 2017-11-07 16:26 • 来自相关话题

EOS 团队于 2017 年 9 月 14 日推出了 Dawn 1.0 release 版本,熟悉 Linux 和 C++的开发人员可以在此基础上尝试自己的合约开发了。OracleChain 团队一直以 来都在对 EOS 代码进行了编译和测试,陆续发布了四份《EOS 编译、测试指南》, 详细介绍了 EOS 的入门知识、基本结构,帮助开发人员学习、研究 EOS。 基于 EOS 刚刚推出的 Dawn 1.0,OralceChain 团队进行了测试,本次将以节 点功能为例,详细介绍 EOS 上不同节点服务之间的区别,基于此开发人员可以根 据自己的业务需求,在 EOS 网络上运行自定义节点,从而参与、利用 EOS 网络 为外部提供服务。 该指南主要依据 EOS 的官方文档,以及欧链团队的实践经验编写,开发者有 任何技术问题可以关注欧链小秘书、在欧链科技社区里向 OracleChain 团队提问 或者发送邮件到 contact@oraclechain.io。
 EOS 文档:https://eosio.github.io/eos/ 
EOS 代码:https://github.com/EOSIO/eos 
备注:OracleChain 团队使用 Mac 环境进行开发。
 
上一章中,我们通过源码研究了 EOS 合约执行机制。合约执行内容主要包括 三方面:合约发布和存储,合约执行环境的数据存取接口,以及状态数据持久化 等。依靠 web assemble 沙盒技术,让合约拥有与 native code 一样的执行速度。 与 bitcoin 相似,EOS 各节点通过 P2P 网络互联,相互传递 block 信息,任何 一个节点都可以参与验证和转发 block 信息,从而达成全网共识。而与 bitcoin 不同的是,EOS 内部采用 DPOS 的出块机制。每个节点可以选出代理,或者直 接投票,选出其信任的 21 个出块节点。这样做,既避免了出块权过于集中,又保证了共识机制不至于分叉(投票表决)。同时,这种投票保证的信任机制避免 了计算资源的浪费,将资源真正运用到 DAPP 的服务中。因此,我们可以把 EOS 合约,当作一个运行在“云”上的服务 
 
 
一、EOS 节点的功能和分类
 EOS 网络中,所有节点都可以参与验证/转发交易和区块,发现和维护一个 点对点网络。 EOS 网络节点可根据函数功能分为四个集合。开发者可以组合不同的集合, 发布符合自己需求的节点,加入到 EOS 网络中,再由这个节点为最终用户提供更 多差异化服务。
 
二、network(转发路由)
 所有节点都包含转发路由模块。通过这个模块,节点可以加入到 EOS 网络 中,参加对交易和区块的验证,发现和共享 p2p 连接池。另外,如果要投票或选 择代理人选出出块节点,就可以通过组合其他模块来实现。 要启动只带有转发和验证功能的节点,我们只需要在启动 eosd 的时候注释掉所有 plugin。config.ini 如下:
 
三、producer(验证出块) 
只有出块节点包含有效的 producer function。出块节点可以根据自己的资源 提供交易和存储服务。普通节点根据节点的价值偏好(可以是资源对应 token 的 单价),投票选出出块节点。选出的出块节点将组成一个网络,任意一个出块时 间段内,只有一个出块节点被全网授权去验证交易,并将交易打包成块。最后, block 被转发到其他节点验证和转发,全网达成共识。 启动一个 producer 节点时,需要在 config.ini 文件中启动 producer plugin,并 且配置出块节点相关数据:
 
四、wallet(保存私钥和发起交易)
 钱包用户都需要有 wallet api 来维护自己的 EOS 智能资产,例如桌面端的 EOS 客户端、钱包 app 等。对于资源吃紧的手机终端的钱包 app 来讲,由于不能保存 所有的账户信息,所以只保留用户相关的数据,并使用类似比特币的 SPV 技术,远程拉取交易所需信息并发出交易。 在 EOS 源码中,wallet 以 plugin 的形式提供对外服务,我们可以使用 eosc 对 这些接口进行简单调用。
在配置中,也需要指定加载 wallet plugin
 
五、blockchain functions(账号状态和交易历史)
 通常只有全节点才会使用 blockchain functions。blockchain 模块实际包含两 部分数据,一部分是保存着所有账号的状态机,另一部分是保存着所有历史交易 的 block 数据。全节点依靠自身保存的完整的账号状态和交易历史,可以在本地 独立地验证所有交易。 举个例子,对于出块节点来说,不一定会带有 wallet 模块,但一定会有带有 blockchain 模块。blockchain 模块是出块节点产生共识的基础数据,出块节点只有 遵守共识,产生的 block 数据才会被区块链所接受。 blockchain 模块也通过 http api 对外提供查询接口,我们可以使用 eosc 对这 些接口进行调用:
 
六、总结 
在 EOS 目前的版本之上,我们已经可以初步的搭建自己的测试网络,完成区 块链基本功能测试。我们相信再不久的将来,基于 EOS,将会开发出丰富的区块 链应用。
 
OracleChain 团队 2017 年 11 月 1 日
 
转自:欧链科技
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  查看全部
EOS 团队于 2017 年 9 月 14 日推出了 Dawn 1.0 release 版本,熟悉 Linux 和 C++的开发人员可以在此基础上尝试自己的合约开发了。OracleChain 团队一直以 来都在对 EOS 代码进行了编译和测试,陆续发布了四份《EOS 编译、测试指南》, 详细介绍了 EOS 的入门知识、基本结构,帮助开发人员学习、研究 EOS。 基于 EOS 刚刚推出的 Dawn 1.0,OralceChain 团队进行了测试,本次将以节 点功能为例,详细介绍 EOS 上不同节点服务之间的区别,基于此开发人员可以根 据自己的业务需求,在 EOS 网络上运行自定义节点,从而参与、利用 EOS 网络 为外部提供服务。 该指南主要依据 EOS 的官方文档,以及欧链团队的实践经验编写,开发者有 任何技术问题可以关注欧链小秘书、在欧链科技社区里向 OracleChain 团队提问 或者发送邮件到 contact@oraclechain.io。
 EOS 文档:https://eosio.github.io/eos/ 
EOS 代码:https://github.com/EOSIO/eos 
备注:OracleChain 团队使用 Mac 环境进行开发。
 
上一章中,我们通过源码研究了 EOS 合约执行机制。合约执行内容主要包括 三方面:合约发布和存储,合约执行环境的数据存取接口,以及状态数据持久化 等。依靠 web assemble 沙盒技术,让合约拥有与 native code 一样的执行速度。 与 bitcoin 相似,EOS 各节点通过 P2P 网络互联,相互传递 block 信息,任何 一个节点都可以参与验证和转发 block 信息,从而达成全网共识。而与 bitcoin 不同的是,EOS 内部采用 DPOS 的出块机制。每个节点可以选出代理,或者直 接投票,选出其信任的 21 个出块节点。这样做,既避免了出块权过于集中,又保证了共识机制不至于分叉(投票表决)。同时,这种投票保证的信任机制避免 了计算资源的浪费,将资源真正运用到 DAPP 的服务中。因此,我们可以把 EOS 合约,当作一个运行在“云”上的服务 
 
 
一、EOS 节点的功能和分类
 EOS 网络中,所有节点都可以参与验证/转发交易和区块,发现和维护一个 点对点网络。 EOS 网络节点可根据函数功能分为四个集合。开发者可以组合不同的集合, 发布符合自己需求的节点,加入到 EOS 网络中,再由这个节点为最终用户提供更 多差异化服务。
 
二、network(转发路由)
 所有节点都包含转发路由模块。通过这个模块,节点可以加入到 EOS 网络 中,参加对交易和区块的验证,发现和共享 p2p 连接池。另外,如果要投票或选 择代理人选出出块节点,就可以通过组合其他模块来实现。 要启动只带有转发和验证功能的节点,我们只需要在启动 eosd 的时候注释掉所有 plugin。config.ini 如下:
 
三、producer(验证出块) 
只有出块节点包含有效的 producer function。出块节点可以根据自己的资源 提供交易和存储服务。普通节点根据节点的价值偏好(可以是资源对应 token 的 单价),投票选出出块节点。选出的出块节点将组成一个网络,任意一个出块时 间段内,只有一个出块节点被全网授权去验证交易,并将交易打包成块。最后, block 被转发到其他节点验证和转发,全网达成共识。 启动一个 producer 节点时,需要在 config.ini 文件中启动 producer plugin,并 且配置出块节点相关数据:
 
四、wallet(保存私钥和发起交易)
 钱包用户都需要有 wallet api 来维护自己的 EOS 智能资产,例如桌面端的 EOS 客户端、钱包 app 等。对于资源吃紧的手机终端的钱包 app 来讲,由于不能保存 所有的账户信息,所以只保留用户相关的数据,并使用类似比特币的 SPV 技术,远程拉取交易所需信息并发出交易。 在 EOS 源码中,wallet 以 plugin 的形式提供对外服务,我们可以使用 eosc 对 这些接口进行简单调用。
在配置中,也需要指定加载 wallet plugin
 
五、blockchain functions(账号状态和交易历史)
 通常只有全节点才会使用 blockchain functions。blockchain 模块实际包含两 部分数据,一部分是保存着所有账号的状态机,另一部分是保存着所有历史交易 的 block 数据。全节点依靠自身保存的完整的账号状态和交易历史,可以在本地 独立地验证所有交易。 举个例子,对于出块节点来说,不一定会带有 wallet 模块,但一定会有带有 blockchain 模块。blockchain 模块是出块节点产生共识的基础数据,出块节点只有 遵守共识,产生的 block 数据才会被区块链所接受。 blockchain 模块也通过 http api 对外提供查询接口,我们可以使用 eosc 对这 些接口进行调用:
 
六、总结 
在 EOS 目前的版本之上,我们已经可以初步的搭建自己的测试网络,完成区 块链基本功能测试。我们相信再不久的将来,基于 EOS,将会开发出丰富的区块 链应用。
 
OracleChain 团队 2017 年 11 月 1 日
 
转自:欧链科技