Vitalik: Ausführlicher Artikel über das Exit-Spiel von EVM Validiums und die Rückkehr von Plasma

Plasma ermöglicht es uns, das Problem der Datenverfügbarkeit vollständig zu umgehen und die Transaktionsgebühren erheblich zu senken.

Autor: Vitalik Buterin

Übersetzung: jk, Odaily

 

Plasma ist eine Klasse von Blockchain-Skalierungslösungen, die es erlaubt, dass alle Daten und Berechnungen (außer Einzahlungen, Auszahlungen und Merkle-Wurzeln) off-chain bleiben. Dies eröffnet die Möglichkeit einer enormen Skalierbarkeit, die nicht durch die Datenverfügbarkeit on-chain begrenzt ist. Plasma wurde erstmals 2017 vorgeschlagen und erlebte 2018 mehrere Iterationen, insbesondere Minimal Viable Plasma, Plasma Cash, Plasma Cashflow und Plasma Prime. Leider wurde Plasma weitgehend durch Rollups ersetzt, da (i) hohe Client-Datenspeicherkosten und (ii) grundlegende Plasma-Beschränkungen die Ausweitung auf andere Anwendungen als Zahlungen erschweren.

 

Das Aufkommen von Validitätsnachweisen (auch bekannt als ZK-SNARKs) gibt uns Anlass, diese Entscheidung zu überdenken. Die größte Herausforderung, Plasma für Zahlungen nutzbar zu machen – die Datenspeicherung auf der Clientseite – kann durch Validitätsnachweise effektiv gelöst werden. Darüber hinaus bieten Validitätsnachweise eine Reihe von Werkzeugen, mit denen wir Plasma-ähnliche Chains, die EVM ausführen, erstellen können. Die Sicherheitsgarantien von Plasma gelten nicht für alle Nutzer, da die grundlegenden Gründe, warum Plasma-Exit-Games schwer auf viele komplexe Anwendungen auszuweiten sind, weiterhin bestehen. In der Praxis kann jedoch ein sehr großer Anteil der Vermögenswerte sicher geschützt werden.

 

Im Folgenden werde ich im Detail erläutern, wie Plasma dies erreicht.

 

Überblick: Wie Plasma funktioniert

Die einfachste Version von Plasma, die man verstehen sollte, ist Plasma Cash. Plasma Cash funktioniert, indem jeder einzelne Token als ein eigenständiges NFT betrachtet wird und für jeden Token eine eigene Historie verfolgt wird. Die Plasma-Chain hat einen Operator, der für die Erstellung und regelmäßige Veröffentlichung von Blöcken verantwortlich ist. Jede Transaktion in einem Block wird als ein spärlicher Merkle-Baum gespeichert: Wenn eine Transaktion das Eigentum an Token k überträgt, erscheint sie an Position k im Baum. Wenn der Plasma-Chain-Operator einen neuen Block erstellt, veröffentlicht er die Wurzel des Merkle-Baums on-chain und sendet jedem Nutzer direkt den Merkle-Zweig, der dem von ihm gehaltenen Token entspricht.

 

 

Nehmen wir an, dies sind die letzten drei Transaktionsbäume in der Plasma Cash Chain. Wenn alle vorherigen Bäume gültig sind, wissen wir, dass Eve derzeit Token 1 besitzt, David Token 4 und George Token 6.

 

Das Hauptrisiko in jedem Plasma-System ist das Fehlverhalten des Operators. Dies kann auf zwei Arten geschehen:

 

1. Veröffentlichung eines ungültigen Blocks (z. B. der Operator fügt eine Transaktion ein, die Token 1 von Fred an Hermione überträgt, obwohl Fred diesen Token zu diesem Zeitpunkt nicht besitzt);

 

2. Veröffentlichung eines nicht verfügbaren Blocks (z. B. der Operator sendet Bob nicht seinen Merkle-Zweig und verhindert so, dass Bob anderen beweisen kann, dass sein Token weiterhin gültig und nicht ausgegeben ist).

 

Wenn das Verhalten des Operators die Vermögenswerte eines Nutzers betrifft, ist der Nutzer dafür verantwortlich, sofort auszusteigen (genauer gesagt, innerhalb von 7 Tagen). Wenn ein Nutzer („Exiter“) aussteigt, liefert er einen Merkle-Zweig, der den Einschluss der Transaktion nachweist, mit der der Token vom vorherigen Eigentümer auf ihn übertragen wurde. Dies startet eine 7-tägige Challenge-Periode, in der andere durch Vorlage eines der folgenden drei Merkle-Nachweise den Exit anfechten können:

 

1. Nicht aktueller Eigentümer: Eine nachfolgende, vom Exiter signierte Transaktion, die den Token des Exiters an jemand anderen überträgt;

 

