Wie Polygon 70 Millionen gestohlene POL an Wiederherstellungs-Wallets zurückgeben will

Zwei Diebstähle hinterließen Millionen POL auf fünf blockierten Adressen. Ein Polygon-Vorschlag würde diese Guthaben in Wiederherstellungs-Wallets verschieben, indem er die Regeln des Netzwerks an einem bestimmten Block ändert. Die Token dorthin zu bringen, würde einen Teil der Wiederherstellung lösen. Sie zurück zu den Kunden zu bringen, ist eine separate Aufgabe.

Ein Polygon-Verbesserungsvorschlag hat 70,49 Millionen POL auf fünf blockierten Adressen identifiziert, die ein koordinierter Hard Fork in Wiederherstellungs-Wallets verschieben könnte, die für Binance und Polymarket designiert sind.

Der Vorschlag beschreibt eine Änderung der nativen POL-Guthaben an einem festen Block. Die Software würde die fünf aufgeführten Guthaben auf null setzen und die entsprechenden Beträge den verifizierten Wiederherstellungsadressen gutschreiben.

Die Unterscheidung besteht zwischen einem Guthaben, das das Netzwerk an der Bewegung gehindert hat, und einem, das ein Wiederherstellungsteam kontrollieren kann. Für Kunden gibt es eine weitere Unterscheidung zwischen Token, die eine Wiederherstellungs-Wallet erreichen, und einer Plattform, die einen Anspruch anerkennt und auszahlt.

Wie sich die beiden Vorfälle summieren

Der Vorschlag ordnet 46,63 Millionen POL auf einer Adresse dem Binance-Vorfall und 23,86 Millionen auf vier Adressen dem Polymarket-Vorfall zu. Addiert man diese gerundeten Zahlen, ergeben sich 70,49 Millionen POL. Teilt man jede durch diese Summe, ergibt sich ein Anteil von Binance von etwa 66,2 % und von Polymarket von 33,8 %.

Dies sind Anteile an der vorgeschlagenen Wiederherstellung, keine Maße für die Gesamtverluste der beiden Vorfälle. Eine Dollarschätzung hängt auch vom verwendeten Zeitstempel und Preis ab. Die Mengen im Vorschlag sind in POL denominiert.

Die Adressen sind wichtiger als die Schlagzeilen-Dollarzahl

Die Referenzguthaben des Vorschlags summieren sich auf 70.489.329,34 POL. Die Binance-Adresse macht 46.626.593,27 POL aus, während die vier Polymarket-Adressen 23.862.736,07 POL ausmachen. Dies sind Guthaben an Referenzblöcken, die von den Autoren gewählt wurden. Der frühere Transfer von einer Binance-Hot-Wallet war etwas kleiner als das anschließend an der Empfängeradresse verzeichnete Guthaben.

Eine Differenz von vier Token bei einem Transfer von mehr als 46 Millionen würde die Schlagzeile kaum ändern. Für einen Implementierer ist sie wichtig, weil es zwei mögliche Zahlen zu kodieren gibt: den vom Sender zurückverfolgten Betrag und das vollständige Guthaben am Ziel. Der Vorschlag beschreibt Letzteres als den Betrag, der unmittelbar vor der Aktivierung aus dem Zustand gelesen werden soll, wobei ein vorhergehender Snapshot veröffentlicht werden soll, damit Änderungen sichtbar sind. Der Entwurf sollte daher als Verfahren zur Bestimmung des endgültigen Betrags gelesen werden, zusammen mit einer Tabelle, die den ungefähren zur Diskussion stehenden Betrag festlegt.

Die Polymarket-Zahl stellt ein separates Messproblem dar. Der Vorschlag beziffert den Vorfall auf etwa 28 Millionen POL und die vier ausgewählten Salden auf rund 23,86 Millionen POL. Gegenüber dieser gerundeten Schätzung des Vorfalls macht der ausgewählte Betrag etwa 85 % aus, was eine Differenz von ungefähr 4,14 Millionen POL lässt. Diese Subtraktion misst die Lücke zwischen der Schätzung des Vorfalls und den ausgewählten Salden. Sie kann nicht feststellen, wo die verbleibenden Token gelandet sind oder ob einige über einen anderen Weg zurückgewonnen werden könnten.

