Autor: Anatoly Yakovenko

Zusammengestellt von: Deep Wave TechFlow

Überblick

MEV ist ein grundlegendes Problem in erlaubnislosen Blockchains. Wie bei den meisten erlaubnisfreien Blockchains besteht das Ziel von Solana darin, den MEV zu minimieren, den Kettenbetreiber den Benutzern entziehen.

Der Ansatz von Solana besteht darin, den MEV zu reduzieren, indem der Wettbewerb zwischen führenden Unternehmen (d. h. Blockproduzenten) maximiert wird. Dies bedeutet, dass die Slot-Zeiten verkürzt werden, die Anzahl der Slots, die ein einzelner Leiter nacheinander planen kann, reduziert wird und die Anzahl der gleichzeitigen Leiter pro Slot erhöht wird.

Im Allgemeinen bedeuten mehr Anführer pro Sekunde, dass der Benutzer nach einer Wartezeit von T Sekunden mehr Möglichkeiten hat, aus den eingehenden Anführern das beste Angebot auszuwählen. Mehr Leader bedeuten auch, dass es für gute Leader weniger kostet, Blockplatz bereitzustellen, was es für Benutzer einfacher macht, nur Transaktionen mit guten Leadern durchzuführen und Transaktionen von schlechten Leadern auszuschließen. Der Markt soll entscheiden, was gut und was schlecht ist.

Die größere Vision von Solana besteht darin, eine globale, erlaubnislose Preisfindungsmaschine aufzubauen, die mit der besten Leistung jeder zentralisierten Börse (CEX) konkurrieren kann.

Tritt in Singapur ein marktbeeinflussendes Ereignis ein, muss die Nachricht weiterhin über Glasfaser mit Lichtgeschwindigkeit zum CEX in New York übertragen werden. Bevor die Nachricht New York erreicht, hätte der Leiter des Solana-Netzwerks die Nachricht im Block verbreiten müssen. Sofern nicht gleichzeitig eine physische Internetpartition erfolgt, wird der Status von Solana die Nachricht bereits widerspiegeln, wenn sie New York erreicht. Daher sollte es in New York keine Arbitragemöglichkeit zwischen CEX und Solana geben.

Um dieses Ziel vollständig zu erreichen, benötigt Solana viele gleichzeitige Führungskräfte mit äußerst optimistischen Bestätigungsgarantien.

Konfigurieren Sie mehrere Leiter

Genau wie beim aktuellen Anführerplan konfiguriert das System jeden Slot mit zwei Anführern statt mit einem Anführer. Um zwischen den beiden Leadern zu unterscheiden, ist ein Kanal mit A und ein Kanal mit B gekennzeichnet. A und B können unabhängig voneinander rotieren. Die Fragen, die zur Umsetzung dieses Plans beantwortet werden müssen, sind:

• Was passiert, wenn die Blöcke A und B zu unterschiedlichen Zeiten eintreffen oder ausfallen?

• Wie kann die Reihenfolge der Transaktionen in den Blöcken A und B zusammengeführt werden?

• Wie teilt man die Blockkapazität zwischen A und B auf?

Gleichzeitige Blöcke übertragen

Um den Prozess zu verstehen, müssen wir einen kurzen Blick auf Turbine werfen.

Der Anführer teilt den Block beim Aufbau in Fragmente auf. Ein Stapel von 32 Fragmenten ist ein Löschcode aus 32 Codefragmenten. Viele der 64 Fragmente wurden merckisiert und mit der Root-Signatur versehen, und diese wurden mit dem vorherigen Los verknüpft.

Jedes Fragment wird über einen unabhängigen deterministischen Zufallspfad gesendet. Der erneute Sender jeder letzten Charge signiert die Wurzel.

Aus der Sicht des Empfängers muss jeder Empfänger 32 Fragmente vom authentifizierten Weitersender empfangen. Eventuell fehlende Teile werden nach dem Zufallsprinzip repariert.

Diese Zahl kann ohne geringe Auswirkungen auf die Latenz erhöht oder verringert werden.

Unter der Annahme, dass die Fragmentierungspfad-Abtastung des Retransmitters ausreichend zufällig und nach Anteilen gewichtet ist, werden die für ein kooperativ partitioniertes Netzwerk erforderlichen Anteile weitaus größer sein als ε-Anteile, sowohl hinsichtlich der Ankunftszeit als auch der Daten. Wenn der Empfänger erkennt, dass jeder Stapel von 32/64 (konfigurierbaren) Shards innerhalb der T-Zeit eintrifft, trifft dies höchstwahrscheinlich auch bei jedem Knoten zu. Dies liegt daran, dass 32 zufällige Knoten groß genug sind und sich wahrscheinlich nicht alle zufällig in derselben Partition befinden.