2. Double Spending: Eine Transaktion, die den Token vom vorherigen Eigentümer an jemand anderen überträgt und vor der Transaktion, die den Token an den Exiter überträgt, enthalten ist;

 

3. Ungültige Historie: Eine Transaktion, die den Token in den letzten 7 Tagen überträgt, ohne dass ein entsprechender Spend vorliegt. Der Exiter kann durch Vorlage des entsprechenden Spends antworten; tut er dies nicht, schlägt der Exit fehl.

 

 

Nach diesen Regeln muss jeder, der Token k besitzt, alle Merkle-Zweige an Position k in allen historischen Bäumen der letzten Woche sehen, um sicherzustellen, dass er tatsächlich Token k besitzt und diesen auch exiten kann. Sie müssen alle Zweige speichern, die Asset-Transfers enthalten, damit sie auf Challenges reagieren und ihre Token sicher exiten können.

 

Ausweitung auf fungible Token

Das oben beschriebene Design eignet sich für nicht-fungible Token (NFTs). Häufiger als NFTs sind jedoch fungible Token wie ETH und USDC. Eine Möglichkeit, Plasma Cash auf fungible Token anzuwenden, besteht darin, jeden kleinen Nennwert (z. B. 0,01 ETH) als eigenständiges NFT zu behandeln. Leider wären die Gasgebühren für den Exit dann zu hoch.

 

Eine Lösung besteht darin, viele benachbarte Token als eine Einheit zu optimieren, die gemeinsam übertragen oder exitiert werden können. Es gibt zwei Möglichkeiten, dies zu tun:

 

1. Plasma Cash fast unverändert verwenden, aber mit einem komplexen Algorithmus sehr schnell den Merkle-Baum für viele Objekte berechnen, wenn viele benachbarte Objekte identisch sind. Dies ist überraschend einfach; eine Python-Implementierung ist hier zu sehen.

 

2. Plasma Cashflow verwenden, das viele benachbarte Token einfach als ein einzelnes Objekt darstellt.

 

Beide Methoden stoßen jedoch auf das Problem der Fragmentierung: Wenn du von Hunderten von Leuten, die Kaffee kaufen, jeweils 0,001 ETH erhältst, besitzt du an vielen Stellen im Baum 0,001 ETH, sodass der tatsächliche Exit dieser ETH weiterhin viele einzelne Exits erfordert, was die Gasgebühren zu hoch macht. Es wurden Protokolle zur Defragmentierung entwickelt, deren Implementierung jedoch recht schwierig ist.

 

Eine andere Methode besteht darin, das System neu zu gestalten und ein traditionelleres „Unspent Transaction Output“ (UTXO)-Modell zu verwenden. Wenn du einen Token exiten möchtest, musst du die Historie dieses Tokens der letzten Woche vorlegen, und jeder kann deinen Exit anfechten, indem er nachweist, dass einer dieser historischen Token bereits exitiert wurde.

 

 

Der Exit des 0,2 ETH UTXO unten rechts kann durch Nachweis des Exits eines beliebigen UTXO in seiner Historie aufgehoben werden, wie im grünen Bereich dargestellt. Besonders zu beachten ist, dass die UTXOs in der Mitte links und unten links Vorfahren sind, der UTXO oben links jedoch nicht. Diese Methode ähnelt dem sequentiellen Färbeansatz der Colored Coin-Protokolle um 2013.

 

Es gibt verschiedene technische Möglichkeiten, dies zu erreichen. In allen Fällen ist das Ziel, ein Konzept von „demselben Token“ an verschiedenen Punkten in der Historie zu verfolgen, um zu verhindern, dass „derselbe Token“ zweimal ausgezahlt wird.

 

Herausforderungen bei der Ausweitung auf die EVM

Leider ist die Ausweitung auf die EVM über Zahlungen hinaus viel schwieriger. Eine zentrale Herausforderung ist, dass viele Statusobjekte in der EVM keinen klaren „Eigentümer“ haben. Die Sicherheit von Plasma hängt davon ab, dass jedes Objekt einen Eigentümer hat, der für die Überwachung und Sicherstellung der Datenverfügbarkeit on-chain verantwortlich ist und im Problemfall das Objekt exiten kann. Viele Ethereum-Anwendungen funktionieren jedoch nicht so. Zum Beispiel haben Uniswap-Liquiditätspools keinen einzelnen Eigentümer.

 

