Einführung

Im fortwährenden Streben nach Verbesserung der Blockchain-Performance zur Bewältigung der Massenadoption hebt sich Monad als bahnbrechende Kraft zur Optimierung des Ethereum Virtual Machine (EVM)-Modells hervor. Dies geschieht durch eine Reihe von Low-Level-Verbesserungen: asynchrones I/O, einen optimierten Patricia Trie, verzögerte Ausführung und Optimistic Concurrency Control für parallele Verarbeitung [2]. Diese Verbesserungen bewältigen effektiv die Ausführungsengpässe und ineffiziente Zustandszugriffe, die auf Plattformen wie Ethereum zu beobachten sind, ohne dabei die Dezentralisierung zu beeinträchtigen.

In diesem Beitrag erkunden wir mögliche Implementierungen einer robusten Miner Extractable Value Auction Infrastructure (MEVA) auf Monad. Wir beschreiben auch einige übertragbare, wertvolle Lektionen aus bestehenden Ansätzen wie Flashbots auf Ethereum und Jito Network auf Solana.

Wir möchten einige wichtige Überlegungen hervorheben:

1. MEV ist inherent in jedem Blockchain-Netzwerk. Eine robuste MEVA-Infrastruktur ist entscheidend, um einen chaotischen Blockproduktionsprozess mit negativen externen Effekten und unvereinbaren Anreizen zu vermeiden.
2. Das MEVA-Design ist eng mit den zugrunde liegenden Mechanismen einer Blockchain, insbesondere ihrer Konsens- und Ausführungsstufen, integriert. Zukünftige Verbesserungen werden von der Weiterentwicklung dieser Faktoren und der Leistung des Netzwerks unter verschiedenen Belastungsstufen abhängen.
3. Historische Trends in der Blockproduktion, wie sie auf Ethereum und Solana zu sehen sind, können das MEVA-Design auf Monad beeinflussen.
4. MEVA auf hochleistungsfähigen, verzögerten Ausführungs-Blockchains wie Monad wird wahrscheinlich probabilistische Blockbau- und Suchstrategien erfordern, ähnlich dem Hochfrequenzhandel, aufgrund seiner zeitlichen Einschränkungen.

Indem wir diese Punkte ansprechen, hoffen wir, Einblicke in die Herausforderungen und Überlegungen zu geben, die bei der Gestaltung einer MEVA-Infrastruktur auf die einzigartige Architektur und Leistungsanforderungen von Monad zugeschnitten sind.

MEVA-Landschaft in Ethereum

MEVA unter Ethereum's Consensus-Execution Staging

In Ethereum erfordert der Konsens eine vorherige Ausführung. Wenn sich Knoten auf einen Block einigen, stimmen sie sowohl der Liste der Transaktionen im Block als auch dem Merkle-Wurzel zu, die den nachträglichen Zustand nach der Ausführung des Blocks zusammenfasst. Daher müssen Führungskräfte alle Transaktionen im vorgeschlagenen Block ausführen, bevor sie den Vorschlag verbreiten. In der Zwischenzeit müssen validierende Knoten die Transaktionen vor der Abstimmung ausführen.

Abbildung 1: Der Builder-Workflow in MEV-Boost unter der EL-CL-Trennung.

Abbildung 1 zeigt einen typischen Builder-Workflow in MEV-Boost für die Trennung von Proposer-Builder (PBS). Builder beenden den Blockbau und geben sie an ein Relay weiter, das die Blöcke an einen Execution Layer (EL)-Client zur Simulation und Überprüfung der Gültigkeit weiterleitet.

Da die Ausführung eine Voraussetzung für den Konsens ist, muss ein Erbauer, wenn er einen Block erstellt, den erstellten Block an einen Execution Layer (EL)-Client weiterleiten und den Block simulieren, um seine Gültigkeit zu überprüfen. Jenseits seiner notwendigen Rolle in der Konsens-Ausführungsphase bringt auch die Simulationsphase Vorteile sowohl für Erbauer als auch für Suchende.

