Der DAO-Softchenversuch war schwierig. Es stellte sich nicht nur heraus, dass wir die Nebenwirkungen auf das Konsensprotokoll (dh DOS -Sicherheitsanfälligkeit) unterschätzt haben, sondern es auch geschafft hat, ein Datenrennen in die gehetzte Implementierung einzuführen, die eine tickende Zeitbombe war. Es war nicht ideal, und obwohl im letzten Fall die schnelle Annäherung an Hartgnoße, gelinde gesagt, unheimlich trostlos aussah. Wir brauchten eine neue Strategie …
Der Sprungbrett in dieser Hinsicht war eine von Google ausgeliehte Idee (mit freundlicher Genehmigung von Nick Johnson): Ein detailliertes Aufschreiben Postmortem von der Veranstaltung, um die Grundursachen des Problems zu beurteilen und sich ausschließlich auf die technischen Aspekte und geeigneten Maßnahmen zu konzentrieren, um ein Wiederauftreten zu verhindern.
Technische Lösungen skalieren und bestehen; Menschen zu beschuldigen, tut es nicht. ~ Nick
Aus dem Postmortem wurde eine interessante Entdeckung aus der Perspektive dieses Blog -Beitrags gemacht. Der Code mit Softchenbacken im Inneren [go-ethereum](https://github.com/ethereum/go-ethereum) schien aus allen Perspektiven solide fest zu sein: a) Es wurde gründlich durch Unit-Tests mit einem 3: 1-Test-zu-Code-Verhältnis abgedeckt. b) es wurde gründlich von sechs Stiftungsentwicklern überprüft; und c) es wurde sogar manuell lebend in einem privaten Netzwerk getestet … dennoch blieb ein tödliches Datenrennen, das möglicherweise schwere Netzwerkstörungen hätte verursachen können.
Es stellte sich heraus, dass der Fehler immer nur in einem Netzwerk auftreten konnte, das aus mehreren Knoten besteht, mehrere Bergleute und mehrere Blöcke gleichzeitig geprägt werden. Auch wenn all diese Szenarien zutreffen, gab es nur eine leichte Chance, dass der Fehler auftrat. Unit -Tests können es nicht fangen, Code -Rezensenten können es möglicherweise fangen oder nicht, und manuelles Fangen wäre unwahrscheinlich. Unsere Schlussfolgerung war, dass die Entwicklungsteams mehr Tools benötigten, um reproduzierbare Tests durchzuführen, die das komplizierte Zusammenspiel mehrerer Knoten in einem gleichzeitigen vernetzten Szenario abdecken würden. Ohne ein solches Werkzeug ist die manuelle Überprüfung der verschiedenen Kantenfälle unhandlich. Und ohne diese Überprüfungen kontinuierlich im Rahmen des Entwicklungsworkflows durchzuführen, wären seltene Fehler in der Zeit unmöglich zu entdecken.
Und damit, Bienenstock wurde geboren …
Was ist Bienenstock?
Ethereum wurde so weit, dass die Implementierungen von Tests zu einer großen Belastung wurden. Unit -Tests sind in Ordnung für die Überprüfung verschiedener Implementierungs -Macken, aber die Überprüfung, dass ein Kunde einer Basisqualität entspricht, oder zu validieren, dass Kunden in einer Multi -Client -Umgebung gut zusammen spielen können, ist so gut wie einfach.
Bienenstock soll als leicht erweiterbares Testkabelbaum dienen, wo irgendjemand Kann Tests hinzufügen (einfache Validierungen oder Netzwerksimulationen) in beliebig Programmiersprache, mit der sie sich wohl fühlen, und Hive sollte gleichzeitig in der Lage sein, diese Tests gegen alle potenzielle Kunden. Daher soll der Kabelbaum Black -Box -Tests durchführen, bei denen kein Kundenspezifischer interner Details/Zustand getestet und/oder inspiziert werden kann, sondern die Betonung der offiziellen Spezifikationen oder Verhaltensweisen unter unterschiedlichen Umständen eingehalten wird.
Am wichtigsten ist, dass Hive von Grund auf zum Rahmen des CI -Workflows aller Kunden entworfen wurde!
Wie funktioniert Bienenstock?
Hive’s Körper und Seele sind [docker](https://www.docker.com/). Jede Client -Implementierung ist ein Docker -Image. Jede Validierungssuite ist ein Docker -Bild; Und jede Netzwerksimulation ist ein Docker -Bild. Hive selbst ist ein umfassendes Docker -Bild. Dies ist eine sehr mächtige Abstraktion …
Seit Ethereum -Kunden Sind Docker -Bilder in Hive, Entwickler der Clients können die bestmögliche Umgebung für ihre Kunden zusammenstellen (Abhängigkeit, Werkzeug- und Konfiguration). Hive wird so viele Instanzen wie nötig aufdrehen, und alle laufen in ihren eigenen Linux -Systemen.
Ebenso wie Testsuiten Validierung von Ethereum -Kunden sind Docker -Bilder. Der Autor der Tests kann jede Programmierungsumgebung verwenden, mit der er am besten vertraut ist. Hive stellt sicher, dass ein Kunde ausgeführt wird, wenn er den Tester startet, der dann validieren kann, wenn der bestimmte Client einem gewünschten Verhalten entspricht.
Schließlich, Netzwerksimulationen werden erneut durch Docker -Bilder definiert, aber im Vergleich zu einfachen Tests führen Simulatoren nicht nur Code gegen einen laufenden Kunden aus, sondern können auch die Clients nach Belieben starten und beenden. Diese Clients werden im selben virtuellen Netzwerk ausgeführt und können sich frei (oder wie vom Simulator-Container diktiert) miteinander verbinden und ein privates Ethereum-Netzwerk On-Demand bilden.
Wie hat Hive die Gabel geholfen?
Hive ist weder ein Ersatz für Unit -Tests noch für eine gründliche Überprüfung. Alle aktuellen verwendeten Praktiken sind wichtig, um eine saubere Implementierung jeglicher Funktionen zu erhalten. Hive kann Validierung über das, was aus der Perspektive eines durchschnittlichen Entwicklers möglich ist, über das hinausgeht: Durchführende Tests, die komplexe Ausführungsumgebungen erfordern können; und Überprüfung von Networking -Eckfällen, deren Einrichtung Stunden dauern kann.
Im Falle des DAO-Hard-Riebene mussten wir über alle Konsens- und Unit-Tests hinaus sicherstellen, dass vor allem die Knoten auf zwei Teilmengen auf der Networking-Ebene sauber in zwei Teilmengen aufteilt: eine Unterstützung und eine gegen die Gabel. Dies war unerlässlich, da es unmöglich ist, vorherzusagen, welche nachteiligen Auswirkungen zwei Konkurrenzketten in einem Netzwerk haben könnten, insbesondere aus der Sicht der Minderheit.
Daher haben wir drei spezifische Netzwerksimulationen in Hive implementiert:
-
Der erste Um zu überprüfen, ob Bergleute die vollständigen Ethash-DAGs ausführen, erzeugen die korrekten Block-Extra-Daten-Felder sowohl für Professionen als auch für No-Morfers, auch wenn sie versuchen, naiv zu fälschen.
-
Die zweite Um zu überprüfen, ob ein Netzwerk, das aus gemischten Profi- und No-Gabel-Knoten/Bergleuten besteht, beim Eintreffen des Gabelblocks korrekt in zwei aufteilt, wobei auch die Spaltung anschließend beibehalten wird.
-
Der dritte Um zu überprüfen, ob ein bereits gabeltes Netzwerk mit neu verbundenen Knoten, schnelle Synchronisierung und Lichtsynchronisation mit der Kette ihrer Wahl synchronisiert, synchronisiert werden kann.
Die interessante Frage ist jedoch: Hive hat Hive tatsächlich Fehler aufgenommen oder ist einfach als zusätzliche Bestätigung, dass alles in Ordnung ist? Und die Antwort ist, beide. Bienenstock gefangen Drei gggesfische Fehler In Geth, aber auch stark unterstützt Geths Hard-Riebene-Entwicklung, indem sie kontinuierlich Feedback darüber gab, wie sich Veränderungen auf das Netzwerkverhalten auswirkten.
Es gab einige Kritik an dem Go-Ehereum-Team, dass sie sich Zeit für die Implementierung von Hardlieben genommen hatten. Hoffentlich werden die Leute jetzt sehen, was wir vorhatten, während wir die Gabel selbst gleichzeitig umsetzen. Alles in allem glaube ich Bienenstock Es stellte sich heraus, dass es eine wichtige Rolle bei der Reinheit dieses Übergangs spielte.
Was ist die Zukunft von Hive?
Die Ethereum Github -Organisation bezieht sich [4 test tools already](https://github.com/ethereum?utf8=%E2%9C%93&query=Test), mit mindestens einem EVM -Benchmark -Tool -Kochen in einem externen Repository. Sie werden nicht in vollem Umfang genutzt. Sie haben eine Menge Abhängigkeiten, erzeugen eine Menge Müll und sind sehr kompliziert zu bedienen.
Mit Hive wollen wir alle verschiedenen verstreuten Tests unter einem zusammengefasst Universal Client Validator Das hat minimale Abhängigkeiten, kann von jedem erweitert und im Rahmen des täglichen CI -Workflows von Kundenentwicklern ausgeführt werden.
Wir begrüßen jeden, um Beiträge zum Projekt zu leisten, dass neue Kunden zum Validieren, Validatoren zum Testen oder Simulatoren interessante Netzwerkeprobleme finden. In der Zwischenzeit werden wir versuchen, den polnischen Bienenstock selbst weiter zu polieren, um Unterstützung für das Ausführen von Benchmarks sowie gemischte Simulationen zu verleihen.
Mit ein bisschen oder Arbeit haben wir vielleicht sogar Unterstützung für das Ausführen von Hive in der Cloud und ermöglichen es ihm, Netzwerksimulationen in einer viel interessanteren Skala auszuführen.
