mt logoMyToken
总市值:
0%
恐慌指数:
0%
币种:--
交易所 --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

社区互动 | 解读aelf区块链白皮书——Part 1

收藏
分享

此前,社区用户代表艾斯系统地介绍了aelf区块链项目,本文将更进一步,为大家解读aelf区块链白皮书。

接下来两篇文章,让我们开始正题:展开介绍aelf区块链白皮书的内容。

为什么需要云计算?

我们已经提及云计算是一个关键特性。在BingoGame里,aelf团队只部署了两个智能合约,而且它们都很简单(通过把C#代码编译成中间码,然后发一个特殊的合约创建交易,把中间码传到区块链上)。每个人都可以把C#的合约编译并部署在区块链上,这样其他人就可以调用合约开发一些DApp。如果使用aelf区块链的人比较少,并不会构成什么影响,但是对于任何企业级的场景来说,这个区块链架构就会引发严重的问题,只需想象一下供应链领域中如同洪流一样的数据量就可以体会到这点。在这种情况下,部署的合约数量将非常庞大,如果有许多人调用它们,合约的执行总次数将会更高。就算一个全节点或区块生产节点在.NET的框架上执行智能合约,但面对庞大的合约执行量,节点还是要花费较长时间完成,这是无法容忍的缺陷——试想有2,500,000个智能合约排队执行会是怎样的情况?对于一般的区块链,这种情况又叫做“交通堵塞”。

综上所述,要使用云计算的原因便不言而喻,与其用一般的电脑作为全节点,为什么不使用一台超级电脑呢?

为什么要采取并行呢?

除了云计算之外,aelf还让这些节点以并行的方式执行智能合约。在这之前,智能合约都是单线程串行执行的,如同Javascript引擎的事件循环。但是精于C#的aelf团队发现C#底层架构就支持这样的并行执行,于是这个特性就被自然而然地应用于aelf区块链的架构设计中。结合一些设计模式,aelf团队发明了这种引领新潮流的并行执行的区块链节点。

比如系统要执行1000个任务(交易或合约),首先aelf系统会检查这些任务是否会同时更改一个相同的值,如果是,就让这些任务串行执行,因为我们不想让并行执行发生冲突。但如果不是,这些不冲突的任务就可以相互并行执行。因此,这些任务会被分组,相互冲突的放在一个组串行执行,不冲突的就放在别的组,这样几个组就可以一起并行执行。假设这1000个任务会被分为4个组:200个、300个、250个和250个,这样总体的执行效率将提高大约4倍。

就如同漫威英雄集结在一起对战灭霸那样,aelf也结合了包括云计算和并行执行的技术,使得企业级的应用体验畅通无阻。接下来,我们看看更多的技术。

DPoS和AEDPoS

在上篇文章中“什么是区块链”的部分我们提及,对于分布式系统,把交易传播给超大量的节点是很费时间的。在 比特币 系统里,我们知道只有挖矿节点服装负责创造新区块,所以为什么不把挖矿节点的数量尽可能减少呢?因此,就出现了一种叫做“委托权益证明(DPoS)”的共识机制。权益证明(PoS)是一系列使用某种东西(比如通证数量)作为权益来打包新区块的共识算法,权益越高,打包的区块就越可能被一致承认。在DPoS里并没有很多挖矿节点(严格讲,在PoS中不存在挖矿的概念,这种节点被叫做验证节点),我们只委托很少量的验证节点生产新区块,然后把它们广播给其他的被委托节点。显然,DPoS消除了区块链分布式系统里的长时间广播问题。不过当验证节点大为减少的情况下,怎么防止这些节点相互串谋以至于最终违背区块链的去中心化原则呢?因此,所有的DPoS都有严格的投票机制,确保选出来的代表们是公平和透明的。

实际上,DPoS源于EOS区块链项目。在DPoS的设计里,有至少三种节点:新区块生产者(BP), 候选节点和普通节点。候选节点指的是候选成为BP的节点,他通过智能合约申请成为候选节点。理论上讲,任何具有足够算力的普通节点都可以成为候选节点(比如aelf推荐一个机器应该至少有8核CPU、8GB内存和500GB固态硬盘)。不过通过其他普通节点的投票,其中只有一小部分能成为BP节点。从经济角度讲,一个选择DPoS的区块链项目会给投了票的节点一定的token奖赏,这样节点们就会倾向投票了。投票机制实际上是一个智能合约,其中有投票方法,它需要投票节点的地址、给谁投票以及想抵押多少token,因为抵押的越多,投票的权重就越大。在aelf中,我们并不知道有多少节点成为候选节点,但是只有排名前17的候选节点可以成为BP节点。

aelf凭借一些特别技术,把DPoS升级成了特别的AEDPoS(aelf DPoS)。创始人创造了一种特别的回合制区块生产机制。如果你试图研究白皮书上这方面的内容,你会看到大量的数学表达式,不过不用害怕,核心思想其实很简单且直接。

在解释这些之前,我得提醒你两件事:第一个是真随机数产生器(后续文章会详细讲)。这个方法不仅可以用于产生随机数,还可以用来打乱一个集合的顺序(比如列表),这样就会使得其不可被预测、操纵和串谋。第二个是拜占庭将军问题。回顾一下,如果我们解决了这个问题,在分布式系统里我们就达成了共识。在1982年,这个问题被Lamport等人正式提出,他们在3个将军的场景下发现只要有一个人是叛徒,那么他们三个人就不可能达到共识。在这个观察的基础上,Lamport推导出系统在3n(n是正整数)个节点的情况下,如果有至少n个节点是叛徒,那么这个系统就不可能达成共识。因此在很多其他文章里,你总会看到如下陈述:

如果有f个作恶节点,要想让分布式系统有意义,系统就必须存在至少3f+1个节点。

在AEDPoS里,如果上线了主网或者测试网,默认会设定2N+1个BP,第一年N=8,往后每一年N增加1。这样在最开始系统中存在17个BP。如果13个BP正常工作(不超过5个BP——17/3的向下取整——是作恶的),那么所有的BP就可以达成共识。在这个条件下,aelf定义一个回合(round),在该回合里所有的BP节点顺次打包区块,在他们都打包完之后,我们再随机从其中挑一个BP,让他再打包一次新区块。在这个回合结束之后,我们将BP的出场顺序打乱,然后继续重复上述过程。其中的关键是,区块生产的顺序是足够随机化的,防止了BP串谋成功的可能。当然,这里面还有其他设计,不过这些内容并不会影响我们对AEDPoS的理解,因此就不再讨论了。

如同一般DPoS一样,BP的阵容会因为得票数的变化而总在变化。一个普通节点可以在任何时候为BP和候选节点投票,aelf区块链现在就支持该功能。每个月,aelf的系统都会检查谁在最近的前17名里,这样一些BP节点就会被剔除,而出现新的BP节点加入。

免责声明:本文版权归原作者所有,不代表MyToken(www.mytokencap.com)观点和立场;如有关于内容、版权等问题,请与我们联系。