Sicht des Entwicklers: Entwickler können den Wert des Blocks für sich selbst und die Validatoren genau schätzen, indem sie jede Transaktion simulieren. Sie können auch mit der Neuanordnung von Transaktionen experimentieren, um Umkehrungen zu minimieren und die Extraktion von Gasgebühren oder Grundtipps aus Mempool- und Bundle-Transaktionen zu maximieren. Ihre präzise Schätzung ermöglicht höhere Gebote an die Validatoren.

Sucherperspektive: Als Ergebnis der Vorsortierung von potenziell rückgängig zu machenden Bundles durch die Entwickler, bevor sie in der Kette landen, sehen Sucher auch garantierte Strategieausführung, was zu Determinismus führt. Darüber hinaus erhalten Sucher auch Zugriff auf den aktuellsten Blockstatus. Wenn die Konsensschicht (CL) einen neuen Block verbreitet, können Sucher den Status aus diesem Block als Ausgangspunkt verwenden, um profitable Bundles zu erstellen. In der Zwischenzeit gibt es Hinweise auf weitere außerprotokollarische Geschäfte oder Funktionen, die derzeit von den Entwicklern angeboten werden und es Suchern ermöglichen, Statusinformationen für den aktuellen zu erstellenden Block zu erhalten, um Rücklauftstrategien zu ihren zu landenden Blöcken hinzuzufügen.

Allerdings hat die Entwicklung von PBS zu einer Zunahme der Zentralisierung beim Blockaufbau geführt, die dem traditionellen Handel ähnelt, bei dem Unternehmen um dedizierte Mikrowellen-Netzwerkkanäle konkurrieren, um Priorität bei der Ausführung von Arbitragestrategien zu erlangen.

Produktiteration, wenn das Netzwerk reift

Wir untersuchen nun, wie sich MEVA im Laufe der Entwicklung von Ethereum entwickelt hat, wie in Abbildung 2 chronologisch dargestellt.

Abbildung 2: Eine chronologische Ansicht, wie MEV sich entwickelt, während das Ethereum-Netzwerk voranschreitet. Die Abbildung wurde leicht angepasst von [4].

Ära der Prioritäts-Gasauktion (PGA)

Wie in Abbildung 3 dargestellt, identifizierten Suchende profitable MEV-Chancen und übermittelten ihre smart-Vertrags-fähigen Transaktionen an den öffentlichen Mempool. Diese öffentliche Sichtbarkeit führte zu einem On-Chain-Auktionsformat mit offenen Geboten zum Erstpreis, bei dem auch fehlgeschlagene Transaktionen Gas kosten verursachten.

In dieser Zeit gab es wettbewerbsfähige und kostspielige unstrukturierte MEV-Aktivitäten wie Transaktionen mit demselben (Konto, Nonce)-Paar und steigende Gebote [6], was zu einer Überlastung des Netzwerks oder zu Konsensinstabilität führte.

Abbildung 3: Einfache Prioritäts-Gasauktion. Die Abbildung wurde leicht angepasst von [6].

Flashbots und EIP-1559

Um diese Probleme zu lösen, führte Flashbots Relays ein, Zwischenversteigerungshäuser zwischen Suchenden und Blockproduzenten (Miner in der PoW-Ära) ein. Diese Initiative verwandelt den MEV-Marktplatz von einer offenen Gebots-Erstpreisversteigerung in eine geschlossene Gebotsversteigerung. Abbildung 4 zeigt, wie die Relays helfen, Gebotserhöhungen im öffentlichen Mempool zu verhindern und einen geordneteren und sichereren Blockproduktionsprozess zu etablieren.