Eine Dollar-Umrechnung fügt eine weitere Variable hinzu. Bei 0,092 $ pro POL wäre der Referenzsaldo etwa 6,49 Millionen $ wert. Bei 0,096 $ wären dieselben Token etwa 6,77 Millionen $ wert. Die Berechnung multipliziert die Referenzmenge des Vorschlags mit zwei illustrativen Preisen. Sie erklärt, wie Dollar-Beträge nahe 6,5 Millionen $ und 6,8 Millionen $ nahezu dieselbe vorgeschlagene Übertragung beschreiben könnten. Die ursprüngliche Berichterstattung bezifferte den Wert auf rund 6,5 Millionen $. Eine Zahlungsentscheidung würde ein ausdrückliches Bewertungsdatum und eine Preisquelle erfordern.

Was der vorgeschlagene Fork zurücklassen würde

Die vorgeschlagene Wiederherstellung deckt etwa 85 % der rund 28 Millionen POL ab, die im Forumbeitrag dem Polymarket-Vorfall zugeschrieben werden. Es ist verlockend, die verbleibenden 15 % als einen Betrag zu beschreiben, den der Fork nicht zurückgewinnen würde. Der präzisere Vergleich ist der zwischen einer ungefähren Vorfallszahl und den Salden, die laut den Autoren noch an vier Adressen gehalten werden. Eine separate Nachverfolgungsübung wäre erforderlich, um die Differenz zu erklären.

Der Binance-Vergleich ist anders. Der Vorschlag identifiziert eine Übertragung von 46.626.589,6 POL von einer Hot Wallet und einen Saldo von 46.626.593,27 POL beim Empfänger zum Zeitpunkt der Referenz-Momentaufnahme. Der Zielsaldo war rund 3,67 POL größer als diese Übertragung. Die Differenz ist klein genug, um in jeder gerundeten Schlagzeile zu verschwinden, aber sie hilft zu erklären, warum eine zu einem bestimmten Block erstellte Momentaufnahme nützlicher ist als die Angabe eines Betrags aus der ursprünglichen Transaktion.

Eine zweite Lehre liegt in den Einheiten. Die Referenztabelle verwendet natives POL, während die frühere Binance-Übertragung auch 6.185.900,1 USDT umfasste. Eine Dollar-Summe, die beides einschließt, würde eine andere Gruppe von Vermögenswerten abdecken als der vorgeschlagene Fork. Ein Bericht über blockiertes Geld könnte vernünftigerweise beides erörtern, sofern er klarstellt, welche Organisation welche Maßnahme ergriffen hat und ob die Mittel anschließend bewegt wurden.

Die beiden Fälle teilen auch einen Aktivierungsmechanismus, ohne ein einziges Konto zu teilen. Die Polygon-Software würde separate Wiederherstellungsadressen gutschreiben und dabei die Unterscheidung zwischen den jedem Vorfall zugeordneten Salden wahren. Die Empfänger könnten daher das, was sie erhielten, mit ihren eigenen Ansprüchen und Entschädigungsunterlagen abgleichen. Der Forumbeitrag kombiniert nicht die Ansprüche aus den beiden Vorfällen oder gibt einer Plattform Autorität über die Erlöse der anderen.

Was uns ein blockierter Saldo sagen kann

Eine Blockierung kann eine gelistete Adresse daran hindern, Gelder zu übertragen, während der Saldo weiterhin auf der Chain erscheint. Ein Beobachter kann sehen, wie viel an einer Adresse verbleibt, ohne feststellen zu können, wie viel einem einzelnen Kunden geschuldet wird.

Die fünf Salden definieren den Umfang dieses Vorschlags. Ein Vermögenswert, der an einem der beiden Vorfälle beteiligt ist, aber außerhalb dieser Salden liegt, würde seinen eigenen Wiederherstellungsweg benötigen.

Was der Übertragungsdatensatz belegen kann

Der Vorschlag beschreibt zwei native Übertragungen um 18:30:34 und 18:35:59 UTC am 29. Oktober. Zusammen bewegten sie 3.282.275,71 POL von einer Adresse zu einer anderen. Zwei Zeitstempel sind wichtig, weil sie helfen, die Reihenfolge festzustellen, in der sich Salden über Wallets verteilten. Die Transaktionshistorie kann Bewegung und Beträge zeigen, selbst wenn die Personen, die die Schlüssel kontrollieren, schwerer zu identifizieren sind.

