关注公众号
随时掌握最新区块链知识

区块链入门、投资、套利增值的百科全书,从这里起飞!

站长QQ:61506546

EOS正式版技术白皮书(中文)一

ID:381 / 打印

导读

EOS即将震撼来袭,重磅干货技术白皮书为您奉上!



EOS.IO技术白皮书 

作者:block.one

2017年6月5号

翻译:Harvey老狼、谭智勇、宋承根@OracleChain,梓岑@YOYOW

 

本中文白皮书翻译自EOS白皮书英文版,如果有表述不一致的地方,以英文版本为准。

 

摘要

EOS.IO软件引入了一种新的块链架构,旨在实现分布式应用的性能扩展。这是通过创建一个可以构建应用程序的类似操作系统的架构来实现的。该软件架构提供帐户,身份验证,数据库,异步通信以及在数以百计的CPU或群集上的程序调度。该技术的最终形式是一个块链体系架构,该区块链每秒可以支持数百万个交易,同时普通用户无需支付使用费用。

1. 背景 

Blockchain技术源于2008年推出的比特币,自那时以来,企业家和开发人员一直在努力推广该技术,以便在单个块链平台上支持更广泛的应用。 

虽然一些通用区块链平台还在努力实现第一个能正常运行的区块链应用,针对特定场景的区块链应用诸如BitShares去中心化交易所(2014)和Steem社交媒体平台(2016)已经成为日活跃用户上万的成功应用。 这两个应用成功的把性能提高到每秒数千个交易,延迟降低到1.5秒,降低交易费用,并实现了与中央服务器方案相似的用户体验。 

由于现有的块链平台使用费用高昂,性能有限,阻碍了区块链应用的广泛传播。 

2. 区块链应用的要求 

成为一个成功的区块链应用平台块,应该需要满足以下要求: 

支持百万级别用户

如Ebay,Uber,AirBnB和Facebook这样的应用,需要能够处理数千万日活跃用户的区块链技术。 在某些情况下,应用程序可能无法正常工作,除非达到了大量用户,因此可以处理大量用户数量的平台至关重要。 

免费使用

有时候应用开发人员需要灵活的为用户提供免费服务; 用户不必为了使用平台而付出费用。可以免费使用的块链平台自然可能会得到更多的关注。有了足够的用户规模,开发者和企业可以创建对应的盈利模式。

轻松升级和Bug恢复

基于块链的应用程序在进行功能迭代的时候自然需要能支持软件升级。所有软件都有可能受到bug的影响。一个区块链底层平台在遭遇bug的时候,需要能够从bug中修复错误。

低延迟

及时的反馈是良好用户体验的基础。延迟时间如果超过了几秒钟,会大大影响用户体验,严重降低程序的竞争力。

串行性能

有些应用程序由于命令执行必须是顺序的,从而无法用并行算法进行实现。诸如交易所之类的应用经常需要处理大量的串行操作,因此一个成功的区块链架构需要具有强大的串行性能。

并行性能

大规模应用程序需要在多个CPU和计算机之间划分工作负载。

3. 共识算法(DPOS) 

EOS.IO软件架构中采用目前为止唯一能够复合上述性能要求的区块链共识算(DPOS)。根据这种算法,全网持有代币的人可以通过投票系统来选择区块生产者,一旦当选任何人都可以参与区块的生产。 

EOS.IO里预计每3秒生产一个区块。任何时刻,只有一个生产者被授权产生区块。如果在某个时间内没有成功出块,则跳过该块。 

EOS.IO架构中区块产生是以21个区块为一个周期。在每个出块周期开始时,21个区块生产者会被投票选出。前20名出块者首选自动选出,第21个出块者按所得投票数目对应概率选出。所选择的生产者会根据从块时间导出的伪随机数进行混合。以便保证出块者之间的连接尽量平衡。

如果出块者错过了一个块,并且在最近24小时内没有产生任何块,则这个出块者将被删除。这确保了网络的顺利运行。 

