EOS.IO技术白皮书

比特币BITCOIN BTC 以太坊 ETHEREUM ETH 莱特币LITECOIN LTC 资产托管增值服务 QQ:47079569

比特币钱包BITCOIN CORE WALLET wallet.dat密码恢复服务,请找数据恢复服务商 QQ:47079569

 

Genesis Mining 比特币云挖矿优惠码

嫌自己挖矿麻烦?你可以使用云挖矿

节约4%的成本获得更多的算力:cjVGvt

点击访问世界最大云挖矿服务商 genesis-mining 官方网站

点击下载genesis-mining云挖 矿购买使用指南

于2017年6月26日

 

摘要:EOS.IO软件引入了新的区块链设计架构以实现分布式应用在水平和垂直方向上的扩展。每个网络中的节点通过软件建立起一个类操作系统构建,以使得应用可以部署其上。EOS.IO软件提供了账户、授权、数据库、异步通信以及横跨上百个CPU或集群的应用调度功能。这项技术实现将最终成为整个区块链底层架构基础以支撑每秒百万级的事务处理,降低用户的交易费用,并允许分布式应用可以进行快速和方便的部署。

 

请注意:本白皮书中所提到的加密令牌是指使用EOS.IO软件运行的区块链上的令牌。它们并不是指众筹时发出的流通于以太区块链上的和EOS令牌相对应的ERC-20兼容令牌。

 

此白皮书无需经允许,任何人可以使用,重建或分发其中的任意部分材料用于非商业和教育目的(这里不包括用于商业目的和付费使用),不过在使用时,须注明原始来源及适用的版权公告。

 

免责声明:EOS.IO技术白皮书仅用于资讯信息大致阐述目的。block.one并不保证白皮书中的所有结论都非常精确,白皮书中的内容都是以“as is ”(“就像这样”)的形式说明的,block.one不会为对所做陈述做出明确的保证、拒绝、暗示、规定,这些陈述包括但不限于:(i)用于特定目的或适合场景的标题或非侵权用语(ii)内容中存在的谬误(iii)部分可能存在侵犯第三方权利的内容。block.one和其分支将不会对白皮书中的内容在被使用、引述或基于此白皮书的其它任何内容所造成的或可能存在引发的任何损害承担责任。

即在任何情况下,block.one或其分支都不会对任何人或实体因此白皮书的使用或引述所受到的损害、损失、责任、任何种成本或费用、直接或非直接的、连续或偶发的处罚、补偿要求进行负责。商业上的损失和利润均和block.one或其分支无关。

 

  • 背景
  • 区块链应用需求
    • 百万级用户支持
    • 免费使用
    • 简单的升级和bug修复
    • 低延时
    • 时序性能
    • 并行性能
  • 一致性算法(DPOS)
    • 交易事务确认
    • 交易事务权利证明(Transaction as Proof of Stake: TaPoS)
  • 账户
    • 信息和处理程序
    • 基于角色的权限管理
      • 命名权限等级
      • 命名信息处理程序组
      • 权限匹配
      • 评估权限
        • 默认权限组
        • 并行评估权限
      • 强制性延迟信息
      • 遗失或被窃取密钥恢复
    • 应用中的并行执行
      • 沟通延时最小化
      • 只读信息处理程序
      • 多账户间的原子性交易
      • 区块链状态局部评估
      • 主观性最大努力调度
    • 令牌模型和资源使用
      • 主观观察对象
      • 接收支付
      • 授权能力
      • 交易成本与令牌/代币价值的分离
      • 状态存储成本
      • 区块奖励
      • 社会获益应用
    • 管理
      • 账户冻结
      • 账户修改
      • 体系构建
      • 协议及构建升级
        • 紧急修改
      • 脚本和虚拟机
        • 模式定义消息
        • 模式定义数据库
        • 应用授权分离
        • 虚拟机独立架构
          • Web组件
          • 以太虚拟机(EVM)
        • 内部区块链通信
          • 轻钱包验证(LCV)Merkle证明
          • 内部链通信延时
          • 证据完整性
        • 总结

 

背景

区块链技术自2008年比特币的引入,之后企业家们和开发者们都在不断地普及这一技术,以使这一区块链平台受到更多更广范围的应用落地。

