【DNT精英论坛回顾】基于.Net Core构建aelf区块链云计算平台

2019年7月28日，DNT精英论坛（暨.NET北京俱乐部）第1期在北京中关村国际创客中心举行。论坛由资深.NET专家和社区活跃用户发起，以“分享、成长、合做、双赢”为原则，旨在打造一个领先的技术分享平台和成长交流生态。

aelf技术VP戎朋做为受邀嘉宾参加主题为“见证.NET，风口上的成功案例”的论坛。并分别就aelf的设计理念，以及如何结合.NET Core和相关技术进行实现，同时将对.NET Core和区块链技术将来结合进行深度思考。 当前区块链的痛点是什么？如何解决？怎样破局？带着这些问题，咱们回顾一下，aelf技术副总裁戎朋在这次论坛上所提出的一些解决方案。

做为去中心化云计算的区块链平台，aelf旨在解决区块链的商业落地应用问题，为了推动区块链价值的实现，aelf找出了区块链目前亟待解决的如下三个主要问题。

资源隔离问题

在一个旨在实现商业落地应用的区块链平台上，会存在成百上千个Dapp，如何让这些Dapp各自实现自身的功能属性，互不影响，资源隔离是目前比较具备前瞻性的解决设计。

性能问题

每个Dapp的用户增加是没法预见的，如何在大规模临时访问等大流量忽然增加的状况下，保持性能不受影响，是须要区块链系统具备很强可伸缩处理能力的。

治理问题

区块链是一个开放的去中心化平台。一旦启动，就至关于得到了本身的生命。如何构建一套生态体系，均衡区块链内部利益相关方的需求，使整个区块链生态系统朝着有益的方向演进？

基于以上三个行业痛点，aelf提出了对应的解决方案。

DPoS共识协议

DPoS解决了区块链的治理问题。首先经过DPoS共识协议，全部利益相关方投票决定产生区块的节点，其次是产生区块的顺序，最后是对于所产生区块的验证问题。

主链+多侧链，一链一场景

主链+多侧链解决了资源隔离的问题，每个Dapp均可以运行在本身的区块链（即aelf侧链）上，每条链均可以自主设置商业场景，并且侧链之间是物理资源隔离的。

并行执行

akka.net 基于.NET Core实现集群并行，基于.NET TPL实现的本机并行。

模块化

aelf深度应用了Dapp的设计理念，因此模块化特征很是明显，好比aelf使用GRPC实现了网络层的模块化，只要用户使用合适的接口，便可实现预约的功能。同理，只要有合适的接口，DPoS共识也能够转化为POW。

基于集群

aelf的构件运行在集群上，结合模块化的设计，aelf内部各模块的处理能力均可以伸缩与优化。

针对这些解决方案，戎朋在论坛上向嘉宾介绍了一些具体的实现细节

【DPOS机制】

DPOS共识机制决定了出块节点、出块顺序以及验证区块等问题。戎朋重点分享了出块顺序的架构设计。

aelf构建了一个依靠外界输入的随机系统，每一个记帐几点会产生一个in值和out值，每一轮的出块顺序依赖于上一轮in值的输入和本轮的in值，进而决定出块顺序。验证区块主要是对于记帐节点所产生区块的时间和是否合法进行验证。紧接着，戎朋就aelf和以太坊的架构进行了对比，以太坊的Network、Miner、Worker、DB等全部的模块都在一个kubernetes里执行的，而aelf的DB cluster和执行交易的Worker cluster都是基于集群执行的，因此具备很高的伸缩性。

【并行执行】

aelf的并行执行设计分为两个层次，首先是链级别的，也能够称为是设计师的并行，开发者能够根据本身的应用场景进行划分，对于不一样的场景去构建不一样的Dapp，以分散在不一样的侧链上，从而实现并行执行。另一层就是链内的并行，也能够称之为run time的并行，这种并行是将冲突的交易放在同一组别中，而后组别之间进行并行执行。

紧接着，戎朋讲到：咱们能够把区块链想象成一个经过合法交易促发的状态转移机。那么，这里面有两个角色。一个用来储存状态的数据库，一个定义状态转移逻辑的智能合约。

在合约的字段里，有可能有两种类型的字段。一种是普通字段，另一种是Map类型的字段，其中字段自己是一个键值对的集合。由于区块链的状态数据是在数据库里面以键值对的形式储存的，而合约里面使用的数据形式是合约类的字段。因此咱们须要一种机制来将合约的字段翻译为数据库数据的key。咱们定义了一个被称为data provider来负责这个翻译工做。每个合约实例咱们会分配一个root data provider，这种root data provider会负责整个合约全部字段的翻译。

对于普通字段，能够直接获得一个最终惟一的Key，可是对于map类型的字段是办不到的。因此对于map字段的翻译咱们获得的不是最终的key，而是一个sub data provider，这个sub data provider会负责在运行时将实际使用的这个map里的data key翻译为数据库的key。被翻译出的结果，咱们称为path。对于一个普通字段的path，一个标准形式包含合约地址，data provider名，以及字段名。而sub data provider，咱们能够认为翻译后的sub data provider名是root data provider名加上map字段名。完整的path被用来惟一肯定交易所使用的资源，普通字段的path能够经过静态分析合约代码获得。