在正常情况下,DPOS块链不会经历任何叉,因为块生产者合作生产区块而不是竞争。如果有区块分叉,共识将自动切换到最长的链条。具有更多生产者的区块链长度将比具有较少生产者的区块链增长速度更快。此外,没有块生产者应该同时在两个区块链分叉上生产块。如果一个块生产者发现这么做了,就可能被投票出局。

交易确认

由DPOS共识算法维护的区块链一般出块者都是100%在线的。这就是说一个交易平均1.5秒后,会被写入区块链中,同时被所有出块节点知晓这笔交易。这就意味着只需要1.5秒,一笔交易可以认定为99.9%被区块链接收了。 

有一些非常情况下例如,软件bug,Internet拥塞或恶意出块者出现,区块链可能出现分叉。为了确保一个交易是不可逆转的,可以等待15个区块确认。根据EOS.IO软件的配置,在正常情况下15个区块确认平均需要45秒。 

在分叉产生的9秒钟内,出块节点就可能发现这个分叉可能并警告用户。一个节点观察网络的时候如果发现连续2次的丢块事件,这意味着改节点由95%可能性在区块链的分叉分支上。有出现3个连续的丢块以后,该节点有99%的可能性在一条分叉出来的区块链上。可以生成一个预测模型,它将利用节点丢失的信息,最近的参与率以及其他因素来快速地警告用户出现什么问题。

对这种警告的反应完全取决于业务交易的性质,但最简单的反应是等待15/21确认,直到警告停止。 

交易证明(TaPoS)

EOS.IO软件要求每个交易都包括最近的区块头的哈西。 这个哈希有两个目的:

1.防止分叉区块链上出现大量交易记录;

2.使得系统能感知到用户是否在分叉出来的区块链上

随着时间的推移,所有用户最终直接确认块链,这使得难以伪造假冒链,因为假冒将无法从合法链路迁移交易。

4. 帐户 

EOS.IO软件允许使用唯一的长度为2到32个字符的可读的名称来实现对帐户的引用。该名称由帐户的创建者自行选择。所有帐户必须在创建时必须充入最小的帐户余额以支付存储帐户数据的费用。帐户名称还支持命名空间,因此帐户@domain的所有者是唯一可以创建帐户@user.domain的用户。

在去中心化的情况下,应用程序开发人员将支付创建帐户名义上的成本以注册新用户。通常企业已经以广告和免费服务等形式为获取每个客户花费了大量资金。相比之下,创建新的区块链帐户所需的资金成本是微不足道的。并且幸运的是,没有必要为已经由另一个应用程序注册的用户创建帐户。

消息和消息处理程序

每个帐户可以将结构化消息发送到其他帐户,并且可以定义消息被接受后的处理脚本。EOS.IO软件为每个帐户提供其自己独有的数据库,只能由自己的消息处理程序访问。消息处理脚本还可以向其他帐户发送消息。消息和自动的消息处理程序的组合正是EOS.IO定义智能合约的方式。

基于角色的权限管理

权限管理主要涉及明确特定的消息是否被正确授权。权限管理的最简单形式是检查事务是否具有所需的签名,但这隐含着所需的签名是已知的。通常权力是与可以分类的个人或个人群组绑定在一起的。EOS.IO软件提供了一个声明式权限管理系统,可以让帐户细粒度和高级别地控制谁在何时能够做什么。

至关重要的是,身份认证和权限管理被标准化实现,并与应用程序的业务逻辑分离。这使得开发某种工具以通用方式管理权限成为可能,并为性能优化提供了巨大的空间。

每个帐户都可以通过其他帐户和私钥的任何加权组合来控制。这种机制创建了一个能够真实反映权限在现实中的组织情况的层次化权限结构,并使得多用户对资金的控制比以往任何时候都更容易。多用户控制是提升安全性的最重要因素,如果能正确地使用,可以极大地消除黑客盗窃的风险。

