Erste Erkenntnisse aus dem Audit des Fault Proofs Programms Sherlock

Mit dem Abschluss des Sherlock-Audit-Wettbewerbs sind die Fehlernachweise dem OP Mainnet einen Schritt näher gekommen! Dieser Beitrag behandelt die ersten Ergebnisse des Wettbewerbs und die nächsten Schritte.

Unser Sherlock-Audit-Wettbewerb ist in die Eskalationsphase eingetreten und die Fehlernachweise sind dem OP Mainnet offiziell einen Schritt näher gekommen! In der Zwischenzeit möchten wir Ihnen einige Informationen über die ersten Ergebnisse des Wettbewerbs und die nächsten Schritte auf unserem Weg zu Stufe 1 mitteilen.

Audit-Status-Update

Am 27. März haben wir einen Sherlock-Audit-Wettbewerb für das vorgeschlagene OP Stack-Fehlernachweissystem gestartet. Dieser Wettbewerb konzentrierte sich in erster Linie auf (1) die wichtigsten Sicherheitsmechanismen, die es dem Optimism Security Council ermöglichen, sich von Fehlern im fehlersicheren System zu erholen, und (2) die Punkte, an denen die Fehlersicherheit in bestehende Verträge integriert wird.

Wir freuen uns, berichten zu können, dass während des Audits keine kritischen Schwachstellen gemeldet wurden, mit denen die Sicherheitsmechanismen umgangen werden könnten. Wir planen, eine vollständige Zusammenfassung des Audits zu veröffentlichen, sobald die Eskalationsfrist abgelaufen ist und Sherlock die endgültige Schwere und Gültigkeit der Probleme festgestellt hat.

Ein besonderes Dankeschön

Ein besonderes Dankeschön geht an das Team von Offchain Labs, das vor dem Start des Sherlock-Audit-Wettbewerbs zwei Probleme im [FaultDisputeGame] Vertrag gemeldet hat. Beide Probleme betrafen einen Fehler, bei dem der FaultDisputeGame Vertrag die Spezifikation für die „Schachuhr“-Logik, die während der Spielauflösung verwendet wird, nicht korrekt implementierte.

Werfen wir einen kurzen Blick auf den zugrunde liegenden Fehler:

In unserem Fehlernachweissystem treten zwei „Teams“ gegeneinander an - das verteidigende Team (das der ursprünglichen Forderung zustimmt) und das angreifende Team (das der ursprünglichen Forderung nicht zustimmt). Jedes Team erhält eine Art „Schachuhr“, die die Zeit festhält, die dem Team für die Teilnahme am Spiel zur Verfügung steht. Der von Offchain Labs gemeldete Fehler hat gezeigt, dass ein Fehler in der Logik der Schachuhr dazu führte, dass ein Anspruch aufgelöst werden konnte, wenn einem Team die Zeit ausging, auch wenn das andere Team noch Zeit auf seiner Uhr hatte. Das bedeutete, dass das gegnerische Team keine Chance hatte, zu reagieren, obwohl es noch genügend Zeit dazu gehabt hätte.

Die Auswirkung dieses Fehlers ist, dass ein Team den FaultDisputeGame Vertrag fälschlicherweise „gewinnen“ und beweisen konnte, dass ein ungültiger Anspruch gültig war oder dass ein gültiger Anspruch ungültig war. Obwohl dieser Fehler durch die Sicherheitsnetze des aktuellen Fehlerprüfungssystems entdeckt und abgefangen worden wäre, hätte er den Optimism Security Council gezwungen, die Auszahlungen vorübergehend zu pausieren, während der Fehler behoben wurde, was den Benutzern des OP Stack wahrscheinlich Kopfschmerzen bereitet hätte.

Diese Probleme wurden im Rahmen von PR #10148 in der Optimism-Monorepo behoben. Offchain Labs meldete zusätzlich ein Duplikat eines bestehenden öffentlichen Berichts, der hier auf GitHub zu finden ist und in PR #10248 behoben wurde. Wir schätzen es sehr, dass Offchain Labs bereit war, einen Blick auf unser Proof-System zu werfen.

Nächste Schritte

Die Korrekturen für alle Probleme, die während des Sherlock-Audits gemeldet wurden, sind in den Entwicklungszweig der Optimism-Monorepo eingeflossen und wurden ab heute im OP Sepolia-Testnetz bereitgestellt.

Wir planen, diesen Beitrag mit einer vollständigen Zusammenfassung der während des Audits gemeldeten Probleme zu ergänzen, sobald der Eskalationszeitraum zu Ende ist. Bleiben Sie dran, denn wir werden bald einen Vorschlag für die Aufnahme dieser Änderungen in das OP Mainnet machen!

Subscribe to 0xa4D7…BA74
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.