Wenn eine Teilung auftritt, muss sie im Konsens gelöst werden. Dies hat keinen Einfluss auf die Sicherheit, ist aber relativ langsam.

Mehrblockproduktion

Wenn ein einzelner Block übertragen wird, sieht jeder Empfänger (einschließlich des nächsten Leiters), dass für jeden Block eine Reihe von Fragmenten eintrifft. Wenn ein Block T Millisekunden lang unvollständig ist, überspringt der aktuelle Anführer den Block und baut einen Fork ohne ihn auf. Wenn der Anführer falsch liegt, stimmen alle anderen Knoten über den Block ab und der Block des Anführers wird übersprungen. Der nicht fehlerhafte Anführer wechselt sofort zur schwersten Gabel, die durch die Abstimmung angegeben wurde.

Bei Mehrblockübertragungen muss jeder Knoten bis zu T Millisekunden warten, bevor er über die beobachtete Blockpartition abstimmt. Bei zwei gleichzeitigen Anführern sind folgende Szenarios möglich: A, B oder A und B. Zusätzliche Latenz wird nur hinzugefügt, wenn der Block verzögert wird. Im Normalbetrieb sollten alle Blöcke gleichzeitig eintreffen und jeder Validator kann abstimmen, sobald beide eintreffen. Daher kann T in der Praxis nahe Null liegen.

Dieser Angriff muss sich darauf konzentrieren, sich dagegen zu verteidigen, ob ein Anführer mit einer sehr kleinen Menge an eingesetzten Token einen Block etwas später an einer Slot-Grenze übertragen kann, wodurch das Netzwerk zuverlässig aufgeteilt wird und das Netzwerk viel Zeit dafür aufwenden muss Lösung durch den Konsensmechanismus. Ein Teil des Netzwerks wird für A stimmen, ein Teil wird für B stimmen und ein Teil des Netzwerks wird sowohl für A als auch für B stimmen. Diese drei Spaltungssituationen müssen alle durch Konsensmechanismen gelöst werden.

Insbesondere sollte das Ziel der Null-Nachbarschaft darin bestehen, sicherzustellen, dass Knoten gleichzeitig Blöcke wiederherstellen. Wenn ein Angreifer einen kooperierenden Knoten in der Null-Nachbarschaft hat, kann er 31/64 Fragmente normal übertragen und dem Angreifer erlauben, das letzte Fragment selektiv zu übertragen, um eine Partition zu erstellen. Ehrliche Knoten können erkennen, welche Retransmitter zu spät kommen, und die fehlenden Fragmente an jeden einzelnen ehrlichen Knoten weiterleiten, sobald sie den Block wiederhergestellt haben. Weitersender können fortfahren, wenn sie das Fragment von irgendwoher empfangen oder wiederherstellen. Daher sollten Blöcke von allen Knoten kurz nach der Wiederherstellung eines ehrlichen Knotens wiederhergestellt werden. Es sind Tests erforderlich, um zu bestimmen, wie lange gewartet werden muss und ob sie absolut ist oder nach der Ankunftszeit jedes Shards gewichtet wird und ob die Reputation des Stake-Knotens verwendet werden soll.

Die Wahrscheinlichkeit eines Co-Leaders und eines Retransmitters in jedem Block beträgt ungefähr P Leader-Anteile (64P Retransmitter-Anteile). 1 % des Einsatzes kann für Angriffsversuche in ½-Shard-Batches verwendet werden, die vom Angreifer als Anführer angeordnet werden. Daher müssen Erkennung und Schadensbegrenzung robust genug sein.

Dieser Angriff hat nur minimale Auswirkungen auf den nächsten Anführer, da die asynchrone Ausführung die Übertragung ungenutzter Kapazität ermöglicht. Wenn also der aktuelle Anführer den nächsten Anführer zwingt, einen Slot zu überspringen, und der nächste Anführer vier aufeinanderfolgende Slots hat, kann die ungenutzte Kapazität des übersprungenen Slots übertragen werden, sodass der Anführer die übersprungene Slot-Transaktion wieder einschließen kann.

Gleichzeitige Blöcke zusammenführen

Wenn ein Benutzer die gleiche Transaktion an beide Anführer A und B sendet, um ihre Chancen zu erhöhen, aufgenommen zu werden oder Erster im Block zu sein, führt dies zu einer Verschwendung von Ressourcen. Wenn dies geschieht, führt eine Erhöhung der Anzahl gleichzeitiger Leiter nur zu einer sehr begrenzten Leistungsverbesserung, da diese einfach doppelt so viele Mülltransaktionen verarbeiten.