EOS.IO软件允许帐户可以定义与其他帐户密钥的“and”和“or”的组合,并且把这个组合以将特定类型的消息发送到另一个帐户。例如,可以为用户的社交媒体帐号提供一个密钥,另一个用于交易。甚至用户可以给予其他帐户许可让其代表自己的帐户行事,而无需向其他帐户分配密钥。 

命名权限级别 

使用EOS.IO软件,帐户可以定义命名权限级别,每个权限级别可以从更高级别的命名权限派生。每个命名权限级别定义一个权力,这个权力可以是其他帐户的密钥和(/或)命名权限级别组成的多签名检查的阈值。例如,帐户的“朋友”权限级别可以设置为帐户能被其任何朋友帐户平等地控制。

另一个例子是Steem区块链,其具有三个硬编码命名的权限别:owneractivepostingPosting权限只能执行诸如投票和发布等社交行为,而active权限可以做除了更改所有者的所有事情。owner权限实质是被保留了起来,它能够做所有一切。EOS.IO通过允许每个帐户持有者定义自己的权限层次结构以及动作的分组来实现类似的管理理念。 

命名消息处理程序组

EOS.IO软件允许每个帐户将自己的消息处理程序以命名嵌套的方式予以组织。这些命名的消息处理程序组可以通过配置其权限级别被其他帐户引用。 

最高级别的消息处理程序组是处理帐户名称的程序组,最低级别的消息处理程序组是处理该帐户正在接收的单独消息类型的程序组。这些程序组的引用格式为:@accountname.groupa.subgroupb.MessageType。 

在这种模式下,可以将创建和取消订单的交易合约与存取款的交易合约分离。这种交易合约的分组对用户使用交易合约提供了较大便利。 

权限映射

EOS.IO软件允许每个帐户定义任何帐户的命名消息处理程序组与其自己的命名权限级别之间的映射。例如,账户持有人可以将账户持有人的社交媒体应用程序映射到帐户持有者的“朋友”权限组。通过此映射,帐户的任何朋友都可以和帐户持有者一样,在帐户的社交媒体上发布内容。即使他们将作为帐户持有者发布,他们仍然会使用自己的密钥来签名。这意味着总是可以辨别出来哪些朋友以何种方式使用了其帐户。 

权限评估

当从@alice到@bob传送“Action”类型的消息时,EOS.IO软件将首先检查@alice是否为@bob.groupa.subgroup.Action定义了权限映射。如果没有找到任何结果,那么将会检查@bob.groupa.subgroup,然后是@bob.groupa,最后是@bob的映射。如果此时仍然没有找到匹配的结果,那么假定的映射将是命名的权限组@alice.active。

一旦识别出权限映射,则启动多签名阈值校验过程。如果校验成功,所命名的权限将与关联的权限建立关联。如果失败,那么它会遍历父权限,最终遍历到其所有者的权限@alice.owner。 

默认权限组

该技术还允许所有帐户都有一个可以做所有事情的“owner”权限组,和一个除了更改所有者组之外可以执行所有操作的“active”权限组。所有其他权限组均派生自“active”权限组。 

权限的并行评估

权限评估是个“只读”的过程,即使在事务过程中对权限进行了修改,在运行到区块结尾时这种修改也会失效。首先,这意味着所有事务的所有密钥和权限评估可以并行执行。其次,这种机制意味着可以快速验证权限,而不需要考虑启动可能回滚的昂贵的应用程序逻辑。最后,这意味着当挂起的事务继续执行时,事务权限的评估可以继续执行,而无需重新执行。 

这么设计考虑的主要原因,是因为权限验证占据交易验证的很大计算量比例。使之成为一个只读和可并行化的过程,可以显着提高性能。 

当区块链消息被重放,来从消息日志中重新生成确定状态时,并不需要再次评估权限。事务被包含在一个已知的状态良好的区块中的事实使其可以跳过这个步骤。这极大地减少了重放之前的区块链数据相关的计算量。 

有强制延迟的消息

