Partie 1. Analyse des données de vote de la blockchain 2019 à la Douma de Moscou par Alexeishch
Partie 2. Audit parallèle lors du vote électronique par CryptoTyan
J'ai eu la chance de participer à la rédaction d'un rapport sur le vote blockchain dans le MHD 2019 au sein de l'équipe Roman Uneman, et dans cet article je parlerai en détail de la partie liée à l'analyse des données.
Quelques mots sur les données source. Au départ, le fichier de déchargement de la blockchain est tombé entre mes mains. Plus tard, lors de l’analyse initiale, j’ai contacté l’équipe de Roman Uneman, j’ai eu à ma disposition les témoignages d’observateurs présents au «bureau de vote» et photographié des moniteurs avec les données de vote.
Mesures
J'ai décidé de regarder tout ce qui se passe à travers les yeux du développeur. La première question que je me suis posée était: "que ferais-je si je commençais à concevoir un tel système?" Système de vote - devrait être un système à haute disponibilité et contenir un composant d'observation, et ce n'est pas seulement la journalisation. Par conséquent, pour l'observer, il était nécessaire de choisir un certain nombre de quantités qui serviraient de paramètres. Étant donné que le système était basé sur la blockchain, les métriques de la blockchain elle-même devraient faire partie de ces métriques. L'une de ces mesures est le temps de blocage. Cette conjecture a été le début de toute l'étude. Avant moi, la même méduse faisait attention aux problèmes, mais ils ne considéraient que les voix et tout était loin d'être évident sur eux.
Tout d'abord, je vais expliquer ce que signifie le temps de blocage et pourquoi vous devez surveiller cette métrique pendant que la blockchain fonctionne. Temps de bloc, c'est le temps pendant lequel le bloc est calculé et écrit. Deux valeurs peuvent être masquées sous ce nom: il s'agit du temps prévu pour calculer un bloc et du temps moyen d'un bloc. Le temps de bloc attendu dans le cas de la preuve d'autorité (PoA) de la blockchain est défini par les paramètres du système. Le temps de bloc moyen, c'est déjà du temps réel, qui est calculé comme suit: si dans le temps T le réseau de blockchain a calculé n blocs, alors le temps de bloc moyen est T / n. Un changement anormal dans cette métrique suggère des problèmes et vous permet de résoudre rapidement ces problèmes.
Jetons un coup d'œil à cette métrique, calculée sur la base du téléchargement de données depuis la blockchain. Comme je suis toujours développeur, et non analyste, pour faciliter le travail d'analyse des données, j'ai simultanément écrit de manière itérative un programme d'analyse, qui m'a constamment aidé dans ce domaine. Vous trouverez un lien vers son code source à la fin de l'article. Ci-après, tous les graphiques s'en déchargent.
L'axe X est le numéro de bloc, l'axe Y est le temps moyen.
En regardant cette métrique, nous pouvons corriger les zones de fonctionnement stable de la blockchain, les zones d'une forte augmentation de la durée moyenne du bloc (zones 1A, 1B, 2) et la zone de dégradation du réseau informatique de la blockchain, ainsi qu'une zone suspecte qui ressemble un peu à distance à une impulsion (zone 3).
Premièrement, j’affirme que cette métrique aurait dû être affichée sur les moniteurs du bureau de vote, il peut être clairement jugé sur la performance de l'un des principaux composants du système. Deuxièmement, je soutiens qu'à partir de ces données, il s'ensuit que le travail de la blockchain a été arrêté. Calculons combien de fois et combien de temps.
Nous avons trois sections avec des temps de blocage suspects appelés par moi "Zone 1A", "Zone 1B" et "Zone 2". Le temps de calcul du bloc jusqu'au bloc 2046 était compris entre 3 et 4 secondes. Pour l'évaluation, nous prenons la limite supérieure de 4 secondes et calculons le moment où la blockchain a été arrêtée.
Description des colonnes du tableau
- Numéro de bloc de début de zone
- Numéro de bloc de fin de zone
- Le nombre de blocs dans la zone
- Heure de début de zone
- Heure de fin de zone
- Durée de la zone
- Temps estimé lorsque la blockchain a effectué des calculs sur la base du calcul du temps de bloc de 4 secondes
- Temps estimé lorsque la blockchain a été désactivée
Je note que j'ai pris une limite supérieure pour le temps de bloc, respectivement, cela donne une limite supérieure pour le temps de calcul et une limite inférieure pour le temps d'arrêt. C'est-à-dire les temps d'arrêt réels sont probablement encore plus. C'est-à-dire le temps total pour que la blockchain s'arrête complètement est d'environ 2 heures.
La prochaine zone curieuse est la "zone 3". Il y a un étrange enregistrement de blocs en fréquence par rapport aux périodes précédentes, mais nous considérerons ce domaine séparément lorsque nous examinerons la répartition des votes entre les blocs.
Et enfin, à partir de 14 h 20 jusqu'à la fin du vote, on observe une augmentation constante du temps de calcul. Permettez-moi de vous rappeler que nous parlons de la blockchain PoA et qu'il n'y a pas de complication des opérations comme dans le cas des ETH, lorsqu'un tel comportement a été causé par une «bombe de complexité» dans la blockchain PoW. C'est-à-dire nous observons un comportement inattendu de la métrique blockchain, qui indique la dégradation du système.
Analyse de la répartition des votes
Je réserve tout de suite que je serai aussi objectif que possible et ne toucherai pas aux bizarreries dans la répartition des votes entre les candidats, et cette analyse ne sera pas menée dans le contexte des candidats individuels. Dans le programme que j'ai écrit, j'ai néanmoins laissé l'opportunité de le faire à toute personne intéressée. Dans cet article, je ne m'intéresse qu'aux performances du système. Si vous êtes intéressé par ces bizarreries, alors vous devriez vous référer au rapport, là tout est décrit aussi détaillé que possible.
La répartition des votes ressemble à ceci
L'axe X est le numéro du bloc, l'axe Y est le nombre de votes dans le bloc.
Comme prévu, dans les zones d'arrêt de la blockchain (1A, 1B, 2), il n'y a pas d'enregistrements vocaux, car ce sont des zones de défaut. Mais la zone 3 donne matière à réflexion. Il y a un petit nombre de blocs de 1 à 3 votes, quelques rafales de 4 à 5 votes et une énorme vague de votes à la fin de cette zone. J'ai combiné ces événements sur la base de la métrique de temps de bloc, car la dégradation s'est déjà produite après ces événements et l'enregistrement de ces blocs est allé dans des limites acceptables. Dans la zone 3, il n'y avait pas d'arrêt de la blockchain, mais pour une raison quelconque, les données ne tombaient pratiquement pas dans la blockchain.
La durée totale de ces zones est d'environ 4 heures. C'est-à-dire étant donné que l'ensemble du vote a duré 12 heures, puis pendant environ un tiers du temps, pour diverses raisons, les données n'ont pas été enregistrées sur la blockchain.
Dans le domaine associé à la dégradation, nous voyons clairement que le mode d'enregistrement a changé et que les données ont commencé à être écrites plus souvent, contrairement aux endroits où la blockchain fonctionnait de manière stable. Ce à quoi il est connecté n'est pas exactement connu, car la configuration exacte n'est pas disponible pour nous, mais il y a une hypothèse que cela peut être dû au dépassement de la file d'attente de transactions en parité. Ce comportement soulève des questions pour l'équipe qui a intégré la parité avec le backend, et parle également de la possibilité théorique de perdre des votes associés aux transactions d'abattage.
Il est intéressant de noter que le nombre de votes dans le bloc est limité à 100. Nous n'avons pas trouvé cette constante dans le code publié - ni dans les paramètres, ni dans le code.
Je n'ai pas reçu d'explication sur l'origine de la flambée des votes, après quoi la dégradation a commencé, à ce stade de l'analyse, et j'ai essayé de trouver une explication dans les photographies des données des écrans de vote que les observateurs ont faites.
Analyse des données disponibles pour les observateurs
Nous parlerons ici des données dont disposent les observateurs; ils étaient positionnés comme une alternative à la présence d'observateurs dans un vrai bureau de vote. Les photos sur la base desquelles elles sont collectées, vous pouvez les obtenir à partir du rapport.
Je dois dire tout de suite que je pense que les observateurs n'ont délibérément pas reçu les données dans la mesure où ils ont besoin de comprendre et de suivre les processus en cours dans le système
- Les observateurs n'ont pas vu les mesures du système et, par conséquent, n'ont même pas pu évaluer superficiellement le degré de son opérabilité
- Le nœud de surveillance de la chaîne de blocs n'a pas été fourni aux observateurs
- La présentation tabulaire des données n'a pas permis aux observateurs d'évaluer ce qui se passait.
Les données affichaient 4 nombres, qui montraient essentiellement un entonnoir de conversion
- Combien de personnes sont allées au début du processus de vote
- Combien de personnes ont saisi le SMS d'inscription
- Combien de personnes ont reçu la newsletter
- Combien de personnes ont voté
Puisqu'il s'agit d'un entonnoir, les quatre paramètres sont interconnectés:
- Vous ne pouvez pas recevoir de SMS sans accéder à la page
- Ne pas recevoir de SMS ne peut pas recevoir de newsletter
- Vous ne pouvez pas voter sans recevoir de newsletter
De plus, il convient de noter que la durée de vie de la newsletter est de 15 minutes. Cela signifie recevoir une newsletter, vous ne pouvez voter que pendant 15 minutes.
L'axe des X est le temps. L'axe des y est le nombre de personnes.
Une représentation visuelle montre immédiatement des anomalies.
Les faits de l'absence de visites sur la page de vote (la ligne verte, la ligne est horizontale) indiquent l'inaccessibilité de la face avant du système. La note inférieure est de 17 parcelles complètes (dont une parcelle où la quantité a augmenté puis diminué), chacune pendant 15 minutes. Au total, cela représente environ 4 heures 15 minutes. Ces intervalles se chevauchent partiellement avec des dysfonctionnements liés à la blockchain et sont partiellement nouveaux (par exemple 14h20 - 15h01, 15h30 - 16h15).
Au cours de cette étrange vague de votes, pour une raison quelconque, personne n'est venu sur le site et personne n'a entré de SMS. Je n'ai pas trouvé d'explication à ce fait. C'est-à-dire avec une forte probabilité, cette surtension est associée à une sorte d'interférence extérieure.
Au cours de l'intervalle 15h30 - 16h15, un seul paramètre «SMS entré» a augmenté, il semble qu'ils aient ajusté les statistiques, car avant cela, le nombre de bulletins émis était supérieur au nombre de personnes (ligne rouge) qui avaient correctement saisi SMS. Ce qui est impossible en termes de logique.
Bien sûr, il est possible que le mécanisme de présentation des données aux observateurs n'ait tout simplement pas fonctionné, ou ait fonctionné avec de graves erreurs, mais la reconnaissance de ce fait est essentiellement le fait que les observateurs n'étaient pas autorisés à se rendre au bureau de vote, car en plus de ces données, les observateurs n'avaient absolument rien
Conclusions
Traditionnellement, lorsque les gens parlent de systèmes à haute disponibilité, ils entament une conversation avec un à neuf - 90% du temps, le système fonctionne sans erreur. Les systèmes sérieux peuvent fournir du travail avec deux ou trois neuf (99% et 99,9% du temps, le système traite correctement les demandes). Dans le cas du vote à la Douma d'État de Moscou, le vote a duré environ 12 heures et le nombre d'électeurs était inférieur à 10 000 personnes. Dans le même temps, le système n'a pas fonctionné pendant plus de 4 heures. Ensuite, pendant cinq heures et demie, les calculs dans la blockchain se sont dégradés et personne n'a réagi à cela, ce qui montre des problèmes d'architecture en raison du manque de surveillance des métriques. Personnellement, j’avais l’opinion que, avec de telles caractéristiques, ce système ne pouvait pas être considéré comme un prototype fonctionnel.
PS Déjà lorsque je préparais lentement cet article, un article du DIT est apparu sur Habré, dans lequel ils affirmaient que "tout au long de la journée, le système de vote électronique a fonctionné de manière stable, sauf pendant une heure, mais nous avons pu résoudre rapidement le problème". J'espère sincèrement que cela s'est produit dans un univers parallèle et que l'auteur recevra le prix Nobel pour sa découverte, car les mesures et les données contredisent directement cela. Selon les données que j'ai reçues de cette réalité, il s'ensuit que la blockchain a été désactivée pendant 2 heures, les composants associés à la blockchain n'ont pas fonctionné pendant 4 heures, et de 14h20 jusqu'à la fin du vote, le réseau informatique de la blockchain s'est dégradé en permanence, ce qui n'a pas pu faire face à une étrange vague de votes, qui n'a pas pu expliqué par les données que j'ai reçues des observateurs de cet univers.