Teil 1. Analyse der Blockchain-Abstimmungsdaten von 2019 in der Moskauer Duma von alexeishch
Teil 2. Parallele Prüfung während der elektronischen Abstimmung durch CryptoTyan
Ich hatte das Glück, an der Abfassung eines Berichts über die Blockchain-Abstimmung im MHD 2019 als Teil des Teams von Roman Uneman mitzuwirken, und in diesem Artikel werde ich ausführlich auf den Teil eingehen, der mit der Datenanalyse zusammenhängt.
Ein paar Worte zu den Quelldaten. Anfangs fiel mir die Datei zum Entladen aus der Blockchain in die Hände. Später, als ich die erste Analyse durchführte, nahm ich Kontakt mit Roman Unemans Team auf. Ich hatte die Zeugenaussagen von Beobachtern, die im Wahllokal anwesend waren und Monitore mit Abstimmungsdaten fotografierten.
Metriken
Ich beschloss, alles, was passiert, mit den Augen des Entwicklers zu betrachten. Die erste Frage, die ich mir stellte, war: "Was würde ich tun, wenn ich mit dem Entwurf eines solchen Systems beginnen würde?" Abstimmungssystem - sollte ein Hochverfügbarkeitssystem sein und eine Beobachtungskomponente enthalten, und dies ist nicht nur die Protokollierung. Um dies zu beobachten, war es dementsprechend erforderlich, eine Anzahl von Größen auszuwählen, die als Metriken dienen würden. Da das System auf der Blockchain basierte, sollten die Metriken der Blockchain selbst Teil dieser Metriken sein. Eine dieser Metriken ist die Blockzeit. Diese Vermutung war der Beginn der gesamten Studie. Vor mir achtete dieselbe Medusa auf Probleme, aber sie berücksichtigten nur Stimmen und alles war bei ihnen alles andere als offensichtlich.
Zunächst erkläre ich, was die Blockierungszeit bedeutet und warum Sie diese Metrik überwachen müssen, während die Blockierungskette funktioniert. Blockzeit, dies ist die Zeit, in der der Block berechnet und geschrieben wird. Unter diesem Namen können zwei Werte ausgeblendet werden: die erwartete Zeit zum Berechnen eines Blocks und die durchschnittliche Zeit eines Blocks. Die erwartete Sperrzeit für den Berechtigungsnachweis (Proof of Authority, PoA) der Blockchain wird durch die Systemparameter festgelegt. Die durchschnittliche Blockzeit, dies ist bereits Echtzeit, die wie folgt berechnet wird: Wenn in der Zeit T das Blockkettennetz n Blöcke berechnet, dann ist die durchschnittliche Blockzeit T / n. Eine anormale Änderung dieser Metrik weist auf Probleme hin und ermöglicht es Ihnen, diese Probleme schnell zu beheben.
Werfen wir einen Blick auf diese Metrik, die auf der Grundlage des Herunterladens von Daten aus der Blockchain berechnet wird. Da ich immer noch ein Entwickler und kein Analytiker bin, um die Arbeit der Datenanalyse zu erleichtern, habe ich gleichzeitig iterativ ein Analyseprogramm geschrieben, das mir dabei ständig weitergeholfen hat. Einen Link zum Quellcode finden Sie am Ende des Artikels. Nachfolgend werden alle Graphen daraus entladen.
Die X-Achse ist die Blocknummer, die Y-Achse ist die durchschnittliche Zeit.
Wenn wir uns diese Metrik ansehen, können wir Bereiche mit stabilem Betrieb der Blockchain, Bereiche mit einem starken Anstieg der Durchschnittszeit des Blocks (Zonen 1A, 1B, 2) und den Bereich der Verschlechterung des Blockchain-Computernetzwerks sowie einen verdächtigen Bereich, der etwas entfernt an einen Puls erinnert (Zone 3), bestimmen.
Erstens bestätige ich, dass diese Metrik auf Monitoren im Wahllokal hätte angezeigt werden sollen Es kann eindeutig an der Leistung einer der Hauptkomponenten des Systems gemessen werden. Zweitens behaupte ich, dass aus diesen Daten folgt, dass die Arbeit der Blockchain gestoppt wurde. Lassen Sie uns berechnen, wie oft und wie viel Zeit.
Wir haben drei Abschnitte mit verdächtigen Sperrzeiten, die von mir als "Zone 1A", "Zone 1B" und "Zone 2" bezeichnet werden. Die Blockberechnungszeit für Block 2046 lag zwischen 3 und 4 Sekunden. Zur Auswertung nehmen wir die obere Grenze von 4 Sekunden und berechnen die Zeit, zu der die Blockchain gestoppt wurde.
Beschreibung der Tabellenspalten
- Nummer des Zonenstartblocks
- Nummer des Zonenendblocks
- Die Anzahl der Blöcke in der Zone
- Zonenstartzeit
- Zonenendzeit
- Zonendauer
- Geschätzte Zeit, in der die Blockchain Berechnungen basierend auf der Berechnung der Blockzeit von 4 Sekunden durchgeführt hat
- Geschätzte Zeit, zu der die Blockchain deaktiviert wurde
Ich stelle fest, dass ich eine Obergrenze für die Blockzeit genommen habe, dies gibt eine Obergrenze für die Berechnungszeit und eine Untergrenze für die Stoppzeit. Das heißt Echte Haltezeiten dürften noch größer sein. Das heißt Die Gesamtzeit für das vollständige Anhalten der Blockchain beträgt ca. 2 Stunden.
Die nächste neugierige Zone ist "Zone 3". Es gibt eine merkwürdige Aufzeichnung der Häufigkeit von Blöcken im Vergleich zu früheren Perioden, aber wir werden diesen Bereich separat betrachten, wenn wir die Verteilung der Stimmen unter den Blöcken betrachten.
Und schließlich stellen wir von 14.20 Uhr bis zum Ende der Abstimmung eine konstante Verlängerung der Rechenzeit fest. Lassen Sie mich daran erinnern, dass es sich um die PoA-Blockchain handelt und es keine Komplikationen bei Operationen wie im Fall der ETH gibt, als ein solches Verhalten durch eine „Komplexitätsbombe“ in der PoW-Blockchain verursacht wurde. Das heißt Wir beobachten ein unerwartetes Verhalten der Blockchain-Metrik, das auf die Verschlechterung des Systems hinweist.
Analyse der Stimmenverteilung
Ich werde umgehend einen Vorbehalt einlegen, dass ich so objektiv wie möglich bin und nicht auf die Kuriositäten bei der Verteilung der Stimmen unter den Kandidaten eingehen werde, und diese Analyse wird nicht im Zusammenhang mit einzelnen Kandidaten durchgeführt. In der Sendung, die ich geschrieben habe, habe ich es trotzdem jedem Interessenten überlassen, dies zu tun. In diesem Artikel interessiert mich nur die Leistung des Systems. Wenn Sie an diesen Kuriositäten interessiert sind, dann sollten Sie sich auf den Bericht beziehen, dort wird alles so detailliert wie möglich beschrieben.
Die Verteilung der Stimmen sieht so aus
Die X-Achse ist die Blocknummer, die Y-Achse ist die Anzahl der Stimmen im Block.
Wie erwartet gibt es in den Sperrzonen der Blockchain (1A, 1B, 2) keine Sprachaufzeichnungen, da es sich um Fehlerzonen handelt. Aber Zone 3 gibt Anlass zum Nachdenken. Es gibt eine kleine Anzahl von Blöcken mit 1-3 Stimmen, ein paar Reihen mit 4-5 Stimmen und einen enormen Stimmenanstieg am Ende dieser Zone. Ich habe diese Ereignisse basierend auf der Blockzeitmetrik kombiniert, da die Verschlechterung bereits nach diesen Ereignissen erfolgte und die Aufzeichnung dieser Blöcke innerhalb akzeptabler Grenzen lag. In Zone 3 gab es keinen Blockchain-Stopp, aber aus irgendeinem Grund fielen die Daten praktisch nicht in die Blockchain.
Die Gesamtdauer dieser Zonen beträgt ca. 4 Stunden. Das heißt Da die gesamte Abstimmung 12 Stunden dauerte, wurden die Daten aus verschiedenen Gründen etwa ein Drittel der Zeit nicht in der Blockchain aufgezeichnet.
Im Bereich der Verschlechterung ist deutlich zu erkennen, dass sich der Aufnahmemodus geändert hat und Daten häufiger geschrieben wurden, im Gegensatz zu Orten, an denen die Blockchain stabil funktionierte. Womit es verbunden ist, ist nicht genau bekannt, da uns die genaue Konfiguration nicht zur Verfügung steht. Es wird jedoch davon ausgegangen, dass dies auf den Überlauf der Transaktionswarteschlange in Parity zurückzuführen ist. Dieses Verhalten wirft Fragen für das Team auf, das Parity in das Backend integriert hat, und spricht auch von der theoretischen Möglichkeit, Stimmen zu verlieren, die mit dem Löschen von Transaktionen verbunden sind.
Es ist interessant, dass die Anzahl der Stimmen im Block auf 100 begrenzt ist. Wir haben diese Konstante im veröffentlichten Code nicht gefunden - weder in den Einstellungen noch im Code.
Ich habe zu diesem Zeitpunkt der Analyse keine Erklärung über den Ursprung des Stimmenanstiegs erhalten, nach dem die Verschlechterung einsetzte, und ich habe versucht, eine Erklärung in den Fotos der Daten auf den Abstimmungsbildschirmen zu finden, die die Beobachter gemacht haben.
Analyse der Daten, die den Beobachtern zur Verfügung stehen
Hier werden wir über Daten sprechen, die Beobachtern zur Verfügung stehen und die als Alternative zur Anwesenheit von Beobachtern in einem echten Wahllokal positioniert wurden. Fotos, anhand derer sie gesammelt werden, können Sie dem Bericht entnehmen.
Ich muss sofort sagen, dass ich glaube, dass die Beobachter absichtlich nicht mit den Daten versorgt wurden, die sie benötigen, um die im System ablaufenden Prozesse zu verstehen und nachzuverfolgen
- Beobachter sahen die Systemmetriken nicht und konnten daher den Grad ihrer Funktionsfähigkeit nicht einmal oberflächlich einschätzen
- Der Blockchain-Überwachungsknoten wurde Beobachtern nicht zur Verfügung gestellt
- Die tabellarische Darstellung der Daten ermöglichte es den Beobachtern nicht, das Geschehen zu bewerten.
Die Daten zeigten 4 Zahlen, die im wesentlichen einen Konversionstrichter zeigten
- Wie viele Personen sind zu Beginn des Abstimmungsprozesses gegangen?
- Wie viele Personen haben eine Registrierungs-SMS eingegeben?
- Wie viele Personen haben den Newsletter erhalten?
- Wie viele Leute haben gewählt?
Da dies ein Trichter ist, sind alle vier Parameter miteinander verbunden:
- Sie können keine SMS erhalten, ohne zur Seite zu gehen
- Wenn Sie keine SMS erhalten, können Sie keinen Newsletter erhalten
- Sie können nicht abstimmen, ohne einen Newsletter zu erhalten
Außerdem sollte beachtet werden, dass die Lebensdauer des Newsletters 15 Minuten beträgt. Dies bedeutet, dass Sie einen Newsletter erhalten, für den Sie nur 15 Minuten abstimmen können.
Die X-Achse ist die Zeit. Die y-Achse ist die Anzahl der Personen.
Eine visuelle Darstellung zeigt sofort Anomalien.
Die Tatsache, dass die Abstimmungsseite nicht besucht wurde (grüne Linie, horizontale Linie), deutet auf die Unzugänglichkeit der Vorderseite des Systems hin. Die Grundnote beträgt 17 volle Parzellen (einschließlich einer Parzelle, in der die Menge erhöht und dann verringert wurde), jede für 15 Minuten. Insgesamt sind dies ungefähr 4 Stunden und 15 Minuten. Diese Intervalle überlappen sich teilweise mit Blockchain-bezogenen Fehlfunktionen und sind teilweise neu (z. B. 14:20 - 15:01, 15:30 - 16:15).
Während dieser merkwürdigen Stimmenflut kam aus irgendeinem Grund niemand auf die Website und niemand gab SMS ein. Ich habe keine Erklärung für diese Tatsache gefunden. Das heißt Mit hoher Wahrscheinlichkeit ist dieser Anstieg mit einer Störung von außen verbunden.
In der Zeit von 15.30 bis 16.15 Uhr ist nur ein Parameter "SMS eingegeben" gewachsen, anscheinend haben sie die Statistik angepasst, da die Anzahl der ausgegebenen Stimmzettel zuvor mehr war als die Anzahl der Personen (rote Linie), die die SMS korrekt eingegeben haben. Was logisch unmöglich ist.
Natürlich besteht die Möglichkeit, dass der Mechanismus zur Präsentation von Daten für Beobachter einfach nicht funktioniert hat oder mit schwerwiegenden Fehlern gearbeitet hat, aber das Erkennen dieser Tatsache ist im Wesentlichen die Tatsache, dass Beobachter nicht zum Wahllokal durften, da die Beobachter zusätzlich zu diesen Daten absolut nichts hatten
Schlussfolgerungen
Wenn von Hochverfügbarkeitssystemen die Rede ist, wird traditionell mit einer Neun gesprochen. In 90% der Fälle arbeitet das System fehlerfrei. Seriöse Systeme können mit zwei oder drei Neunen arbeiten (99% und 99,9% der Zeit, in der das System Anforderungen korrekt verarbeitet). Bei der Abstimmung in der Moskauer Staatsduma dauerte die Abstimmung etwa 12 Stunden, und die Zahl der Wähler betrug weniger als 10 000 Personen. Gleichzeitig funktionierte das System nicht länger als 4 Stunden. Dann verschlechterten sich für fünfeinhalb Stunden die Berechnungen in der Blockchain und niemand reagierte darauf, was auf Architekturprobleme aufgrund der fehlenden Überwachung von Metriken hinweist. Persönlich war ich der Meinung, dass dieses System mit solchen Merkmalen nicht einmal als funktionierender Prototyp angesehen werden kann.
PS Schon als ich diesen Artikel langsam vorbereitete, erschien auf Habré ein DIT-Artikel, in dem behauptet wurde: "Das elektronische Abstimmungssystem hat den ganzen Tag über stabil funktioniert, bis auf eine Stunde, aber wir konnten das Problem schnell beheben." Ich hoffe aufrichtig, dass dies in einem Paralleluniversum passiert ist und dem Autor der Nobelpreis für seine Entdeckung verliehen wird, da sowohl Metriken als auch Daten dem direkt widersprechen. Nach den Daten, die ich aus dieser Realität erhalten habe, wurde die Blockchain 2 Stunden lang ausgeschaltet, die mit der Blockchain verbundenen Komponenten funktionierten 4 Stunden lang nicht, und von 14:20 bis zum Ende der Abstimmung verschlechterte sich das Computernetz der Blockchain kontinuierlich, was einem merkwürdigen Stimmenanstieg nicht standhielt erklärt durch die Daten, die ich von Beobachtern aus diesem Universum erhalten habe.
Der Inhalt des vollständigen Berichts ist auf der Website für elektronische Abstimmungen zu finden.
Der Quellcode des Analyseprogramms und die Daten werden in Github (.NET Core 3 / WPF) hochgeladen.
Inhalt des DIT-Artikels zur Systemarchitektur