Die Gebührenstruktur von EIP-1559 spielt hier auch eine Rolle [7]. Es vereinfachte das Bieten, indem es teilweise veröffentlichte Preise durch Grundgebühren einführte, aber es behandelte nicht die Transaktionsreihenfolge innerhalb der Blöcke, die immer noch MEV durch Prioritätsgebühren antreibt. In Wirklichkeit haben viele Suchende zuvor Gebote direkt an die Miner über Coinbase-Transfers abgegeben. Sie hatten mehr Beschwerden über die Coinbase-Gebühren, da sie nicht mehr in der Lage waren, 0-Gas-Bundles einzureichen.

Abbildung 4: MEVA mit Relais. Die Abbildung wurde leicht angepasst aus [6].

Trennung von Antragsteller und Bauherr (PBS)

Nach dem Übergang von Ethereum zu Proof of Stake (PoS) nach der Fusion wurde eine Trennung von Vorschlagssteller und Blockersteller (PBS) implementiert, um die Trennung der Rollen in der Blockproduktionspipeline weiter zu verfeinern. Wie bereits beschrieben, fungieren Relays nun als Vermittler zwischen Blockerstellern und Vorschlagsstellern und agieren als Verwalter, die die Datenverfügbarkeit und Blockgültigkeit sicherstellen. Da ein Vorschlagssteller sich mit verschiedenen Blockerstellern für unterschiedliche private Transaktionen verbinden kann, müssen die Blockersteller durch Zahlungen an den Vorschlagssteller konkurrieren. Dieser Dynamik ist in Abbildung 5 dargestellt.

Abbildung 5: MEVA in der PBS-Ära. Diese Abbildung wurde leicht angepasst von [6].

Konzentrationsrisiken

Trotz dieser historischen Fortschritte ist es wichtig, auf die wachsenden Bedenken hinsichtlich der Konzentrationsrisiken auf dem Baubereichsmarkt hinzuweisen. Im vergangenen Jahr haben neun Oligarchen der obersten neun Bauherren konsequent >50% des Marktes gehalten, was auf ein hohes Maß an Marktkonzentration hinweist, wie in Abbildung 6 dargestellt. Der Zustand der Konzentration ist derzeit noch ausgeprägter, da die drei führenden Bauherren über >90% der Blöcke abdecken.

Abbildung 6: Marktanteil der Bauunternehmer. Die Grafik zeigt die hohe Konzentration auf dem Markt für Bauunternehmer. Die Grafik stammt von https://arxiv.org/pdf/2405.01329

Jito auf Solana

Jitos Architektur

Als kanonische MEVA auf Solana wurde Jito erstellt, um die hohe Spamming-Rate von Solana aufgrund der niedrigen Transaktionskosten zu beheben. Spamming-Trades sind effektiv motiviert, solange die Kosten einer fehlgeschlagenen Transaktion (ca. 0,000005 SOL) den erwarteten Gewinn nicht übersteigen.

Laut einem Bericht von Jito Labs aus dem Jahr 2022 [8] sind über 96% der Arbitrage- und Liquidationsversuche in diesem Jahr gescheitert, wobei Blöcke mehr als 50% MEV-bezogene Transaktionen enthielten. Der Bericht hebt auch hervor, dass Liquidationsbots das Netzwerk mit Millionen von Duplikatpaketen überflutet haben, nur um mehrere tausend erfolgreiche Liquidationen zu erreichen, was zu einer Ausfallrate von über 99% führte [8].

Abbildung 7: Ein Überblick über Jitos MEVA auf Solana.

Die Schwere der MEV-Externalitäten auf Solana führte Jito dazu, eine MEVA-Schicht zu entwickeln, die darauf abzielt, Ordnung und Determinismus in den Blockproduktionsprozess zu bringen. Lassen Sie uns die ursprüngliche von Jito vorgeschlagene MEVA-Architektur überprüfen, wie in Abbildung 7 dargestellt.

Jito hat die folgenden Komponenten:

Relay - fungiert als Proxy zum Empfangen von Transaktionen und leitet sie sowohl an den Block Engine (oder die MEVA-Supply-Chain) als auch an Validatoren weiter.