Um doppelte Transaktionen zu vermeiden, bestimmen die höchsten N-Gebührenzahler, in welchem ​​führenden Kanal die Transaktion gültig ist. In diesem Beispiel wählt das höchste Bit A oder B aus. Gebührenzahler müssen einem exklusiven Kanal zugewiesen werden, damit der Anführer sicher sein kann, dass der Gebührenzahler gültig ist und nicht alle seine Lamporte (die kleinste Währungseinheit in der Solana-Blockchain) für andere Anführer ausgegeben hat.

Dadurch wird der Spammer gezwungen, für die logisch identische Transaktion mindestens zweimal zu bezahlen. Um jedoch die Wahrscheinlichkeit zu erhöhen, dass es sich um die erste Transaktion handelt, kann der Spammer trotzdem die logisch identische Transaktion senden.

Um dieses Verhalten zu verhindern, können Benutzer zusätzlich zur Prioritätsgebühr des Leiters eine zusätzliche Gebühr für den Brennauftrag in Höhe von 100 % einbeziehen. Aufträge mit den höchsten Gebühren werden zuerst ausgeführt. Andernfalls wird die FIFO-Reihenfolge (First-In-First-Out) verwendet. Im Falle eines Gleichstands wird die Reihenfolge mithilfe deterministischer Zufallspermutationen aufgelöst. Daher ist es für Spammer kostengünstiger, ihre Auftragsgebühren zu erhöhen und zuerst auszuführen, als zweimal Aufnahmegebühren zu zahlen.

Um gebündelte und neu geordnete Transaktionssequenzen verarbeiten zu können, muss das System gebündelte Transaktionen unterstützen, wodurch eine Bestellgebühr zur Deckung der Sequenzierungskosten der gesamten Transaktionssequenz anfallen kann. Der Gebührenzahler ist nur in seinem geplanten Kanal gültig, daher kann das Bundle nur Sequenzen in seinem eigenen Kanal manipulieren.

Alternativ ist möglicherweise keine Bestellgebühr erforderlich. Wenn die FIFO-Reihenfolge verwendet wird und Spammern in allen Kanälen immer eine Prioritätsgebühr berechnet wird, kann es möglich sein, dem Markt einfach die Entscheidung zu überlassen, dass die Bezahlung von N Leadern, um die Kosten für Inklusionsmöglichkeiten zu erhöhen, dasselbe ist wie die Bezahlung des wahrscheinlich nächstgelegenen Leaders Bei der Transaktion sind zunächst die Kosten des Betreibers einzubeziehen.

Blockressourcen verwalten

Wenn in einem Blockchain-Netzwerk zwei gleichzeitige Leiter vorhanden sind, muss jede systemweite Blockkapazitätsgrenze gleichmäßig verteilt werden. Konkret geht es nicht nur um die Gesamtkapazität, sondern auch um jedes spezifische Limit, wie zum Beispiel das Schreibsperrlimit – kein Konto kann mehr als 6 Millionen Recheneinheiten (CUs) schreiben, und jeder Anführer kann nur bis zu 24 Millionen CUs handeln. Auf diese Weise überschreiten die zusammengeführten Blöcke selbst im schlimmsten Fall nicht die Gesamtkapazitätsgrenze des Systems.

Dieser Mechanismus kann zu Gebührenschwankungen und einer Unterauslastung der Ressourcen führen, da die Gebühr für die Planungspriorität von der Kapazität jedes Leiters abhängt und jeder Leiter nur wenig über den Planungsstatus anderer gleichzeitiger Leiter weiß.

Um eine Unterauslastung der Ressourcen und daraus resultierende Gebührenspitzen abzumildern, sollte jede ungenutzte Blockkapazität auf zukünftige Blöcke übertragen werden. Das heißt, wenn der aktuell zusammengeführte Block weniger als einen Maximalwert verwendet. Die asynchrone Ausführung kann dem oberen Ende der Kette um bis zu eine Epoche hinterherhinken, sodass das Kapazitätsrolling recht aggressiv sein kann.

Aktuellen Blockdaten zufolge sind die meisten Blöcke typischerweise zu 80 % gefüllt, während die Schreibsperrgrenze deutlich unter 50 % liegt. Im Allgemeinen sollte immer etwas freie Kapazität für zukünftige Blöcke vorhanden sein. Da Blöcke vorübergehend die Kapazitätsgrenzen überschreiten können, muss die Ausführung asynchron zum Konsensprozess erfolgen. Weitere Informationen zum asynchronen Ausführungsvorschlag finden Sie im APE-Artikel.