Der Vorschlag verknüpft die gelisteten Adressen mit den Vorfällen. Für eine unabhängige Prüfung müsste ein Prüfer die genannten Transaktionsdatensätze verfolgen und die Quelladressen mit den von den betroffenen Plattformen identifizierten Konten vergleichen. Das ist spezifischer, als zu sehen, dass mehrere Wallets am selben Tag Geld bewegen. Es unterscheidet sich auch davon, einen rechtlichen Anspruch auf jede noch in einem Konto befindliche Münze zu beweisen.

Eine Adresse, die natives POL und einen Stablecoin hielt, kann die Grenzen der Sprache auf Wallet-Ebene veranschaulichen. Der Emittent des Stablecoins kann über den Stablecoin-Vertrag handeln. Natives POL ist Teil der Saldo-Buchhaltung des Netzwerks. Die beiden Vermögenswerte teilen sich eine Adresse, aber die Personen, die Übertragungen verhindern können, und der Mechanismus, den sie nutzen können, hängen davon ab, um welchen Vermögenswert es sich handelt.

Der Vorschlag beschreibt weitere von Binance bereitgestellte Adressen als Klasse B. Sie gehören zur Blockierungsdiskussion, während die Zustandsänderungen des Entwurfs auf die für die Wiederherstellung angegebenen Klasse-A-Adressen beschränkt sind. Jede blockierte Adresse als eine Wallet zu zählen, die geleert würde, würde den Umfang überzeichnen. Es würde auch eine wichtige Governance-Frage verschleiern: Das Blockieren einer Transaktion ist eine Handlung, während die Entscheidung, dass ein bestimmtes Guthaben an einen benannten Empfänger gehen soll, eine andere ist.

Warum zwei Vermögenswerte unterschiedliche Reaktionen erforderten

Die Chronologie des Polygon-Vorschlags verfolgt 46.626.589,6 native POL und 6.185.900,1 USDT von einer Binance-Hot-Wallet an denselben Empfänger in Block 96.406.484. Tether fror die USDT ein. Die POL blieben Gegenstand der vorgeschlagenen Netzwerkintervention.

Die vorgeschlagene Übertragung adressiert die unterschiedlichen Kontrollmöglichkeiten, die über diese beiden Vermögenswerte verfügbar sind. Ein Emittent kann Beschränkungen durch das System auferlegen, das er für seinen Token betreibt. In diesem Fall nutzten Polygons Blockproduzenten stattdessen einen Bor-Transaktionsfilter für native POL, und der Vorschlag beschreibt diesen Filter als Übergangslösung.

Jeder Blockproduzent liest die Liste beim Start, so der Vorschlag. Änderungen erfordern eine Bereitstellung und einen Neustart oder eine Rotation, und der Filter deckt äußere Absender und EIP-7702-Autoritäten ab. Der Vorschlag besagt, dass der Snapshot vor der Aktivierung erneut gelesen wird, sodass seine veröffentlichte Tabelle eine Referenz und keine Garantie für die endgültigen Belastungsbeträge ist.

Warum ein Transaktionsfilter tagelang halten und dennoch vorübergehend sein kann

Die Liste der Blockproduzenten beruht auf Softwarekonfiguration. Der Vorschlag besagt, dass die Liste beim Start gelesen wird. Ein neuer Eintrag erfordert daher eine betriebliche Änderung, und Betreiber müssen dieselbe Konfiguration anwenden, damit die Beschränkungen wie beabsichtigt funktionieren. Der damit verbundene Aufwand kann während eines laufenden Vorfalls gerechtfertigt sein, wenn jede Stunde einer Person, die die Schlüssel hält, eine weitere Chance gibt, Gelder zu verschieben.

Eine Beschränkung auf der Ebene der Produzenten muss auch mit der Art und Weise übereinstimmen, wie eine Transaktion autorisiert werden kann. Der Vorschlag besagt, dass der Filter äußere Absender und EIP-7702-Autoritäten abdeckt. Das ist eine engere Aussage als die Behauptung, die Gelder seien unter jedem denkbaren Transaktionspfad unbeweglich gemacht worden. Was die Autoren berichten, ist, dass die Gelder gestoppt wurden und dass sie keine Umgehung gefunden haben. Sie benennen Grenzen des Ansatzes als Teil ihrer Begründung für eine dauerhaftere Änderung.