在大量区块链平台还在为开发和支持功能化的去中心应用落地而挣扎时,特定应用区块链如比特股(BitShares)去中心化交易所(2014)以及Steem社区媒体平台(2016)已经成为两个大型区块链,其每天应用活跃用户数达到上万人。这两个平台支持每秒成千上万笔的交易的同时,延迟也低于1.5秒,降低了交易费,并提供了和那些当前存在的中心化服务相同的体验。

有许多现存的区块链平台受到大费率和有限的计算能力拖累,而阻碍了其得到进一步采纳和发展的机会。

 

区块链应用需求

为了获得更广泛的使用,区块链上的应用要求平台具有足够的弹性以满足以下需求:

  • 百万级用户支持

为了保证业务不受中断,像Ebay,Uber,AirBnB和Facebook需要区块链技术能力来处理数以百万计的日活跃用户。在某些情况下,除非用户数始终在临界数量下,否则应用就很可能无法工作,因此一个可以应对巨量用户的平台是非常重要的。

  • 免费使用

应用开发者应该能够灵活地为用户提供免费服务;用户不应该为使用此平台或从平台中获得服务而承担费用。一个区块链平台应该是对用户可免费使用的,这样它才能获得更广泛支持和采纳。开发商和企业也能在之后建立有效的货币化战略。

  • 简单的升级和bug修复

业务构建基于区块链的应用时,也需要考虑到对应用新特性持续增强的可扩展需要。

即使是通过最严格的形式验证,也无法避免复杂的软件开发中不存在bug。因此,平台必须足够健壮才能在问题发生时,能够修复错误。

  • 低延时

一个良好的用户体验要求可靠的反馈延迟保持在几秒以内。更长的等待延迟会让用户有受挫感并使得建立在区块链上的应用和那些已存的非区块链应用相比,显得缺乏竞争力。

  • 时序性能

一些应用需要顺序依赖的步骤无法用并行计算来实现。像交易类应用就需要保证足够的时序性能以处理大量事务。因此平台开发中,对于快速的时序性能要求也是需要的。

  • 并行性能

大型应用需要能够将其负载分到多个CPU和计算机上的能力。

 

一致性算法(DPOS)

EOS.IO软件是完全去中心化的,开发仅使用了分布式一致性算法来满足区块链上应用的需求,即委托权益证明(Delegated Proof of Stake: DPOS)方式来实现。在这个算法下,那些持有所在运行EOS.IO软件的区块链上的令牌的拥有人可以通过连续的批准投票系统来选出区块生产者;当然任何人也可以选择自己参与到区块的生产中,其获得的生产区块的机会将正比于相对其它生产者所获得的投票数。对于私有区块链,管理上还可以使用令牌选举方式来新增和移除IT团队。

EOS.IO软件保持区块以每3秒1块的速度生产出来,其中在任意个时间点上只能有一个生产者可生产且仅被授权生产1个区块。如果区块为按计划的时间产生,那么那个时点的区块会被无视。

使用EOS.IO软件时,区块的产生会以21个块为1轮。在每1轮开始时,会选出21个唯一的区块生产者。投票的前20名会被自动选为每轮区块的生产者,最后1个生产者则是相对于其它生产者,其所得投票最高的那一个。被选出的生产者会基于由区块时间而派生得到的伪随机数来进行顺序洗牌。这种洗牌保证了区块生产者能够在和所有其它生产者之间维持连接平衡。

如果一个生产者丢了一个块,且未能在最近的24小时内产生区块。那么它会从可考虑的生产者中移除,直至它通知区块链它意图再次开始生产区块为止。通过剔除那些被证明已不可信赖的生产者,可以保证网络运行更平滑并减少区块的丢失数量。

在正常情况下,一个DPOS区块链并不会经历分叉需要,因为区块的生产者是以互相合作的方式来生产区块的,而非通过竞争的方式来生产块。如果存在分叉事件,共识机制会自动将从分叉链上切换回最长链上。由于区块产生并被加入分叉区块链的速率和共享共识的区块生产者的占数量百分比有关,因此这个机制会起效。进一步说,一个有更多生产者的区块链分叉的区块增长长度会比生产者少的分叉产生区块要快很多,此外,没有区块生产者可以在同一时间为两个分叉同时生产区块。如果有一个区块生产者正这么做,那么这个生产者可能会落选生产者名单。这种双重生产的加密证据会被用于自动移除这些分叉滥用者。

  • 交易事务确认