时间是安全的关键组成部分。在大多数情况下,在私钥被使用前不可能知道其是否已经被盗用。基于时间的安全机制在人们使用一些特殊类型应用程序时更为关键,这些应用程序需要将密钥保存在连接到互联网的人们日常使用的计算机上。EOS.IO软件支持应用程序开发者指定某些消息在包含在区块后,实际应用之前必须等待一段比较小的时间段。在此期间,这些消息可以被取消。 

当这类消息被广播时,用户可以通过电子邮件或短信收到相应通知。如果他们不授权该消息,那么他们可以登录其帐户来还原帐户数据并撤回消息。 

所需的延迟取决于操作的重要程度。支付一杯咖啡可以毫不拖延地在几秒钟内确认,而买房子可能需要72小时清算周期。将整个帐户转移到新的控制者手上可能最多需要30天。具体延迟的选择取决于应用程序开发者和用户。 

密钥被盗后的恢复

EOS.IO软件为用户提供了一种在密钥被盗时恢复其帐户控制的方法。

帐户所有者可以使用在过去30天内活动的任何其批准的帐户恢复合作伙伴的密钥,在其帐户恢复合作伙伴的允许后,重置其帐户上的所有者密钥。在没有帐户所有者的配合情况下,帐户恢复合作伙伴无法重置其帐户的控制权。

对于攻击帐户的黑客而言,由于其已经“控制”该帐户,因此尝试执行恢复过程没有任何收获。此外,如果他们的确进行恢复的过程,那么恢复合作伙伴可能需要身份认证和多因素认证(如电话和电子邮件)。这或者会暴露黑客的身份,或者黑客在恢复过程中毫无所得。

这个过程与简单的多重签名机制有极大的不同。通过多重签名的交易,会有一个对象会执行并参与每一个交易;而通过恢复过程,恢复过程的操作者仅参与了恢复的过程,并没有权力参与日常的交易。这极大降低了相关参与者的成本和法律责任。

5. 应用程序的确定性并行执行 

区块链共识取决于确定性(可重现)行为。这意味着所有并行执行都能不能使用互斥体或其他锁的原语的情况下正常运行。没有锁,必须有一些方法来保证所有帐户只能读写自己的私有数据库。这也意味着每个帐户会顺序处理其消息,并行性确定在帐户级别。 

使用EOS.IO软件,区块生成器的工作是将消息传递到独立的线程中,以便它们可以并行地评估。每个帐户的状态只取决于传递给它的消息。调度表是区块生成器的输出,并且将被确定性地执行,但是生成调度的过程不必是确定性的。这意味着区块生成器可以利用并行算法来调度事务。

并行执行还意味着当脚本生成新消息时,它不会立即发送,而是在下一个周期中发送它。无法立即发送的原因是因为接收方可能会在另一个线程中主动修改自己的状态。 

通信延迟优化

延迟时间是一个帐户将消息发送到另一个帐户并收到响应所需的时间。EOS.IO软件的目标是使两个帐户能够在单个区块内来回交换消息,而不必在每个消息之间等待3秒。为了实现这一点,EOS.IO软件将每个区块分为周期(cycle)。每个周期分为线程(thread),每个线程包含事务列表。每个事务包含一组要传递的消息。该结构可以被可视化为树,其中各层依据其特性被顺序或者并行地进行处理。

区块Block

 周期Cycles(顺序) 

   线程Threads(并行) 

     交易Transactions(顺序)

       消息Messages(顺序)

         接收方和通知的帐户Receiver and Notified Accounts(并行)

在一个周期中生成的交易可以在任何后续周期或区块中传送。区块生成器将不断把周期添加到区块中,直到最长的区块时间间隔达到,或者没有新的可传送交易生成。

可以使用区块的静态分析来验证在给定周期内是否存在两个线程包含修改同一个帐户的事务。只要这种静态分析机制一直起作用,就可以通过并行运行所有线程来处理区块。 

只读消息处理

部分账户可能会处理一些只需要决定通过与否的消息,而不会改变自己内在状态。这种情形下,只需要有一个或多个进程包含这个特殊账户下的只读消息处理器,这些处理就能并行进行。 