Die Autoren beschreiben eine ausstehende Transaktion mit einer ungewöhnlich hohen vorgeschlagenen Gebühr und Versuche, Unterstützung von Validatoren zu erhalten. Eine versuchte Transaktion ist ein Beleg für eine Bemühung, den Status des Guthabens zu ändern. Sie hat ein anderes Beweisgewicht als eine ausgeführte Übertragung. Der Vorschlag beschreibt auch einen unbeantworteten Onchain-Wiederherstellungskanal. Eine ausgehandelte Rückgabe hätte von einer Antwort einer Partei abgehangen, die zur Autorisierung der Zahlung in der Lage ist, während der Fork-Vorschlag durch Teilnehmer funktionieren würde, die neue Regeln übernehmen.

Eine unbefristete Liste hat praktische Konsequenzen für die Personen, die sie verwalten. Sie müssten wissen, welche Einträge noch einem Zweck dienen, wie neue Betreiber die korrekte Konfiguration erhalten und wer für die Überprüfung alter Einträge verantwortlich ist. Der Forum-Vorschlag sieht eine Überprüfung nach der Wiederherstellung vor, einschließlich einer gesonderten Behandlung der zusätzlichen Adressen. Das bedeutet, dass der Vorschlag sowohl eine einmalige Guthabenänderung als auch das betrifft, was mit den vorübergehenden Kontrollen darum herum geschieht.

Was sich am Fork-Block ändert

Normalerweise ändert eine Übertragung Kontoguthaben, nachdem eine gültige Transaktion nach den Regeln des Netzwerks akzeptiert wurde. Der Vorschlag verlangt stattdessen, dass Software, die den aktualisierten Regeln folgt, die aufgeführten Belastungen und Gutschriften als Teil der Verarbeitung eines bestimmten Blocks anwendet.

Die übereinstimmenden Gutschriften sind wichtig. Die beschriebene Operation entnimmt den aufgeführten Adressen dieselbe Anzahl nativer Token, wie sie den designierten Wiederherstellungsadressen gutschreibt. Der Umfang erstreckt sich nicht auf beliebige Token in den Wallets.

Der Block, der die Wiederherstellung aufzeichnen würde

Die vorgeschlagene Zustandsänderung ist um den Aktivierungsblock herum geordnet, den der Entwurf F nennt. Der relevante Betrag ist das Guthaben nach F minus eins. Aktualisierte Knoten würden die vorgeschriebenen Guthabenanpassungen vor gewöhnlichen Transaktionen in F anwenden. Diese Abfolge ist wichtig, weil sie die genaue Grenze bestimmt, die ein Prüfer zur Kontrolle des Ergebnisses verwenden würde.

Eine normale Überweisung gibt einem Explorer normalerweise einen Transaktionseintrag zur Anzeige. Eine Änderung, die direkt nach den Regeln der Chain angewendet wird, kann stattdessen durch den Vergleich von Guthaben über benachbarte Blöcke hinweg sichtbar werden. Wer nur die Liste der gewöhnlichen Überweisungen des Empfängers betrachtet, könnte sie übersehen. Die vorgeschlagene Veröffentlichung eines Verifikationsskripts würde helfen, den Zustand vor und nach der Änderung mit der Liste der beabsichtigten Empfänger zu verbinden.

Die Verifikation muss beide Seiten des Ledgers abdecken. Sie würde für jedes Guthaben eine übereinstimmende Belastung und Gutschrift suchen. Wenn eine Wiederherstellungsadresse im selben Block auch gewöhnliche Transaktionen erhalten hat, könnte die rohe Differenz zwischen zwei Snapshots diese Bewegungen einschließen. Ein Prüfer müsste sie dann von der besonderen Zustandsänderung trennen, anstatt jeden Zuwachs als wiederhergestellte Mittel zu behandeln.

Der Aktivierungsblock ist eine Koordinierungsfrist. Ein Betreiber, der Software ausführt, die den alten Zustand berechnet, und ein Betreiber, der die besondere Guthabenregel anwendet, könnten aus demselben Block unterschiedliche Ergebnisse berechnen. Die praktische Arbeit umfasst daher die Veröffentlichung der Änderung, die Einräumung von Zeit für die Betreiber zur Prüfung und die klare Festlegung des Aktivierungspunkts. Die Tabelle des Vorschlags kennzeichnet den Block weiterhin als eine Entscheidung, die nach Vorliegen der Genehmigung zu treffen ist. Eine Governance-Diskussion ist eine Gelegenheit, diesen Plan festzulegen, während der Chain-Zustand die Ausführung begründen würde.

