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,所以在做模块化功能的时候，需要考虑延迟的存在，这样对于系统的稳定性有一定程度的提升。