多账户原子交易

有时,我们希望确保消息被多个帐户以原子方式交付和接受。在这种情况下,两个消息被放置在一个交易中,两个帐户将被分配相同的线程和消息按顺序执行。这种情况在性能上并不理想,并且当涉及到“付费”用户的使用时,他们将会被根据交易所涉及的特殊帐户的数量来收费。

出于性能和费用的考虑,最好将涉及两个或更多帐户的原子操作最小化 

部分区块链状态评估

大规模区块链技术组件应该是模块化的。每个人都不应该运行所有东西,特别是如果他们只需要使用一小部分应用程序的时候。

出于将交易状态显示给用户的目的,交易应用的开发者将维护一个完整的节点。这款交易应用不需要与其他社交媒体应用关联状态。EOS.IO系统允许任何完整的节点选择性的运行任意应用子集。传递给其他应用的消息将被安全地忽略,因为应用的状态完全来自于传递给它的消息。 

这对于多帐户之间的通信有一些重要的影响。最重要的是,不能假定另一个帐户的状态在同一台机器上是可访问的。它还意味着,虽然允许一个帐户同步调用另一个帐户的“锁”是一种诱人的设计模式,但如果其他帐户不在内存中,这种设计模式将会崩溃。 

因此,所有帐户间的状态通信必须通过区块链上的消息进行传递。 

自主最优任务安排

EOS.IO系统不能强制阻止区块生成者向其他帐户发送的任何消息。每个区块的生成者对处理交易的计算复杂度和时间复杂度都有自己的主观度量,无论这个交易是由用户生成的还是由脚本自动生成的。

在网络层面,EOS.IO系统处理的每一笔交易都有固定的计算带宽成本,不管它是耗费01ms还是10 ms来处理它。但是,使用该系统的每个单独的区块生成者会使用它们自己的算法和度量来衡量资源使用。当一个区块生成者发现一个交易或帐户已经消耗了大量的计算能力时,他们会在生成自己的块时拒绝该交易;但是,如果其他区块生成者认为它是有效的,他们仍然会处理该交易。

一般来说,只要一个区块生成者认为一个交易是有效的,并且所消耗的资源是可控的,那么其他所有的区块生成者也会接受它,但可能要花费1分钟才能使该交易传播到这个区块生成者处。

在某些情况下,区块生成者可以创建一个区块,其中包括在可接受范围之外的交易。在这种情况下,下一个区块生成者可能会选择拒绝这个区块,而这条线路将会被第三个区块生成者终结。这与一个大区块导致网络传播延迟所引发的情况没有什么不同。社区会注意到这种异常模式,并最终清理该流氓区块生成者的选票。

这种对计算、资源成本的主观评估将使区块链不必精确地去度量运行一个任务需要多长时间。有了这个设计,就不需要精确地数指令,这将极大地增加优化的机会,而不会打破共识。

6. 令牌模型和资源使用

所有的区块链都是资源受限的,并且需要一个系统来防止滥用。在EOS.IO系统中,有三大类资源被应用程序消耗: 

1.带宽和日志存储(磁盘);

2.计算和计算积压(CPU);

3.状态存储器(RAM)。 

瞬时使用和长期使用的这两类组件都会消耗带宽和计算。区块链系统将维护所有消息的日志,这些日志将会被所有的完整节点下载和存储。通过日志信息,可以重构所有应用程序的状态。 

可计债务是指通过对消息日志重新生成状态的计算消耗。如果可技债务增长太大,就有必要对区块链的当前状态进行拍照,并抛弃区块链的历史状态。如果计算债务增长过快,区块链将使用6个月的时间来重放1年的交易。因此,对可计债务进行精心管理是至关重要的。 

区块链存储的状态指那些可从应用程序逻辑访问的信息。它包括诸如订单和帐户余额等信息。如果应用程序不读取该状态,则不应该存储它。例如,博客文章的内容和注释不被应用程序逻辑读取,因此它们不应该存储在区块链的状态中。与此同时,邮件或评论的索引、投票数和其他属性将作为区块链状态的一部分被存储起来。 

