Parte 1. Análise dos dados de votação da blockchain de 2019 na Duma da cidade de Moscou por alexeishch
Parte 2. Auditoria paralela durante votação eletrônica por CryptoTyan
Tive a sorte de participar da redação de um relatório sobre a votação em blockchain no MHD 2019 como parte da equipe Roman Uneman, e neste artigo vou falar em detalhes sobre a parte relacionada à análise de dados.
Algumas palavras sobre os dados de origem. Inicialmente, o arquivo de descarregamento da blockchain caiu em minhas mãos. Mais tarde, quando fiz a análise inicial, entrei em contato com a equipe de Roman Uneman, tinha à disposição os depoimentos de observadores presentes na “assembleia de voto” e fotografei monitores com dados de votação.
Métricas
Decidi olhar para tudo o que acontece através dos olhos do desenvolvedor. A primeira pergunta que me fiz foi: "o que eu faria se começasse a projetar esse sistema?" Sistema de votação - deve ser um sistema de alta disponibilidade e conter um componente observacional, e isso não é apenas registro. Assim, para observá-lo, era necessário escolher um número de quantidades que serviriam como métricas. Como o sistema foi baseado na blockchain, as métricas da própria blockchain devem fazer parte dessas métricas. Uma dessas métricas é o tempo de bloqueio. Essa conjectura foi o começo de todo o estudo. Antes de mim, a mesma Medusa prestava atenção aos problemas, mas eles apenas consideravam vozes e tudo estava longe de ser óbvio para eles.
Primeiro, explicarei o que significa o tempo de bloqueio e por que você precisa monitorar essa métrica enquanto o blockchain está funcionando. Hora do bloco, este é o tempo durante o qual o bloco é calculado e gravado. Dois valores podem estar ocultos sob esse nome: esse é o tempo esperado para calcular um bloco e o tempo médio de um bloco. O tempo de bloqueio esperado no caso da Prova de autoridade (PoA) da blockchain é definido pelos parâmetros do sistema. O tempo médio de bloqueio, já é em tempo real, calculado da seguinte forma: se no tempo T a rede blockchain calculou n blocos, o tempo médio de bloqueio é T / n. Uma alteração anormal nessa métrica sugere problemas e permite corrigir rapidamente esses problemas.
Vamos dar uma olhada nessa métrica, calculada com base no download de dados da blockchain. Como ainda sou desenvolvedor, e não analista, para facilitar o trabalho de análise de dados, escrevi simultaneamente um programa para análise, que constantemente me ajudava nisso. Você encontrará um link para seu código-fonte no final do artigo. A seguir, todos os gráficos estão sendo descarregados dele.
O eixo X é o número do bloco, o eixo Y é o tempo médio.
Olhando para essa métrica, podemos corrigir áreas de operação estável da blockchain, áreas de um aumento acentuado no tempo médio do bloco (zonas 1A, 1B, 2) e a área de degradação da rede de computadores blockchain, bem como uma área suspeita que lembra remotamente um pulso (zona 3).
Em primeiro lugar, afirmo que essa métrica deveria ter sido exibida em monitores na mesa de votação, como pode ser claramente julgado pelo desempenho de um dos principais componentes do sistema. Em segundo lugar, argumento que a partir desses dados, conclui-se que o trabalho da blockchain foi interrompido. Vamos calcular quantas vezes e quanto tempo.
Temos três seções com tempos de bloqueio suspeitos chamados por mim de "Zona 1A", "Zona 1B" e "Zona 2". O tempo de cálculo do bloco para o bloco 2046 foi entre 3 e 4 segundos. Para avaliação, tomamos o limite superior de 4 segundos e calculamos o tempo em que o blockchain foi parado.
Descrição das colunas da tabela
- Número do bloco inicial da zona
- Número do bloco final da zona
- O número de blocos na zona
- Hora de início da zona
- Horário de término da zona
- Duração da zona
- Tempo estimado em que a blockchain realizou cálculos com base no cálculo do tempo de bloqueio de 4 segundos
- Tempo estimado em que o blockchain foi desativado
Observo que assumi um limite superior para o tempo do bloco, respectivamente, isso fornece um limite superior para o tempo de cálculo e um limite inferior para o tempo de parada. I.e. tempos de parada reais provavelmente ainda mais. I.e. o tempo total para o blockchain parar completamente é de cerca de 2 horas.
A próxima zona curiosa é "zona 3". Há uma estranha gravação de blocos na frequência em comparação com períodos anteriores, mas consideraremos essa área separadamente quando examinarmos a distribuição de votos entre os blocos.
E, finalmente, das 14h20 até o final da votação, observamos um aumento constante no tempo de cálculo. Deixe-me lembrá-lo de que estamos falando sobre o blockchain do PoA e não há complicações das operações, como no caso da ETH, quando esse comportamento foi causado por uma "bomba de complexidade" no blockchain do PoW. I.e. observamos um comportamento inesperado da métrica blockchain, que indica a degradação do sistema.
Análise de distribuição de votos
Farei uma reserva imediatamente de que serei o mais objetivo possível e não abordarei as esquisitices na distribuição de votos entre os candidatos, e essa análise não será conduzida no contexto de candidatos individuais. No programa que escrevi, deixei a oportunidade de fazer isso para qualquer parte interessada. Neste artigo, estou interessado apenas no desempenho do sistema. Se você estiver interessado nessas esquisitices, consulte o relatório, pois tudo é descrito da maneira mais detalhada possível.
A distribuição dos votos é assim
O eixo X é o número do bloco, o eixo Y é o número de votos no bloco.
Como esperado, nas zonas de parada do blockchain (1A, 1B, 2), não há registros de voz, porque são zonas de falha. Mas a zona 3 é motivo de reflexão. Há um pequeno número de blocos de 1 a 3 votos, algumas explosões de 4 a 5 votos e uma enorme onda de votos no final desta zona. Combinei esses eventos com base na métrica de tempo do bloco, pois a degradação já ocorreu após esses eventos e a gravação desses blocos ficou dentro de limites aceitáveis. Na zona 3, não houve parada da blockchain, mas por algum motivo os dados praticamente não caíram na blockchain.
A duração total dessas zonas é de cerca de 4 horas. I.e. como a votação durou 12 horas, por cerca de um terço do tempo, por várias razões, os dados não foram registrados na blockchain.
Na área associada à degradação, vemos claramente que o modo de gravação mudou e os dados começaram a ser gravados com mais frequência, em contraste com os locais onde o blockchain funcionava de maneira estável. O que está conectado não é exatamente conhecido, porque a configuração exata não está disponível para nós, mas há uma suposição de que isso possa ocorrer devido ao estouro da fila de transações na paridade. Esse comportamento levanta questões para a equipe que integrou a Paridade ao back-end e também fala da possibilidade teórica de perder votos associados às transações de seleção.
É interessante que o número de votos no bloco seja limitado a 100. Não encontramos essa constante no código publicado - nem nas configurações nem no código.
Não recebi uma explicação sobre a origem do surto de votos, após o qual a degradação começou, nesta etapa da análise, e tentei encontrar uma explicação nas fotografias dos dados nas telas de votação feitas pelos observadores.
Análise dos dados disponíveis para os observadores
Aqui, falaremos sobre os dados disponíveis para os observadores, que foram posicionados como uma alternativa à presença de observadores em uma verdadeira assembleia de voto. Fotos com base nas quais são coletadas, você pode obter no relatório.
Devo dizer imediatamente que acredito que os observadores não receberam deliberadamente os dados na medida em que precisavam entender e rastrear os processos ocorridos no sistema
- Os observadores não viram as métricas do sistema e, como resultado, não conseguiram avaliar superficialmente o grau de operabilidade
- O nó de monitoramento de blockchain não foi fornecido aos observadores
- A apresentação tabular dos dados não permitiu aos observadores avaliar o que estava acontecendo.
Os dados exibiram 4 números, que mostraram essencialmente um funil de conversão
- Quantas pessoas foram ao início do processo de votação
- Quantas pessoas entraram no SMS de registro
- Quantas pessoas receberam o boletim
- Quantas pessoas votaram
Como esse é um funil, todos os quatro parâmetros estão interconectados:
- Você não pode receber SMS sem acessar a página
- Não receber SMS não pode receber um boletim informativo
- Você não pode votar sem receber um boletim informativo
Além disso, deve-se notar que a vida útil do boletim é de 15 minutos. Isso significa receber uma newsletter, você pode votar apenas por 15 minutos.
O eixo X é o tempo. O eixo y é o número de pessoas.
Uma representação visual mostra imediatamente anomalias.
Os fatos da ausência de visitas à página de votação (a linha verde na linha é horizontal) indicam a inacessibilidade da frente do sistema. A nota inferior é de 17 parcelas completas (incluindo uma que aumentou e diminuiu a quantidade), cada uma por 15 minutos. No total, são aproximadamente 4 horas e 15 minutos. Esses intervalos se sobrepõem parcialmente às falhas relacionadas ao blockchain e são parcialmente novos (por exemplo, 14:20 - 15:01, 15:30 - 16:15).
Durante aquela estranha onda de votos, por algum motivo, ninguém entrou no site e ninguém entrou no SMS. Não encontrei uma explicação para esse fato. I.e. com uma alta probabilidade, esse aumento está associado a algum tipo de interferência externa.
Durante o intervalo 15:30 - 16:15, apenas um parâmetro "SMS inserido" cresceu, parece que eles ajustaram as estatísticas, porque antes disso o número de cédulas emitidas era maior que o número de pessoas (linha vermelha) que inseriam corretamente o SMS. O que é impossível em termos de lógica.
Obviamente, existe a possibilidade de o mecanismo de apresentação de dados aos observadores simplesmente não ter funcionado ou ter funcionado com erros sérios, mas o reconhecimento desse fato é essencialmente o fato de os observadores não terem permissão para ir à assembleia de voto, porque, além desses dados, os observadores não tinham absolutamente nada
Conclusões
Tradicionalmente, quando as pessoas falam sobre sistemas de alta disponibilidade, elas iniciam uma conversa com nove - 90% do tempo em que o sistema funciona sem erros. Sistemas sérios podem fornecer trabalho com dois ou três noves (99% e 99,9% do tempo em que o sistema processa corretamente as solicitações). No caso da votação na Duma do Estado de Moscou, a votação durou cerca de 12 horas e o número de eleitores foi inferior a 10 mil pessoas. Ao mesmo tempo, o sistema não funcionou por mais de 4 horas. Então, por cinco horas e meia, os cálculos no blockchain se degradaram e ninguém reagiu a isso, o que mostra problemas na arquitetura devido à falta de monitoramento das métricas. Pessoalmente, eu tinha a opinião de que, com essas características, esse sistema não pode ser considerado nem um protótipo funcional.
PS Já quando eu estava lentamente preparando este artigo, um artigo do DIT apareceu em Habré, no qual eles afirmavam que "Ao longo do dia, o sistema de votação eletrônica funcionou de maneira estável, exceto por uma hora, mas conseguimos resolver rapidamente o problema". Espero sinceramente que isso tenha acontecido em um universo paralelo e que o autor receba o Prêmio Nobel por sua descoberta, porque métricas e dados contradizem isso diretamente. De acordo com os dados que recebi dessa realidade, conclui-se que o blockchain foi desativado por 2 horas, os componentes associados ao blockchain não funcionaram por 4 horas e, das 14:20 até o final da votação, a rede de computadores blockchain estava continuamente degradando, o que não podia lidar com uma onda estranha de votos, que não explicado pelos dados que recebi de observadores deste universo.
O conteúdo do relatório completo pode ser encontrado no site dedicado à votação eletrônica.
O código-fonte do programa analisador e os dados são carregados no Github (.NET Core 3 / WPF) -
Conteúdo do artigo DIT sobre arquitetura do sistema