一般DPOS区块链有100%区块生产者参与。一笔交易从其被播报的时间点开始,一般在平均1.5秒后会就已经得到了99.9%的确认。

不过,还有会由于某些未知的软件bug、网络拥堵、某个恶意的区块链生产者建了两个或多个分叉,而存在一些神奇的例外。因此,为了确保交易事务的不可逆,节点可以选择在21个块生产商中等待15个确认。基于EOS.IO软件上的一般配置,在正常环境下这会花时约平均45秒。默认所有节点会在得到21个生产者中的15个不可逆的确认后,完成对一个区块的确认,因此所有节点不会切换到不包含任何长度的其它分叉中。

不过,有时候可能某个节点会警告用户,它在9秒内可能正处于一个刚启动的小分叉上。在发现连续丢失了2个区块后,一个节点就有95%可能正处于一个小的分叉上。如果连续3个块发现丢失,那么99%以上可确定正处于一个小分叉上。我们可能胡i生成一个鲁棒性的预估模型来根据节点丢失信息、最近参与率和其它因素来判断是否哪里出了问题。

对于此类警告的解决回复方式完全取决于业务交易的类型,不过最简单的就是等警告结束并完成15/21次确认。

  • 交易事务权利证明(Transaction as Proof of Stake: TaPoS)

EOS.IO软件要求每笔交易都包括有一个最近的区块头hash值。这串哈希用于两个目的:

  1. 避免了交易在不存在此区块的分叉上重放;
  2. 给网络发信号告知某个用户和其股份在一个指定的分叉上。

随着时间的推移,用户在区块链上的确认交易将越来越难以伪造,且假币也无法从假币链迁移到合法的交易链中。

 

账户

EOS.IO软件允许所有帐户名以可读的2到32个字符长度组成的字符串唯一命名。账户名将由账号的建立者自己来选择。所有账户必须在创建账户时支付最低账户余额,以支付存储账户数据的费用。账户名也支持命名空间如账户所有者@domain是唯一一个可以建立账户@user.domain的人。

在一个去中心化环境中,应用开发者将支付一些微不足道的成本来为一个新用户注册建立账户。传统商业上在为获取更多客户上,已经在每个客户上花费了大量的金钱成本,这种花费的形式有广告、免费服务等。一个区块链上新账户的支付成本相比较而言简直就是太少了。而且更棒的是,我们也需要为由其它应用而已经注册账户的用户建立新的账户。

  • 信息和处理程序

每个账户都能发送结构性信息给其它账户,并且也可以定义脚本对收到的信息进行处理。EOS.IO软件给了每个账户都分配了一个私有的数据库,库中的数据仅能通过这个账户自己的信息进行访问调用。信息处理脚本也可以发信息给其它账户。通过信息和自动信息处理一起,我们就能了解智能合约是如何定义的。

  • 基于角色的权限管理

权限管理涉及到对信息是否进行了合适授权的判断。权限管理的最简单形式是检查事务是否有必需的签名,但这意味着所需的签名已经已知。一般授权会绑定个人或组并进行划分。EOS.IO软件提供了声明式的权限管理系统,给与客户细粒度和高水平的控制(即可以控制谁可以做,什么时候做)。

认证和权限管理标准化且和应用的商业逻辑进行分割开来是非常重要的。这使得开发出的工具可以以一种统一的方式来进行权限管理,并为大量的性能优化提供切入机会。

每个账户都可以由其它账户和私钥加权组合进行控制。这就建立起了一个层次化的权限结构,它反映了在现实中的组织权限,并使得用户对资金的控制比以往更容易。多用户控制功能是对安全的最大贡献。如果使用得当,它可以大大降低因黑客攻击而造成的盗窃风险。

EOS.IO软件允许账户定义的哪种私钥和账户的组合可以发送特定类型的消息给其它账户。例如,可以为用户的社交媒体账户提供一个私钥,而给用户访问交易所的账户提供另一个私钥。你甚至可以给其它账户许可,在不分配密钥的情况下代表用户账户行事。

  • 命名权限等级

在使用EOS.IO软件时,账户可以定义自己命名的权限级别,而这些权限级别是从更高级别的命名权限派生出来的。每个命名的权限级别定义了一种授权权限;这种授权权限是一种由私钥和/或其它账户的命名权限级别所组成的多签名阈值。例如,一个账户的“Friend”权限级别可以设置账户被其它朋友账户控制,具有和此账户相同的权限。