Block Engine - nimmt Transaktionen vom Relayer entgegen, koordiniert mit Suchenden, akzeptiert Bündel, führt Bündelsimulationen durch und leitet die besten Transaktionen und Bündel zur Verarbeitung an den Validator weiter. Bemerkenswert ist, dass Jito anstelle einer vollständigen Blockauktion eine teilweise Blockauktion für die Bündelaufnahme durchführt und historisch gesehen über 80% der Bündel innerhalb von zwei Slots verarbeitet hat [9].

Pseudo-Mempool - über den Jito-Solana-Client wird ein Betriebszeitfenster von etwa 200 Millisekunden erstellt, das eine diskretisierte Auktion für den Auftragsfluss auslöst [10]. Jito hat diesen Mempool am 9. März 2024 geschlossen.

Jitos Designentscheidungen

Lassen Sie uns die spezifischen Komponenten von Jito's Systemdesign erkunden und darüber nachdenken, wie diese Designentscheidungen aus dem Blockproduktionsprozess von Solana resultieren.

Jito unterstützt nur teilweise Blockauktionen anstelle des vollständigen Blockaufbaus, wahrscheinlich aufgrund des multi-threaded Execution-Modells von Solana, das keine globale Planung aufweist. Insbesondere zeigt Abbildung 8 parallele Threads, die Transaktionen ausführen, wobei jeder seine eigene Warteschlange von Transaktionen wartet, die ausgeführt werden müssen. Transaktionen werden zufällig Threads zugewiesen und lokal nach Prioritätsgebühr und Zeit geordnet. Ohne globale Reihenfolge auf der Scheduler-Seite (vor dem Update 1.18.x) erleben Solanas Transaktionen inhärenten Nichtdeterminismus durch das Scheduler-Jitter [11]. Folglich können in der MEVA Sucher oder Validatoren den aktuellen Zustand nicht zuverlässig bestimmen.

Abbildung 8: Das Multi-Threaded-Ausführungsmodell für Solana-Client. Beachten Sie, dass die Bundle-Stage von MEVA als separater Thread innerhalb der Mehrfach-Thread-Warteschlange angehängt ist.

Aus ingenieurtechnischer Sicht passt die Integration des Blockmotoren-Feeds von Jito als zusätzlicher Thread, der parallel zu den bestehenden läuft, gut zur multithreaded Architektur von Solana. Während Bündelauktionen eine prioritätsgestützte Reihenfolge innerhalb des Jito-Blockmotoren-Threads sicherstellen, gibt es keine Garantie dafür, dass Bündel immer vor Benutzertransaktionen global platziert werden.

Um dies zu lösen, reserviert Jito einen Teil des Blockraums für den Bundle-Thread und garantiert damit Bundles mit Platz im Block. Obwohl die Unvorhersagbarkeit bleibt, erhöht dieser Ansatz die Wahrscheinlichkeit für eine erfolgreiche Strategieausführung. Es fördert auch die Teilnahme von Suchenden an der Auktion anstelle von Spamming des Netzwerks. Durch die Reservierung von Blockraum für Bundles kann Jito ein Gleichgewicht schaffen, das geordnete Auktionen fördert und die chaotischen Auswirkungen von Transaktionsspamming mildert.

Entfernen des Pseudo-Mempools

Die weite Verbreitung von Jito hat positive Ergebnisse bei der Eindämmung des Spam-Problems auf Solana gezeigt. Untersuchungen von p2p [12] und Daten, die in Abbildung 9 gezeigt werden, zeigen eine statistisch signifikante Verbesserung der relativen Blockproduktionsrate nach der Einführung des Jito-Clients. Dies deutet darauf hin, dass die Transaktionsverarbeitung dank des optimierten Blockmotors von Jito, der 2023 eingeführt wurde, effizienter geworden ist.