Eine weitere Herausforderung ist, dass die EVM keine Abhängigkeiten einschränkt. In Block N kann das in Account A gehaltene ETH von überall in Block N-1 stammen. Um einen konsistenten Status zu exiten, müsste eine EVM Plasma Chain ein Exit-Game haben, bei dem jemand, der Informationen aus Block N exiten möchte, im Extremfall die Kosten für die Veröffentlichung des gesamten Status von Block N on-chain tragen müsste: Kosten in Millionenhöhe. UTXO-basierte Plasma-Lösungen haben dieses Problem nicht: Jeder Nutzer kann seine Assets aus dem letzten Block, für den er die Daten besitzt, exiten.

 

Eine dritte Herausforderung ist, dass die unbegrenzten Abhängigkeiten in der EVM es schwierig machen, konsistente Anreize für Validitätsnachweise zu schaffen. Die Gültigkeit eines beliebigen Status hängt von allem anderen ab, sodass der Nachweis einer Sache den Nachweis von allem erfordert. In diesem Fall ist es aufgrund von Datenverfügbarkeitsproblemen oft nicht möglich, fehlgeschlagene Lösungen anreizkompatibel zu gestalten. Ein besonders ärgerliches Problem ist, dass wir die Garantie verlieren, die in UTXO-basierten Systemen besteht, dass der Status eines Objekts nicht ohne Zustimmung des Eigentümers geändert werden kann. Diese Garantie ist sehr nützlich, da sie bedeutet, dass der Eigentümer immer den neuesten nachweisbaren Status seines Assets kennt und das Exit-Game vereinfacht. Ohne sie wird die Erstellung eines Exit-Games viel schwieriger.

 

Wie Validitätsnachweise diese Probleme mildern

Die grundlegendste Funktion von Validitätsnachweisen besteht darin, die Gültigkeit jedes Plasma-Blocks on-chain zu beweisen. Dies vereinfacht den Designraum erheblich: Wir müssen uns nur noch um Operator-Angriffe mit nicht verfügbaren Blöcken kümmern, nicht mehr um ungültige Blöcke. In Plasma Cash zum Beispiel entfallen dadurch die historischen Challenges. Das reduziert den Status, den Nutzer herunterladen müssen, von einem Zweig pro Block der letzten Woche auf einen Zweig pro Asset.

 

Außerdem sind Exits aus dem neuesten Status (im üblichen Fall, dass der Operator ehrlich ist, erfolgen alle Exits aus dem neuesten Status) nicht mehr durch Challenges von nicht aktuellen Eigentümern gefährdet, sodass solche Exits in Plasma-Chains mit Validitätsnachweisen überhaupt nicht angefochten werden. Das bedeutet, dass Auszahlungen im Normalfall sofort erfolgen können.

 

Ausweitung auf die EVM: Parallele UTXO-Grafen

Im Fall der EVM ermöglichen Validitätsnachweise uns noch etwas Cleveres: Sie können verwendet werden, um parallele UTXO-Grafen für ETH und ERC-20-Token zu implementieren und mit SNARKs die Äquivalenz zwischen dem UTXO-Grafen und dem EVM-Status zu beweisen. Sobald dies vorhanden ist, kann man auf dem UTXO-Grafen ein „reguläres“ Plasma-System implementieren.

 

 

Dies ermöglicht es uns, viele der Komplexitäten der EVM zu umgehen. In einem kontenbasierten System kann beispielsweise jemand dein Konto ohne deine Zustimmung bearbeiten (indem er dir Token sendet und so dein Guthaben erhöht), was jedoch unerheblich ist, da Plasma nicht auf dem EVM-Status selbst, sondern auf einem parallelen UTXO-Status zur EVM aufbaut, wobei alle empfangenen Token eigenständige Objekte sind.

 

Ausweitung auf die EVM: Vollständiger Status-Exit

Es wurden bereits einfachere Ansätze vorgeschlagen, um eine „Plasma EVM“ zu erstellen, wie Plasma Free und zuvor dieser Artikel aus dem Jahr 2019. In diesen Ansätzen kann jeder auf L1 eine Nachricht senden, die den Operator zwingt, entweder eine Transaktion einzuschließen oder einen bestimmten Statuszweig verfügbar zu machen. Wenn der Operator dies nicht tut, beginnt die Chain, Blöcke zurückzurollen. Sobald jemand eine vollständige Kopie des gesamten Status oder zumindest aller Daten, die Nutzer als möglicherweise fehlend markieren, veröffentlicht, stoppt die Chain das Zurückrollen. Für Auszahlungen kann es erforderlich sein, eine Belohnung auszuschreiben, die den Gasanteil für die Veröffentlichung so großer Datenmengen an die Nutzer zahlt.

 

Solche Ansätze haben den Nachteil, dass sie im Normalfall keine sofortigen Auszahlungen erlauben, da es immer möglich ist, dass der neueste Status zurückgerollt werden muss.

 

Beschränkungen von EVM Plasma-Lösungen