另一个例子,在Steem区块链上有三个硬编码的命名权限级别:owner(所有者),active(活跃的)和posting(发布者)。posting权限仅能用于进行社会行为如投票和发布公告,而active权限能做除了变更所有者外的所有操作。owner权限则意味着你可以做任何事情,一般不太用。而EOS.IO软件的开发会保持这样一个概念,即允许每个账户拥有者可以定义自己的权限层级并对操作进行分组。

  • 命名信息处理程序组

EOS.IO软件允许每个账户可以对自己的信息处理以命名和嵌套分组的形式进行组织。这些命名的信息处理组可以被其它账户引用用于配置其权限级别。

最高级别的消息处理程序组是帐户名,最低级别则是应对帐户消息接收的单个消息类型。这些组可以以以下形式调用,如:@accountname.groupa.subgroupb.MessageType

在这种模式下,交易合约可以将订单创建和订单取消与存入和取现区分开来。这种分组对于用户在交易的区分时是很方便的。

  • 权限匹配

EOS.IO软件允许每个帐户定义一个命名的任何帐户信息处理组和自己命名的权限级别之间进行映射匹配。例如,账户拥有者可以匹配其账户下的社会传媒应用到其账户下的“Friend”(朋友)权限组中。这样,这个组下的任何一个朋友都可以像这个账户拥有者在其社会传媒应用上一样来进行信息发布。甚至他们可以在发布时,仍可以使用他们自己的私钥进行信息签名,这意味着可以确认是哪个朋友使用了这个账户进行操作,并以何种方式操作。

  • 评估权限

当从@alice给@bob发送一个类型为Action的消息时,EOS.IO软件会首先查看@alice是否对@bob.groupa.subgroup.Action有定义权限匹配。如果没有找到,则会继续找匹配@bob.groupa.subgroup,然后继续上溯找@bob.groupa,最后会找@bob进行查看。如果还是没有找到权限匹配,那么就假设匹配可能是命名权限组是@alice.active。

一旦确定映射,则使用阈值多重签名过程和与命名权限相关联的权限来确认签名权限验证有效。如果匹配映射失败,那么它会上溯遍历父权限并最终查看所有者权限,如@alice.owner

  • 默认权限组

EOS.IO技术允许所有账户有一个“owner”所有者组可以做任何事,一个“active”活跃组可以做除了修改owner组之外的所有事。所有其它权限组都是从“active”组派生出来的。

  • 并行评估权限

权限评估过程是只读的,且对权限修改的操作直到块结束时才生效。这意味着所有事务的私钥和权限评估都可以并行执行。此外,这意味着在可以在不启动需回滚的高成本应用程序逻辑的情况下快速完成权限验证。当然,这也意味着某些修改事务在收到时可以被挂起,使得当前事务得以顺利评估,而不需要在其被修改后进行重新评估。

总的来说,权限验证占了验证事务所需计算量的很大一部分。因此,只读且并行执行查询能够大幅提高性能。

当区块重放所再生的确定性状态消息的日志不需要评估的权限了。事务包含在已知好的块中的事实足以跳过验证这一步。这大大减少了回放不断增长的区块链所带来的巨量的计算负荷。

  • 强制性延迟信息

时间是安全的重要组成部分。在大多数情况下,你直到使用私钥前,都可能都不知道私钥是否被窃取。因此,当人们在使用应用程序时,需将密钥保存在计算机上并连接到因特网中以供日常使用时,这种基于时间的安全性就显得更为关键。EOS.IO软件使得应用开发者能够指示某些消息在被应用前,需要在被包含在一个块后,必须等待的最小时间。在此期间,他们可以进行取消。

当消息被传播时,之后用户可以通过邮件或文本消息接收到通知。如果他们没有授权它,那么他们可以使用帐户恢复过程来恢复帐户并重新接收消息。

所需的延迟取决于操作的敏感度。买一杯咖啡是没有延迟的,在几秒钟内是不可逆的,而买一套房子则可能需要72小时的结算时间。将整个帐户转移到新的控制系统可能需要30天时间。实际的延迟取决于应用程序开发人员和用户操作。

  • 遗失或被窃取密钥恢复

