Willkommen zur vierten Ausgabe von ETH2 schnelles Update. Es gibt viele bewegliche Teile, über die man diese Woche sprechen kann. Abgesehen von der Heroic Eth2 -Kundenentwicklung sind dies die Highlights:
TLDR;
Differential Fuzzing Grant
Sigma Prime wurde mit einem Stipendium ausgezeichnet, um die zu leiten Differential Fuzzing -Anstrengung Für ETH2 -Kunden. Diese Bemühungen sind entscheidend für den Erfolg, ein mehrstufiges Netzwerk auf den Markt zu bringen, indem Sie beim Fangproblemen vor dem Hauptnetz bei der Aufnahme von Konsensproblemen helfen.
Der Akt des “Fuzzing” ist der Akt, viele zufällige Eingaben auf ein Software -Stück zu werfen, um zu sehen, wie es reagiert. Bei der Verschmelzung einer einzigen Software ist das Ziel häufig, Inputs zu finden, die zu unerwarteten Abstürzen führen. Wenn wir solche Eingaben finden, stellen wir heraus, was schief gelaufen ist, und härten Sie die Software für diese Art von Eingabe aus.
Differential Fuzzing ist etwas anders. Anstatt explizit nach Abstürzen zu suchen, suchen wir nach Fällen, in denen verschiedene Implementierungen eines Protokolls eine andere Ausgabe für denselben Eingang haben. In einem Blockchain -Kontext verwenden wir differentielle Fuzzing, um Fälle zu finden, in denen eine Reihe von Blöcken zu einem anderen resultierenden Zustand für zwei verschiedene Kunden führt. Idealerweise gibt es in der Produktion keine solchen Fälle.
Light Client Task Force
Kettensafe/LeitsternDie Empfänger eines Stipendiums der Ethereum Foundation für Forschung und Entwicklung von ETH2 Light -Kunden haben die gebildet Light Client Task Force. Diese Gruppe hat sich beauftragt, sicherzustellen, dass leichte Kunden erstklassige Bürger in ETH2 sind. Zu diesem Zweck veranstalten sie a Monatlicher Anruf Ziel, die Forschung, Standards, Spezifikationen und Bildung von Leichtkunden voranzutreiben.
Die Notwendigkeit eines reichhaltigen Ökosystems von leichten Clients und leichten Client -Servern wird nur in einem Sharded -Protokoll wie ETH2 verstärkt. Selbst wenn ein Client eine Teilmenge des Protokolls synchronisiert (z. B. nur ein paar Scherben), muss ein Benutzer sehr oft Informationen über Konten, Verträge und den allgemeinen Zustand der Dinge auf einem anderen Shard erhalten. Ein Kunde könnte den gesamten zusätzlichen Shard ineffizient synchronisieren, aber meistens wird es der richtige Weg sein, um Informationen über bestimmte Konten auf der Scherbe mit prägnanten Beweisen zu fordern.
Schalten Sie auf den nächsten ab Light Client Task Force Call In ETH2 auf dem Laufenden über alles Licht zu bleiben.
ETH1 -> ETH2
In den frühen Tagen von ETH2 wird die Übertragung von Äther aus der bestehenden Ethereum-Kette (ETH1) in die neue Beacon-Kette (ETH2) unisch-Richtung sein. Das heißt, der Äther, der in ETH2 in die Steckdose bewegt wurde, kann nicht zu ETH1 zurückgeführt werden. Die Auswahl einer einzelnen Richtungsübertragung in die Validierung besteht darin, das Risikoprofil zu minimieren, das ETH2 auf ETH1 induziert, und um einen schnelleren Entwicklungszyklus für ETH2 zu ermöglichen, ohne dass ETH1 in diesem Prozess gegossen werden muss. Es gibt einige Bewegungen, um eine bidirektionale Brücke zu erstellen, aber ich werde die Diskussion über die Brückenmechanik und die Kompromisse für einen späteren Posten speichern. Heute würde ich gerne mehr aufnehmen Wie Diese einheitliche Übertragung funktioniert und wie sie sicher implementiert werden kann, ohne ETH1 zu ändern.
In der bestehenden Ethereum POW -Kette werden wir die bereitstellen ETH2 -Validatorvertrag. Dieser Vertrag hat eine einzelne Funktion namens Kaution Dies erfordert eine Reihe von Parametern, um einen neuen Validator zu initialisieren (z. B. öffentlicher Schlüssel, Auszahlungsanmeldeinformationen, ETH -Einzahlung usw.). Es gibt nein Rückzug Funktion bei diesem Vertrag. Abgesehen von einer Gabel, um eine bidirektionale Brücke hinzuzufügen, existiert diese abgelagerte ETH nun nur in ETH2 in der Beacon-Kette.
Es liegt dann in der Verantwortung der Validatoren in der Beacon -Kette, über den Zustand dieses Vertrags zu konsens zu sein, so dass neue Einlagen verarbeitet werden können. Hier ETH1_DATA. Wenn genügend Block -Anträge während eines Abstimmungszeitraums zustimmen ETH1_DATADiese Daten werden im Beacon Chain -Zustand verankert, sodass neue Einlagen bearbeitet werden können.
Ein wichtiger Hinweis zu diesem Mechanismus ist, dass die ETH1_DATA ist tief in der ETH1 -POW -Kette – ~ 1000 Blöcke “Follow Distanz”. Dies folgt der Entfernung in der Verarbeitung neuer Validatoreinlagen in hoher Latenz, bietet jedoch ein hohes Maß an Sicherheit bei der Kopplung dieser beiden Systeme. Die ETH1-Kette müsste tiefer als 1000 Blöcke wieder vornehmen, um die Verbindung zu brechen, und in einem solchen Fall müsste eine manuelle Intervention überwunden werden.
Wir recherchieren und prototypen die Nutzung der Beacon -Kette, um ETH1 (dh das Endgültigkeits -Gadget) abzuschließen. Dies würde erfordern, dass ETH1 letztendlich seine Gabelauswahl auf die Beacon -Kette verschieben, von den POS -Validatoren Sicherheit erlangt und eine viel schnellere ETH1 -Einzahlungen zulässt. Das Endgültigkeits-Gadget eröffnet auch andere lustige Dinge wie die bidirektionale Brücke und die Beleg der ETH2-Datenschichten ETH1. Mehr zu all dem in einem späteren Beitrag 🚀.
