分析莫斯科市杜马市2019区块链投票的数据

第1部分。通过alexeishch分析莫斯科市杜马市的2019年区块链投票数据
第2部分 。CryptoTyan 进行电子投票时并行审核


我很幸运能作为Roman Uneman团队的一员参加MHD 2019中有关区块链投票的报告的撰写,在本文中,我将详细讨论与数据分析有关的部分。


关于源数据的几句话。 最初,从区块链卸载的文件落入我的手中。 后来,当我进行初步分析时,我与Roman Uneman的团队取得了联系,我可以支配在“投票站”的观察员的证词,并为他们拍摄带投票数据的监视器。


指标


我决定通过开发人员的眼光看待发生的一切。 我问自己的第一个问题是:“如果我开始设计这样的系统,我会怎么做?” 投票系统-应该是一个高可用性系统,并包含观察性组件,而不仅仅是记录。 因此,要观察它,需要选择许多数量作为度量标准。 由于系统基于区块链,因此区块链本身的指标应成为这些指标的一部分。 这些指标之一是阻止时间。 这个猜想是整个研究的开始。 在我之前,同一个美杜莎(Medusa)注意到了问题,但他们只考虑了声音,而且声音远非显而易见。


首先,我将解释区块时间的含义以及为什么您需要在区块链运行时监视该指标。 块时间,这是计算和写入块的时间。 该名称下可以隐藏两个值:这是计算块的预期时间和块的平均时间。 在区块链的权限证明(PoA)的情况下,预期的阻止时间由系统参数设置。 平均区块时间已经是实时的,其计算如下:如果在时间T中区块链网络计算了n个区块,则平均区块时间为T / n。 此度量标准的异常更改提示存在问题,并使您可以快速解决这些问题。


让我们看一下根据从区块链下载数据计算得出的指标。 由于我仍然是开发人员,而不是分析师,因此可以简化数据分析工作,因此我同时迭代地编写了一个分析程序,在此方面不断提供帮助。 您将在文章末尾找到其源代码的链接。 在下文中,所有图形均从中卸载。



X轴为程序段号,Y轴为平均时间。


查看此指标,我们可以确定区块链稳定运行的区域,区块平均时间急剧增加的区域(区域1A,1B,2)和区块链计算机网络的退化区域,以及可疑区域,该区域在某种程度上类似于脉冲(区域3)。


首先,我确认该指标应该已经显示在投票站的监视器上,例如 可以根据系统主要组件之一的性能来明确判断它。 其次,我认为从这些数据可以看出,区块链的工作已停止。 让我们计算多少次和多少时间。


我们有三个带有可疑阻止时间的部分,我将其称为“区域1A”,“区域1B”和“区域2”。 到块2046的块计算时间在3-4秒之间。 为了进行评估,我们将上限设为4秒,并计算区块链停止的时间。


块号开始块号结尾块数开始时间结束时间T间隔估计计算时间估计停止时间
2046252547909:26:0410:20:120:54:080:31:560:22:12
2525265112610:20:1211:08:220:48:100:08:240:39:46
28182956年13811:19:0812:29:181:10:100:09:121:00:58

表列说明


  1. 区域起始块编号
  2. 区域末端块号
  3. 区域中的块数
  4. 区域开始时间
  5. 区域结束时间
  6. 区域持续时间
  7. 区块链基于4秒的区块时间的计算进行估算的时间
  8. 估计禁用区块链的时间

我注意到,我分别为块时间设置了一个上限 ,这为计算时间提供了一个上限 ,为停止时间给出了一个下限 。 即 实际停车时间可能更多。 即 区块链完全停止的总时间约为2小时。


下一个好奇的区域是“区域3”。 与以前的周期相比,有一个奇怪的频率记录块,但是当我们查看块之间的投票分布时,我们将单独考虑该区域。


最后,从下午2:20到投票结束,我们发现计算时间不断增加。 让我提醒您,我们谈论的是PoA区块链,并且没有像ETH那样的操作复杂性,而这种行为是由PoW区块链中的“复杂炸弹”引起的。 即 我们观察到了区块链指标的意外行为,这表明系统性能下降。


投票分配分析


我会立即做出保留,我将尽可能地保持客观,并且不会涉及候选人之间投票分配的差异,并且不会针对个别候选人进行这种分析。 但是,在我编写的程序中,我还是把机会留给了感兴趣的任何一方。 在本文中,我只对系统的性能感兴趣。 如果您对这些奇怪的事情感兴趣,那么您应该参考该报告,其中对所有内容均进行了详细描述。


选票分配看起来像这样

X轴为区块编号,Y轴为区块中的票数。


不出所料,在区块链的停工区(1A,1B,2)中没有语音记录,因为这些是故障区。 但是第3区值得深思。 在这个区域的尽头,只有少量的1-3票区,几张4-5票的连串和大量的票数激增。 我基于块时间度量标准组合了这些事件,因为降级已经发生在这些事件之后,并且这些块的记录处于可接受的范围内。 在区域3中,没有区块链停止,但是由于某种原因,数据实际上没有落入区块链。


这些区域的总持续时间约为4小时。 即 鉴于整个投票持续了12个小时,因此出于各种原因,大约三分之一的时间里,数据没有记录在区块链上。


在与退化相关的区域中,我们清楚地看到,与区块链稳定运行的地方相比,记录模式已经改变并且数据开始被更频繁地写入。 它所连接的对象并不确定,因为我们无法使用确切的配置,但是可以假设这可能是由于奇偶校验中事务队列的溢出。 这种行为给将Parity与后端集成在一起的团队提出了疑问,同时也谈到了与淘汰交易相关的选票流失的理论可能性。