EOS.IO软件为用户提供了一种当账户钥匙被偷后恢复他们账户控制的方法。账户所有者可以使用在过去30天中活跃的所有所有者密钥,以及他们指定的账户恢复伙伴(如交易所)的批准,来对其账户进行密钥重置。账户恢复伙伴不能在没有所有者的帮助下重启账户的控制权。

黑客通过这种尝试恢复过程对他并没有什么好处,因为他们已经“控制”了账号。此外,如果他们确实经历了这个过程,那么恢复伙伴很可能需要身份验证和多因素身份验证(电话和电子邮件)。这可能会损害黑客或无法获得黑客在这个过程中的任何东西。

这个过程也与简单的多重签名验证方式有很大的不同。对于多签名事务,另一个公司是执行每个事务的一方,但在恢复过程中,代理(恢复伙伴)只是恢复过程中的一方,它对日常事务没有权力。这大大降低了涉及每个人的风险成本和法律责任。

 

应用中的并行执行

区块链共识依赖于确定的(可重复的)行为。这也就意味着所有并行执行必须摆脱对互斥锁或其它锁的使用。没有锁,必须有某种方法来保证所有帐户只能读写自己的私有数据库。它也意味着每个帐户处理信息必须按顺序处理,并行将处于帐户级别。

在一个基于EOS.IO软件运作的区块链上,区块生产者的一项工作是组织信息传递到独立的线程以进行并行评估。每个帐户的状态只取决于传递给它的消息。区块生产者会有安排地进行输出,并且进行明确地执行,不过执行进度并不确定。这意味着区块生产者可以利用并行算法来安排事务。

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

  • 沟通延时最小化

延迟是一个帐户发送消息到另一个帐户并接收响应的时间。

我们的目标是使两个帐户在一个块内来回交换消息,每条消息之间等待时间不超过3秒。为了实现这个目标,EOS.IO软件将每个块分入循环中。每个循环被划分给线程,每个线程包含一个事务列。每个事务包含一组要传递的消息。这种结构可视为一棵树,其中很多层次互相交替顺序或并行地处理。

Block

Cycles (sequential)

Threads (parallel)

Transactions (sequential)

Messages (sequential)

Receiver and Notified Accounts (parallel)

在一个周期中生成的事务可以在任何后续循环或块中被提交。块生产者将继续向块分配周期,直到最大时钟时间已经过去或没有新生成的事务交付。

可以对块使用静态分析来验证在给定的周期内没有两个线程包含修改同一个帐户的事务。只要能始终保持这种规则不变,就可以通过并行运行所有线程来处理块。

  • 只读信息处理程序

有些帐户可以在不改变其内部状态的情况下以传递/失败传递的基础方式来处理消息。如果是这样的话,这些处理程序可以并行执行,只要特定帐户中只读的消息处理程序包含在一个或多个特定线程中。

  • 多账户间的原子性交易

有时我们需要确保在多个账户间的消息发送和接收包含在一个原子性事务中。在这种情况下,消息被置入一个事务中,且所涉及的两个账户都会被分配在相同的线程中,其中的消息都被顺序处理。这种情况对性能并不理想,当涉及到“计费”事务应用时,事务会涉及多个唯一账户来进行记账支付。

出于性能和成本方面的原因,最好将涉及两个或多个使用帐户的原子操作最小化。

  • 区块链状态局部评估

组件模块化对于区块链技术的弹性缩放是非常必要的。每个人都不应该也不会需要运行所有东西,特别是他们仅需要使用应用中很小一部分功能的时候。

一个交易所应用开发者运行完整节点以向用户显示交易所状态。此应用程序状态不需要与社交媒体应用相关联。EOS.IO软件允许任意节点选择任意应用程序的子集单独运行。传递给其他应用程序的消息会被安全地忽略,因为应用程序的状态完全是从传递给它的消息派生出来的。

这对与其他账户的通信有重要意义。其最重要的意义在于,它不能假定其他帐户的状态可以在同一台机器上访问。这也意味着当允许“一个帐户”同步调用另一个帐户时,如果另一个帐户不驻留在内存中,这种设计模式就会崩溃。

账户间所有的状态信息通信都必须通过区块链中的消息传递来获取。

  • 主观性最大努力调度

EOS.IO软件不会对块生产者发送信息给任意其他帐户的操作进行负责。每个块生产者都会对处理事务所需的计算复杂度和时间作出自己的主观度量。这可用于决定是由用户来生成事务还是由脚本来自动生成事务。

