Gemeinsamer neuer Artikel von Solana: Solanas Concurrent-Leader-Mechanismus löst MEV und baut eine globale Preisfindungsmaschine auf

Autor: Anatoly Yakovenko

Zusammengestellt von: Deep Tide TechFlow

Übersicht

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.

Solanas Ansatz besteht darin, den MEV durch Maximierung des Wettbewerbs zwischen führenden Unternehmen (d. h. Blockproduzenten) zu reduzieren. 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 Leader pro Sekunde, dass der Benutzer nach einer Wartezeit von T Sekunden mehr Möglichkeiten hat, das beste Angebot aus den eingehenden Leadern 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 sollte entscheiden, was gut und was schlecht ist.

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

Wenn in Singapur ein marktbeeinflussendes Ereignis eintritt, 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 mehrerer Anführer

Genau wie beim aktuellen Anführerplan konfiguriert das System jeden Slot mit 2 Anführern anstelle von 1 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 Frage, die zur Umsetzung dieses Plans beantwortet werden muss, lautet:

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

• Wie füge ich die Transaktionsreihenfolge in den Blöcken A und B zusammen?

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

Gleichzeitige Blöcke übertragen

Um den spezifischen Prozess zu verstehen, müssen wir Turbine schnell verstehen.

Der Anführer teilt den Block beim Bau in Scherben. Ein Stapel von 32 Fragmenten ist ein Löschcode aus 32 Codefragmenten. Lose von 64 Fragmenten waren mit Quecksilber und Wurzel signiert und diese waren mit dem vorherigen Los verknüpft.

Jeder Shard 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 mit minimaler Auswirkung auf die Latenz erhöht oder verringert werden.

Angenommen, dass die Abtastung des Retransmitter-Fragmentpfads zufällig genug 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 Partition auftritt, muss sie im Konsens gelöst werden. Dies hat keinen Einfluss auf die Sicherheit, ist aber relativ langsam.

Multi-Block-Produktion

Wenn ein einzelner Block übertragen wird, sieht jeder Empfänger (einschließlich des nächsten Leiters), dass die Shard-Batches für jeden Block eintreffen. 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. Für zwei gleichzeitige Leiter 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, ob ein Anführer mit einer sehr kleinen Menge an eingesetzten Token einen Block etwas später an der Slot-Grenze übertragen kann, wodurch das Netzwerk zuverlässig geteilt wird und das Netzwerk gezwungen wird, viel auszugeben Zeit, einen Konsensmechanismus zur Lösung von Problemen zu verabschieden. 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. Alle drei Spaltungssituationen müssen durch Konsensmechanismen gelöst werden.

Konkret 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 koordinierten Leaders und eines Retransmitters in jedem Block beträgt ungefähr P Leader-Anteile (64P Retransmitter-Anteile). Ein Anteil von 1 % kann Angriffe in ½-Shard-Batches versuchen, 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 dieselbe Transaktion an beide Anführer A und B sendet, um die Chance 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, bestimmt die oberste N-Anzahl der 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, mindestens das Doppelte für die logisch identische Transaktion zu zahlen. Um jedoch die Wahrscheinlichkeit zu erhöhen, dass es sich um die erste Transaktion handelt, sendet der Spammer möglicherweise trotzdem die logisch identische Transaktion.

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, bei denen eine Bestellgebühr anfallen kann, um die Sequenzierungskosten der gesamten Transaktionssequenz zu decken. Der Gebührenzahler ist nur in seinem geplanten Kanal gültig, daher kann das Bundle nur Sequenzen in seinem eigenen Kanal manipulieren.

Alternativ sind möglicherweise keine Bestellgebühren 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 aktuelle zusammengeführte Block weniger als X an Schreibsperren, Gesamtbytes oder Gesamtrecheneinheiten (CUs) verwendet, sollten K*X zum nächsten Block hinzugefügt werden, wobei 0 K < Maximalwert. Die asynchrone Ausführung kann dem oberen Ende der Kette um bis zu eine Epoche hinterherhinken, sodass das Kapazitätsrolling recht aggressiv sein kann.

Basierend auf aktuellen Blockdaten 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.

Das obige ist der detaillierte Inhalt vonGemeinsamer neuer Artikel von Solana: Solanas Concurrent-Leader-Mechanismus löst MEV und baut eine globale Preisfindungsmaschine auf. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!