Wer die Änderung wirksam macht

Der Forum-Vorschlag beschreibt die beantragte Änderung. Ein separater Meilenstein wäre eine Version, die sie umsetzt und den Aktivierungsblock benennt. Die Betreiber müssten dann kompatible Software übernehmen, damit die Änderung auf der von ihnen genutzten Chain wirksam wird.

Ein Nutzer, der dem Vorschlag folgt, sollte daher einen Forum-Beitrag, eine Implementierung und einen Block, der tatsächlich die neuen Guthaben widerspiegelt, voneinander unterscheiden. Jeder beantwortet eine andere Frage zur Wiederherstellung.

Die Arbeit hinter der Wahl eines Aktivierungsblocks

Eine Blocknummer kann wie ein administratives Detail aussehen. In der Praxis ist sie der Punkt, an dem die neue Software und die alte Software beginnen, sich über die Guthaben der betroffenen Konten uneinig zu sein. Ihre Wahl gibt den Betreibern eine gemeinsame Frist für die Installation des Upgrades, und sie gibt Explorern, Infrastrukturanbietern und den betroffenen Firmen einen gemeinsamen Ausgangspunkt, von dem aus das Ergebnis geprüft werden kann.

Die im Forum-Beitrag vorgeschlagene Vorbereitung umfasst die Bestätigung der Zieladressen, die Aufrechterhaltung der Sperrvereinbarungen bis zur Aktivierung und die Veröffentlichung eines aktuellen Guthaben-Snapshots. Diese Schritte adressieren verschiedene Arten, wie eine Wiederherstellung schiefgehen könnte. Eine falsch erfasste Adresse könnte Vermögenswerte an einen unbeabsichtigten Ort senden. Eine unerklärte Änderung eines Guthabens könnte Leser dazu bringen, das Ergebnis mit einer veralteten Zahl zu vergleichen. Ein verzögertes Upgrade könnte einen Betreiber den Zustand nach den alten Regeln berechnen lassen.

Jedes dieser Probleme erfordert eine andere Prüfung. Für das Ziel ist der wichtige Nachweis, wie der Empfänger die Kontrolle nachweist und wie die veröffentlichte Adresse geprüft wird. Für den Betrag ist es das Guthaben am endgültigen Referenzpunkt. Für das Netzwerk ist es, welche Softwareversionen nach dem Aktivierungspunkt tatsächlich Blöcke verarbeiten. Eine Erklärung, dass die Betreiber die Wiederherstellung unterstützen, würde keine dieser Implementierungsfragen für sich genommen beantworten.

Es gibt auch eine nützliche Prüfung nach dem Ereignis. Die Zustandsänderung würde native Guthaben direkt betreffen, während eine gewöhnliche Zahlung, die im selben Block erfolgt, denselben Empfänger betreffen könnte. Eine Guthabendifferenz muss daher mit den gewöhnlichen Transaktionen in diesem Block abgeglichen werden. Hier wäre das von den Autoren vorgeschlagene Verifikationsskript nützlich, insbesondere wenn es sowohl die Belastung als auch die entsprechende Gutschrift für jedes Konto identifiziert.

Wo Kunden in den Prozess eintreten

Der Empfänger der vorgeschlagenen Übertragung ist eine Wiederherstellungsadresse, keine Liste von Kundenkonten. Sobald ein Betreiber die Mittel kontrolliert, ist die nächste Frage, wie sein eigener Wiederherstellungs- und Erstattungsprozess sie berücksichtigt.

Relevante Nachweise würden einen Fristenplan für Ansprüche, Anweisungen zum Nachweis eines Verlusts und eine Richtlinie zum Bewertungsdatum umfassen. Eine Plattform könnte einige Nutzer bereits aus anderen Mitteln erstattet haben. Ihre Buchhaltung müsste festlegen, wohin wiederhergestellte POL in diesen Fällen fließt.

Was als Rückgabe an Kunden gilt

Eine empfangende Wallet ist der Ort, an dem die Fähigkeit des Netzwerks, die Mittel zu bewegen, auf die Verantwortung einer Organisation trifft, sie zu verbuchen. Wenn betroffene Kunden bereits aus den eigenen Ressourcen einer Börse erstattet wurden, könnte die Wiederherstellung diese Ressourcen gemäß den geltenden Bedingungen wieder auffüllen. Wenn sie offene Ansprüche haben, könnte eine Verteilung stattdessen den Betrag verringern, den sie geschuldet bekommen. Beide Szenarien beinhalten, dass Geld eine Wiederherstellungsadresse erreicht, mit unterschiedlichen Folgen für die Nutzer.