在一个启动并运作的区块链采纳EOS.IO软件节点时,在网络层面所有交易,不管是否使用都会占用固定的计算带宽成本。执行耗时01ms或总的10毫秒。不过,使用该软件的每个块生产者都可以使用自己的算法和度量来计算资源使用情况。当块生产者判断一个事务或帐户消耗了过多的计算能力时,他们在生产自己的块时可以简单地拒绝处理这次事务;然而,如果其它块生产者认为它是有效的,他们仍将处理该事务。

一般来说,即使只有一个块生产者认为这笔交易事务是有效的,在资源使用限制下,其他所有块生产者也会接受它,但这笔交易可能需要1分钟才能找到接受处理它的生产者。

在某些情况下,生产者可以建立一个块,该块包含那些在可接受范围之外的事务。在这种情况下,下一块生产者可以会选择拒绝这个块,而区块的衔接将因此而被打破。这与当一个大的区块造成网络传播延迟时会发生类似。不过社区会注意到这种模式是否有被滥用的嫌疑,并最终将那些流氓生产者从被选人中移除。

这种计算成本的主观评估使得区块链不必过于精确地去测量判断事务到底花多长时间运行。有了这种设计,就不需要精确地计算指令,这大大提高了优化的机会而无需打破共识。

 

令牌模型和资源使用

请注意:本白皮书中提到的加密令牌为推出区块链并采用eos.io软件所使用的加密令牌。它们不是指那些和EOS令牌相对应的分布于以太坊区块链上的ERC-20兼容令牌。

所有的区块链都有其资源约束,并要求有系统可以防止滥用。对于使用EOS.IO软件的区块链,其上的应用所使用的资源可分为三大类别:

  • 带宽和日志存储(磁盘);
  • 计算力和计算存储(CPU);和
  • 状态存储(RAM)。

带宽和计算都有两个组件组成,即用于瞬时使用和长期使用。区块链记录所有日志信息,而这个日志将最终被全部节点所存储和下载。使用消息日志,可以重建所有应用程序的状态。

计算负担(debt)是对必须从消息日志中生成用于区块链状态恢复的成本计算。如果计算负担增长过大,那么就有必要对区块链状态进行快照保存,这样就可以丢弃区块链历史快照备份。如果计算负担增长过快,在需要恢复时,可能需要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软件运行的区块链将在区块生产者每次产生出一个块会给生产者发放新的令牌以作为奖励。在这种情况下,奖励的令牌数量由所有区块生产者所需的工资中位数决定。EOS.IO软件可以配置一个生产者奖励限制,即令牌供应总量每年增加不超过5%为上限。

  • 社会获益应用

除了选举区块生产者,基于EOS.IO软件运行的区块链,用户可以选出3个社区受益应用(也被称为智能合约)。这3个应用每年将收到最多的令牌供应百分比的令牌(减去已支付给区块生产者的令牌)。这些智能合约收到令牌的数量分配将和每个应用从令牌持有者处得到的选票成正比。之前当选的应用或智能合约可以被新当选的应用或令牌持有者的智能合约替代。

 

管理

管理是人们在主观问题上达成共识的过程,这一点并不能完全由软件算法来捕获。基于EOS.IO软件运行的区块链实现一套管理流程,以有效地引导当前区块生产者的工作。过去存在的区块链由于缺乏明确的管理流程,区块链都依赖于临时的、非正式的、通常是有争议的管理流程,这会产生不可预知的后果。

基于EOS.IO软件运行的区块链认识到权力来源于令牌持有者的委托,并授权区块生产者。区块生产者被授予有限的审查权限来冻结账户,更新有缺陷的应用,并针对底层协议提出硬叉改变。

EOS.IO软件中嵌入了区块生产者投票功能。在任何变化前需要由区块链的这些区块生产者批准。如果区块生产者拒绝进行令牌持有者所期望的更改,那么他们在之后的选举中被淘汰。如果区块生产者进行的改变没有得到令牌持有者允许,那么所有其他非生产区块的全节点上的验证(交易,等等)都会拒绝改变。

  • 账户冻结

有时,一个智能合约以异常或不可预知的方式行事,且未能按预期的方式行事;有时,应用或帐户可能会发现一个漏洞,使智能合约能够消耗不合理的资源。当此类问题不可避免地发生时,区块生产者有权纠正这种情况。