有趣的是,该块中的投票数限制为100。在发布的代码中-在设置或代码中都没有找到此常数。


在分析的这个阶段,我没有收到关于投票数量激增的起源的解释,此后投票开始退化,我试图在观察者所做的投票屏幕数据的照片中找到解释。


分析提供给观察者的数据


在这里,我们将讨论观察者可以使用的数据;它们的定位是代替实际投票站中观察员的存在。 您可以从报告中获取基于它们收集的照片。


我必须马上说,我相信观察者不是故意向他们提供数据,以至于他们需要了解和跟踪系统中发生的过程。


  1. 观察者没有看到系统指标,因此甚至无法从表面上评估其可操作性程度
  2. 没有向观察者提供区块链监控节点
  3. 数据的表格显示不允许观察者评估正在发生的事情。

数据显示4个数字,本质上显示了一个转化渠道


  1. 有多少人参加了投票程序的开始
  2. 有多少人输入了注册短信
  3. 有多少人收到时事通讯
  4. 有多少人投票

由于这是一个漏斗,所以所有四个参数都是相互关联的:


  1. 您必须先转到该页面才能收到短信
  2. 不接收短信不能接收新闻
  3. 您不能不接收时事通讯就投票

此外,应注意的是,新闻通讯的寿命为15分钟。 这意味着收到新闻通讯,您只能投票15分钟。


时间Zaregistr。短信输入已收到已投票
08:30:00575289274236
08:45:00858428406372
09:30:001825年831783710
09:45:001825年831783710
10:00:001898年1007957年710
10:15:001898年1007957年710
10:30:001898年1007957年710
10:45:001898年1007957年710
11:00:001898年1007957年710
11:15:00267510901045736
11:30:00278711041079748
11:45:00278711041079748
12:00:00278711041079748
12:15:00278711041079748
12:30:00288711781103759
12:45:00324512741213868
13:00:00386613211295973
13:16:004147142013521045
13:31:004436149513931085
13:46:004524158814601114
14:01:0044511783年15481138
14:16:0044511783年17001165
14:31:0044511783年1846(+63)1582
14:46:0044511783年1926年(+143)1669
15:01:0044641786年1992(+206)1731
15:15:0051531905年2045(+140)1784年
15:30:0053372024年2095(+71)1838年
15:45:00533721432095年1838年
16:00:00533722622095年1838年
16:15:00533723812095年1838年
16:30:007161268322302000
16:45:007260271722592028年
下午5点7388275522932069
17:15:007500278723172096年
17:30:007622281723402127
17:45:007731285023612153
18:00:007839288523862184
18:15:007920290824052214
18:30:008005293224182235
18:45:008091295124342256
晚上7点8199297324512275
19:15:008287299624692292
19:30:008394303524952325
19:45:008503306425122358
20:00:008581307725252376


X轴是时间。 y轴是人数。


视觉表示立即显示异常。


没有访问投票页面的事实(绿线,水平线)表明系统正面无法访问。 最低等级是17个完整地块(包括数量增加然后减少的一个地块),每个地块持续15分钟。 总共大约需要4个小时15分钟。 这些间隔与与区块链相关的故障部分重叠,并且是部分新的(例如14:20-15:01、15:30-16:15)。


在那奇怪的选票激增期间,由于某种原因,没人来该站点,也没有人输入SMS。 我没有为这个事实找到解释。 即 这种电涌很可能与某种外部干扰有关。


在15:30-16:15的时间间隔内,只有一个参数“ SMS输入”增加了,似乎他们调整了统计数据,因为在此之前,已发出的投票数大于正确输入SMS的人数(红线)。 就逻辑而言,这是不可能的。


当然,有可能将数据呈现给观察者的机制根本不起作用,或者出现了严重错误,但是这一事实的认识实质上是不允许观察者去投票站的事实,因为除了这些数据之外,观察者绝对没有任何东西。


结论


传统上,当人们谈论高可用性系统时,他们开始对话的时间是系统正常运行的九分之一-90%。 认真的系统可以提供两个或三个九的工作量(系统正确处理请求的时间分别为99%和99.9%)。 在莫斯科国家杜马投票的情况下,投票持续了大约12个小时,选民人数不到1万人。 同时,该系统无法运行超过4个小时。 然后,在五个半小时内,区块链中的计算性能下降,没有人对此做出反应,这表明由于缺乏指标监控,架构出现了问题。 我个人认为,具有这样的特性,即使是可以正常工作的原型也不能认为该系统。


PS当我正在慢慢准备本文时,DIT文章出现在哈布雷(Habré)上,他们声称“整天,电子投票系统稳定运行,只有一个小时,但我们能够迅速解决该问题。” 我衷心希望这是在并行的宇宙中发生的,并且因其发现而被授予诺贝尔奖,因为指标和数据都直接与此矛盾。 根据我从现实中获得的数据,可以得出以下结论:区块链关闭了2个小时,与区块链相关的组件在4个小时内都没有工作,并且从14:20到投票结束,区块链计算机网络一直在退化,无法应对奇怪的投票浪潮,这没有我从这个宇宙的观察者那里收到的数据来解释。


  • 报告全文可在专门用于电子投票的网站上找到。


  • 分析器程序的源代码和数据已上传到Github(.NET Core 3 / WPF)-


  • DIT文章中有关系统架构的内容


Source: https://habr.com/ru/post/zh-CN480332/


All Articles