区块生成者可以发布它们可用的带宽、计算资源和状态的容量。EOS.IO系统允许每个帐户在一个3天对赌合约中消耗一定比例的可用容量。例如,假设一个基于EOS.IO系统的区块链应用启动,如果一个帐户持有该区块链提供的总令牌的1%,那么这个帐户就有可利用该区块链1%的状态存储容量。

使用EOS.IO系统,带宽和计算能力将被分配到部分储备基础中,因为它们是短暂的(未使用的容量不能存储下来为将来使用)。EOS. IO系统将使用类似于Steem的算法来限制带宽使用速率。

目标和主观度量

正如前面所讨论的,可度量计算的使用对性能和优化有很大的影响;因此,所有资源的使用限制最终都是主观的,并且根据各自的算法和估计来执行。 

也就是说,从客观角度来说,有些事情是微不足道的。站在客观的角度,传递的消息数量和存储在内部数据库中的数据的大小都是很便宜的。EOS.IO系统允许区块生成者能够在这些客观度量上应用相同的算法,但是也可以在主观度量上选择更严格的主观算法。 

接收方支付

传统上,它是用来支付办公空间、计算电力以及运营业务所需的其他费用的业务。客户从该业务中购买特定产品,而这些产品的销售收入将用于支付业务成本。同样,没有任何网站要求访问者为维护服务器而支付小额费用。因此,分散的应用程序不应该强迫它的客户直接为使用区块链支付费用。

EOS.IO系统不要求用户直接向区块链支付,因此不限制或阻止企业确定其产品的货币化策略。

授权能力

如果一个区块链是使用EOS.IO系统开发的,而其令牌是由一个持票人持有,他可能不需要立即消耗全部或部分可用带宽,这样的持有者可以选择将未消耗的带宽给予或租给他人;使用EOS.IO 系统的区块生成者将识别这样的授权并直接分配相应的带宽。

将交易成本与令牌价值分开

EOS.IO系统的主要优点之一是,应用程序可用的带宽完全独立于任何令牌价格。如果应用程序所有者持有相应数量的令牌,那么应用程序可以在固定的状态和带宽使用中持续运行。开发人员和用户不会受到令牌市场价格波动的影响,因此不会依赖于价格。EOS.IO系统运行区块生成者能够自然地增加带宽、计算资源和每个令牌的可用性,这与令牌的价值无关。

EOS.IO系统将奖励那些生成了区块的区块生成者一定的令牌。令牌的值将影响一个区块生成者能够购买的带宽、存储和计算量;这个模型自然会利用上升的令牌价值来提高网络性能。 

状态存储成本

因为带宽和计算资源可以被委托,因此应用程序状态的存储要求应用的开发者持有令牌直到该状态被删除。如果状态不被删除,那么令牌将被有效地从循环中删除。

每个用户帐户需要一定数量的存储空间;因此,每个帐户必须保持最低余额。随着网络存储容量的增加,最低余额的要求将会下降。 

块奖励

每次生成一个块时,EOS.IO系统都会奖励该区块生成者一个新的令牌。所创建的令牌数量由所有区块生成者所公布的期望报酬的中位数决定。EOS.IO系统可能被配置为限制区块生成者所得奖励上限,这样,令牌供应的年总增长不超过5%。 

社区福利应用

除了加入以EOS.IO系统为基础的区块生成者团队,用户还可以选择3个社区福利应用,也称为智能合约。这3个应用程序最多能按配置的比例接收到每年的令牌配额减去已支付给区块生成者的部分。这些智能合约将根据每个应用程序从令牌持有者收到的选票比例来收取令牌。经选举的应用程序或智能合约可以由新当选的应用程序或令牌持有人的智能合约所替代。


EOS正式版技术白皮书(中文)二

cache
Processed in 0.003925 Second.