Abbildung 9: Nachweise für die Wirksamkeit von Jito bei der Eindämmung des Spamming-Problems auf Solana. Die Grafik stammt aus einem Forschungsbericht in [12], der vom p2p-Team durchgeführt wurde.

Obwohl bereits erhebliche Fortschritte erzielt wurden, bleiben zahlreiche Herausforderungen bestehen. Da Jito-Bundles die Blöcke nur teilweise füllen, können MEV-induzierende Transaktionen immer noch den Jito-Auktionskanal umgehen. Dieses Problem wird zumindest teilweise durch das Dune-Dashboard in Abbildung 10 [13] belegt, das zeigt, dass das Netzwerk seit 2024 weiterhin im Durchschnitt mehr als 50% fehlgeschlagene Transaktionen aufgrund von Bot-Spam aufweist.

Abbildung 10: Ein Dune-Dashboard (https://dune.com/queries/3537204/5951285) die die Bot-Spam-Aktivitäten auf Solana seit Mai 2022 illustriert.

Am 9. März 2024 entschied Jito, seinen Flaggschiff-Mempool auszusetzen. Diese Entscheidung wurde durch das Wachstum von Memecoin-Transaktionen und einen entsprechenden Anstieg von Sandwich-Angriffen (eine Art von Front-Running, bei dem Sucher Transaktionen vor und nach der Zieltransaktion platzieren) veranlasst, was letztendlich zu einer Beeinträchtigung der Benutzererfahrung führte. Ähnlich wie bei den auf Ethereum beobachteten Trends mit privaten Auftragsflusskanälen in MEVA kann die Schließung des öffentlichen Mempools das Wachstum des privaten Auftragsflusses durch Partnerschaften mit Front-End-Diensten wie Wallet-Anbietern und Telegramm-Bots fördern. Sucher können direkt Partnerschaften mit Validatoren eingehen, um bevorzugte Ausführungen, Einbeziehung oder Ausschluss zu erreichen. Tatsächlich lässt sich dies anhand von Abbildung 11 belegen, die das stündliche Gewinnprofil des Sandwich-Bots für den größten privaten Mempool-Sucher (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) nach der Mempool-Schließung veranschaulicht.

Abbildung 11: Der stündliche Gewinn für den Sandwich-Bot mit privatem Mempool für den Sucher "3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81".

Jitos Entscheidung, das Mempool zu schließen, unterstreicht das starke Engagement des Teams, grundlegende Probleme im Solana-Ökosystem anzugehen. Neben der Weiterentwicklung von MEVA oder der Anpassung des Gasgebührenmechanismus von Solana hilft Jito auch dabei, Protokolle über die Begrenzung von Angriffsvektoren durch UI-Produktdesignentscheidungen wie die Begrenzung der Standard-Slippage-Parameter zu informieren. Ob durch Anpassungen der Gebührenstruktur, die das Spamming teurer machen, oder durch Modifikation der Kommunikationsprotokolle, die Infrastruktur von Jito bleibt für die Aufrechterhaltung der Netzwerkgesundheit und -stabilität von Solana unerlässlich.

MEVA Design auf Monad

Verzögerte Ausführung und Auswirkungen auf MEVA

Im Gegensatz zu Ethereum, wo die Einigung auf einen Block sowohl die Liste der Transaktionen (mit Reihenfolge) als auch den Merkle-Wurzel zusammenfassend alle nachträglichen Zustände erfordert, entkoppelt Monad die vorherige Ausführung von Konsens. Die Node-Übereinkunft erfordert nur die Abwicklung der offiziellen Reihenfolge. Wie in Abbildung 12 dargestellt, führt jeder Knoten die Transaktionen im Block N unabhängig aus, während er sich auf Konsens über Block N+1 einlässt. Diese Anordnung ermöglicht ein Gasbudget, das der vollen Blockzeit entspricht, da die Ausführung nur mit dem Konsens Schritt halten muss. [15] Ohne die Notwendigkeit, dass der Leitknoten die de facto Zustandswurzel berechnet, kann die Ausführung den gesamten Konsenszeitraum für den nächsten Block nutzen.

Abbildung 12: Monad Deferred Execution im Vergleich zur Execution-Consensus-Staging von Ethereum. Das operative Zeitfenster wird auch aus der Perspektive des MEVA-Designs veranschaulicht.

Wir definieren das operative Zeitfenster als den Zeitrahmen, der für MEVA auf Monad erlaubt ist, einen Blockbaugungsvorschlag abzuschließen, der sowohl machbar als auch profitabel im Vergleich zur Standard-Blockbaumethode ist. Es gibt zwei unmittelbare Konsequenzen des verzögerten Ausführungsmodells:

1. Wenn MEVA innerhalb des Betriebszeitfensters für den N-ten Block erstellt, stimmen die Validatoren gleichzeitig über die Transaktionsliste für den N-ten Block ab, während sie versuchen, die Ausführung für den N-1-ten Block abzuschließen. Daher ist es innerhalb des Betriebszeitfensters bei N sehr wahrscheinlich, dass der verfügbare Zustand immer noch bei N-2 liegt. Dies bedeutet, dass es unter dieser verzögerten Ausführungsarchitektur keine garantierten "aktuellsten Zustand" für das Relay oder den Builder gibt. Daher ist es unmöglich, gegen den neuesten Block zu simulieren, bevor der nächste produziert wird, was zu Indeterminismus führt.
2. Angesichts der 1-Sekunden-Blockzeit von Monad ist das Betriebszeitfenster für MEVA extrem begrenzt. Das bedeutet, dass die Entwickler möglicherweise nicht genug Zeit haben, um vollständige Blöcke von Transaktionen und Bündeln sequenziell zu simulieren, wie sie es normalerweise auf Ethereum tun. Viele Variablen können sich auf die Zeit auswirken, die für die Transaktionssimulation auf EVM benötigt wird. Wenn man jedoch davon ausgeht, dass die Simulation einer Transaktion zwischen 10^1 und 10^2 Mikrosekunden dauert (eine grobe Annahme), und mit dem Ziel von Monad von 10^4 Transaktionen pro Sekunde, könnte es ungefähr 1 volle Sekunde dauern, nur um den gesamten Block innerhalb des Betriebszeitfensters zu simulieren. In Anbetracht der 1-Sekunden-Blockzeit von Monad wäre es für Konstrukteure oder Relais eine Herausforderung, mehrere vollständige Blocksimulationen durchzuführen, um den gebauten Block zu optimieren.

Probabilistische Builder & Searcher Strategie

Angesichts der Einschränkungen ist es nicht praktikabel, innerhalb des Betriebszeitfensters eine vollständige Blocksimulation durchzuführen und gegen den neuesten Zustand zu simulieren. Da den Erstellern jetzt sowohl die Zeit als auch der neueste Zustand fehlen, um den genauen Tipp von jeder Transaktion zu kennen, müssen sie den Sucher-Tipp auf der Grundlage der Wahrscheinlichkeit einer Transaktionsumkehrung durch Reputation oder durch Simulation gegen (möglicherweise bestenfalls) N-2 Zustand ableiten. Dies macht die Blockbewertung weniger deterministisch.

Sucher haben auf Monad eine höhere Unsicherheit bei der Ausführung aufgrund des Mangels an theoretischen Garantien gegen Transaktionsrückgängen, sobald der Validator den Block akzeptiert, der vom Builder erstellt wurde. Im Gegensatz dazu konkurrieren Sucher auf Ethereum um dedizierte private Orderflow-to-Builder-Kanäle für relativ deterministische Strategieausführungen. In dieser relativ probabilistischen Umgebung auf Monad haben Sucher nun ein höheres Risiko, dass Bündel on-chain rückgängig gemacht werden, was zu einem unsichereren Execution-PnL-Profil führt. Dies spiegelt Hochfrequenzhändler wider, die auf probabilistischen Signalen mit leicht positiven erwarteten Renditen im Laufe der Zeit handeln.

Abbildung 13: Ein konzeptionelles Spektraldiagramm, das verschiedene MEVA-Design-Paradigmen veranschaulicht, die nach dem Grad der vorgeschlagenen Blocküberprüfung oder Simulation kategorisiert sind.

Wie in Abbildung 13 gezeigt, erzeugt der Grad der vorherigen Bündel-/Blockprüfung auf der Seite des Erbauers ein Spektrum der Unsicherheit hinsichtlich der Preisgestaltung oder Bewertung des vorgeschlagenen Blocks. Auf der einen Seite steht das Ethereum-ähnliche PBS-Modell mit genauer Preisgestaltung, bei dem die Erbauer den Execution Layer (EL) Client verwenden müssen, um Transaktionen im vorgeschlagenen Block zu simulieren. Sie müssen sich durch eine Vielzahl von Kombinatorik bei den eingereichten Bündeln navigieren. Auf der anderen Seite steht das Optimistic Builder Model [16] mit asynchroner Blockprüfung. In diesem Modell umgehen die Erbauer die Zeit, die für eine Simulation während des Betriebszeitfensters erforderlich ist, und ehren die den Validatoren oder dem Relais gezeigten Tipps, indem sie Pfandrechte hinterlegen, die einem Slashing unterliegen. Der hier auf Monad vorgeschlagene probabilistische Prüfungs- oder teilweise Simulationansatz liegt dazwischen und erhöht die Wahrscheinlichkeit einer erfolgreichen Strategieumsetzung für Suchende trotz einiger Unbestimmtheit.

Beispielsweise könnte ein Market Maker an einer Onchain-Orderbuch-DEX über die MEVA bezahlen, um ihre Positionen im Voraus zu verschieben, wenn sie eine major unidirektionale Preisbewegung erkennen, um eine ungünstige Auswahl zu vermeiden. Diese probabilistische Strategie ermöglicht es ihnen, schnell zu handeln, selbst ohne die aktuellsten Zustandsinformationen, und Risiko und Belohnung in einer dynamischen Handelsumgebung auszubalancieren.

Abschlussbemerkungen

MEVA spielt eine entscheidende Rolle bei der Optimierung der Blockproduktion durch die Abschwächung von Externalitäten und die Verbesserung der Gesamtstabilität des Systems. Die kontinuierliche Weiterentwicklung der MEVA-Frameworks, wie sie beispielsweise bei Jito auf Solana und verschiedenen Implementierungen auf Ethereum zu sehen ist, ist äußerst hilfreich, um Skalierbarkeitsprobleme anzugehen und die Anreize der Netzwerkteilnehmer in Einklang zu bringen.

Monad ist ein vielversprechendes Netzwerk, das noch in den Kinderschuhen steckt und der Community eine einzigartige Gelegenheit bietet, das optimale MEVA-Design zu gestalten. In Anbetracht des einzigartigen Ausführungs-Konsens-Stagings von Monad laden wir Forscher, Entwickler und Validatoren ein, zusammenzuarbeiten und Erkenntnisse auszutauschen. Diese Zusammenarbeit wird entscheidend dazu beitragen, einen robusten und effizienten Blockproduktionsprozess zu schaffen, der es Monad ermöglicht, sein Potenzial als Hochdurchsatz-Blockchain-Netzwerk auszuschöpfen.

Haftungsausschluss:

1. Dieser Artikel wurde von [ abgedruckt0xapr]. Alle Urheberrechte gehören dem Originalautor [ APRIORI ⌘]. Sollten Einwände gegen diesen Nachdruck bestehen, wenden Sie sich bitte an die Gate LernenTeam, und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel geäußert werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagieren der übersetzten Artikel untersagt.