基于此，戎朋介绍了key内部的处理流程，首先要进行资源的定义，定义那些冲突的资源，把冲突的资源进行分组，而后进行组与组之间的并行执行，对于因为用户手动失误而产生的冲突资源，最后进行针对性的阶段性测试。为了说明这个流程，戎朋用了几个例子进行说明。

戎朋：这是一个最简单的token合约。它有几个普通字段，用来记录stringstate和mappedstate的一些信息，这些字段都是0xabcd相似的合约地址，表明这一些key值，定义了一系列的path，这些资源的总和就被称为是资源的集合，咱们能够从下面的示例交易中看出最终产生的path。咱们看tx 1，从aaaa用户转帐给bbbb用户的交易，这里就涉及到的两个资源，/0xabcd/Balances/a和/0xabcd/Balances/b，tx 2是一样的道理。

在aelf系统里，须要实现一个标准，即acs2.proto ,在aelf系统中有不少相似的标准，要想实现资源的定义和合约的并行，那就须要实现Resource Info 这个函数，在这个例子中，须要根据合约的方法，定义这些冲突的资源，这样在合约执行的时候，会获取到这些冲突的资源，而后进行分组。接下来这个例子将很好地说明这个分组的方法。

这边有四个交易，第一个是从aaaa用户到bbbb用户的转帐100个token，第二个是从cccc用户到dddd用户的转帐300个token，第三个是跨合约的调用，从一个合约的aaaa到另一个合约的aaaa，第四个是从cccc用户到aaaa用户的转帐100个token,很明显，若是没有第四个交易，两个合约的资源是没有交叉可能性的，因此说，若是没有第四个交易，第一个交易和第二个交易是能够并行执行的，可是由于第四个交易的存在，整个系统就不能进行并行执行，由于资源冲突会对系统产生根本性的影响。 对于冲突资源的处理，aelf给出了这样的解决方案：当执行完毕监测到冲突的资源时，会把产生冲突的交易进行简单的丢弃，而后就会对这些合约进行标识，防止其执行，直到这些资源可以被正确的标识，这就是一个简单解决冲突的过程。

【侧链】

戎朋：虽然咱们用并行执行的思路加速了交易执行速度，但若是在一条链上存在多个DAPP，仍然会出现资源争用的问题，所以咱们引入了资源隔离的概念，即侧链结构。

aelf的侧链包含两种结构，一种是内部侧链，基于aelf经过联合挖矿的形式建立的侧链，另一种是外部侧链，像比特币和以太坊这样的异构链经过识别器加入aelf，进行交互。紧接着，戎朋介绍了侧链的索引过程和跨链通信机制。戎朋介绍道：跨链通信须要完成两个步骤的程序，首先要验证交易的存在性，其次验证交易的时序性，在完成这样的程序之后，就能够进行跨链转帐等一些具体的应用程序。而跨链索引有如下几个步骤，由父链索引自子链的区块头部数据，侧链同时索引主链的区块头部数据，从而进行数据的交互，最后进行跨链的验证。

【集群】

戎朋：上面咱们提到的并行执行和侧链，都是基于集群，aelf的每个节点都是基于集群运行。

咱们经过使用Kubernetes实现对集群的管理，集群里面最大的管理单元是链，有主链和侧链；而Pod是Kubernetes中的最小的管理单位，一个链中有多组不通的Pod角色组成，有Akka Manager Pods、Worker Pods、DB Pods等。aelf基于集群的并行执行是经过Akka框架实现的，交易经过多个Worker Pod组成并行执行的集群，而每个Worker Pod由多个actor组成，actor是Akka中最小的计算单元，咱们的交易就是最终分配给这些actor完成执行的 。不只并行执行经过集群管理，经过联合挖矿的侧链也属于集群的范畴，这里展现的是一个主链+2个侧链的结构，主链和侧链之间经过Merge Mining（联合挖矿）的形式实现相互索引。

最后，戎朋分享了关于aelf将来的深度思考。第一，即将发布的. NET 3.0 ，具备Assembly unload的特征，相比于2.0，在aelf系统里，将会比较方便的解决合约unload问题，第二，gRPC和ASP.NET Core 的深度结合，在aelf的技术栈中，gRPC做为底层通信，将会大大促进aelf接口的性能改进，增长便捷性。第三，aelf使用了大量的DDD (Domain-Driven Design)模型，促使aelf的模块化程度很高，让企业级用户可以简单便捷定制本身的区块链，最后一点就是网络延迟的问题，由于aelf是分布式的区块链系统，因此会有一个难以免的网络延迟，大概是300ms--500ms,因此在作模块化功能的时候，须要考虑延迟的存在，这样对于系统的稳定性有必定程度的提高。