Solche Ansätze sind leistungsfähig, können aber nicht für alle Nutzer vollständige Sicherheitsgarantien bieten. Die offensichtlichsten Ausfallfälle sind Situationen, in denen bestimmte Statusobjekte keinen klaren wirtschaftlichen „Eigentümer“ haben.

 

Betrachten wir den Fall eines CDP (Collateralized Debt Position), eines Smart Contracts, in dem Nutzer Token sperren, die erst nach Rückzahlung der Schulden freigegeben werden. Angenommen, ein Nutzer sperrt 1 ETH (zum Zeitpunkt des Schreibens etwa 2000 Dollar wert) in einem CDP und hat 1000 DAI Schulden. Nun hört die Plasma-Chain auf, Blöcke zu veröffentlichen, und der Nutzer weigert sich auszusteigen. Der Nutzer kann einfach für immer nicht exiten. Jetzt hat der Nutzer eine kostenlose Option: Fällt der ETH-Preis unter 1000 Dollar, gibt er das CDP auf; bleibt der ETH-Preis über 1000 Dollar, beansprucht er es schließlich. Im Durchschnitt wird ein böswilliger Nutzer dadurch profitieren.

 

Ein weiteres Beispiel sind Privatsysteme wie Tornado Cash oder Privacy Pools. Betrachten wir ein Privatsystem mit fünf Einzahlern:

 

 

Die ZK-SNARKs im Privatsystem halten die Verbindung zwischen dem Besitzer der eingehenden und dem Besitzer der ausgehenden Token verborgen.

 

Angenommen, nur Orange hat bereits ausgezahlt, und der Plasma-Chain-Operator hört auf, Daten zu veröffentlichen. Angenommen, wir verwenden die UTXO-Grafenmethode mit FIFO-Regel, sodass jeder Token mit dem darunterliegenden Token abgeglichen wird. Dann kann Orange seine Pre-Mix- und Post-Mix-Token auszahlen, das System behandelt sie als zwei unabhängige Token. Wenn Blau versucht, seinen Pre-Mix-Token auszuzahlen, wird Oranges aktualisierter Status diesen ersetzen; gleichzeitig hat Blau keine Informationen, um seinen Post-Mix-Token auszuzahlen.

 

Wenn man den anderen vier Einzahlern erlaubt, den Privacy Contract selbst auszuzahlen (was die Einzahlungen ersetzt) und dann die Token auf L1 abzuheben, kann dieses Problem gelöst werden. Die tatsächliche Implementierung eines solchen Mechanismus erfordert jedoch zusätzliche Anstrengungen der Entwickler des Privatsystems.

 

Es gibt weitere Ansätze zur Lösung von Datenschutzproblemen, wie die Intmax-Methode, bei der einige Bytes im Rollup-Stil on-chain gespeichert werden und ein Plasma-ähnlicher Operator Informationen zwischen den Nutzern weitergibt.

 

Uniswap-LP-Positionen haben ähnliche Probleme: Wenn du in einer Uniswap-Position mit USDC ETH getauscht hast, kannst du versuchen, dein USDC vor dem Tausch und dein ETH nach dem Tausch auszuzahlen. Wenn du mit dem Plasma-Chain-Operator kolludierst, können Liquiditätsanbieter und andere Nutzer nicht auf den Status nach dem Tausch zugreifen und somit ihr USDC nach dem Tausch nicht auszahlen. Es ist spezielle Logik erforderlich, um dies zu verhindern.

 

Fazit

Selbst im Jahr 2023 ist Plasma immer noch ein unterschätztes Design. Rollups sind weiterhin der Goldstandard und bieten unvergleichliche Sicherheitsmerkmale. Dies gilt insbesondere aus Sicht der Entwickler: Nichts ist so einfach wie die Tatsache, dass Anwendungsentwickler sich nicht einmal Gedanken über Eigentumsverhältnisse und Anreizflüsse in ihrer Anwendung machen müssen.

 

Plasma hingegen ermöglicht es uns, das Problem der Datenverfügbarkeit vollständig zu umgehen und die Transaktionsgebühren erheblich zu senken. Für Chains, die sonst Validiums wären, kann Plasma ein bedeutendes Sicherheitsupgrade darstellen. ZK-EVMs wurden dieses Jahr endlich Realität, was uns eine hervorragende Gelegenheit bietet, diesen Designraum neu zu erkunden und effektivere Konstruktionen vorzuschlagen, um das Entwicklererlebnis zu vereinfachen und die Gelder der Nutzer zu schützen.

Besonderer Dank gilt Karl Floersch, Georgios Konstantopoulos und Martin Koppelmann für ihre Beiträge zu Feedback, Review und Diskussion.