Es kann auch eine Diskrepanz zwischen dem wiedererlangten Vermögenswert und dem Vermögenswert bestehen, den ein Kunde verloren hat. Ein Nutzer, dessen ursprüngliches Guthaben in Dollar oder einem anderen Token denominiert war, müsste wissen, ob die Entschädigung in Einheiten dieses ursprünglichen Vermögenswerts, in POL oder in Geld zu einem festgelegten Preis berechnet wird. Ein volatiler Token kann je nach dem Zeitpunkt der Umrechnungsmessung wesentlich unterschiedliche Ergebnisse erzeugen.

Die Unterscheidung zwischen Kundenguthaben und Plattformverlusten ist besonders wichtig, wenn separate Vorfälle in einem Vorschlag zusammengefasst werden. Die Referenztabelle ordnet die Polygon-Guthaben nach Vorfall zu. Sie enthält keinen gemeinsamen Anspruchspool und keine Berechnung der einzelnen Nutzern geschuldeten Beträge. Selbst wenn sich beide Guthabenbestände im selben Aktivierungsblock bewegen, können die Plattformen unterschiedlichen Verpflichtungen gegenüberstehen und unterschiedliche Zahlungsvereinbarungen ankündigen.

Die öffentlichen Beweise können danach geordnet werden, was jeder Schritt beweisen würde. Eine Freigabe- und Aktivierungshöhe würde zeigen, dass eine Implementierung bereit ist. Der Blockzustand würde zeigen, ob sich das Ledger verändert hat. Aufzeichnungen der Plattform würden belegen, ob die wiedererlangten Vermögenswerte verteilt, gegen frühere Entschädigungen einbehalten oder anderweitig verbucht wurden. Der Forenentwurf macht seine beabsichtigten Ziele auf Chain-Ebene für jeden Vorfall spezifisch und sieht eine öffentliche Verifizierung der Guthabenänderungen vor.

Wer kann entscheiden, was ein wiedererlangter Token wert ist?

Nehmen Sie zur Veranschaulichung an, dass eine Plattform einem Nutzer den Barwert eines Guthabens schuldet und POL erhält, nachdem sich der Preis geändert hat. Es gibt mindestens drei Zeitpunkte, auf die sich die Plattform beziehen könnte: den Zeitpunkt des Diebstahls, den Zeitpunkt, zu dem sie die wiedererlangten Token erhält, und den Zeitpunkt, zu dem sie eine Verteilung vornimmt. Der Geldbetrag, der durch dieselbe Menge POL repräsentiert wird, kann zu jedem Zeitpunkt unterschiedlich sein.

Eine Anspruchsrichtlinie könnte stattdessen eine Zahlung in Einheiten des Vermögenswerts vorsehen, der verloren wurde. Das vermeidet die Wahl eines Marktpreises für einen Anspruch, der in demselben Vermögenswert denominiert ist, lässt aber weiterhin Fragen zur Anspruchsberechtigung und zu früheren Erstattungen offen. Ein Kunde, dem bereits zurückgezahlt wurde, könnte eine andere Position haben als jemand, dessen Anspruch noch aussteht. Das Netzwerk hat keine Rolle bei diesen Feststellungen.

Was ein Kunde braucht, ist eine Erklärung dessen, was die Plattform schuldet, in welcher Einheit und wie sie alles früher Gezahlte verbucht. Die Chain kann feststellen, dass eine Wiederherstellungsadresse ein Guthaben erhalten hat, und die Plattform kann dies mit ihren Aufzeichnungen abgleichen. Keines der beiden Dokumente erfüllt die Aufgabe des anderen. Dies ist ein Grund, warum eine bestätigte Wiederherstellung eine Nachricht sein kann, selbst wenn noch separat auf Details einer Verteilung gewartet werden muss.

Ein Berichtsvergleich kann die Zahlen nebeneinander halten. Die erste wäre die native POL, die unter der Zustandsänderung wiedererlangt wurde. Die zweite wäre der Betrag, der Kundenansprüchen oder bereits geleisteten Erstattungen zugeordnet wird. Die dritte wäre jedes Guthaben, das in Verwahrung bleibt, während die Plattform einzelne Fälle klärt. Eine einzelne Dollarnummer aus der ersten Stufe würde den Lesern wenig über die anderen beiden sagen.