所有区块链上的区块生产者有权块选择哪些事务包括在区块中,这使得他们有了冻结账户的能力。一个使用EOS.IO软件运行的区块链通过一次17 / 21的投票表决流程来实现冻结账户的正式授权。如果生产者滥用权利,他们也可以投票表决来将帐户予以解冻。

  • 账户修改

当一切尝试都失败了且一个“不个停不下来的应用”正以一种不可预知的方式运行,使用EOS.IO软件运行的区块链允许区块生产者在不分叉整个区块链的情况下可以替代掉账户的代码。这个剁成与冻结账户类似,这种代码替换也需要区块生产商17/21的投票通过。

  • 体系构建

EOS.IO软件使得区块链可以建立对等的服务条款协议或用户签字之间有约束力的合约,称为“宪法”。此宪法的内容界定了使用者之间的义务,这些义务不能完全由法典强制执行,并通过确立管辖权和法律选择以及其他相互接受的规则来促进争端解决。在网络上广播的每一个事务都必须纳入宪法hash值以作为签名的一部分,从而明确地将签名者绑定到合约中。

宪法还定义了具有可读性意图的源代码协议。此用于当错误发生时识别bug和特性之间的区别,并引导社区确定哪些修补是正确的或不正确的。

  • 协议及构建升级

EOS.IO软件定义了一个流程,通过这个流程,对于使用权威的源代码及宪法来定义协议,可以使用以下方法进行更新:

  1. 区块生产者提议修改宪法并获得17/21的批准。
  2. 区块生产者连续30天维持17/21的批准。
  3. 所有用户被要求使用新宪法hash来签署事务。
  4. 区块生产者采取修改源代码以反映宪法更改,建议区块链使用git 的hash值来进行区块链代码提交。
  5. 区块生产者连续30天维持17/21的批准。
  6. 对代码的更改在7天后生效,在批准源代码后,给所有完整的节点1周时间进行升级。
  7. 不升级到新代码的所有节点将自动关闭。

在EOS.IO软件的默认配置中,更新区块链添加新功能的流程,这个过程需要2到3个月,不过那些解决非关键问题的更新,因为不需要修改宪法则可能只需要1到2个月。

  • 紧急修改

如果需要修改软件以修复有害用户的错误或安全漏洞,则区块生产者可能会加快这一流程。一般来说,加速更新引入新特性或修复无害的bug可能违反宪法。

 

脚本和虚拟机

EOS.IO软件将是首个协调传递认证消息到帐户的先进平台。脚本语言和虚拟机实现的详情细节,这些大多是属于EOS.IO的独立技术设计。那些确定的和适当的在沙箱测试下具有足够性能的任何语言或虚拟机可以与EOS.IO软件API相集成。

  • 模式定义消息

发送账户之间的所有消息通过模式进行定义,这种模式是作为区块链共识的一部分。此模式允许消息可以在二进制和JSON之间无缝转换。

  • 模式定义数据库

数据库状态也使用类似的模式定义。这样可以确保所有应用程序存储的所有数据都可以被解释为人类可读的JSON格式,但以二进制的效率进行存储和操作。

  • 应用授权分离

为了最大限度地并行化并减少从事务日志中的再生应用状态所需计算相关的债务负担,EOS.IO软件将验证逻辑分为以下三部分:

  1. 验证消息是内部一致的;
  2. 验证所有前提条件都是有效的;
  3. 修改应用状态。

消息的内部一致性验证是只读操作的,不需要访问区块链状态。这意味着它可以以最大并行性来执行。验证前提条件,如所需的平衡,这些操作也是只读的,因此也可以从并行中获益。只有修改应用程序状态需要写访问,并且必须对每个应用程序进行顺序处理。

身份验证是验证消息是否可用的只读过程。应用程序都会做这项工作。在当时需要进行计算,不过一旦交易包括在区块链中了,则它不再需要进行认证操作。

  • 虚拟机独立架构

基于EOS.IO软件运行的区块链意在支持多个虚拟机,且支持新虚拟机在必要时的添加。本文中不会不深入讨论任何特定语言或虚拟机的细节。不过,现在有两个虚拟机,目前运作使用基于EOS.IO软件的区块链以进行评估。

  • Web组件(WASM)

