您想要搜索什么内容?

技术公告|阅读需要5分钟

亦来云主网暂停增长问题分析及解决方案

  • 共享

故障回顾

 

2019年8月8日主网停滞在高度439668,分析运行节点日志发现该高度发生了inactive切换,而在发送inactive切换的同时也完成了对该高度的区块确认。

经分析此次故障的原因有以下两点:

  • 主因:同一个高度上inactive交易与不包含该交易的已确认区块形成竞争条件,即其中一项先到达某节点后会导致其拒绝接受另一项,从而导致参与共识的DPoS节点因接受二者的先后次序不同而无法达成共识;
  • 诱因:该高度发生inactive切换是因为对应区块中存在大量input,这会涉及到相应的前驱交易的查询操作,而此类查询性能存在瓶颈。

以下就这两方面已做的工作以及计划改进工作分别做简要阐述:

共识中的竞争条件

 

故障的临时解决

 

由于在故障时间点前已发生了多次inactive切换,但触发这些inactive切换不是因为有超过1/3的超级节点不能正常工作,而是由于所在区块存在大量交易的前置查询(即存在很多交易input),导致验证时花费很长时间进而影响到各超级节点共识开启时间所致。此外即便发生了inactive切换,也不能及时使得全网恢复高度增长:这主要是因为切换仲裁人后,新加入的仲裁人需要较长的时间与其他仲裁人建立直连,如果这个过程过长再加上大量交易的前置查询所引起的延迟影响,就很有可能再次引发inactive切换。综上所述目前情况与设计inactive交易用于加速共识故障恢复的初衷不符,因此在v0.3.6中暂时去掉了inactive交易的触发情况。

由于v0.3.6之后不再会有inactive交易,上述故障中有关inactive交易的竞争条件不复存在,该故障的主因得以解决。

 

故障的长期解决方案
 

上文提到inactive切换暂时不会触发,这主要是因为目前链上处理区块性能存在瓶颈(关于该部分的解决方案请参见下文的[性能优化小节](#性能优化))。而当性能优化充分之后,inactive切换仍会触发用于解决超过1/3仲裁人无法正常工作的问题。此外,我们还考虑在极端情况下,大部分当前仲裁人都无法正常工作时退化为PoW共识出块,当仲裁人准备就绪时再恢复为DPoS+PoW共识出块,当然PoW出块时只会允许部分交易(如跨链提币交易在PoW出块时则不被允许)以保障主链以及侧链的安全。

由于共识机制的改进需要充分的论证、测试,而目前阶段需要将主要精力用于CR相关的功能以及性能优化的相关工作,因此长期解决方案预计将会在CR第二阶段发布后正式启动。

 

其他的竞争条件
 

除了上述的与inactive相关的竞争条件外,目前主链还存在一个竞争条件:即同一个高度上可能存在两个区块,他们对应view offset不同。不过该竞争条件可通过链上的分叉重组机制自动修复,因此不会如上述故障一样导致全网高度停止。但由于分叉重组涉及所有内存状态变动,而这些内存状态和不同交易甚至交易输出中的amount值都有关联,若线上频繁出现此类竞争条件,也会引发一些状态异常相关的问题,其中v0.3.8、v0.3.9中都有涉及相关问题的解决。

CR第二阶段发布后,我们计划在DPoS共识层面进一步解决该竞争条件频发的问题。

 

性能优化

 

如上文所述,目前区块处理存在性能瓶颈,而该瓶颈会放大当前仲裁人开启共识的时间差异,进一步延缓共识完成时间、增加各类竞争条件触发概率。因此在近期的开发中以及未来的开发计划中,性能优化都是我们需要重点改进的工作。以下就CR第一阶段和CR第二阶段的主要性能优化工作做以说明:

CR第一阶段
 

该阶段主要就UTXO缓存池及数据库两方面做了优化:

 

UTXO缓存池
 

一个交易从进入到交易池,打包后包含该交易的区块进入区块池,最后该区块确认到达后接入到最高链,会在短时间内对该交易做三次有效性验证。在验证过程中会涉及对该交易所花费的UTXO查询,而每一次查询都访问数据库则会延长处理时间。由于此类操作符合热点数据特性,因此可在内存中维护一个UTXO缓存池用于查询加速。

区块数据从数据库中剥离
 

目前线上版本中区块数据整个存储于leveldb数据库中,这对于数据库用于优化查询的缓存是很不利的(数据越大就意味着缓存命中率越低)。因此我们将区块数据以文件的形式存储,仅将区块相关的索引数据存储于数据库中,这样就会提高数据库的查询速度。

我们可以看到这样改造之后数据库存储区块的部分仅存储了区块的元数据信息,但数据库还有部分数据并不是元数据而是整块数据,这部分工作在第二阶段中会完成改造。

 

CR第二阶段
 

该阶段主要的优化工作有:

 

数据库元数据化
 

继CR第一阶段的数据库改造工作,我们在该阶段将数据库彻底变为一个存储元数据的索引库,这主要涉及以下两方面的数据迁移:

  • UTXO数据:包括以地址为索引主要服务于钱包业务的UTXO数据,以及以交易hash及交易输出index为索引主要用于双花检查的UTXO数据。
  • Confirm数据:即区块确认的相关信息

数据库元数据化除了可以提升性能,还可以支持通过区块文件数据恢复存储元数据的索引库,这可以优化数据拷贝部署和灾难恢复的体验。

 

UTXO按使用场景细分
 

我们在第一阶段的基础上进一步按使用场景对UTXO进行细分并做针对性优化,主要会涉及以下方面:

  • 以地址为索引的UTXO数据存储:拆分后该部分缓存主要用于钱包相关业务,由于该部分为的区块处理的性能瓶颈,我们可进一步支持可配置注册地址,按地址裁剪该部分的存储则可以极大地加速区块处理性能
  • 以交易hash为索引的UTXO缓存:用于一般的UTXO访问操作,采用LRU策略,拟支持可配置大小,这样性能较好的超级节点可以根据情况做优化
  • 用于跨链交易的UTXO数据存储: 跨链交易由一系列特殊地址组成,主要用于跨链共识
  • 用于DPoS投票的UTXO缓存:DPoS投票为热点数据,需要缓存以优化处理DPoS投票交易处理速度
  • 用于CRC相关的UTXO缓存:与CRC相关的缓存主要涉及投票及流通量统计地址相关的交易

 

  • 共享

其它帖子

年度报告|0 MIN. READ

CR筹委会委员变更公告

双周报|2 MIN. READ

亦来云双周报|2019-12-03

年度报告|1 MIN. READ

亦来云双周报|2019-11-19

00:00 / 0:00:00