> For the complete documentation index, see [llms.txt](https://eosforce.gitbook.io/eosforce/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://eosforce.gitbook.io/eosforce/eosc-ji-shu-bai-pi-shu.md). # EOSC - 技术白皮书 ## EOSC 高可用去中心化智能应用生态 ## 1.EOSC ### 1.1 背景 加密经济迎来了从社会试验走向大规模商用的关键阶段。 大规模商用的背后意味着庞大的交易压力。一个区块链系统要高效地承载起巨量的交易需求，首先必须提供足够强劲的性能。要实现这一点，就需要对全节点提出更高的要求，如配置更好的硬件机器、更大的存储容量、更加稳定的网络、更快的带宽、更低的时延，等等。显然，全节点门槛过高会导致能稳定运行的出块节点数量减少，如果在这样的区块链系统中采用POS机制，系统将迅速收敛至中心化的局面。要在高性能和去中心化之间取得平衡，DPOS共识算法无疑是当前最佳的选择，也是针对管理少量节点可行的最好的解决方案。 基于DPOS共识算法的EOSIO应运而生，社区第一次看到了加密经济大规模商用的曙光。选举机制是否充分生效是DPOS共识机制存亡的关键，也关系到DPOS共识机制能否接力POW引领下一代加密浪潮。 为了加速加密经济大规模商用时代的到来，EOSC社区对EOSIO的选举机制进行了优化，在创世高度1启动了EOSC主网，并持续对EOSC主网进行迭代升级，使得EOSC朝着去中心化的高性能智能应用的方向持续演进。 ### 1.2 区块链商业作为商业应用的要求 当区块链成为商业应用的载体，一个应用一条链将成为常态，要满足商业去中心化应用的开发区块链必须要满足以下条件 * 在可以接受的成本下支撑百万级的用户数量 * 允许普通用户无成本进入, 同时维持相对稳定的手续费 * 便于更新和拓展 * 低延迟 * 高性能 * 性能容量上限可扩展 * 良好的原生跨链支持 * 去中心化治理机制 针对以上的业务要求, EOSIO是目前高可用去中心化智能合约平台的最佳选择, 但是, EOSIO对于以上要求还有很多方面的欠缺。 EOSC启动阶段是基于EOSIO项目, 在多个方面对EOSIO进行拓展和彻底的重构, 同时也和EOSIO在最大程度上保持兼容的基础之上, 满足以下要求： #### **在可以接受的成本下支撑百万级的用户数量** EOSIO可以支持百万级的用户数量, 但是其账户系统使得用户进入成本较高, 虽然理论上EOSIO可以支持百万级别的用户数, 但是其需要消耗大量的链上资源. 对此EOSC创新的设计了一套全新的资源模型, 使得用户账户的资源消耗可以更小, 同时减少了资源的无故浪费与投机行为, 使得EOSC在可以接受的成本下支撑百万级的用户数量。 #### **允许普通用户无成本进入, 同时维持相对稳定的手续费** EOSC为每个账户设置有限的RAM低保资源, 使得账户可以在付出少量的手续费就可以使用链的基本功能, 同时减少用户操作的复杂性. EOSC使用手续费来作为资源的基本支付方式, 保证DAPP消耗的手续费相对稳定, 可以避免因为资源限制的波动影响DAPP的发展。 #### **便于更新和拓展** EOSC上基于合约实现的功能可以简单的通过更新合约的方式更新, 同时EOSC添加了基于链上配置触发更新的机制, 这样可以平滑的进行链基础代码的升级, 避免大量节点出现硬分叉的情况. EOSC支持子链机制, 可以在使用二级链结构拓展主网功能, 这样即支持拓展新功能, 也能保持主网兼容性, 使得EOSC即不会被EOSIO发展限制, 也可以与EOSIO技术发展同步。 #### **性能容量上限可扩展** EOSC可以通过子链实现主链之外的计算链, 这样可以拓展主网性能容量上限, 通过基于子链来实现对于IPFS协议的激励层子链, EOSC上的DAPP可以使用海量的数据。 #### **良好的原生跨链支持** 跨链是目前区块链发展的重要方向之一, EOSC通过子链和静态账户机制可以很好的支持各种跨链协议, 这可以为EOSC带来更大的应用场景。 #### **去中心化的治理机制** EOSC不断探索更加去中心化的链治理机制, 在兼容EOSIO的基础之上, 基于L2子链添加丰富的基础功能以支持更复杂的DAPP开发, 同时强化轻节点在链中的作用和功能, 在高性能环境下基于轻节点加强链的去中心化程度。 EOSC与EOSIO保持兼容, 这使得EOSC可以与EOSIO共同发展, 同时EOSC的架构使得EOSC可以在EOSIO之外进行更多的实践, 打破EOSIO带来的天花板. EOSC将会不断探索更加去中心化的链治理机制, 在兼容EOSIO的基础之上, 基于L2子链添加丰富的基础功能以支持更复杂的DAPP开发, 同时强化轻节点在链中的作用和功能, 在高性能环境下基于轻节点加强链的去中心化程度**。** ## **2.共识机制** EOSC未来的共识机制将会从两个方向并行演进 * 兼容EOSIO发展更新其共识算法,我们根据EOSIO当前开发进度判断，当EOSIO完成并行改进之后, 将会升级共识算法, 实现更快的区块确认时间. * 将会适配其他的基于确认数的共识机制, 作为现有DPOS共识的补充, 一方面实现内嵌的子链共识与主链的交互。另一方面, 可以实现与其他共识机制的链完成更加去中心化的跨链机制. ### **2.1 更加稳健的出块速度** EOSC沿用了EOSIO的共识机制, 即DPOS BFT Pipeline Consensus, 与EOSIO不同, EOSC没有采用EOSIO每0.5秒一个区块, 一个节点连出6个块的模式, EOSC中每3秒一个区块, 节点不会连续出块, 虽然节点连续出块可以降低未打包交易的等待时间, 但是由于当前网络环境往往并不十分理想, 快速出块会影响链的稳定, 造成大量的微分叉**。** EOSC减少了出块的频次, 可以在当前的网络情况下提高主网的稳定性, 未来当EOSC的并行支持得到完善之后, 会逐步稳健的过渡到快速出块的模式。 ### **2.2 可拓展的附加共识机制** 共识是基于区块的, EOSC将会在原有共识算法的基础上, 添加其他的共识机制, 基于不同的算法对区块实现多批次的验证, 这样可以兼顾不同共识算法的优点。 EOSC基于子链可以加强EOSC主链的共识程度, EOSC子链在与主链进行挂钩证明的同时, 也同时对主链区块进行验证, 随着EOSC轻节点的增多, EOSC的去中心化程度将会大大提高。 ## **3.资源模型** EOSIO的CPU和NET资源的支付模式虽然在技术是一个很好的设计, 对于用户来说太过复杂, 同时不能促进DAPP开发者优化其合约, 另一方面, EOSIO的RAM的购买方式会导致某些囤积行为, 不利于DAPP生态的发展, 为此, EOSC创新的设计了一套全新的资源模型, 通过实践中的优化,探索在复杂智能合约环境下基于手续费的资源模型, 彻底解决困扰EOS生态的资源问题. ### **3.1手续费模型** EOSC以手续费模式支付用户的CPU和NET资源消耗, 对于DAPP当中开发者定义的Action, DAPP开发者可以为Action设置所需的手续费, 系统基于此来控制Action的资源使用, 这样便于用户理解资源的消耗, 同时强烈的促进DAPP开发者优化合约资源使用, 使得整个生态良性发展. ### **3.2租赁机制** EOSC采用类似租云主机的方式以方式分配RAM资源, 用户可以通过使用投票分红来支付租赁RAM资源的费用, 这样即不需要用户担忧租金缴纳问题, 也杜绝了租金欠费的问题. 通过“以租代售”的方式, EOSC可以有效避免针对RAM资源的投机行为, 使得DAPP的发展不必受到RAM价格的干扰, 有效促进DAPP生态建设。 ### **3.3兼容抵押模型** EOSC在机制也兼容EOSIO的资源模型, 对于CPU和NET资源, 用户可以基于分红票龄支付手续费来达到类似EOSIO抵押获取CPU和NET资源的效果, 对于RAM, 用户可以通过抵押投票互换的形式来达到EOSIO基于市场购买的效果, 这样DAPP开发者可以快速从其他EOSIO链切入EOSC, 并平滑的转向EOSC的资源模式。 ## 4.用户体系 ### 4.1基于角色(Actor)的账户体系 EOSC的手续费模式允许账户与资源消耗解除绑定, 即执行action不需要依赖于一个特定的账户以支付资源消耗, 因此EOSC以角色(Actor)为基本单位, 在此之上可以建立等同与EOSIO的账户体系。 ### 4.2以角色为核心 EOSC的角色与EOSIO等同, 其核心在于权限的管理, 这样EOSC可以兼容类似UTXO模型的通证结构, 用户可以不预先创建账户即可使用链的大部分功能。 ### 4.3账户体系 EOSC的账户体系与EOSIO相同, 不同支持在于, 基于EOSC的资源模型, 账户并不是与链交互的必要条件, 只要用户可以通过某些方式支付足够的手续费和RAM租赁费用, 用户并不需预先创建账户即可和链进行交互, 这也就意味着EOSC对于新用户有极低的门槛, 进而促进整个链的发展。 ### 4.4静态账户(Static Account) 静态账户是EOSC中的一类特定账户, 一个账户可以声明自身为静态账户, 此时账户相关的状态都由区块数据直接决定, 节点不需要重跑区块即可确定账户相关的状态。 静态账户可以基于轻节点进行验证和操作, 一方面适合与链交互的应用开发, 另一方面可以有效增加对跨链技术的支持。 ## 5.轻节点框架 EOSC的全节点需要很高的机器配置, 新节点同步也需要大量时间, 这样使得整个网络的节点过于中心化, 同时也意味着开发运维一个与链强交互的应用将会十分困难。 EOSC将会完善主网轻节点框架, 在EOSC中, 将会有多种不同职能的轻节点参与网络治理, 这些轻节点的共同点是不会完整的执行每个action而只做验证性工作, 这样的设计使得轻节点可以大量存在, 以此加强EOSC主网功能并提高去中心化程度。 为了高效稳健的添加不同功能的轻节点, EOSC将会实现一个轻节点开发框架, 这个框架架构上独立于现有的EOSC节点, 这可以使得开发者可以根据自身的需求自行设计与开发对应的轻节点。 ## **6.治理机制** ### 6.1基于时间加权的选举机制 EOSC通过选举机制持续改进，实现DPOS共识机制的去中心化。 #### **加权票数** 节点的排名由所获得的加权票数决定，节点所获得的加权票数越高，节点的排名越靠前。 参与投票的方式分为定期投票和活期投票。定期投票有多种时间周期可选择，分别是3个月、6个月、12个月和24个月对应的块高度。定期投票期间代币处于锁定状态，到期自动解锁。 活期投票没有无固定周期，投票代币可以随时选择赎回，赎回需要3天时间的块高度解锁。 此外，不同的时间周期所对应的票数权重也不同，活期票数权重为0.2，而3个月、6个月、12个月，24个月的时间周期分别对应的权重为1、2、4、8。 不论是定期投票还是活期投票，投票人都可以随时切换节点，只需要支付系统本身的操作手续费，无需等待时间。 #### **一票一投** 选举机制决定了DPOS机制能否充分生效。 EOSC主网实行一票一投的投票机制，一个账户可以给多个节点投票，但每一个EOSC一次仅能投给一个节点。EOSC主网的实践证明，一票一投可以有效地防止节点联盟的出现，为节点的竞选营造了一个更加公平、合理、有活力的选举空间。 通过一票一投的投票制度，没有节点可以长期霸占出块节点列席，后来的新节点也有足够的空间跻身成为出块节点。EOSC主网的选举机制充满活力。 #### **去中心化的协议治理** EOSC开放的协议治理体系，使得当选节点通过链上治理实现网络的升级，确保EOSC协议的发展遵循社区的意志。 投票分红是EOSC主网激励链上用户积极参与投票的激励方式。持币人参与投票可获得分红奖励，分红奖励来源于系统的增发。 投票人可获得分红奖励的多少，取决于其投票的加权票数在总加权票数中的占比。加权票数占比越高，可获得的分红奖励也越高。 定期投票和活期投票所产生的分红都可以随时领取和复投，但定期投票的本金无法在定期结束之前释放，到期后票数权重清零。 EOSC主网的节点分为出块节点和收益节点。 出块节点，也即超级节点，是基于加权票数排名的前23名节点。收益节点是能够获取网络投票收益的注册节点。任何人都可以接入EOSC主网成为收益节点，并按照投票加权票数占比瓜分区块奖励的10%。 基于DPOS共识机制的区块链系统需要多个超级节点共同运行和维护，如果这些超级节点中某些节点运行出错或作恶，系统的安全和稳定将会受到威胁。为了更高效地保障系统的安全稳定，淘汰作恶节点和不作为节点，选举出能够真正地为社区服务、支撑系统运作的节点，EOSC主网建立了节点惩罚机制。 节点惩罚机制主要体现在三个方面，一是减少出块节点的区块奖励，二是扣除出块节点押金，三是冻结节点。 根据区块奖励分配规则，生产节点可以获得区块奖励的10%。但区块奖励并不由出块节点平均分配，而是按照节点的出块币龄（连续出块时间）作为权重来分配。 具体地说，EOSC主网提出了”出块节点稳定度“的概念。每个节点的出块节点稳定度的初始值为0，如果每个周期600个块不漏块则加1。最大为3800,达到3800不再继续增加。如果有漏块情况重置为0. 出块节点稳定度和出块分红权重相关。如果连续稳定出块则分红权重高，在出相同块的情况下，稳定度越高的节点分红越高。 节点需要抵押一部分系统代币作为押金才能成为出块节点。如果出块节点漏出块，每少生产一个区块将扣除该区块奖励的2倍押金。当节点的押金低于系统设定的最低值，则节点无法获得出块奖励，且不能竞选出块节点。 如果在出块过程中，节点的押金被扣为负数后还不补足，则投票给此节点的所有用户都没有分红，节点也无收入奖励。 在节点连续漏块超过9个块后，任何人都可以发起多签提议惩罚冻结节点，未出块扣除的罚金由提议多签惩罚漏块节点的用户和同意多签的前16名出块节点平分（发起方占20%，同意多签占80%）。提议多签惩罚需要抵押100EOSC代币，14400块高度后无论多签是否通过，可领取返还抵押代币。 被冻结的出块节点进入为期1小时的观察期，此期间用户投票无挖矿奖励，节点也无任何奖励。观察期过后BP可申请恢复正常,再进入正常选举,产生正常投票挖矿收益。 ## **7.链上去中心化预算系统** EOSC主网的链上去中心化预算系统为社区贡献者、开发者提供预算支持，任何人都可以发起预算提案申请，并交由去中心化的预算管理委员会进行审批。实现区块链的长期可持续发展。 预算提案的申请有以下规则： * 提案人发起提案需要抵押100个EOSC作为押金，防止垃圾提案，押金在提案通过后退回。 * 提案人需要详细说明提案目标，实施细则（周期、成本、金额）以及提案将带来的回报。 * 提案获得管理委员会批准后，将有14天的公示期，公示期内大于三分之一超级节点反对，即可否决提案。若提案在公示期没有被否决，在公示期后，系统将自动将申请奖励按月份发放到申请人账户。 * 提案通过公示期后，提案人在下一个区块奖励中，会按月份开始获得申请的EOSC代币来执行自己的提案内容。 * 奖励发放期间，管理委员会和超级节点大于三分之一否决，可以叫停该提案奖励发放。 ## 8.虚拟机与执行引擎 虚拟机支持是EOSC技术框架中最重要的一部分之一, 虚拟机定义整个链的对外功能, 所有DAPP合约都在虚拟机中执行, 在EOSC中这一部分被定义为执行引擎。 目前, EOSIO技术栈主要支持基于WASM的虚拟机实现, 未来将会统一使用EOS-VM实现, 但另一方面, 对于EOSIO来说使用哪种虚拟机并不是固定的, 支持不同的虚拟机或脚本系统可以很大程度上简化DAPP开发的难度, 但是需要注意的是, 为了最大程度上兼容EOSIO以后的发展, EOSC的执行引擎被设计为插件式的拓展支持, EOSC中, 新增的虚拟机支持和脚本系统不会取代原生的C++合约实现和基于EOS-VM规则下的虚拟机实现, 这类拓展支持更多的将会在子链中实现。 ### 8.1更多的链状态拓展 目前EOSIO中的链状态数据结构相对固定, 这样虽然可以很好的兼顾效率和使用, 但也会成为DAPP开发的一个限制因素。 为了更好的支持插件式的运行时系统, 在EOSC中会添加更多的链状态拓展数据结构, 与原有的数据类型不同, 这些数据的存储和内存状态将会相对独立, 并且序列化结构中将会添加数据类型元信息, 以此增强这部分数据的兼容性和拓展性。 ### 8.2插件式运行时支持 EOSC将会支持更多的虚拟机和脚本系统, 同时最大程度的保持与原来系统的兼容性. 为此EOSC将会加入插件式的运行时支持, 新增的虚拟机代码和脚本将会采取两段式的执行逻辑, 即超级节点计算时先执行代码或脚本以得出链状态变化的结果信息, 同时对此结果信息和原有的行为信息进行签名验证, 在对应的区块进入不可逆区块之后, 节点的重放时不会重复执行原有的代码, 而是直接使用兼容性较高的状态迁移结果, 这样可以使得EOSC的主链和子链可以保持较高的兼容性。 ## 9.子链架构 EOSC需要满足性能和功能上的水平可拓展性, 同时与EOSIO保持兼容, 为此EOSC将会加入子链架构, 不同于常见跨链架构, 各个子链是链原生的一部分, 与主网保持一致的超级节点权限状态, 子链通过纠缠证明来与主链进行“挂钩”, 以此证明其状态的有效性。 相对于各个不同共识下的链通过跨链机制组成的多链架构, 子链架构不会影响整个链的去中心化程度和共识, 很好的平衡了链的拓展性和权益。 ### 9.1子链 区块链采用hash绑定的方式维持一个单链结构, 对于EOSIO来说, 一个块高度上最终有且仅有一个区块, 所有产出的区块中, 事务(transcation)和行为(action)都是有序的, 虽然通过并发执行结果不相关联的事务(transcation)可以使得链的计算充分利用多核环境, 但是依然会将链的节点限制在单机上。 原始的EOSC链称为主链, 超级节点的选举和治理都在主链完成, 在主链之外, EOSC可以添加独立的子链, 子链与主链的超级节点权限保持一致, 子链的区块同样需要超级节点的验证. 由于子链的大部分状态和行为独立于主链,所以对于一个超级节点, 子链节点可以独立于主链节点运行, 这使得EOSC可以通过添加物理机器来拓展主网运行的性能。 ![](https://2843707721-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LkSzbFzzFSFjpEUgtlI%2F-Lu70XZRrsFMp6BIUUo2%2F-Lu73t4GkVJO4ijwT4Hd%2F%E5%9B%BE%E7%89%87%201.png?alt=media\&token=e1481121-0c55-4f9c-9002-5f2203a0b4f6) 通过子链, EOSC也可以在拓展功能的同时保持原有链的兼容性, 一些独立特定的功能可以通过子链添加如EOSC中, 形成数个专用子链, 这样EOSC可以添加更多的特性以支持复杂的DAPP。 ### 9.2主状态纠缠证明 子链独立于主链, 所以主链需要能够确认子链的状态与主链保持一致。对于各个子链, 其需要与主链保持一致的状态称为主状态, 一个子链中的区块, 除了超级节点的确认之外, 还需确认其主状态, 这样就可以确认一个子链的区块是否有效。 ![](https://2843707721-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LkSzbFzzFSFjpEUgtlI%2F-Lu70XZRrsFMp6BIUUo2%2F-Lu741v5O9WmQuqrLfUM%2F%E5%9B%BE%E7%89%87%202.png?alt=media\&token=64902f48-2b2a-4403-99a3-482283ce5c70) 在EOSC中, 子链需要进行主状态纠缠证明, 通过在区块中计入主状态变换行为的Hash结果以证明其一致性, 这样可以通过主链的状态快速验证子链区块。 ### 9.3元子链 元子链是只包括EOSC主链主状态的子链, 对于各个子链来说主状态是验证其有效性的最基本的信息, 但是主状态是基于EOSC主链获得的, 子链可以基于元子链的数据来进行主状态纠缠证明, 这可以允许子链进行轻量级的验证同步过程。 ![](https://2843707721-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LkSzbFzzFSFjpEUgtlI%2F-Lu70XZRrsFMp6BIUUo2%2F-Lu749pXsCtfa-v81ysJ%2F%E5%9B%BE%E7%89%87%203.png?alt=media\&token=e4a8f10a-72ab-44a8-baa2-d032dd518ec5) ### 9.4状态校验子链 EOSC区块数据与状态数据都是通过全节点重放计算得出的, EOSC可以实现轻节点验证, 但是在可信的基础上无法直接获取链状态。 目前基于EOSIO的区块链往往需要用户通过中心化的节点或者服务获取链的状态信息, 这些信息并没有方式可以被证明是可信的, EOSC引入状态子链, 可以将状态变换信息至于子链之上, 可以使得链外应用获取到可靠的链状态信息。 配合静态账户机制, 状态校验子链可以使EOSC更简单高效的融入各种跨链场景中, 增加链的可用性。 ![](https://2843707721-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LkSzbFzzFSFjpEUgtlI%2F-Lu70XZRrsFMp6BIUUo2%2F-Lu74GM2yfSth12RJFKX%2F%E5%9B%BE%E7%89%87%204.png?alt=media\&token=081a0f06-115c-451d-a550-1e1a32b159b1) ### 9.5计算子链 EOSC的子链同样可以部署DAPP, 这相当与常见的Layer 2子链模式等价, EOSC将会创建一些对等的计算子链用于用户部署特定的DAPP, 以实现拓展主网运行的性能。 ![](https://2843707721-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LkSzbFzzFSFjpEUgtlI%2F-Lu70XZRrsFMp6BIUUo2%2F-Lu74MlKOei--EfLfqBW%2F%E5%9B%BE%E7%89%87%206.png?alt=media\&token=c38ca9af-518d-4042-b4fd-849f26e8f90b) ### 9.6存储子链 EOSC将会纳入一条存储子链, 这条子链将会在IPFS协议基础之上引入链上激励与惩罚机制, 通过这条子链用户可以在链上使用大型状态信息, 以此支撑更加复杂的DAPP。 存储子链可以允许DAPP使用可信的海量数据, 这将可以支撑更加复杂的DAPP, 以拓展DAPP的业务范围, 这是一条完整公链的必备功能。 当前的EOSC中, 存储状态主要通过两个途径: 基于区块数据和基于状态数据, 前者无法与合约层去中心化的交互, 而后者的成本过高, 无法支持海量数据的存储。 存储子链将会允许EOSC支持可信的海量数据, 这需要引入专门的角色来完成对应的职能, 这些角色的权利在主链中承载, 主链将会引入对应的合约依照存储子链的数据来进行这些角色的激励与惩罚, 而功能性的逻辑将会基于存储子链完成, 其中主要包括三个方面: 数据元信息管理, 存储有效性证明和存储经济系统。 * **存储子链中的角色** 存储子链中有三类角色: 矿工(worker), 数据所有者(owner)和验证者(checker). 这三类角色基于存储数据功能的不同而互有重叠, 矿工实际存储数据, 其需要向链完成存储有效性证明, 以此被系统奖励和惩罚. 数据所有者是数据的提供者, 其需要向系统提供数据的元信息并进行验证确认, 验证者可能是存储子链上的任何角色, 其根据实际的状态会对矿工发起存储有效性证明挑战, 以此确认有效性. * **数据元信息** 为了验证存储海量数据, 需要在链上建立大量数据元信息及其索引信息, 这些数据存储于存储子链的RAM中, 不同于一般合约使用的多重索引数据结构, EOSC将会优化数据元信息的存储, 使得存储子链可以支持大量的存储元数据. * **存储有效性验证** 为了确认存储的有效性, 需要矿工和数据所有者完成存储有效性验证, 以此来证明在一定概率下其角色可以提供完整数据, 存储有效性验证可以由存储子链上的任何角色发起, 如果对应角色无法在一定时间内完成存储, 其将会受到对应的惩罚. 存储子链需要建立对应的激励惩罚机制, 激励和惩罚在主链上完成, 基于EOSC来分配存储链的权利, 另一方面, 为了更加有效的利用存储空间和链资源, 存储子链将会通过交易合约来进行存储扇区分配, 这一过程类似于操作系统中的内存分配算法, 数据所有者可以通过调整手续费来平衡成交所需的时间。 ### 9.7子链双向互操作 EOSC子链可以直接获取主链的信息和状态, 这些信息可以以两种形式进入子链的区块: 引用形式和嵌入形式. 对于引用形式, 子链的区块中只包含主链信息的索引及Hash信息, 要全面验证子链的区块需要同步主链的状态, 这种方式可以使子链更加轻量化, 适合配合主链的功能性子链使用. 对于嵌入形式, 子链的区块中将会包含主链全部有关信息, 全面验证子链不需依赖同步主链的状态, 这种方式虽然会增加子链的数据量, 但是子链可以更加独立于主链, 这种方式适合比较独立的计算性子链使用。 通过以上方式可以实现主链到子链的状态传递, 以实现主链对子链的单向可操作性, 另一方向, 子链也需要传递部分状态到主链, 由于子链仅是主链的补充, 同时为了保持兼容性, EOSC主链需要保持独立性, 所以所有子链向主链的状态转移都需要以嵌入的方式进行。 子链与主链之间可以实现双向的互操作性, 子链与子链之间也可以实现同样的机制, 实现的具体形式可以根据子链的作用不同而做出不同的选择。 ## 10.跨链与多链 跨链是目前区块链发展的重要方向之一, 通过跨链技术, 一条链可以获得更多的应用场景和更大的用户数量. 目前除了热门的跨链项目, 如Polkadot、Cosmos等, 原力团队也设计并实现Codex.Relay中继链, 以实现在零信任基础上为高性能链间提供中继服务, EOSC将会原生支持Codex.Relay项目, 同时EOSC也将会支持其他跨链协议。 ### 10.1 高性能跨链支持 对于基于EOSIO的高性能链来说, 适配其他异构或者同构的跨链协议有一定的障碍, 主要的问题在于基于EOSIO的链由于其往往承载了大量的交易和行为, 所以搭建全节点以验证行为会消耗大量计算资源, 这也是EOSIO基于超级节点出块的一个主要原因, 但是对于其他跨链协议, 这样的负载消耗会使得跨链过程趋向于中心化, 虽然可以通过由超级节点负责跨链验证的方式解决这一点, 但这回阻碍项目融入其他跨链协议中。 EOSC基于静态账户和子链机制可以让轻节点具备验证链状态的能力, 因此EOSC将可以几乎无缝的实现大部分跨链协议, 并且不会趋于中心化, 这将会使得EOSC具有更大的应用场景和更多的用户数量。 ### 10.2 Codex.Relay中继服务 EOSC可以基于Codex.Relay中继服务来与其他链进行互操作, 作为原生支持Codex.Relay中继服务的公链, EOSC的超级节点将会作为验证者参与与Codex.Relay中继服务的状态通信过程, 这样EOSC与Codex.Relay的跨链过程将不会降低EOSC和Codex.Relay的去中心化程度。