Web组件是一种用于构建高性能Web应用程序的新兴的Web标准。有一些小的Web组件可以进行确定性修改定制和沙箱测试。Web组件的好处是受到行业的广泛支持,它使用常见的语言如C或C++开发。

以太坊的开发者们已经开始修改Web组件以提供合适的沙盒和定制以太坊所需的Web组件(WASM)。这些组件可以很容易地适应并和EOS.IO软件集成。

  • 以太虚拟机(EVM)

这个虚拟机已用于现有的智能合约,且可以适应于EOS.IO区块链的工作。可想而知,EVM合约也可以运行在基于EOS.IO运行的区块链所使用的沙盒里面,有一些适用于EVM合约的软件也可以与EOS.IO运行的区块链应用进行通信。

 

内部区块链通信

EOS.IO软件的设计目的是为了促进跨区块链的通信。这可以通过简单地生成消息存在证明和消息序列证明来实现。这些证明和围绕消息传递的一套应用架构设计可以使得应用开发者不用关注这些跨区块链沟通和证明验证等底层细节。

  • 轻钱包验证(LCV)Merkle证明

如果客户不需要处理所有事务,那么和其他区块链的集成将更容易。毕竟,交易所只关心交易所的进出。如果交换链可以利用轻量级Merkle证明存款而不是完全信任自己的区块生产者,那会是非常理想的。因为至少一个链块生产者在和其它区块链同步时候都会尽量考虑保持尽可能小的开销。

LCV的目标是生成相对轻量级的存在证明,任何人可以跟踪一个相对轻量级的数据集来进行验证。在这种情况下,一个特定的交易得到证明是包含在一个特定的块中,块中会包含一个特定的区块链验证历史。

比特币支持的交易验证假设所有节点可以访问区块头中的所有历史,这些历史每年会有4MB大小。在每秒10事务的节奏下,有效的验证需要大约512字节。这个区块验证间隔需要10分钟的区块链, 相比一个区块验证间隔为3秒的区块链,它就太笨重了。

EOS.IO软件使轻量级证明用于证明当时任何人的交易被包括在了不可逆的区块头中。使用下面所示的散列链接结构,可以证明存在小于1024字节大小的事务的存在。如果假设验证节点与过去一天中的所有块头保持一致(2 MB的数据),那么证明这些事务只需要200字节长的证据。

启用这些证明,适当的哈希链接对生成区块相关的增量开销很少,这意味着没有理由不以这种方式生成区块。

当需要验证其他链的证据时,可以进行各种各样的时间/空间/带宽优化。跟踪所有的块头(420兆字节/年)将保持小尺寸的证据。如果仅需跟踪最近的头,可以提供最小的长期存储和验证大小之间的折衷。另外,区块链可以使用一种懒惰的评估方法,它可以记得过去的证据哈希中间值。新的证明只需要包含已知稀疏树的链接。确切的方法将取决于包含涉及使用Merkle证明交易的外部块的比例。

在具有一定密度的联系后,就能使得一个链包含了其它区块链整个区块的历史,并且减少了对所有证据的需要,这样就能变得更为高效。出于性能的原因,理想情况下,以尽量减少链间证明的频率。

  • 内部链通信延时

在和另一个区块链沟通时,区块生产者必须等到有100%的把握,交易已经不可逆转,在由另一个区块链确认后,才能接受它作为一种有效的输入。使用EOS.IO软件运行的区块链和3秒区块确认和21个生产者的DPOS机制,这中跨链确认大约需要45秒。如果一个链块生产者不等待这一不可逆性,它就会像接受存款的交易所,之后又将交易推翻,这可能会影响区块链共识的有效性。

  • 证据完整性

当外部区块链使用Merkle证明时候,知道所有交易处理是有效的和知道没有交易被跳过或忽略之间的证明验证是存在很大不同的。虽然不可能证明所有最近的交易都是已知的,但有可以证明交易历史上没有以后空白间隔。EOS.IO软件通过为每个传递到账户的信息分配一个序列号。用户可以使用这些序列号来证明所有针对特定帐户的消息都经过了处理,并按照顺序进行了处理。这样就实现了证据的完整性。

 

总结

EOS.IO软件是证明概念和经验和最佳设计实践,其代表了区块链技术的进步。该软件是一个可扩展的为成为具有全球社会整体蓝图一部分的去中性化的分散应用,并可以很容易地进行部署和管理。

 

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569