Warum der enge Geltungsbereich wichtig ist

Ein Fork, der Guthaben ändert, wirft eine Frage auf, die ein normales Software-Upgrade nicht aufwirft. Welche Fakten müssten vorliegen, damit Teilnehmer diese Intervention erneut unterstützen?

Der Vorschlag selbst beschreibt die Maßnahme als extrem und beschränkt sie auf aufgelistete native POL-Guthaben. Die Begründung für den Vorschlag und die Frage des Präzedenzfalls können beide anhand derselben konkreten Details bewertet werden: der identifizierten Adressen, des vorgeschlagenen Ziels und des Blocks, in dem sich die Guthaben ändern würden.

Was würde diesen Fall zu einem Präzedenzfall machen?

Ein anderes Projekt könnte auf Polygons Vorgehen nach einem Diebstahl verweisen, aber die Umstände in diesem Entwurf sind ungewöhnlich spezifisch. Die Autoren benennen die Vorfälle, die aufgelisteten Konten, die von der vorgeschlagenen Änderung betroffenen Vermögenswerte und wohin sie gelangen würden. Sie beschreiben auch, warum die bereits verwendete Beschränkung nur eine vorübergehende Maßnahme war. Ein Vorschlag ohne diese Elemente würde einen anderen Fall für die Änderung von Guthaben darstellen.

Die wichtige Frage ist, wer überzeugt werden muss und welche Informationen er erhält. Eine Börse kann wissen, welche Kundenguthaben betroffen waren, während Betreiber Beweise über die vorgeschlagene Änderung an der Chain benötigen. Ein Nutzer, dessen Gelder wiedererlangt werden, ist am Ergebnis interessiert. Ein Betreiber, der den Vorschlag bewertet, muss auch darüber nachdenken, wie er eine künftige Anfrage einer anderen Partei bewerten würde.

Der sicherste Vergleich ist der zwischen den Fakten, die eine andere Anfrage belegen könnte. Kann sie den Betrag an einem bestimmten Block identifizieren? Kann sie diese Mittel mit einem anerkannten Vorfall in Verbindung bringen? Kann sie einen Empfänger verifizieren und angeben, was mit bereits blockierten Adressen geschieht? Diese Fragen ergeben sich direkt aus dem veröffentlichten Entwurf und sind nützlicher, als jede ungewöhnliche Zustandsänderung als gleichwertig zu beschreiben.

Der Vorschlag würde einige dieser Fragen öffentlich überprüfbar lassen. Eine Aktivierungshöhe würde es Beobachtern ermöglichen, den genauen Zustandsübergang zu identifizieren. Benannte Ziele würden es ihnen ermöglichen, nachzuvollziehen, was danach geschah. Die Autoren schlagen außerdem vor, die Einträge auf der temporären Sperrliste nach der Aktivierung zu überprüfen, einschließlich einer unterschiedlichen Behandlung der zusätzlichen Binance-bezogenen Adressen. Diese abschließende Überprüfung würde helfen festzustellen, welche Notfallbeschränkungen nach Abschluss der Wiederherstellung in Kraft bleiben.

Was das Ledger bestätigen könnte

Wenn der Vorschlag umgesetzt wird, würde die erste Prüfung die aufgelisteten Adressguthaben auf beiden Seiten des Fork-Blocks vergleichen. Übereinstimmende Gutschriften würden zeigen, dass das Ledger die Übertragung wie angegeben angewendet hat. Kundenausschüttungen würden Nachweise von den Wiederherstellungsbetreibern erfordern.

Der aktuelle Vorschlag legt fünf Quelladressen und designierte Wiederherstellungsadressen für die beiden Vorfälle fest.

Welche Aufzeichnungen welche Wiederherstellungsfrage beantworten

Ein Vorfall kann diese Phasen mit unterschiedlicher Geschwindigkeit durchlaufen. Die USDT-Sperre beispielsweise betrifft einen anderen Vermögenswert und Mechanismus als der vorgeschlagene POL-Fork. Eine spätere Ankündigung über geschützte oder wiederhergestellte Mittel müsste angeben, welcher Vermögenswert gezählt wurde und was mit ihm geschah.

Die Salden können sich auch zwischen den in der Berichterstattung verwendeten Daten ändern. Ein Vorschlag, der einen früheren Snapshot zitiert, sollte die Blocknummer bewahren, damit Leser den Betrag reproduzieren können, selbst wenn sich der aktuelle Saldo ändert. Wenn das Ergebnis bekannt ist, würde ein Vergleich des Ausführungsblocks mit dem veröffentlichten Snapshot feststellen, ob der zurückgegebene Betrag von dem im Vorschlag diskutierten Betrag abweicht.

Die wichtigste Abstimmung für Leser ist die zwischen dem belasteten und dem gutgeschriebenen Betrag. Die separate Veröffentlichung dieser Prüfung für die beiden Vorfälle würde es ermöglichen, die spätere Darstellung der Erlöse durch jede Plattform mit dem Betrag zu vergleichen, über den sie tatsächlich die Kontrolle erlangt hat. Eine einzige kombinierte Summe würde es erschweren nachzuvollziehen, welche Erlöse zur Deckung welcher Ansprüche verfügbar waren.

Eine eng begrenzte Wiederherstellung gibt den Plattformen auch eine Möglichkeit zu kommunizieren, was mit Vermögenswerten außerhalb des Forks geschah. Die Polymarket-Zahl im Forumbeitrag umfasst mehr POL als in der vorgeschlagenen Zustandsänderung aufgeführt ist. Die Binance-Übertragung umfasste USDT, das Tether separat behandelte. Ein Wiederherstellungs-Update, das den relevanten Vermögenswert, die Adresse und die ergriffene Maßnahme benennt, würde es Lesern ermöglichen, beide Vorfälle abzustimmen, ohne anzunehmen, dass alle gestohlenen Mittel einem einzigen Weg folgten.

Die Chronologie ergibt drei Daten mit unterschiedlicher Bedeutung. Das Vorfallsdatum legt fest, wann die Mittel bewegt wurden. Der Referenzblock legt fest, was an den Adressen beobachtet wurde, als die Autoren den Vorschlag zusammenstellten. Das Aktivierungsdatum, falls vereinbart, würde festlegen, wann das Netzwerk die Wiederherstellungsregel anwendet. Ein Token kann zwischen diesen Daten gegen bestimmte Übertragungen geschützt sein, ohne in der Zwischenzeit zurückgegeben worden zu sein.

Die Adressaufzeichnungen können auch als Kontrolle für Aussagen dienen, die nach einem Upgrade gemacht werden. Wenn ein Betreiber behauptet, dass Gelder an das veröffentlichte Ziel gesendet wurden, sollte die Chain die entsprechende Bilanzänderung in der Aktivierungshöhe zeigen. Wenn es heißt, dass Kunden zurückgezahlt wurden, sind die nützlicheren Beweise ein Verteilungsprotokoll oder eine klare Darstellung der Erstattungen. Das eine ist eine Aussage über das Netzwerk, das andere über die Verpflichtungen der Plattform.

Deshalb sind die Ledger-Beweise besonders wertvoll, wenn die öffentliche Diskussion sich der Frage zuwendet, ob der Fork funktioniert hat. Sie gibt Beobachtern eine eng umrissene Frage, die sie verifizieren können, ohne darauf zu warten, dass jedes betroffene Unternehmen seine eigene Buchhaltung abschließt. Der Vorschlag legt ein Verfahren fest, um die bei der Zustandsänderung verwendeten Salden zu veröffentlichen und die Empfängergutschriften danach zu prüfen. Diese Aufzeichnungen würden Nutzern auch einen Ausgangspunkt bieten, um nachzuverfolgen, was jede Plattform getan hat, sobald sie die Kontrolle über das Geld hatte.

Worauf zu achten ist

• Freigabevorschlag: Die vorfallsspezifischen Mengen, die vorgeschlagenen Empfängeradressen und die ausführbaren Anweisungen, die der Governance vorgelegt wurden.
• Aktivierungsblock: Die bestätigte Blockhöhe und die Softwareversion, die Polygon-Betreiber vor diesem Block installieren müssten.
• Wiederherstellungsgutschriften: Die von jeder gesperrten Adresse abgebuchten nativen POL und die entsprechende Gutschrift, die beim jeweiligen designierten Empfänger verbucht wird.
• Kundenansprüche: Die Anweisungen jeder Plattform zu Anspruchsberechtigung, Bewertung und zur Behandlung früherer Erstattungen.

Häufig gestellte Fragen