Vorwärts mit dem Originaltitel 'Wir bauen alle dasselbe'

Einführung

Dieser Beitrag analysiert das Folgende

• asynchrone Ausführung - Warum hochleistungsfähige integrierte Blockchains (z.B., SolanaundMonad) entkoppelt die Ausführung von der Konsensbildung über die Reihenfolge (Sequenzierung).
• träge Sequenzierung - wie sie das Design eines träge Sequenzers spiegeln werden (z. B.,@astriaorg/hj6ccpp9t">astria).
• Pre-Bestätigungen - Preconfs auf Ethereum L1 und basierten Rollups.
• basiert vs. nicht basiert - Vergleich von basierten Rollups + Preconfs vs. nicht basierten Rollups + Basisschicht-Rückfall.
• Universelle synchrone Komponierbarkeit - über atomare Einbindung (aus gemeinsamen Sequenzern) + kryptografische Sicherheit (z.B., AggLayerund/oder Echtzeitnachweis).
• schnelle basierte Rollups - basierte Rollups sollten nur eine schnelle Basisschicht haben.
• Zeitspiele - Zeit ist Geld, und wie sich das in den divergenten Endspielen zwischen Solana und Ethereum widerspiegelt.
• Dezentralisierung für Zensurresistenz - wieTrennung von Attester und VorschlagendenviaDurchführungsauktionenkann dezentrale Validatoren erhalten, die Zensurresistenz durchsetzen könnenInklusionslisten.

zuletzt und am wichtigsten werden wir sehen, warum Wir bauen alle dasselbe verdammte DingVielleicht sollten wir also einfach...

Optimierung der Replikation von Zustandsmaschinen (SMR)

Wir werden von den Grundlagen aufbauen, um zu sehen, dass das Endspiel für Hochleistungs-Blockchains (z. B. Solana, Monad, @patrickogrady/rys8mdl5p#mitigation-strategie-ermöglichen-profit-maximierenden-entwicklern, ungültige TPS zu minimieren">hypersdk) nähert sich der Ansatz einer fauler Sequenzer (z. B., @astriaorg/hj6ccpp9t">astria). Wir werden später wieder auf sie zurückkommen, um sie mit Ethereum-basierten Rollups + Preconfs zu vergleichen.

Sequenzieren vs. Ausführung

Blockchains sind replizierte Zustandsmaschinen. Dezentrale Knoten halten und aktualisieren jeweils ihre eigene Kopie des Systemzustands. Um die Kette voranzubringen, führen die Knoten die Zustandsübergangsfunktion (STF) über den aktuellen Zustand + neue Eingaben (z. B. neue Transaktionen) aus. Dadurch entsteht der neue Zustand.

In diesem Abschnitt verwenden wir die folgenden Begriffe:

• syntaktisch gültig - die Transaktion ist korrekt formatiert mit einer ordnungsgemäßen Transaktionsstruktur und Signatur.
• semantisch gültig - die Transaktion führt einen gültigen Zustandsübergang durch (z.B. zahlt die erforderlichen Gebühren).
• Sequenz - bestimmen die Reihenfolge und Einbeziehung von Daten.
• ausführen - Daten entsprechend den stf interpretieren und handeln.
• Erstellen - Erstellen Sie einen Block (oder einen teilweisen Blockchunk/Splitter) aus lokal gespeicherten Transaktionen.
• überprüfen - die erforderliche syntaktische und/oder semantische Überprüfung eines Blocks (oder eines Teils eines Blockchunks/Splitters) durchführen.
• replizieren - einen Block (oder einen Teilblock Chunk/Shred) an andere Validatoren verbreiten.

Lassen Sie uns auf Sequenzierung und Ausführung zoomen, da dies die Kernunteraufgaben sind, die benötigt werden, um den Zustand der Kette zu berechnen:

Zusätzlich verifizieren und replizieren Knoten die Daten im Netzwerk. Knoten erzielen Konsens, um eine konsistente Sicht auf die Kette zu behalten.

Jedoch unterscheiden sich verschiedene Kettenarchitekturen bedeutsam darin, wer für diese Aufgaben verantwortlich ist und wann dies geschieht (z. B. kann der Blockaufbau und die Überprüfung die Ausführung beinhalten oder auch nicht). Die Gesamtdauer vom Anfang bis zum Ende der vollständigen Zustandsmaschinenreplikation (SMR)Die Schleife legt die untere Grenze für die Systemlatenz fest. Unterschiedliche Konstruktionen können zu stark variablen Zeiten führen, sodass ein effizienter SMR-Prozess Pipeline) diese Aufgaben sind notwendig für eine geringe Latenz und hohe Durchsatzleistung.

In den folgenden Abschnitten werden wir sehen, dass eine Kern-Erkenntnis der effizienten Pipelining darin besteht, sich auf die Erzielung von Konsens über Ausführungseingaben zu konzentrieren, anstelle von Ausführungsergebnissen. Dies erfordert die Lockerung bestimmter Einschränkungen hinsichtlich der Transaktionen, die enthalten sein dürfen. Dann müssen wir einige schwächere Einschränkungen wieder einführen, um sicherzustellen, dass das System nützlich bleibt und Angriffen gegenüber widerstandsfähig ist (z. B. Vermeidung von DoS-Vektoren aus Transaktionen, die keine Gebühren zahlen).

traditionelles SMR

Traditionelle SMR (z. B. Ethereum) koppelt Sequenzierung und Ausführung eng miteinander. Vollknoten sequenzieren und führen kontinuierlich alle Transaktionen der Basisschicht aus - beides sind Voraussetzungen dafür, dass Knoten zu einem Konsens gelangen. Neben der Überprüfung, ob alle Blockdaten verfügbar (und sequenziert) sind, müssen Knoten auch den Block ausführen, um zu überprüfen, dass:

• Alle Transaktionen sind syntaktisch und semantisch gültig
• Der neu berechnete Zustand stimmt mit dem vom Anführer bereitgestellten überein

Validatoren werden nur für einen Block stimmen und darauf aufbauen, sobald sie dessen Zustand unabhängig überprüft haben. Dies bedeutet, dass die Ausführung mindestens zweimal erfolgt, bevor ein Konsens erreicht werden kann (d. h. der Blockproduzent führt während des Aufbaus aus + die empfangenden Validatoren führen erneut aus, um zu überprüfen).

In diesem traditionellen Modell umfassen sowohl das Erstellen als auch die Überprüfung die Ausführung.

Quelle: @patrickogrady/rys8mdl5p#Making-the-Case-for-Decoupled-State-Machine-Replication-DSMR">vryx: Verstärkung der entkoppelten Zustandsmaschinenreplikation

Streaming SMR

Streaming SMR (z. B. Solana) ist eine effiziente Form des Pipelining, bei der Blockproduzenten übertragen kontinuierlich Stücke von Blöcken (genannt Shredsoder Stücke) während des Aufbaus empfangen und verifizieren andere Knoten diese Shreds kontinuierlich, einschließlich der Ausführung, auch wenn der Rest des Blocks noch aufgebaut wird. Dies ermöglicht es dem nächsten Leader, früher mit dem Aufbau ihres Blocks zu beginnen.

Quelle: @patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: Stärkung der entkoppelten Zustandsmaschinenreplikation

In diesem Streaming-Modell umfassen Aufbau und Überprüfung nach wie vor Sequenzierung und Ausführung. Dadurch wird die Effizienz von SMR im Vergleich zu herkömmlichem SMR erhöht, ohne dass dabei die Bedingungen gelockert werden, dass alle enthaltenen Transaktionen sowohl semantisch als auch syntaktisch gültig sind.

asynchrone Ausführung

integrierter Ansatz

Können wir jetzt noch bessere Leistungen erzielen, wenn wir diese Einschränkungen lockern?

Die asynchrone Ausführung entfernt die Ausführung aus dem heißen Pfad des Konsenses - Knoten kommen einfach zu einem Konsens über die Reihenfolge der Daten, ohne diese zuerst auszuführen. Dies ist effizienter, weshalb.SolanaundMonadBeide planen die Implementierung einer asynchronen Ausführung.

Der Anführer würde einen Block (oder Scherben) erstellen und replizieren, ohne ihn ausführen zu müssen. Dann würden andere Validatoren darüber abstimmen, ohne ihn ebenfalls auszuführen. Knotenpunkte einigen sich nur auf die Reihenfolge und Verfügbarkeit von Transaktionen. Dies ist ausreichend, da jeder bei einer deterministischen STF letztendlich den gleichen Zustand berechnen wird. Die Ausführung muss den Konsens nicht aufhalten - sie kann asynchron ausgeführt werden. Dadurch kann das Ausführungsbudget für Knotenpunkte geöffnet werden (indem ihnen mehr Zeit für die Ausführung gegeben wird), während die erforderlichen Schritte (und daher die Zeit) zur Erreichung eines Konsenses reduziert werden.

Die Bestellung bestimmt die Wahrheit. Die Ausführung offenbart sie einfach. Jeder kann die Daten ausführen, um die Wahrheit zu enthüllen, sobald ihre Reihenfolge festgelegt ist.

Das ist wahrscheinlich der Grund, warum Keone glaubt, dass letztendlich jede Blockchain eine asynchrone Ausführung nutzen wird, und es ist ein wichtiges Stück von Tolys Endgame-Vision für Solana:

"Die synchrone Ausführung erfordert, dass alle Knoten, die abstimmen und Blöcke erstellen, für die ungünstigste Ausführungszeit in jedem Block überdimensioniert sind... Konsensknoten können vor der Abstimmung weniger Arbeit leisten. Die Arbeit kann aggreGate.iod und in Batches zusammengefasst werden, wodurch sie effizient und ohne Cache-Fehler ausgeführt wird. Es kann sogar auf einem ganz anderen Rechner als den Konsensknoten oder Leadern ausgeführt werden. Benutzer, die eine synchrone Ausführung wünschen, können genügend Hardwareressourcen zuweisen, um jeden Zustandsübergang in Echtzeit auszuführen, ohne auf den Rest des Netzwerks warten zu müssen.

Derzeit spielen Validatoren alle Transaktionen so schnell wie möglich auf jedem Block nach und stimmen erst ab, wenn der vollständige Zustand des Blocks berechnet ist. Das Ziel dieses Vorschlags ist es, die Entscheidung über die Abstimmung über eine Gabelung von der Berechnung des vollständigen Zustandsübergangs für den Block zu trennen.

Es ist erwähnenswert, dass wir auch sicherstellen möchten, dass die Wahrheit für Benutzer leicht offenbart wird, und das bedeutet robuste Unterstützung für leichte Clients. Einige dieser Designs, die die Ausführung erheblich verzögern, würden dies jedoch herausfordernd machen (z.B., )Solana erwägt, es nur einmal pro Epoche zu verlangen) gegenüber anderen, die einen Zustandswurzel mit einer kürzeren Verzögerung bereitstellen (z. B. wie im hypersdk).

modularer Ansatz

Diese Entkopplung von Sequenzierung und Ausführung mag sehr vertraut klingen, denn dies ist auch der "modulare" Ansatz! Kombinieren Sie verschiedene Schichten, die sich auf verschiedene Aufgaben spezialisieren. Die Entkopplung von Sequenzierung und Ausführung ist das Schlüssel-Designprinzip von Lazy-Sequenzern (z. B. Astria):

• Sequenzierung - Sequenzknoten einigen sich nur auf die Reihenfolge und Verfügbarkeit von Rollup-Daten (d.h. sie sequenzieren, aber führen sie nicht aus).
• Ausführung: Rollup-Knoten führen ihre jeweiligen Daten aus, nachdem der Sequencer einen Commit für sie ausgeführt hat.

Der Hauptunterschied besteht darin, dass die integrierten Kettenknoten nach der Sequenzierung ausgeführt werden, während die faulen Sequenzer sie an eine völlig andere und vielfältige Gruppe von Akteuren weiterleiten. Faule Sequenzer sind völlig unwissend von den Zustandsmaschinen der Rollups. Sie führen diese Transaktionen niemals aus. Rollups übernehmen die asynchrone Ausführung.

Der integrierte Ansatz bietet eine nahtlosere Interoperabilität zwischen Benutzern der Ausführungsumgebung, reduziert jedoch die Flexibilität für App-Entwickler in eine bestimmte Richtung (z. B. benutzerdefinierte VMs, unterschiedliche Slot-Zeiten,Mit Konsens durchgesetzte anwendungsspezifische Transaktionspreisbildung und Reihenfolgeregeln, usw.). Der modulare Ansatz bietet Entwicklern mehr Flexibilität und Souveränität, um individuelle Domains zu besitzen, aber es ist schwieriger, die Erfahrung über sie hinweg zu vereinheitlichen.

In jedem Fall benötigen wir eine wirklich große und schnelle Pipe zur Bestellung von Daten.

Allerdings sollten Sie beachten, dass Sie technisch gesehen so ziemlich jede Kette als einen trägen Sequenzer verwenden können. Im Grunde genommen ist es nur ein großer Datenkanal am Ende des Tages. Ein Rollup kann seine beliebigen Daten einfach auf seine Basis-Ebene der Wahl werfen (ob das nun Ethereum, Bitcoin, Monad, etc. ist), um sie implizit als ihren Sequenzer zu nutzen. Rollup-Knoten können die Daten dann nachträglich asynchron ausführen.

Der Unterschied in der Praxis besteht darin, dass die Ketten, auf die wir tatsächlich als „faule Sequenzer“ verweisen, spezialisiert sind für diese Aufgabe, was viel leichter gesagt als getan ist (z.B. Unterstützung notwendiger Transaktionstypen, Bereitstellung einfacher Schnittstellen, Implementierung von MEV-Infrastruktur, schnelle Slot-Zeiten, zuverlässige Transaktionseinschlüsse, hohe Bandbreite usw.). Als Ergebnis führen Knoten für integrierte Ketten letztendlich die meisten der von ihnen enthaltenen Daten aus, während dies bei faulen Sequenzern hauptsächlich Roll-ups überlassen wird.

Das ist der Grund, warum es nicht so einfach ist wie "Warum verwenden wir nicht einfach Solana (oder eine andere Kette, wenn das nie das Designziel war) als Rollup-Sequenzer?" :

• Es fehlt die notwendige MEV-Infrastruktur, die speziell für Rollups entwickelt wurde (z. B. erforderliche PBS-Infrastruktur, Mechanismen zur interoperabilität über verschiedene Ketten, Komponist zur Abstraktion von Gebührenzahlungen für Rollup-Benutzer in Basisschicht-Gas-Token usw.)
• Fehlende native Transaktionstypen, die für Rollups zur Veröffentlichung von Daten konzipiert sind.
• im Wettbewerb gegen die native Ausführungsumgebung (z. B. ist sie explizit darauf ausgelegt, so viel wie möglich oder so viel wie möglich der bereitgestellten Daten zu verbrauchen, um weniger Platz und zuverlässige Transaktionseingabe usw. zu lassen).
• um allgemeine Entwicklerunterstützung und Priorisierung von Upgrades zu konkurrieren. Wahrscheinlich ziehen Sie es vor, zum Protokoll und zum spezialisierten Team zu gehen, das Ihnen bei der Einführung von Rollups hilft und ihr Protokoll speziell auf Sie abgestimmt hat, im Gegensatz zu dem, bei dem die meisten in der Community Rollups für ziemlich dumm halten.

Festigung des entkoppelten SMR

Können wir nun diese Probleme angehen, die durch die Lockerung dieser Einschränkungen entstehen? Kurz gesagt: Ja, naive Implementierungen führen zu Problemen wie der Zulassung ungültiger Transaktionen, die keine Gebühren zahlen können (was ein DOS-Vektor wäre, wenn es naiv implementiert würde), aber sie sind lösbar, sodass sie keine ernsthaften Probleme darstellen.

Wir werden uns hier nicht zu sehr in den Details verlieren, aber Sie können sich aufPatrick O'Grady'stolle Arbeit an@patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx, um entkoppelte SMR zu stärken, Toly'sasynchrones Ausführungsendspiel, und Monad's Implementierung der Versandkostenwie man diese Probleme angeht. erneut sehen die Lösungen für diese Probleme auf der modularen Seite und auf der integrierten Seite fast gleich aus.

Die Kurzfassung lautet, dass Sie einige viel schwächere Einschränkungen einführen können (im Vergleich zur synchronen Ausführung mit vollständiger Überprüfung), die die meisten Leistungsvorteile beibehalten, ohne eine Vielzahl von Angriffen zu ermöglichen.

In-Protocol- vs. Out-of-Protocol-Akteure

Wichtig ist, dass wir erkennen, dass die oben genannten Prozesse naiv nur die in-Protokoll-Akteure berücksichtigen. In der Realität spielen außerhalb des Protokolls befindliche Akteure eine große Rolle in diesen Transaktionslieferketten. Das ist das, was wir früher für (in-Protokoll) Validatoren im traditionellen SMR gesehen haben:

Quelle: @patrickogrady/rys8mdl5p#Making-the-case-for-decoupled-state-machine-replication-DSMR">vryx: Decoupled-State-Machine-Replikation stärken

in der Praxis jedoch, Fast alle Ethereum-Validatoren geben den Blockaufbau über MEV-Boost aus.mit den drei besten Bauherren (Biber, Titan und Rsync), die fast alle diese Blöcke bauen. Beachten Sie, dass Biber und Rsync OFAC-Transaktionen zensieren, während Titan dies nicht tut.

Quelle: mevboost.pics

Relais übernehmen die Replikation dieser Blöcke für den Rest des Netzwerks. Sie sind auch relativ kopflastig, da die vier wichtigsten Betreiber (Ultra Sound, Bloxroute, Agnostic und Flashbots) den Großteil der Blöcke übermitteln. Bloxroute und Flashbots zensieren OFAC-Transaktionen, während Agnostic und Ultra Sound dies nicht tun.

Quelle: mevboost.pics

Es sollte auch keine Überraschung sein, dass wir hier sehr ähnliche Trends bei der Optimierung der Latenz sehen, wie wir sie zuvor besprochen haben. Der Trend geht in Richtung Optimistische Relaisdie keine Blocküberprüfung mehr vor der Replikation durchführen, weil es einfach schneller ist. Träge Sequenzer können als incentivisierte Relaisnetzwerke betrachtet werden.

Diese Beispiele verdeutlichen, wie MEV die Gewinnanreize in diesen Systemen verändert. Validatoren lagern die Blockproduktion aus, weil erfahrene Entwickler mehr Wert erfassen können im Vergleich zu naiv sequenzierten Blöcken.

Selbst bei asynchroner Ausführung werden oft außerhalb des Protokolls stehende Blockproduzenten Transaktionen während des Aufbaus ausführen, um den Wert zu maximieren. Zum Beispiel ist es sehr wahrscheinlich, dass träge Sequenzer profitmaximierende Erbauer in irgendeiner Form von PBS haben werden. Die Tatsache, dass ein externer Blockproduzent immer dazu angeregt wird, einen Block vollständig auszuführen und den Wert zu optimieren, kann tatsächlich nützlich sein, wenn wir die Einschränkungen in der asynchronen Ausführung lockern. Dennoch müssten andere Validatoren nicht erneut ausgeführt werden, bevor sie abstimmen.

Universelle synchrone Komponierbarkeit

Definitionen

Können wir jetzt die Souveränität und Flexibilität nutzen, die modulare Chains bieten, aber sie zu einer integrierten Chain vereinen? Können wir unser Kuchen haben und ihn auch essen, oder bauen wir letztendlich nur Solana mit zusätzlichen Schritten?

Wenn Sie Leute darüber reden hören, wie man die Fragmentierung von Rollups behebt, haben Sie wahrscheinlich die großen Buzzwords gehört.universelle synchrone Zusammensetzbarkeit (USC). Allerdings war dies wahrscheinlich Ihre Reaktion:

Diese Begriffe werden alle mit unterschiedlichen Bedeutungen geworfen, und einige Begriffe werden oft fälschlicherweise synonym verwendet. Wir müssen einige konkrete Definitionen festlegen. Im Folgenden definieren wir die notwendigen Begriffe im Rahmen der Cross-Chain-Composability.

Beachten Sie, dass wir im weiteren Verlauf dieses Berichts auf "Rollups" eingehen werden, aber viele dieser Konzepte gelten auch für andere Arten von "L2s", wie z. B. Validien. Ich möchte einfach nicht wieder darüber streiten, was zum Teufel ein L2 ist..

in den folgenden Beispielen:

• r_eine= rollup a
• r_b = Rollup b
• t_a1 = Transaktion 1 auf r_eine
• t_b1 = Transaktion 1 auf r_b
• b_a1 = Block 1 auf R_ein
• b_B1= Block 1 auf r_b
  

Beachten Sie, dass wir hier die "Zeit" als "Slot-Höhe" definieren. Zeit ist rein relativ zum Beobachter. Die einzige objektive Vorstellung von Zeit, die wir haben, ist eine relative Ordnung durch einen gemeinsamen Beobachter, d.h. einen gemeinsamen Konsens (wobei dieser "Konsens" ein einzelner Akteur oder ein dezentraler Mechanismus sein kann).

Wenn beide Rollups einen Konsensmechanismus haben, der eine Reihenfolge vorgibt, können wir folgern:

• b_a1 kommt vor b_A2
• b_b1ist vor b_b2

jedoch die einzige Möglichkeit zu behaupten:

• b_a1ist gleichzeitig bei b_b1, und daher
• t_a1 und t_B1 synchron ablaufen, ist, wenn
• Sie teilen eine Reihenfolge, die durch einen gemeinsamen Konsens für diesen bestimmten Slot bereitgestellt wird.

Daher erfordert die definitionsgemäße synchrone Komponierbarkeit über Blockchains hinweg eine Art gemeinsamen Sequenzer für diese Slot-Höhe. Ketten ohne einen solchen können nur eine asynchrone Komponierbarkeit haben.

Beachten Sie jedoch, dass wir eine asynchrone atomare Komponierbarkeit haben können. Leider bemerke ich oft, dass Menschen die Begriffe "atomar" und "synchron" austauschbar verwenden, aber sie sind tatsächlich verschiedene Begriffe.

Damit das erledigt ist, schauen wir uns an, ob wir synchrone Komposabilität in modularen Ketten wieder einführen können. Wenn wir das können, dann könnte das den Wert integrierter Ketten für Gate.io zu erhöhen scheinen. Das ist die Kurzfassung, in die wir eintauchen werden:

• Gemeinsames Sequenzieren kann alleine synchronische atomare Einbeziehung bereitstellen (was viel schwächer ist als Komponierbarkeit).
• Die Kombination eines gemeinsam genutzten Sequenzers mit einem Mechanismus zur kryptografischen Sicherheit (z. B. Agglayer) kann diese Einschlussgarantie in tatsächliche Komponierbarkeit stärken.
• Die Sicherheitsgarantien, die der Agglayer für die Cross-Chain-Sicherheit bietet, können auch ohne Shared Sequencer (d.h. in der asynchronen Einstellung) verwendet werden.
• Wir werden sehen, wie wir auch die Auswirkungen der synchronen Komponierbarkeit simulieren können, wenn auch auf weniger kapitaleffiziente Weise, unter Verwendung von Kryptowirtschaft (direkte Besicherung von Cross-Chain-Transaktionen).

atomare Einbeziehung - gemeinsame Abfolge

Geteilte Sequenzierung bedeutet, dass für eine bestimmte Slot-Höhe eine einzige Einheit (der „Sequenzer“ bzw. der „Vorschlagende“) Monopolrechte zur Sequenzierung (d. h. zur Blockvorschlag für) mehrerer Ketten hat. Nochmals zur Verdeutlichung: Diese geteilten Sequenzer, von denen wir im Allgemeinen sprechen, sind...träge SequenzerSie erzielen Konsens über die Reihenfolge und Verfügbarkeit von Rollup-Daten, führen sie jedoch nicht aus. Sie sind völlig unwissend über die Zustandsmaschinen der Rollups.

Wie ich bereits geschrieben habeDies bedeutet, dass faule gemeinsame Sequenzer eine glaubwürdige Verpflichtung zur Einbeziehung von Cross-Chain-Bundles (d. H. Ein Satz von Transaktionen) bereitstellen können:

• atomarisch - entweder werden alle Transaktionen enthalten sein oder keine, und
• synchron - zur gleichen Zeit (Slot-Höhe)

Dies ermöglicht eine effizientere MEV-Extraktion durch Super Builder(d. h. Cross-Chain-Builder) bei der Durchführung von Cross-Chain-Aktionen, da sie nicht mehr das Risiko der Preissetzung berücksichtigen müssen, dass ein Bein des Cross-Chain-Bundles fehlschlagen könnte. Die Synchronizität hier kann ihnen implizit die Atomarität bieten.

Cross-Chain Unbundling

Nun, wie genau machen wir das, ohne dem Erbauer und/oder aktiven Vorschlagenden für den gemeinsamen Sequenzer vollständig zu vertrauen? Wenn wir einfach zwei unabhängig unterzeichnete Transaktionen senden (t₁ und t₂) für jeden Rollup könnte der gemeinsame Sequenzer immer noch entscheiden, nur eines davon einzuschließen oder das andere.

Zum Beispiel gibt es heute kein Konzept eines nativen Bundle-Formats im EVM, weshalb Sucher vollständig darauf vertrauen, dass Builder/Relais sie nicht entbündeln. Jeder, der ein Bündel unabhängig signierter Transaktionen sieht, bevor sie vom aktuellen Anführer bestätigt werden, kann sie entbündeln. Dies ist im Allgemeinen in Ordnung, da Builder und Relais dazu angeregt werden, ihren Ruf zu wahren und Sucherbündel zu schützen, aber wenn dieses Vertrauen gebrochen wird (oder sie von unehrlichen Teilnehmern getäuscht werden, um die Transaktionen offenzulegen), ...Das Entbündeln kann unglaublich profitabel sein.

Wir brauchen hier eine viel stärkere Sicherheitsgarantie, wenn wir echte Cross-Chain-Interoperabilität wollen. Es geht nicht nur darum, etwas Geld von einem Suchenden zu nehmen. Wenn Cross-Chain-DeFi-Verträge von der Annahme ausgehen würden, dass die Cross-Chain-Bundles respektiert werden, dieses Vertrauen dann aber gebrochen wird, wären die Ergebnisse für diese Protokolle katastrophal (z. B. könnten Sie in einem Burn-and-Mint Cross-Chain-Bridge-Bundle das Burn-and-Minting-Geld auf der anderen Seite weglassen).

Wir benötigen eiserne Sicherheitsgarantien, um die Interoperabilität zwischen Ketten umzusetzen. Das bedeutet, dass wir ein Transaktionsformat definieren müssen, das sicherstellt, dass mehrere Transaktionen in einem Cross-Chain-Bundle zusammengefasst sind. Wenn eine Transaktion ohne die andere enthalten ist, benötigen wir eine Sicherheitsgarantie, dass die enthaltene Transaktion ungültig ist.

Das bedeutet, dass wir eine neue Transaktionsstruktur für Cross-Chain-Bundles erstellen müssen, die nicht möglich ist.unbündelteDie naive Lösung lautet: "Lassen Sie uns einfach einen neuen Transaktionstyp für diese Rollups erstellen", aber das ist nicht so einfach. Es würde VM-Änderungen für diese Rollups erfordern, wodurch die Abwärtskompatibilität verloren ginge. Sie würden auch die Rollups eng miteinander verknüpfen, indem Sie ihre Zustandsmaschinen so ändern, dass jede Transaktion nur zusammen mit der anderen gültig ist.

Allerdings gibt es einen saubereren Weg, dies zu tun. Sie können jede Transaktion im Bundle auch den Bundle-Hash signieren lassen und den Hash-Digest in ein freies Transaktionsfeld (z. B. Calldata in EVM) anhängen. Das Rollup muss seine Ableitungspipeline anpassen, um dies zu überprüfen, aber die VM kann unverändert bleiben. Mit dieser Funktion können Rollup-Benutzer Cross-Chain-Bundles einreichen, bei denen sie sicher sind, dass sie nicht aufgeschnürt werden können. Der Versuch, dies zu tun, würde sie ungültig machen.

Quelle: Ben Fisch

Inklusionsgarantien vs. staatliche Garantien

Mit dem oben Genannten haben wir nun festgestellt, wie ein träge gemeinsamer Sequenzer:

• kann eine glaubwürdige Verpflichtung zur atomaren synchronen Einbeziehung von Cross-Chain-Bundles bereitstellen (d. h. dass alle Transaktionen eingeschlossen werden oder keine)
• kann keine glaubwürdige Verpflichtung hinsichtlich des resultierenden Zustands aus solchen Transaktionen bieten (z. B. ist es möglich, dass beide Transaktionen enthalten sind, aber eine andere Transaktion davor landet und dazu führt, dass sie rückgängig gemacht wird)

Leider ist die atomare Einbindung allein eine viel schwächere Garantie. Diese Verpflichtung zur atomaren Einbindung reicht aus, damit der Builder großes Vertrauen haben kann, dass der von ihnen erstellte Cross-Rollup-Block den gewünschten Endzustand erzeugt, wenn er bestätigt wird. Der Builder kennt zwangsläufig den resultierenden Zustand des Blocks, da er ihn ausgeführt hat, um ihn zu erstellen.

Wir haben immer noch ein Problem - wie können alle anderen mit Sicherheit wissen, wie der Stand sein wird?

Betrachten Sie ein Beispiel:

• Wir haben zwei Rollups (RA und RB), die sich denselben Lazy-Sequencer teilen
• Ich möchte eine Burn-and-Mint-Brücke zwischen Ra → Rb verwenden, die gleichzeitig auf Ra brennt und auf Rb prägt.
• Der Prägebrückenvertrag auf RB benötigt eine Garantie für den Zustandsübergang auf RA (Burn), um auf RB zu prägen. Der Vertrag kann jedoch zum Zeitpunkt der Ausführung nicht wissen, ob das Token tatsächlich auf RA verbrannt wurde, da er keinen Zugriff auf den Zustand von RA hat.

Wenn wir ein ordnungsgemäßes Bündel eingereicht haben, kann der faule Sequenzer garantieren, dass die Brenntransaktion in den Transaktionsstrom für RA aufgenommen wurde. Sie wissen jedoch nicht, ob möglicherweise eine andere Transaktion vor ihr gelandet ist, die sie ungültig gemacht hat (was bedeutet, dass die Token tatsächlich nicht verbrannt wurden).

Die einfache gemeinsame Nutzung eines Lazy Sequencers reicht nicht aus, um es Ketten zu ermöglichen, während der Bundle-Ausführung auf die Zustände der anderen zuzugreifen. Synchrone Composability erfordert, dass der Zustandsautomat jeder Kette zum Zeitpunkt der Ausführung auf den Zustand der anderen Kette zugreifen kann (z. B. muss der Bridge-Vertrag selbst auf RB den Zustand von RA kennen). Diese Fähigkeit ist genau das, was die vollständige Zusammensetzbarkeit innerhalb einer einzigen integrierten Kette ermöglicht.

Der Bauherr kann den Verträgen nicht einfach sagen: „Vertrau mir, Bro, das wird schon klappen.“ Wir sehen, dass die atomare Inklusion ein nützliches Werkzeug für Suchende ist, die darauf vertrauen, dass die Bauherren ihre Bündel ordnungsgemäß ausführen, aber sie ist nicht ausreichend, um die Cross-Chain-Interoperabilität abzustrahieren.

Um dies zu beheben, müssen wir einen anderen Mechanismus zusätzlich zur gemeinsamen Sequenzierung hinzufügen:

Wie bereits erwähnt, weiß der Ersteller persönlich, wie der resultierende Zustand aussehen wird, wenn das Bündel atomar aufgenommen wird. Wie können sie jedoch eine glaubwürdige Verpflichtung abgeben, um alle anderen davon zu überzeugen, wie der resultierende Zustand aussehen wird, wenn ihre Transaktionen enthalten sind?

sie haben im Wesentlichen zwei Optionen:

• Kryptoökonomisch - Der Bauherr kann eine große Menge an Kapital einsetzen, um seine Cross-Chain-Aktionen vollständig zu besichern. Dies ist oft ineffizient und möglicherweise simulierte Komponierbarkeit., aber es ist ein hilfreiches Beispiel, um die Funktionalität zu demonstrieren.
• kryptografisch - wir können einen Mechanismus haben, der kryptografische Gewährleistungen bietet, dass die Transaktionen den gewünschten Zustand erzeugen werden.

kryptowirtschaftliche Sicherheit - Builder Bonds

Lassen Sie uns anhand eines Beispiels durchgehen, um zu sehen, wie die Kryptowirtschaft die Auswirkungen der synchrone Komponierbarkeit simulieren könnte. Das klassische Beispiel, das verwendet wird, ist das eines Cross-Chain-Flashkredit. Ich möchte einen Flash-Kredit auf RA aufnehmen, ihn für eine Arbitrage auf RB verwenden und ihn in derselben Slot auf RA zurückgeben. Dies ist möglich, wenn diese DeFi-Protokolle hier benutzerdefinierte Cross-Chain-Funktionalität bereitstellen, die wir „Bankverträge“ nennen, auf jeder Seite:

Nun zum Sicherheitsproblem - der Vertrag über ra und rb muss die Kettenzustände des anderen kennen, um dies sicher zu tun, aber wir haben nichts unternommen, um dies zu lösen. Die kryptökonomische “Lösung” hier ist eigentlich ziemlich brachial - Sie lassen den Super Builder als Liquiditätsanbieter fungieren und den vollen Wert des Flash-Darlehens bereitstellen. Wenn die Transaktionen fehlschlagen würden, behält das Kreditprotokoll einfach ihren Anteil. Sie können sehen, warum dies keine besonders zufriedenstellende “Lösung” ist.

Kryptographische Sicherheit - Agglayer

was es ist

das AggLayerist ein dezentrales Protokoll, das drei wesentliche Vorteile bietet:

1. Sicherheit für schnelle Cross-Chain-Komponierbarkeit - es erzeugt zk-Beweise, die Aggchains kryptographische Sicherheit für atomare Cross-Chain-Interoperabilität bei geringer Latenz (d. h. schneller als Ethereum-Blöcke) in asynchronem oder synchronem Betrieb bieten. Das Design isoliert Fehlerketten einzigartig, so dass es jede Ausführungsumgebung und Prover unterstützen kann.
2. Kreuzketten-Asset-Fungibilität - es verfügt über eine gemeinsame Brücke, um die Asset-Fungibilität über Aggchains (d. h. die Chains, die es verwenden) sicherzustellen, damit Benutzer nicht mit einer Vielzahl von verpackten Assets enden. Der Brückenvertrag befindet sich auf Ethereum, das ist die Abwicklungsschicht. (Beachten Sie jedoch, dass verschiedene Ketten aufgrund der Implementierung immer noch unterschiedliche Sicherheitsannahmen haben können, was weiter unten genauer erläutert wird.)
3. Gasoptimierung - es aggregiert Proof für Aggchains, um fixe Kosten über viele Chains zu amortisieren. Der gemeinsame Einzahlungsvertrag optimiert auch die Gas kosten, indem er direkte L2-zu-L2-Überweisungen ohne Berührung des L1 ermöglicht.

Quelle: Brendan Bauer, Aggregierte Blockchains

Um zwei häufige Missverständnisse darüber zu klären, was der Agglayer nicht ist:

• Der Agglayer ist nicht nur ein Dienst zur Aggregierung von Gate.io-Beweisen - Dies ist verwirrend, weil es tatsächlich AggreGate.io-Beweise gibt und sie "Aggregation" in den Namen der Sache setzen. Die Aufgabe von Agglayer besteht jedoch darin, Ketten zu aggregieren. Die wichtige Unterscheidung für den Zweck dieses Beitrags besteht darin, dass die alleinige Aggregation von Beweisen nichts dazu beiträgt, die Sicherheitsgarantien zu erreichen, die wir hier benötigen.
• Die Agglayer und gemeinsame Sequenzer sind keine gegensätzlichen Designs - während sie nicht zusammen verwendet werden müssen, Sie sind tatsächlich perfekte Ergänzungen die unterschiedliche Garantien bieten. Der Agglayer ist völlig agnostisch in Bezug auf die Sequenzierung von Aggchains. Es verarbeitet keine der Nachrichten zwischen den Chains, so dass es sich explizit auf die Koordinationsinfrastruktur des freien Marktes (z. B. Relays, Builder, isolierte Sequenzer, gemeinsam genutzte Sequenzer usw.) verlässt, um die Ketten zusammenzustellen.

Lassen Sie uns jetzt durchgehen, wie es funktioniert.

Brückenbau ist schlecht

Heute ist es schwierig, eine Brücke zwischen Rollups zu schlagen. Nehmen wir an, Sie möchten ETH zwischen zwei Ethereum Optimistic Rollups ORU übertragen._eine und oru_b:

• über die native Brücke - Sie werden teure Ethereum L1-Gebühren zahlen (d.h. Überbrückung von Oru_eine → ethereum + ethereum → oru_b) und die Rundreise wird über eine Woche dauern (wegen des fehlersicheren Fensters).
• Direkter Rollup → Rollup - das eingewickelte Eth, das Sie auf Oru erhalten_bwäre tatsächlich nicht fungibel mit dem nativen ETH für oru_eine. Die Pfadabhängigkeit, verschiedene Brücken zu überqueren, zerstört die Fungibilität. Zum Beispiel, wenn die ORU_aDie Brücke wurde entleert, dann würde das gewrappte Eth, das Sie zu Orub überbrückt haben, nicht unterstützt werden, während das native Eth auf Oru bleibt._bwäre in Ordnung. Liquiditätsfragmentierung ist schlecht, also ist dies nichts, was Benutzer wollen. In der Praxis überbrücken Benutzer direkt über Liquiditätsanbieter. Jemand wird Ihnen das Eth auf Oru vorlegen._bund behalten Sie Ihr Geld auf oru_eine. Sie können über die Native Bridge abheben und warten, aber sie werden teure Gebühren für das Risiko und die hohen Kapitalkosten berechnet.

Man könnte denken, dass zk rollups dies von Anfang an lösen, aber das tun sie tatsächlich nicht. Naive Implementierungen erfordern immer noch, dass Sie l1-Transaktionen einreichen, was wiederum teuer und in der Regel ziemlich langsam ist (z. B. aufgrund von Ethereum-Endgültigkeitszeiten, Proof-Generierungszeiten, wie oft Beweise in der Praxis veröffentlicht werden usw.).

Benutzer möchten sich nicht damit befassen müssen. Sie möchten einfach Geld haben und Apps verwenden. Die Brücke sollte vollständig abstrahiert werden - Vermögenswerte sollten austauschbar sein und sich schnell, kostengünstig und sicher bewegen.

Hier kommt das Teilen eines Brückenvertrags ins Spiel. Ein gemeinsam genutzter Brückenvertrag öffnet die Tür für Ketten, die ihn nutzen, um direkt zwischen einander zu überbrücken, ohne durch den L1 zu gehen.

Tokens können auch über Aggchains hinweg austauschbar sein. und über die Brücke ETH von r_eine → r_boder r_c → r_bverbrennt und prägt denselben Token. Es handelt sich nicht um ein Lock-and-Mint-Wrapper-Asset. Es handelt sich um native Eth. Dies ist möglich, da alle Vermögenswerte zusammen hinterlegt und über die einheitliche Brücke abgewickelt werden. Dies ist heute ein wesentlicher Schmerzpunkt für L2s, der angegangen werden muss.

Beachten Sie jedoch, dass ein Benutzer, der ETH auf R hält,_einevs. r_bKönnte ein unterschiedliches Risikoprofil haben, wenn die verschiedenen Chains unterschiedliche Verifizierer verwenden (z.B. wenn Sie von einer sicheren Chain zu einer mit einem Schaltungsfehler gewechselt haben). Risikoprofile bleiben unverändert, wenn gemeinsame Standards verwendet werden (was in der Praxis heute die Norm ist). Eine noch einheitlichere Standardisierung und formale Verifizierung wird dies im Laufe der Zeit nur verbessern, auch wenn heterogene Domänen hinzugefügt werden.

pessimistische Beweise

AggChains reichen ihre Zustandsaktualisierungen und Nachweise bei den staked Knotenpunkten von AggLayer ein, die sie anordnen, Verpflichtungen für alle Nachrichten generieren und rekursive Nachweise erstellen. Die AggLayer erzeugt dann einen einzelnen AggreGate.iod zk-Nachweis (den sie "" nennen.pessimistischer Beweis") für alle aggchains auf Ethereum abzurechnen. Da die Beweisaggregation hier die Kosten über beliebig viele Ketten amortisiert, ist es aus Kostengründen praktisch, sie schnellstmöglich auf Ethereum zu posten, um sie abzuwickeln. Das pessimistische Proof-Programm ist in regulärem Rust-Code geschrieben und verwendet,Succinct’s zkvm sp1für eine einfache Entwicklung und hohe Leistung.

Diese pessimistischen Beweise erzwingen:

• Interchain Accounting - belegt, dass alle Brückeninvarianten eingehalten werden (d.h. keine Kette kann mehr Token abheben, als auf sie eingezahlt wurden).
• Die Gültigkeit von Aggchains – beweist, dass jeder Chain ihren Zustand wahrheitsgemäß aktualisiert hat, ohne Chain-Gleichwertigkeiten oder ungültige Blöcke.
• Cross-Chain-Sicherheit - beweist, dass Zustandsaktualisierungen, die das Ergebnis von Cross-Chain-Transaktionen bei Latenzzeiten unterhalb von Ethereum sind, konsistent sind und sicher auf Ethereum L1 abgerechnet werden können. Dies umfasst die erfolgreiche atomare Ausführung von Cross-Chain-Bundles sowohl synchron als auch asynchron.

Damit stellt die Agglayer sicher, dass die Abwicklung nur dann auf Ethereum erfolgt, wenn die oben genannten Bedingungen erfüllt sind. Wenn sie nicht erfüllt sind, können die entsprechenden Ketten nicht abwickeln. Als solches kann die Agglayer einem Koordinator (z. B. einem gemeinsamen Sequencer oder Builder) erlauben, Nachrichten zwischen Ketten mit geringer Latenz weiterzuleiten, ohne diesem Koordinator für die Sicherheit vertrauen zu müssen.

schnelle & sichere Cross-Chain-Interoperabilität

Aggchains können die hier bereitgestellten Garantien sowohl in den asynchronen als auch in den synchronen Interoperabilitätseinstellungen verwenden, um Einschränkungen für die Gültigkeit von Blöcken in Bezug auf andere Rollups auszudrücken.

Dies würde es Benutzern ermöglichen, Cross-Chain-Bundles einzureichen, die atomar auf beiden Seiten erfolgreich ausgeführt werden müssen. Nicht nur die atomare Inklusion. Tatsächlich erzwingen Sie, dass der resultierende Zustand erfolgreich sein muss. Dies ist genau das, was wir als Mangel bei den atomaren Inklusionsgarantien eines gemeinsamen Sequenzers beschrieben haben.

Quelle: Brendan farmer, Aggregierte Blockchains

Nehmen wir unser Beispiel von vorhin:

• Wir haben zwei Rollups (r_einund r_b) den gleichen trägen Sequenzer und die Agglayer gemeinsam nutzen
• Ich reiche ein Cross-Chain-Bundle ein, um gleichzeitig Eth auf R zu verbrennen_eine und prägen Sie ETH auf R_b
• Ein Super-Builder baut einen Block für beide Ketten, während der gemeinsame Sequenzer dies tut, zu dem sich der gemeinsame Sequenzer verpflichtet
• der Prägebückenvertrag auf r_bkann optimistisch das ETH prägen, abhängig vom Zustand von r_ein(in diesem Fall erfolgreich das Eth verbrennen ausführen)
• Diese Blöcke und Beweise werden an die Agglayer übermittelt, die beweist, dass beide Ketten auf gültige Weise gehandelt haben (sowohl unabhängig voneinander als auch in Bezug aufeinander) und dass die gemeinsame Brücke sicher verwendet wurde.

Damit dies erfolgreich zu Ethereum abgewickelt werden kann, müssen beide Teile des Bündels ordnungsgemäß ausgeführt worden sein. Wenn eine der Seiten versagt, wären die Blöcke ungültig und könnten nicht abgewickelt werden. Das bedeutet, dass wenn zum Beispiel der gemeinsame Sequenzer einen Block genehmigt hat, bei dem das ETH nicht auf R verbrannt wurde,_einaber geprägtes Eth auf r_bWenn dieser Block dann umgeordnet würde, würde dies die Sicherheit aller Ketten gewährleisten und verhindern, dass betrügerische Cross-Chain-Aktionen abgewickelt werden.

Es gibt zwei Punkte, die Sie in Bezug auf diese Reorgs beachten sollten:

• Sie wären unglaublich kurz, weil sie sofort erkannt und nachgewiesen würden.
• Sie können nur auftreten, wenn der Koordinator (z. B. Sequenzer und/oder Erbauer) der Kette, mit der Sie verbunden sind, aktiv bösartig ist.

Diese Reorgs sollten durch die oben genannten Punkte äußerst selten und minimal sein, aber aufgrund dessen werden Aggchains die volle Kontrolle darüber haben, mit welchen Chains sie atomar zusammengesetzt werden möchten und unter welchen Vertrauensannahmen. Zum Beispiel, r_einekönnte einen Kettenzustand von r akzeptieren_bbasierend auf dem Konsens ihres Sequenzers zu komponieren, aber für r_cEs könnte auch einen Nachweis verlangen und dafür r einreichen wollen._dVielleicht möchten sie, dass sie alle Cross-Chain-atomaren Abhängigkeiten kryptoökonomisch absichern. Jede Kette kann hier ihre eigenen anpassbaren Tradeoffs für geringe Latenz und Lebendigkeit vornehmen. Agglayer bietet einfach die maximal flexible und minimal anmaßende Grundlage für Ketten, um sichere Cross-Chain-Interaktionen zu haben.

Sie können auch hier sehen, warum ein solches Design in der Praxis nicht mit einem fehlersicheren Design kompatibel ist. In der Theorie könnten sie dies tun, aber in diesem Fall wäre es möglich, unglaublich tiefe Reorgs zu erleben. Das schnelle Beweisen und Abwickeln aller Ketten begrenzt den Worst Case auf sehr kurze Zeit, was auch als natürlicher Abschreckung für jeglichen böswilligen Versuch dient.

Fehlerisolierung für heterogene Prüfer

Wichtig ist, dass der Agglayer einzigartig komplett heterogene Ketten ermöglicht. Sie können eine Aggchain mit beliebiger benutzerdefinierter VM, Prover, DA-Layer usw. haben, während Sie sicher eine Brücke mit allen teilen.

Wie ist das jedoch möglich? Der Grund, warum dies normalerweise nicht akzeptabel ist, liegt darin, dass ein einziger fehlerhafter Teilnehmer (z. B. mit einem Schaltungsfehler) normalerweise eine Brücke täuschen und sie aller Mittel berauben könnte. Nun, das ist der Punkt, an dem der oben erwähnte Interchain-Buchungsnachweis ins Spiel kommt. Diese Nachweise stellen sicher, dass die Brückeninvarianten eingehalten werden, sodass selbst im Fall eines unsound Beweisers nur die auf die betroffene Kette eingezahlten Mittel abgezogen werden könnten. Der Fehler ist vollständig isoliert.

glaubwürdige Neutralität

Diese Art von Infrastruktur profitiert in hohem Maße von einer glaubwürdigen Neutralität, weshalb die Vollständig quelloffener Code für Agglayer ist neutrales Gebiet.In ähnlichem Geist wird der Agglayer ETH als alleiniges Gas-Token verwenden, um Gebühren für den Proof-Aggregation zu zahlen.

Es ist sicherlich nicht perfekt. Besonders am Anfang wird es nicht vollständig glaubwürdig neutral sein. Auf dem Weg zur endgültigen Unveränderlichkeit und Verankerung als öffentliches Gut wird es wahrscheinlich Vertragsaktualisierbarkeit geben.

Das gesagt, es muss nicht perfekt glaubwürdig neutral sein, nichts ist. (Wir werden dies unten noch einmal mit basierten Rollups sehen.) In der Praxis bietet es wahrscheinlich die überzeugendste technische konkurrierende Vision und nimmt eine absichtlich minimalistische Haltung gegenüber Lock-in und Mieteinnahmen ein. Das Ziel ist es, Aggchains zu ermöglichen, so viel Souveränität wie möglich zu bewahren, und gleichzeitig in der Lage zu sein, vertrauensminimierte Cross-Chain-Kompatibilität abstrakt zu gestalten.

AGGchains benötigen keine bestimmte VM, Ausführungsumgebung, Sequenzer, DA-Schicht, Staking-Token, Gas-Token oder gemeinsame Governance. Ketten können gehen, wann sie wollen. Es gibt keine Anforderungen an die Umsatzbeteiligung. Sie müssen nicht als L3 in der Kette einer anderen Person bereitstellen.

Die Gründe, L3s zusätzlich zu den allgemeinen L2s zu starten, waren meiner Meinung nach meist Pflaster, während Architekturen, die dem Agglayer ähneln, gebaut werden. Um es klar zu sagen, das ist ein absolut triftiger Grund, sie heute zu starten. Der V1 AGGLAYER ist nur ein einfacher Shared-Bridge-Vertrag. Die V2 mit Proof-Aggregation und der Möglichkeit, sichere Interoperabilität mit geringer Latenz zu erzielen, ist noch nicht einmal live. Sie können nicht erwarten, dass die Leute jahrelang warten, wenn sie die Dringlichkeit haben, heute etwas zu versenden, das ihnen die schnellste Verbreitung bringt.

Echtzeitbeweis

Auch wenn es noch einige Jahre dauern wird, bis es in Umgebungen mit geringer Latenz praktikabel ist, sollten wir beachten, dass Echtzeittests möglicherweise auch zusammen mit der gemeinsamen Sequenzierung für die Cross-Chain-Sicherheit verwendet werden könnten. Es ist auch einfach cool, also werden wir es kurz behandeln. Genauer gesagt bezieht sich "Echtzeit"-Proving auf Testzeiten, die kürzer sind als die Slot-Zeiten der betreffenden Kette. Betrachten wir noch einmal das Beispiel der Cross-Chain-Mint-and-Burn-Bridge:

• Wir haben zwei Rollups (r_eine und r_b) mit demselben Lazy Sequencer
• Ich möchte eine Verbrennungs- und Prägebrücke zwischen ra → rb verwenden, die gleichzeitig auf ra verbrennt und auf rb prägt.
• Der Super Builder erstellt einen Cross-Chain-Block, der eine Gruppe dieser Cross-Chain-Transaktionen enthält. Innerhalb der Blöcke enthält der Builder einen Nachweis für den Zustandsübergang, der im anderen Rollup enthalten ist.

Wir hatten bereits die Garantie der synchronen atomaren Bündeleinbindung des gemeinsamen Sequenzers, und jetzt kann jeder Vertrag einen Nachweis des Zustands der anderen Kette überprüfen, um sicherzustellen, dass er erfolgreich ausgeführt wird.

Für das Proofing in Echtzeit möchten wir idealerweise, dass die Testzeit nur einen kleinen Bruchteil der gesamten Slot-Zeit ausmacht, wodurch das "Synchronitätsfenster" maximiert wird. Dies ist der Teil der Slot-Zeit, in dem Sie Transaktionen verarbeiten können, die synchron Cross-Chain arbeiten würden, da Sie genügend Zeit im Slot einplanen müssen, um den Proof zu erstellen und ihn im Block zu landen.

Quelle: Justin Drake, Echtzeit-Beweis

Beachten Sie, dass wir hier implizit Builder und Prover zusammenführen oder kollidieren würden. Es besteht ein klarer Anreiz für Builder, die Nachweissgeschwindigkeit zu optimieren, um bis zur letzten Sekunde aufzubauen und so viel wie möglich in ihrem Block unterzubringen.

Quelle: Justin Drake, Echtzeit-Beweisführung

Wenn dieser hohe Anreiz für Echtzeit-Nachweise in den kommenden Jahren tatsächlich realisiert wird, sollten wir auch beachten, dass dies natürlich überhaupt nicht freundlich gegenüber dezentralen Nachweisen ist. Die Nachweiser müssten relativ zentralisiert sein, da sie sich mit den Erbauern zusammenschließen oder zusammenarbeiten.

Zusammenfassung

Universelle synchrone Komposabilität ist wirklich cool, aber es ist nicht ganz klar, wie wertvoll sie tatsächlich ist. Das Internet ist vollständig asynchron und man würde es nie merken. Das liegt daran, dass es schnell ist und die Komplexität abstrahiert wird. Das wollen alle Benutzer.

Ich erwarte, dass der größte Teil des Nutzens von etwas wie Agglayer nicht nur in der synchronen Einstellung liegt. Vielmehr ist es die Tatsache, dass es als eine Form der Cross-Rollup-Chain-Abstraktion fungieren kann, um viele Chains so zu gestalten, dass sie sich für den Benutzer wie eine einzige anfühlen (z.B. fungible nativ Assets, nativ Cross-Chain-App-Funktionalität, schnelle Interoperabilität usw.).

Synchrone Komponierbarkeit ist klar finanziell wertvoll (z.B. ermöglicht Liquidationen, effizientere Arbitrage, effizientere Refinanzierung mit Flash-Krediten). Jedoch, ähnlich wie das Internet asynchron ist und gut funktioniert, ist Tradfi natürlich asynchron. Es ist vernünftig, noch besser als Tradfi sein zu wollen, aber wir sollten klarstellen, dass universelle Synchronität keine Voraussetzung für eine gute Ausführung ist. Es gibt auch einen realen Kostenfaktor beim Aufbau und Bereitstellen synchroner Infrastruktur.

Meiner Meinung nach ist das beste Argument für die Notwendigkeit von USC, dass es in der Praxis zu einer besseren UX und DevEx führt. Es ist unmöglich, den enormen Nutzen zu leugnen, den dies für Ökosysteme wie Solana gebracht hat. Allerdings hoffe ich, dass dies eher ein heutiges Problem ist und kein dauerhaftes Problem.

Die einfache Tatsache ist, dass es auch für jeden in diesem Stadium einfach schwierig ist, darüber nachzudenken. Es ist nicht so, dass in der Krypto-Welt alles synchron oder alles asynchron ist. Ich denke, wir müssen grundsätzlich das Letztere lösen und uns darauf zubewegen, aber beides kann ad hoc existieren.

Ethereum-basierte Rollups

Ok, jetzt sollten wir eine gute Vorstellung vom Lösungsraum haben, um Fragmentierung in Rollups anzugehen. Die nächste Frage ist, wie sollten wir die Basisschicht in all dem einbeziehen? Was ist Ethereums Rolle hierbei?

Wir verwenden im Folgenden folgende Abkürzungen:

• BL - Basisschicht
• br - basierter Rollup
• Preconfs - Vorbestätigungen

Sofern nicht anders angegeben, handelt es sich bei dem fraglichen BL, über das wir sprechen werden, um Ethereum, und die BRs sind Ethereum-BRs. Die Grundkonzepte gelten jedoch im Großen und Ganzen, da Sie BRS überall starten können.

Vanille-basierte Rollups

Die ersten Rollup-Implementierungen vor mehreren Jahren waren tatsächlichgeplant zu sein, aber waren zugunsten zentralisierter Sequenzer aufgegeben für geringe Latenz und hohe Effizienz. Was wir heute als basierte Sequenzierung bezeichnen, hat Vitalik als „totale AnarchieZu der Zeit war es relativ unpraktisch und ineffizient, bevor die Ethereum-PBS-Infrastruktur (mit erfahrenen Baumeistern) evolvierte.

Brs wurden im März 2023 wieder ins Rampenlicht gebracht,wo sie wie folgt definiert wurden:

"Ein Rollup gilt als basiert oder l1-sequenziert, wenn seine Sequenzierung durch das Basis-l1 gesteuert wird. Konkreter ausgedrückt ist ein basierter Rollup ein Rollup, bei dem der nächste l1-Vorschlagsteller in Zusammenarbeit mit l1-Suchenden und -Erstellern das nächste Rollup-Block ohne Erlaubnis als Teil des nächsten l1-Blocks einbeziehen kann."

Sie sollten die folgenden Vorteile anbieten:

"Die Abfolge solcher Rollups - basierte Sequenzierung - ist maximal einfach und erbt die L1-Lebendigkeit und Dezentralisierung. Darüber hinaus sind basierte Rollups besonders wirtschaftlich mit ihrer Basis-L1 ausgerichtet."

Speziell erhalten Sie die Echtzeit-Sicherheit von Ethereum:

"Sie erben den Zensurwiderstand und die Lebendigkeit von Ethereum. Sie haben also nicht nur die Abwicklungsgarantien von Ethereum, sondern auch den Zensurwiderstand, den Echtzeit-Zensurwiderstand, nicht den verzögerten, den Sie mit der Notausgang kennen, sondern den Echtzeit-Zensurwiderstand."

Wenn Sie eine basierte Rollup sind, ist dies die logische Konstruktion, sobald Sie eine Basisschicht gewählt haben.:

„Ethereum maximiert diese beiden Eigenschaften, Sicherheit und glaubwürdige Neutralität, es ist fast die Definition eines Rollups, richtig... Ein Rollup ist einer, der bereits in die Sicherheitsannahme von Ethereum investiert hat. Sie fügen keine neue Sicherheitsannahme hinzu. Sie fallen nicht auf das schwächste Glied zurück. Sie verwenden einfach die bestehende Sicherheitsannahme. Und zweitens haben Sie Ethereum bereits als glaubwürdig neutrale Plattform akzeptiert, sonst hätten Sie sich für eine andere Blockchain entschieden. Und jetzt können Sie sich fragen, warum nicht jeder einfach die Layer-One-Sequenzierung verwendet?“

In ihrer einfachsten Form können BRS sicherlich die obigen Designziele erreichen. Wenn das Rollup seinen eigenen Sequenzer nicht implementiert, entscheidet implizit der aktuelle Ethereum-Vorschlaggeber, was alle 12 Sekunden (Ethereums Slot-Zeit) eingeschlossen wird.

jedoch geht die basierte Sequenzierung immer noch mit Kompromissen einher, was genau das ist Warum Rollups in der Regel ihren eigenen Sequenzer implementieren:

• Schnelle Preconfs - Rollup-Benutzer möchten nicht mehr als 12 Sekunden auf Ethereum-Blöcke warten.
• Sichere Vorbestellungen - Manchmal kommt es zu Ethereum-Block-Reorgs, sodass Benutzer noch länger warten müssen, um sicher zu sein, was Benutzern wiederum nicht gefällt. Sequencer können Vorbestellungen geben, die nicht von nicht abgeschlossenen Ethereum-Blöcken abhängen und somit selbst dann keine Reorg benötigen, wenn Ethereum selbst eine kurze Reorg erlebt.
• Effizientes Stapelbuchen - Sequenzer können eine große Menge Daten stapeln, komprimieren und in einem kostengünstigen Verfahren periodisch an das BL senden (z. B. um eine vollständige BLOB-Nutzung zu gewährleisten).

rollups auf der Basis von vorbereiteten Konferenzen

Also, können wir den Kuchen haben und ihn auch essen? Eingeben basierte Preconfs.

Wir werden die Intuition hinter basierten Preconfs hier relativ kurz erklären, damit wir brs + Preconfs vs. traditionelle Rollups vergleichen können. Später werden wir zurückkommen, um Preconfs im Allgemeinen genauer zu analysieren (d. h. sowohl br Preconfs als auch bl Preconfs bei Ethereum L1-Transaktionen).

Die Kernidee ist, dass br Preconfs von bl Anbietern stammen müssen. Um Preconfs bereitzustellen, müssen diese Anbieter eine gewisse Sicherheit hinterlegen (z.B. Restaking) und sich zusätzlichen Slashing-Bedingungen unterwerfen (d.h. dass die von ihnen bereitgestellten Preconfs tatsächlich wie versprochen onchain kommen). Jeder Anbieter, der dazu bereit ist, kann als br Sequenzer fungieren und Preconfs bereitstellen.

Wir sollten beachten, dass Antragsteller (d. h. Validatoren) tatsächlich erwartet werden, diese Rolle der Bereitstellung von Vorbestellungen an spezialisiertere Einheiten, die als „Gate.ioways“ bekannt sind, zu übertragen. Die Bereitstellung von Vorbestellungen erfordert eine relativ anspruchsvolle Einheit, und Ethereum möchte, dass die Antragsteller unerfahren bleiben.

Es wird jedoch erwartet, dass bestehende Relais auch diese Rolle übernehmen werden. Das Gate.ioway würde nur als Schnittstelle zwischen dem Benutzer und dem Relais dienen, sodass die Hinzufügung einer weiteren unabhängigen Entität nur Komplexität und Latenz hinzufügt (obwohl die Latenz auch durch Co-Location behoben werden könnte). Das Relais wird bereits von den Erbauern und Vorschlagenden vertraut, daher würden wir hier eine weitere Vertrauensanforderung von den Benutzern an sie hinzufügen.

Beachten Sie, dass die Validatoren derzeit als Ethereum-Block-Proposer fungieren, es wird jedoch überlegt, ein Upgrade durchzuführen, bei dem das Protokoll selbst die Vorschlagsrechte direkt versteigert.AusführungsauktionenDies würde es anspruchsvollen Entitäten ermöglichen, Vorschlagsrechte direkt zu erwerben, ohne dass die Validatoren (die aktuellen Vorschlagenden) sie wie hier vorgesehen an DeleGate.io delegieren müssen.

In jedem Fall ist der wichtige Punkt, dass jede Preconf, die schneller ist als der Konsens von Ethereum (12s), eine vertrauenswürdige dritte Partei (TTP) erfordert. Unabhängig davon, ob es sich bei Ihrem TTP um einen Restaked-Validator handelt, AusführungsauktionGewinner, deleGate.iod Gate.ioway oder was auch immer - es kann im Grunde genommen keine Echtzeit-Ethereum-Sicherheit bereitstellen. Ob Coinbase Ihnen einen „basierten Preconf“ als Ethereum-Vorschlagender oder einen „traditionellen Preconf“ als Rollup-Sequenzer gibt - Sie vertrauen Coinbase. Sie können ebenfalls eine Kaution von einigen ETH hinterlegen, aber in beiden Fällen ist dies unabhängig von der Sicherheit des Ethereum-Konsenses.

Wir sollten dann beachten, dass jedes basierte Preconf-Design notwendigerweise von den erklärten Zielen von BRS ablenkt, mit denen wir begonnen haben (Einfachheit und BL-Sicherheit). Basierend vorkonfigurierte sind zunehmend komplex, und sie können nicht die Echtzeit-Sicherheitsgarantien von Ethereum bieten.

Sie sollten jedoch weiterhin die Möglichkeit haben, eine Transaktion direkt über eine BL-Transaktion zu erzwingen, wenn diese Vorkonferenzen offline gehen oder mit der Zensur beginnen. Diese Garantien von Ethereum sollten noch stärker werden, wenn Einschlusslistenwird umgesetzt.

Für BRS - TTPS werden schnelle Vorbestätigungen bereitgestellt, und BL bietet letztendliche Sicherheit.

Nicht-basierte Rollups + basierte Fallback

Lassen Sie uns jetzt einen traditionellen (d. h. nicht auf Basis von) Rollup in Betracht ziehen. Sein eigener Sequenzer (ob zentralisiert oder dezentralisiert) gibt schnelle Vorbestätigungen. Später erhalten ihre Benutzer volle Ethereum-Sicherheit mit Verzögerung. Dies beinhaltet Lebendigkeit (Ledger-Wachstum + Zensurresistenz), die von irgendeiner Art vonerzwungene EinbeziehungoderBL-NotfallplanMechanismus.

wie ich festgestellt habe Erben Rollups Sicherheit?:

Rollups haben die Fähigkeit, Bestätigungsregeln mit äquivalenten Sicherheitseigenschaften wie ihre Host-Kette offenzulegen. Sie können diese Eigenschaften bestenfalls mit der Geschwindigkeit des Konsenses ihrer Host-Kette erhalten (und in der Praxis ist es oft etwas langsamer, abhängig davon, wie häufig das Rollup an die Host-Kette postet).

Rollups können auch eine „happy path“-Regel für eine lockere Bestätigung (d. h. Sequenzer) für eine bessere Benutzererfahrung bereitstellen, behalten jedoch im Falle eines Fehlers die Rückfalloption. Wenn Ihr Sequenzer stoppt, können Sie weitermachen.

Beachten Sie, dass die Zeit zur endgültigen Sicherheitist hier die Schlüsselvariable zur Optimierung:

Die Annahme, dass Rollup-Benutzer auf eine äquivalente Lebendigkeit wie die Host-Kette zurückgreifen können, setzt voraus, dass Sie erzwungenen Einschluss genau mit der Geschwindigkeit der Host-Kettenblöcke erhalten können (z. B. wenn der Rollup-Sequenzer Sie zensiert, dass Sie den Transaktionseinschluss im nächsten Ethereum-Block erzwingen können).

In der Praxis gibt es in der Regel eine kurze Verzögerung. Wenn Sie eine sofortige erzwungene Einbeziehung zulassen würden, könnten Sie ...profitable Zensur MEVunter anderem Komplexitäten. Allerdings gibt es jedoch Designs, die möglicherweise nahezu Echtzeit-Lebendigkeitsgarantien bietenvom Host-Chain (z. B. möglicherweise mit der Geschwindigkeit von einigen Host-Chain-Blöcken anstatt einem Block).

in diesem Geiste, Sovereign Labs hat ein Designdas folgende tut:

• Erlaubte Sequenzierung - Rollups setzen einen erlaubten Sequenzer, dessen Transaktionen sofort verarbeitet werden, sobald sie in die BL aufgenommen werden. Da sie eine Schreibsperre für den Zustand des Rollups haben, können sie zuverlässige Vorbestätigungen schneller als die BL-Blockzeit bereitstellen.
• Basierte Sequenzierung - Benutzer können Transaktionen auch direkt an ihren BL senden, aber sie werden mit einer N-Blockverzögerung verarbeitet (wobei N ausreichend klein ist). Dies verkürzt die "Zeit bis zur letztendlichen Sicherheit" erheblich, und in der Tat nennen sie das Design sogar "basierte Sequenzierung mit weichen Bestätigungen"! (Beachten Sie, dass diese Definition von brs im Widerspruch zu der Definition steht, die wir zuvor gegeben haben, d.h. dass der bl-Vorschlagende das Recht haben muss, die br zu sequenzieren oder von ihm deleGate.iod zu werden.)

Für Nicht-BRS - TTPS bieten schnelle Vorabbestätigungen, und das BL bietet letztendliche Sicherheit.

Y tho?

Wie wir sehen können, führen beide oben beschriebenen Wege zum gleichen effektiven Ergebnis:

Diese BRS mit Vorbedingungen bieten nicht mehr die Einfachheit oder Echtzeit-Sicherheit von Ethereum. Also, was ist jetzt der Sinn von all dem? Warum straffen wir nicht einfach die Fallbacks bei "traditionellen" Rollups? Was ist überhaupt ein "basierter Rollup" zu diesem Zeitpunkt?

Das hängt tatsächlich mit meinem zurückBeweis der RegierungsführungBeitrag vom letzten Jahr, in dem ich die grundlegenden Anwendungsfälle für das ethereum-spezifische Restaking diskutiert habe:

1) technisch (Anbieterverpflichtungen) - es führt kein Weg daran vorbei - wenn Sie eine glaubwürdige Verpflichtung zur Reihenfolge eines Ethereum-Blocks wünschen, muss sie von Ethereum-Validatoren stammen.MEV-Boost++ist ein Beispiel für eine hypothetische Anwendung, die in diese Kategorie fallen könnte.

2) Sozial - Ich sehe die Ausrichtung von Ethereum als den Hauptanwendungsfall für die meisten Restaking-Anwendungen heute, nicht die Bündelung wirtschaftlicher Sicherheit oder Dezentralisierung. Es wird gesagt, dassSchauen Sie, wir sind ein Ethereum-Projekt!" ist es der gleiche Grund, warum sich Ketten immer wieder Ethereum L2S nennen unabhängig von der Architektur.

Wir können dies im Kontext der Frage, was der Wert von "br + preconfs" gegenüber einem "traditionellen Rollup + schnellem Rückgriff" ist, modernisieren.

1) Technisch (Suggester-Verpflichtungen) - Ethereum-BRs mit Preconfs haben einen grundlegenden technischen Vorteil - sie können eine glaubwürdige Zusage des aktuellen Ethereum-Antragstellers in Bezug auf die Aufnahme und Anordnung des Inhalts eines Ethereum-Blocks erhalten. Dies ist potenziell aus den gleichen Gründen wertvoll, aus denen wir möglicherweise möchten, dass sich eine Reihe von Rollups einen Sequenzer teilen. Wenn der BL-Proposer auch der BR-Proposer ist (d.h. Sequencer), dann kann er mit dem BL die gleichen atomaren Inklusionsgarantien bereitstellen, die Sie zwischen Rollups erhalten können, die den Sequencer gemeinsam nutzen. Sie haben ein Monopol auf beide Ketten. Nun, wie wertvoll ist das? Wir werden gleich darauf zurückkommen.

2) sozial (Ausrichtung / glaubwürdige Neutralität) - man liebt es oder man hasst es,Ethereum-AusrichtungEs ist ein Verkaufsargument, ein BR zu sein. Ich werde ehrlich sein, ich weiß nicht viel über Taiko außer "sie sind die BR-Jungs", und ich würde wahrscheinlich nicht wissen, wer sie sind, wenn sie nicht die BR-Jungs wären. Jeder will etwas gutes Co-Marketing. Es gibt einen Wert darin, hier die Ersten zu sein, aber ich vermute, dass dies kein dauerhaftes Wertversprechen ist und sich nicht auf viele zukünftige potenzielle BRs überträgt. Ähnlich haben wir alle von den ersten Handvoll AVSs gehört, aber kannst du alle aktuellen benennen? Ich kann es nicht.

Auf einer höheren Ebene werden nicht alle Ethereum-Rollups in den (hypothetischen) Optimismus-Shared-Sequenzer oder den Arbitrum-Shared-Sequenzer integriert. Es ist jedoch wahrscheinlicher, dass sie sich alle für den Ethereum-Shared-Sequenzer entscheiden. Kein neuer Token, keine neue Marke, keine neue Konsensbildung. Wenn Sie der Meinung sind, dass es wertvoll ist, dass alle Ethereum-L2s sich auf die Sequenzierung einigen, dann ist diese glaubwürdige Neutralität möglicherweise der stärkste Schelling-Punkt, um dieses Ziel zu erreichen.

Diese glaubwürdige Neutralität ist wahrscheinlich am wertvollsten für Rollup-Entwickler, die versuchen, ökosystemübergreifende Benutzer (z. B. Anwendungen mit grundlegender Infrastruktur wie ENS) anzuziehen. Sie zögern möglicherweise, den Optimism Sequencer zu verwenden, wenn er Arbitrum-Benutzer verprellt oder umgekehrt.

Wir werden jeden einzelnen davon unten ausführlicher behandeln.

glaubwürdige Neutralität

Wenn man tiefer in diesen sozialen Punkt eintaucht, werden BRs oft als die maximal "Ethereum-orientierte" Option angesehen. Unabhängig von der Wertung dieses Umstandes ist der wichtige Punkt, dass dies eine hohe Glaubwürdigkeit und Neutralität für jedes BR-Design voraussetzt.

Ein glaubwürdig neutrales BR ist im Vanilla-Fall einfach zu entwerfen, aber wie wir bemerkt haben, möchte das niemand wirklich. Preconfs erfordern dann zwangsläufig, dass der Antragsteller in zusätzliche Slashing-Bedingungen einwilligt. Diese zusätzlichen Slashing-Bedingungen erfordern, dass der Antragsteller ein zusätzliches System verwendet (z. B. potenziell Eigenlayer-Restaking, ...)Symbiotischoder eine andere Norm), um die Verpflichtung einzugehen. Ein Rollup mag froh sein, sich abstrakt für den glaubwürdig neutralen "Ethereum Sequencer" zu entscheiden, aber die glaubwürdige Neutralität geht wahrscheinlich verloren, wenn Sie privat finanzierte Projekte verwenden, vielleicht sogar mit eigenen Token.

Es gibt mehrere offene Fragen bezüglich der Sicherheiten hier:

Kreditsicherheit Größe

Frühe Entwürfe haben vorausgesetzt, dass die Antragsteller persönlich eine unglaublich hohe Menge an Sicherheiten von etwa 1000 Eth hinterlegen müssten. Das Problem ist, dass ein Antragsteller grundsätzlich immer seine Zusage gegenüber Gate.io brechen und einen Block selbst erstellen kann, indem er die Voraussetzungen missachtet. Dies kann unglaublich wertvoll sein, und 1000 Eth liegt komfortabel über den bisher höchsten beobachteten Zahlungen, die über MEV-Boost abgewickelt wurden. Der Nachteil ist, dass dies natürlich eine hohe Einstiegshürde für kleinere Antragsteller schafft, während größere (z. B. Coinbase) vernünftigerweise 1000 Eth hinterlegen könnten, während sie Belohnungen für ihr gesamtes Stake-Gewicht erhalten.>13% der gesamten eingesetzten ETHDa die Registrierenden eine einzige Kaution für alle ihre Validatoren hinterlegen können. gibt esweitere Ideen, um Vorschläge mit viel kleineren Bonds zuzulassen, obwohl sie natürlich Kompromisse mit sich bringen. Der Designbereich hier ist einfach unsicher.

Es ist erwähnenswert, dass DurchführungsversteigerungenWürde diese Sorge lindern, da wir davon ausgehen können, dass alle Antragsteller dann anspruchsvolle Akteure wären, die dazu leicht in der Lage sind.

Quelle: Barnabé Monnot, von Mev-Boost zu EPBS zu APS

Allerdings zögern selbst die großen Operatoren, große Mengen hochzuladen, wegen potenzieller Liveness-Probleme, die zu Slashing führen (ein Live-Fehler seitens eines Operators, der unsere Preconfs dann ausschaltet, bevor sie in einen Block aufgenommen werden, ist trotzdem ein Sicherheitsversagen für die Benutzer und muss hart bestraft werden).

Sicherheitstyp

Vanilla ETH ist wahrscheinlich das einzige glaubwürdig neutrale Sicherungsmittel in dieser Situation. Es wird jedoch natürlich den Wunsch geben, kapitaleffizientere Vermögenswerte (z. B. stETH) zu nutzen. Es gibt einige Ideen, diese Umwandlung durch einen Underwriter durchführen zu lassen, wie unten beschrieben.mteam hier.

Bahnsteig

Es wäre nicht sehr "glaubwürdig neutral", wenn die "ethereum-basierten Vorbesprechungen" mehr wie die "eigenlayer-basierten Vorbesprechungen" oder die "symbiotischen Vorbesprechungen" wären. Es gibt Teams, die vorhaben, in diese Richtung zu gehen, aber es ist keine strikte Anforderung, eine solche Plattform zu verwenden. Es ist möglich, einen allgemeinen und neutralen Standard zu erstellen, den alle verwenden können, und ein solches System wäre besser positioniert für eine allgemeine Akzeptanz als die basierendste Option.

Die Einführung von Standards für das öffentliche Wohl wird für auf vorherigen Konzepten basierende Entwürfe plausibel erforderlich sein, um "glaubwürdig neutral" zu sein.

Vorbestätigungen

Inklusion vs. Zustandskonfektionen

Wir werden nun im Detail auf Preconfs eingehen. Während wir zuvor eine spezifische Art von Preconfs (br Preconfs zum Zustand) besprochen haben, müssen wir beachten, dass sie ein vollständig allgemeines Konzept sind. Sie können Preconfs für bl Transaktionen zusätzlich zu brs anbieten und verschiedene Stärken von Preconfs anbieten:

• Inklusion Preconfs - ein schwächeres Engagement, dass eine Transaktion letztendlich in der Blockchain aufgenommen wird.
• state preconfs - die stärkste Verpflichtung, dass eine Transaktion letztendlich in die Blockchain aufgenommen wird und eine Garantie für den resultierenden Zustand.

Letzteres (Status Preconfs) ist natürlich das, was Benutzer in ihren Brieftaschen angezeigt haben möchten:

Ich habe 1 ETH gegen 4000 USDC getauscht und 0,0001 ETH an Gebühren bezahlt.

Keine Vorab-Konfigurationen einschließen:

Meine Transaktion, bei der ich versuche, 1 Eth gegen 4000 USDC zu tauschen und bis zu 0,0001 Eth an Gebühren zu zahlen, wird letztendlich onchain landen, aber vielleicht gelingt es, vielleicht scheitert es, wir werden sehen.

Wir sollten jedoch beachten, dass Inklusionsvorkonfs im Fall von Benutzeraktionen auf nicht umstrittenen Status (z. B. einfache Überweisungen, bei denen nur der Benutzer selbst die Transaktion ungültig machen könnte) effektiv austauschbar sind. In diesem Fall reicht es aus, dem Benutzer in der Brieftasche beispielsweise zu zeigen: „Ihre USDC-Überweisung an Bob wird in den nächsten Blöcken enthalten sein“, um nur zu sagen: „Sie haben Ihre USDC an Bob gesendet.“

Es ist wenig überraschend, dass es schwieriger ist, stärkere Verpflichtungen (Vorabkonfigurationen) zu erhalten. Grundsätzlich erfordern sie glaubwürdige Verpflichtungvon der Entität, die derzeit ein Monopol auf das Vorschlagen von Blöcken hat (d. h. ein Schreibschutz des Kettenzustands). Im Falle von Ethereum L1 Preconfs ist dies immer der aktuelle Ethereum L1 Vorschlagende. Im Falle von BR Preconfs ist dies vermutlich der nächste Ethereum L1 Vorschlagende im Ausblick von BR (was sie zum aktuellen Vorschlagenden für BR macht), wie wir unten sehen werden. Vorschlagender und Sequenzer sind im Allgemeinen austauschbare Begriffe, wobei ersterer im L1-Kontext und letzterer im L2-Kontext häufiger verwendet wird.

Preisgestaltung Vorbesprechungen

Eine weitere wichtige Unterscheidung, die wir treffen müssen, ist, welche Art von Zustand diese Preconfs berühren:

• nicht umstrittener Zustand - niemand sonst benötigt Zugriff auf diesen Zustand (z.B. Alice möchte USDC an Bob übertragen)
• umstrittener Zustand - andere wollen Zugang zu diesem Zustand (z.B. Swaps in einem ETH/USDC AMM-Pool)

Preconfs sind Einschränkungen dafür, welcher Block letztendlich erstellt werden darf. Alles andere gleichbleibend, kann die Begrenzung des Suchraums für die Blockersteller nur den potenziellen Wert verringern, den sie durch die Reihenfolgeerstellung erfassen können. Das bedeutet, dass weniger Wert an den Vorschlagenden zurückgegeben wird. Um Anreize zu schaffen, muss Gate.io eine Preconf-Gebühr erheben, die größer oder gleich dem potenziellen MEV-Verlust durch die Begrenzung des Ergebnisses ist.

Das ist einfach genug, wenn der MEV-Verlust ~0 beträgt (z. B. bei einer USDC-Übertragung). In diesem Szenario könnte es vernünftig sein, eine geringe Pauschalgebühr zu erheben. Aber wir haben ein großes Problem - wie bewerten wir Vorbestätigungen bei umstrittenem Status? Es scheint, dass Vorbestätigungen im Voraus weniger bezahlt würden als in letzter Minute. Alles andere gleich, ist es für einen Entwickler am profitabelsten, bis zur letzten Sekunde zu warten, um den MEV zu erfassen und genau zu bewerten.

Nehmen wir jedoch an, dass es ausreichende Benutzernachfrage nach schnellen Preconfs zu einem umstrittenen Zustand gibt (sowohl für erfahrene Suchende als auch für normale Benutzer), sodass es zu bestimmten Zeiten einen Clearing-Preis gibt, der für alle vorteilhaft ist. Wie genau berechnet man nun den Preis für einen Preconf für eine Transaktion zu einem umstrittenen Zustand, den man ansonsten innerhalb der nächsten 12 Sekunden einfügen könnte und dabei möglicherweise profitablere Möglichkeiten vernachlässigt, die dann nicht mehr möglich wären?

Preconfs zu einem umkämpften Zustand, der im gesamten Block gestreamt wird, würden im Konflikt mit der Art und Weise stehen, wie die Erbauer Blöcke erstellen. Die genaue Preisgestaltung von Preconfs erfordert eine Schätzung des MEV-Einflusses bei der sofortigen Einbeziehung, anstatt sie zu verzögern, was bedeutet, dass die möglichen Ergebnisse ausgeführt und simuliert werden müssen. Das bedeutet, dass Gate.ioway nun ein hochsophistizierter Sucher/Erbauer sein muss.

Wir sind bereits davon ausgegangen, dass Gate.ioway und Relay zusammenführen würden. Wenn sie kontinuierlich Preconfs bepreisen müssen, werden sie auch mit dem Builder zusammengeführt. Wir akzeptierten auch, dass die USC die Zusammenführung von Builder und Prove beschleunigen würde. Es scheint auch so, als ob Durchführungsauktionenverkauft das Vorschlagsrecht direkt an erfahrene Akteure (wahrscheinlich Entwickler), die in der Lage sind, den Preis festzulegen.

Damit wird die gesamte Ethereum L1- und BR-Transaktionslieferkette in einer Box zusammengefasst, die eine Monopol-Schreibsperre für den Zustand aller Chains für diesen Zeitraum hat.

Die Bestellrichtlinien des Preconf-Dienstes sind unklar (z. B. laufen sie immer FCFS oder bestellen sie sie auf andere Weise). Es ist auch potenziell möglich, dass die Gate.ioway eine Auktion über alle Preconfs durchführt (z. B. die Suchenden bieten auf Preconfs), obwohl nicht klar ist, wie ein solches Design aussehen würde, und es würde zwangsläufig zu einer höheren Latenz führen.

faire Austauschproblem

Es gibt ein faires Austauschproblem mit Preconfs, bei denen Gate.ioway nicht direkt einen Anreiz hat, die Preconf freizugeben.

Betrachten Sie das folgende Beispiel:

• das aktuelle Gate.ioway hat ein 12s-Monopol
• Ein Benutzer gibt eine Vorbestätigungs-Transaktionsanfrage direkt zu Beginn des Slots (t = 0) ab
• Das Gate.ioway wartet bis t = 11,5, um alle Vorabkonfigurationen freizugeben, die sie während ihres Slots gemacht haben, und lässt einen Puffer von 500 ms, um sie mit ihrem Block alle miteinzubeziehen. Zu diesem Zeitpunkt können sie entscheiden, welche Vorabkonfigurationen sie einschließen wollen, wenn sie profitabel sind, und welche auszuschließen.

In diesem Szenario kann es vorkommen, dass der Benutzer für die Vorbestellung bezahlt, obwohl er sie erst am Ende des Zeitfensters erhält. Die Gate.ioway könnte sie auch einfach am Ende des Zeitfensters fallen lassen, wenn sie sich entscheidet, dass es nicht rentabel ist, sie einzubeziehen. Diese Zurückhaltung durch das Gate.ioway ist kein objektiv zurechenbarer Fehler.aber es könnte intersubjektiv zurechenbar sein).

Tatsächlich gibt es tatsächlich einen Anreiz für Gate.ioways, die Preconfs bis zum Ende zurückzuhalten.Wo es Informationsasymmetrie gibt, gibt es MEV. Die Geheimhaltung von Transaktionen würde es einem Bauherrn ermöglichen, einen aktuelleren Überblick über den Zustand der Welt zu erhalten, was es ihm ermöglicht, das Risiko besser zu bewerten und MEV zu erfassen. Es gibt keinen Konsens über den Satz von Preconfs, die den Benutzern gegeben werden, so dass Gate.ioway hier nicht zur Rechenschaft gezogen werden kann.

Es müssten Standards vorhanden sein und Erwartungen, dass der Preconfirmer sofort öffentlich über alle Preconfs tratscht. Dies würde den Benutzern sofort das geben, was sie wollen, und es anderen ermöglichen, zu sehen, dass ein Gate.ioway die erwarteten Dienste bereitstellt. Wenn sie dies in Zukunft nicht tun, dann würden die Benutzer ihnen nicht vertrauen und sie für Preconfs bezahlen. der Ruf des Gate.ioway hat einen Wert. Davon abgesehen kann es auch sein außerordentlich wertvollhier unehrlich zu sein und gegen Vorurteile vorzugehen.

l1 Basisschicht-Vorkonfigurationen

Nachdem die allgemeinen Vorkonferenzpunkte geklärt sind, werden wir nun auf die Feinheiten der L1-Vorkonferenzen eingehen. Obwohl wir sie zuvor nicht erwähnt haben, gibt es Projekte, die daran arbeiten, und ihre Interaktion mit den BR-Vorkonferenzen wird wichtig sein.

zum BeispielBolzenist ein solches Protokoll, das Ethereum-Vorschlagenden ermöglichen möchte, glaubwürdige Verpflichtungen hinsichtlich ihrer Blockinhalte einzugehen. Registrierte Vorschlagende können den Bolt Sidecar ausführen, um Voranfragen von Benutzern zu empfangen, diese zu bestätigen und dann diese Informationen an Relais und Builder zu senden, die Blöcke zurückgeben können, die diesen Einschränkungen entsprechen (d. h. sie geben einen Block zurück, der die Transaktionen enthält, die der Vorschlagende den Voranfragen gegeben hat).

Es ist wichtig hier zu beachten, dass Bolt v1Wie hier beschrieben, unterstützt dies nur einfache Transaktionsaufnahme-Vorabbestätigungen für nicht umstrittene Zustände, bei denen nur der Benutzer die Vorabbestätigung ungültig machen kann. Wie wir bereits früher besprochen haben, sind dies die einfachsten und schwächsten Verpflichtungen, die bereitgestellt werden können.

Alle diese Preconf-Teams haben größere Ambitionen (z. B. Landes-Preconfs, Teilblock-Auktionen, Slot- oder Teilslot-Auktionen), also was hält sie zurück?

• Rechenschaftspflicht - Verpflichtungsverletzungen sollten auf der Blockchain nachweisbar sein, um eine objektive Kürzung zu ermöglichen. Es ist relativ einfach, die Einbeziehung von Transaktionen nachzuweisen, aber es ist nicht so klar, wie andere Verpflichtungen wie Slot-Auktionen durchgesetzt werden können.
• Kapitalanforderungen - Die Bereitstellung willkürlicher Zusagen bedeutet, dass der Wert eines Verstoßes gegen eine Verpflichtung willkürlich hoch sein kann. Gate.ioways wird wahrscheinlich am Ende riesige Beträge (z. B. Tausende von ETH) einsetzen müssen, um diese bereitzustellen. Diese können sehr wohl zusammengelegt werden, was den größten Unternehmen (z. B. großen Handelsunternehmen oder Coinbase) zugute kommt und kleinere Unternehmen auslässt.
• Preisgestaltung - Es gibt viele offene Fragen zur Preisgestaltung von kontinuierlich gestreamten Zustandsvorabkonfigurationen, selbst wenn wir uns entscheiden, dass es machbar und wertvoll ist.
• Netzwerkbeteiligung - das ist vielleicht der wichtigste und grundlegendste Punkt. Wie wir bereits erwähnt haben, kann nur der aktuelle Vorschlager, der eine Schreibsperre für state hat, Verpflichtungen wie Zustandsvorkonfektionen bereitstellen. Theoretisch könnten sich 100 % der Antragsteller für dieses System entscheiden und es nachahmen. In der Praxis wird das nicht passieren.

mev-boost, ein einfacheres Produkt mit jahrelanger Erfolgsbilanz, das unglaublich profitabel ist, hat>92% Teilnahme für den Kontext (wahrscheinlich sogar etwas höher, da dies nicht berücksichtigt wird mindestgebotEine neue Vorabkonferenz-Service würde sicherlich eine weit geringere Beteiligungsquote erhalten. Aber selbst wenn es in den ~90%-Bereich kommen könnte, scheint dies kein nützliches Produkt für normale Benutzer zu sein. Man kann Benutzern nicht 10% der Zeit sagen: "Oh, tut uns leid, im Moment sind keine Vorabkonferenzen verfügbar, schauen Sie später wieder vorbei."

Im besten Fall fühlt es sich so an, als ob staatliche Preconfs nur ein optionales Tool für anspruchsvolle Sucher und Händler sein würden, die früher im Block eine Verpflichtung eingehen möchten, wenn dieser Slot zufällig einen Proposer eingeloggt hat. Das mag wertvoll sein, aber es gibt hier keine Fragmentierung oder UX-Entsperrungen.

L2-basierte Rollup-Vorkonfektionen

Vorabkonflikte müssen von den BL-Antragstellern stammen (deshalb sind sie "basiert"). Dies erfordert, dass sie etwas Sicherheit hinterlegen und zusätzliche Slashing-Bedingungen akzeptieren (d. h. dass die von ihnen bereitgestellten Vorabkonflikte tatsächlich wie versprochen in der Onchain landen). Jeder Antragsteller, der dazu bereit ist, kann als BR-Sequenzer fungieren und Vorabkonflikte bereitstellen.

Wichtig ist, dass diese BR-Vorconfenzen staatliche Vorconfenzen sind und nicht nur Inklusionspeconfenzen. Dies ist möglich, weil sich BRs für ein Design entscheiden, bei dem sie einem rotierenden Sequenzermonopol für BL-Vorschlagende zustimmen, die sich als Gate.ioways anmelden.

Derzeit fungiert ein Ethereum-Validierer als Vorschlagender für jeden Slot, und der Vorschlagszeitplan ist immer für die aktuelle Epoche und die nächste bekannt. Eine Epoche umfasst 32 Slots, sodass wir immer die nächsten 32-64 Vorschlagenden zu einem bestimmten Zeitpunkt kennen. Das Design funktioniert durch die Gewährung von Monopolrechten für den nächsten aktiven Sequenzer (dh den nächsten Sequenzer im Lookahead) zur Sequenzierung von Transaktionen für die BRS, die sich für dieses Preconf-System entschieden haben. Gate.io-Wege müssen unterschreiben, um den Zustand der BR-Ketten voranzutreiben.

Beachten Sie, dass jeder Vorschlagsteller (auch solche, die sich nicht dafür entschieden haben, ein Gate.ioway zu sein) das Recht, aber nicht die Verpflichtung hat, Transaktionen einzuschließen, die von den Sequenzern vorgegeben wurden (d.h. von den Vorschlagstellern, die sich dafür entschieden haben, ein Gate.ioway zu sein). Sie können als Einbeziehender fungieren, solange sie die vollständige Liste der Transaktionen haben, die bis zu diesem Zeitpunkt vorkonfirmiert wurden (der Sequenzer kann eine bl-Blob erstellen, die die br-Transaktionen enthält und sie veröffentlichen).

Quelle: Ethereum-Sequenzierung, Justin Drake

Der Transaktionsfluss funktioniert wie folgt:

1. Der BR-Benutzer sendet seine Transaktion an den nächsten Sequenzer im Lookahead (Slot n+1 proposer in der Abbildung unten)
2. Der Sequenzer stellt sofort eine Vorbestätigung für den resultierenden Zustand bereit (z. B. Benutzer tauschte 1 Eth gegen 4000 USDC auf der Br und zahlte 0,0001 Eth an Gebühren)
3. An diesem Punkt kann jeder Einbeziehende die sequenzierte Transaktion (der Slot n-Proposer tut dies im untenstehenden Bild) einbeziehen.

Quelle:Ethereum Sequenzierung, Justin Drake

Wenn die anderen Einschließer die Voraussetzungen nicht einschließen, kann der Sequencer, der sie gegeben hat, sie einfach onchain einschließen, wenn er an der Reihe ist, als der bl Vorschlagende. Zum Beispiel, in dem obigen Bild, nehmen wir an, der Einschließer des Slots n hat beschlossen, die Voraussetzungen nicht einzuschließen, die der Sequencer des Slots n+1 gegeben hat. Dann wäre der Sequencer des Slots n+1 dafür verantwortlich, alle Voraussetzungen einzuschließen, die er während des Slots n und des Slots n+1 gegeben hat, wenn er seinen bl Block für n+1 einreicht. Dadurch kann der Sequencer zuversichtlich Voraussetzungen für den gesamten Zeitraum zwischen ihnen und dem letzten Sequencer geben.

Um die obigen Erläuterungen zu vereinfachen, haben wir angenommen, dass der L1-Proposer diese Preconfer-Rolle erfüllen würde. Wie jedoch bereits beschrieben, ist dies wahrscheinlich nicht der Fall. Es wird eine anspruchsvolle Einheit erfordern, um die Preconfs zu bewerten, Vollknoten für alle BRs auszuführen, DoS-Schutz und ausreichende Bandbreite für alle BR-Transaktionen usw. Ethereum möchte die Validatoren sehr unkompliziert halten, daher werden die Proposer die Preconfs voraussichtlich an eine andere Einheit auslagern, ähnlich wie sie heute die vollständige L1-Blockproduktion über MEV-Boost auslagern.

Vorschlagende können Gate.io über On-Chain- oder Off-Chain-Mechanismen an Gate.ioways delegieren, und dies kann bis kurz vor ihrem Slot geschehen. Wie bereits erwähnt, wird diese Rolle in der Praxis wahrscheinlich von Relays übernommen. Es ist auch möglich, dass sie sich auch mit Builders zusammenschließen müssen.

Quelle: Auf Sequenzierung basierend, justin drake

Wie bereits beschrieben, kann nur eine Entität zu einem bestimmten Zeitpunkt zur Gate.ioway deleGate.iod werden. Dies ist erforderlich, um zuverlässige Zustandsvorprüfungen bereitzustellen. Benutzeroberflächen (z.B. Wallets wie Metamask) würden darauf achten, wer der nächste Gate.ioway ist, und sie würden Benutzertransaktionen dorthin senden.

Ethereum-Rollups - wie basiert werden sie sein?

Mit ausreichendem Hintergrundwissen - sollten Ethereum Rollups basiert sein? Hier gibt es wirklich zwei eingebettete Fragen:

1. Sollten viele Ethereum-Rollups einen Sequenzer teilen?
2. Wenn ja, sollte es ein auf einem Sequenzer basierendes System sein (d.h. unter Beteiligung der Ethereum-Bl-Proposer und der umgebenden MEV-Infrastruktur)?

Zunächst ist es wichtig zu beachten, dass Sie einen Sequenzer auf Ad-hoc-Basis mit anderen Ketten teilen können. Zum Beispiel kann der Ethereum-Vorschlagende einen Block für Sie sequenzieren, wenn er das höchste Gebot abgegeben hat, dann könnte ein anderer BFT-Konsens Ihren nächsten Block sequenzieren, wenn er das höchste Gebot abgegeben hat. Dies erfordert jedoch immer noch, dass sich eine Kette vollständig für diese einheitliche gemeinsame Auktion entscheidet, die synchron mit diesen anderen Ketten ablaufen kann, so dass es immer noch Kompromisse in Bezug auf Kontrolle und Flexibilität gibt (z. B. gemeinsame Blockzeiten). Es ist nur so, dass sich die siegreiche Sequenzer-Entität verschieben kann.

Unabhängig davon nehmen wir einfach an, dass Bedingung 1 erfüllt ist. Ich denke, wir haben an diesem Punkt überzeugende Beweise dafür, dass es eine ausreichende Nachfrage gibt, einen dezentralen Shared-Sequencer zu verwenden. Auch wenn sie sich weniger um den "gemeinsamen Aspekt" kümmern, denke ich, dass es einen unglaublich hohen Wert hat, einen dezentralen Sequenzer-as-a-Service von der Stange kaufen zu können (tatsächlich denke ich, dass dies der größte Wert hier ist).

Sollte dieser gemeinsame Sequenzer jetzt ein ethereum-basierter Sequenzer sein?

technisch (Vorschlagsverpflichtungen)

Ich sehe kein starkes technisches Argument für die Verwendung eines Ethereum-basierten Sequenzers. Jegliche Interoperabilität zwischen BRS und dem Ethereum L1 wäre unglaublich eingeschränkt, da es nicht in der Lage ist, zuverlässig gegen den L1 auszuführen (d. h. nicht konsistent eine Schreibsperre für den L1-Zustand zu haben), lange Blockzeiten (12 Sekunden) und die Tatsache, dass BR-Transaktionen, die mit dem L1 interagieren wollten, dann parallel dazu neu organisiert werden müssten. Hier gibt es kein kostenloses Mittagessen. Dadurch werden keine wertvollen benutzerorientierten Produkte im Vergleich zu anderen externen gemeinsam genutzten Sequenzern freigeschaltet.

Der Hauptwert, den ich sehe, besteht darin, dass die Hinzufügung von Ethereum L1 zu dieser größeren kombinatorischen Auktion möglicherweise zu einem höheren aggregierten Wert für Gate.io führt und ermöglichen Sie dem L1, mehr Wert zu erfassen. Wenn wir diese Logik auf die Spitze treiben, sollten wir wahrscheinlich alles auf der Welt in die gleiche Auktion stellen. Diese universelle Auktion sollte auch die Reihenfolge der Taylor Swift Konzertkarten sein. Ich bin noch nicht ganz da.

Dies dient nur dazu zu betonen, dass es eine echte technische und soziale Komplexität bei der Schaffung und Beteiligung aller an dieser gemeinsamen Auktion gibt, die einen realen Kostenfaktor hat, der meiner Meinung nach wahrscheinlich jeden theoretischen zusätzlichen Wert hier übertrifft. Sie können leicht eine weit bessere technische Gestaltung auf der Grundlage erster Prinzipien entwickeln, wenn wir versuchen, sie nicht auf Ethereum L1 aufzusetzen (z.B. einfach einen einfachen, schnellen Konsensmechanismus für diesen Zweck entwickeln). Ganz zu schweigen davon, dass eine solche kombinatorische Auktion zu einer exponentiellen Komplexitätssteigerung führen würde.

In der Praxis besteht für mich ein bedeutendes Risiko, dass dies tatsächlich äußerst kontraproduktiv für Ethereum sein kann, da diese auf der Vorabkonfigurationsarchitektur basierende Methode hinsichtlich der MEV-Infrastruktur potenziell accelerationistisch wirkt, wenn die Lieferkette von Ethereum bereits etwas brüchig ist. Dies gefährdet die Dezentralisierung und Zensurresistenz des Netzwerks - genau die Dinge, die es von Anfang an wertvoll machen.

sozial (glaubwürdige Neutralität)

Ich sehe ein gültiges soziales Argument für einen Ethereum-basierten Sequenzer.

Wie bereits erwähnt, besteht kein Zweifel daran, dass "Ausrichtung" ein Verkaufsargument für die anfänglichen BRS ist. Das ist in Ordnung, aber ich glaube nicht, dass dies von Dauer ist. Es ist cool, der erste BR zu sein, aber es ist nicht cool, der achte zu sein. Es muss noch ein anderer Mehrwert vorhanden sein.

Ich denke, dass die glaubwürdige Neutralität eines Ethereum-basierten Sequenzers möglicherweise dieser Wert ist. Es ist wahrscheinlich das stärkste Argument für ein solches Design. Es gibt viele Ketten, die einen dezentralen Sequenzer von der Stange haben wollen. Wenn wir schließlich genug Infrastruktur darüber hinaus entwerfen können, dass sie die Cross-Chain-UX verbessert, dann noch besser. Von den Projekten, die ein solches Design wollen, kann ich mir vorstellen, dass viele von ihnen zögern, sich für ein Protokoll von Drittanbietern zu entscheiden. Wie bereits erwähnt, stellen Sie sich vor, Sie sind eine App-Chain mit einer grundlegenden allgemeinen Infrastruktur wie ENS und möchten ein Rollup. Sie möchten nicht den (hypothetischen) Arbitrum-Shared-Sequenzer auswählen und die Optimismus-Crowd ausschalten oder umgekehrt.

Möglicherweise ist die einzige Lösung für das soziale Koordinationsproblem hier die Existenz eines glaubwürdig neutralen gemeinsamen Sequenzers, für den Ethereum eindeutig der stärkste Kandidat ist. Beachten Sie, dass dies einen noch höheren Grad an Betonung auf die Punkte legt, die ich früher hinsichtlich der glaubwürdigen Neutralität gemacht habe - wenn dies der Hauptwertzuwachs eines solchen Dienstes ist, dann muss dies ein unglaublich wichtiges Designziel bei seiner Schaffung sein. Es wird nicht funktionieren, wenn es den Anschein hat, das Lieblingsprojekt eines Drittanbieterprotokolls mit eigenen Gewinnmotiven zu sein. Es muss tatsächlich der gemeinsame Sequenzer von Ethereum sein.

Es ist erwähnenswert, dass es auch berechtigte Kritik gibt, dass "neutral" hier als Code für "Ethereum" steht. Das heißt, dass seine primäre Motivation darin besteht, Ethereum und seine native umgebende Infrastruktur zu fördern. Und natürlich würde ein solches System diesen Parteien zugutekommen. Es würde bedeuten, dass mehr Wert auf ETH als Vermögenswert entfällt und mehr Rentabilität für Ethereum-Entwickler, Relays und Sucher.

schnell basierte Rollups

schnelle Basisschichten

Wir sollten jetzt verstehen, dass man auf einer langsamen BL wie Ethereum BRs haben kann, dass man vertrauenswürdige Preconfs für eine schnellere UX hinzufügen kann und dass man sogar Sicherheit beim Wechsel zwischen Ketten durch kryptowirtschaftliche oder kryptographische Garantien gewährleisten kann.

Wie bereits erwähnt, was ist, wenn wir dieses Ding einfach von Grund auf neu entwerfen. Keine Auseinandersetzung mit der Technikschuld und den Entscheidungen einer bestehenden Kette. Was ist der offensichtliche Weg, um das Ding zu bauen...

Früher haben wir besprochen, wie der einzige technische Grund, ein BR mit Preconfs für einen bestimmten BL (z.B. Ethereum) zu sein, darin besteht, dass dessen Anbieter zu bestimmten Zeiten glaubwürdige Verpflichtungen in Bezug auf die synchrone atomare Einbeziehung mit dem BL liefern kann.

Allerdings haben wir die Möglichkeit, ein BR ohne Vorkonferenzen ernsthaft nicht diskutiert. Im Grunde haben wir das aus dem Fenster geworfen, weil Ethereum langsam ist und die Benutzer ungeduldig sind.

Warum verwenden wir also nicht einfach ein schnelles BL für BRs?

Dies löst so ziemlich alle komplexen Randfälle und Bedenken, die wir zuvor hatten. Wir möchten keine seltsamen Randfälle, bei denen Gate.ioways Lebendigkeitsausfälle haben (die hier dasselbe Ergebnis wie Sicherheitsausfälle haben), wir möchten nicht, dass sie von versprochenen Vorkonfigurationen zurücktreten (d. h. Sicherheitsausfälle), und wir möchten keine Ethereum-Reorgs. Genau deshalb existiert Konsens.

Die Schichten sind tot, es leben die Sequenzschichten!

Der größte Teil der Diskussion über Lazy-Sequenzer betrachtet sie als einen Rollup-Sequenzer, der dann seine Daten auf eine andere Datenbank-Ebene ablegt. Zum Beispiel Astrias erste zwei Rollups (FormaundFlamme) wird Celestia als ihre DA-Ebene verwenden. Der Konsens von Astria wird diese Rollups sequenzieren und dann ihre Daten an Celestia weiterleiten.

Diese Kombination ist besonders schön, weil sie offensichtliche Ergänzungen sind: Astria stellt die gesamte Sequenzinfrastruktur bereit und Celestia bietet eine vertrauensminimierte Überprüfung durch Datenverfügbarkeitsstichproben (DAS).

Astria könnte jedoch auch verwendet werden, um einen Rollup zu sequenzieren, der nativ für Ethereum, Bitcoin, Solana oder was auch immer Sie möchten ist. Zum Beispiel könnte es sogar als Preconfer für Ethereum "BRS mit Preconfs" eingerichtet werden (anstelle eines zentralisierten Gate.ioway, da ein fauler Sequenzer im Grunde nur ein incentivierter und dezentralisierter Relay ist).

Um es jedoch klar zu machen, ist jede Kette eine DA-Schicht. Vollknoten können immer nach DA überprüfen. Es ist ein Teil der Gültigkeitsbedingungen jeder Kette, dass die Daten verfügbar sind. Daher bestätigt der Konsens immer, dass die Daten verfügbar sind. Leichte Knoten, die ihre Bestätigung überprüfen, gehen von einer ehrlichen Mehrheitsannahme aus. Der einzige Unterschied besteht darin, ob die Kette eine andere Option für leichte Clients bietet, um direkt nach DA zu suchen, anstatt den Konsens zu fragen.

jedoch, wie ich angemerkt habe Erben Rollups die Sicherheit?, schnelle Ketten wie Astria könnten technisch gesehen einen langsamen Pfad für das Hinzufügen von DAS (zur Verbesserung der Überprüfbarkeit) hinzufügen, und langsame Ketten wie Celestia könnten einen schnellen Pfad für die Sequenzierung hinzufügen (mit einer Mehrheitsvertrauensannahme und ohne DAS), sogenannte Schnelle Blöcke, langsame Quadrate.”

Eine weitere Vertikale Integration spezialisierter Schichten wie Sequenzierung oder DAS würde die Unterscheidung zwischen modularen und integrierten Blockchains weiter verengen. Dies gilt ähnlich für die vertikale Integration derAbrechnungsschichtdurch HinzufügenZK-Verifiziererkonten für die Basisschicht von Celestia.

Allerdings gibt es einen bedeutungsvollen Wert darin, diese Dienste getrennt zu halten, anstatt sie zu bündeln. Dies ist der modulare Ansatz, der es Rollups ermöglicht, auszuwählen, welche Funktionen sie von der Stange haben möchten (z.B. ich möchte dezentrale Sequenzierung mit schnellen Blöcken kaufen, aber ich möchte nicht für DAS bezahlen oder umgekehrt). Forscher haben gezeigt, dass sie DAS wollen, aber Nutzer haben bisher nur gezeigt, dass sie schnelle Blöcke wollen.

Bündelung von Dienstleistungen wie im schnelle Blöcke langsame Quadrate„wäre sehr meinungsfreudig und integriert. Dies würde zwangsläufig Komplexität und Kosten hinzufügen. Die Wirkung der Schachtellänge auf Timing-SpieleDie (und damit potenziell die Dezentralisierung), die nun auf Ethereum allgegenwärtig sind, sind ebenfalls zu berücksichtigen.

schnelle Basisschicht vs. langsam + Vorbestellungen

Aber Sie können auch einfach Astria als das BL für Rollups verwenden. Geteilte Sequenzer können als BLS betrachtet werden, die für ihre eigenen BRS optimiert sind.

Wenn Ihre BL schnell ist, benötigt Ihr BR keine Vorbestätigungen, da es einfach schnelle Bestätigungen direkt aus der Box erhält! Dann erhält Ihr Rollup tatsächlich die Echtzeit-Sicherheit Ihrer BL, im Gegensatz zu BRs + Vorbestätigungen, die diese notwendigerweise verlieren.

BRs ohne Vorbedingungen sind tatsächlich der logischste Weg, um einen Rollup aufzubauen. Deshalb haben alle heutigen Rollups dort begonnen:

Es ist klar, dass ein BL mit schnellen Blöcken die meisten unserer Probleme in „basierten Rollups + Preconfs.“ löst. Gemeinsame Sequenzer werden natürlich eher aus einem First-Principles-Ansatz von „Hey, App-Entwickler wollen einfach eine schnelle, zuverlässige und dezentralisierte Chain starten - wie gebe ich ihnen das?“ erstellt. Der Versuch, Preconfs nachträglich auf eine langsamere Basisschicht wie Ethereum hinzuzufügen, führt zu den oben beschriebenen Komplexitäten.

Wir bauen alle dasselbe

Modularität ist unvermeidlich

So haben wir gesehen, wie wir Gate.io-Modularchains wieder zusammenführen können, um eine universelle synchrone Komponierbarkeit (USC) zu gewährleisten. Natürlich gibt es Kompromisse, aber sie führen wieder eine sinnvolle Einheit ein, während sie weit mehr Flexibilität bewahren als die Verwendung einer einzigen Zustandsmaschine. Für mich spricht auch ein sehr überzeugendes Argument dafür, dass asynchrone Komponierbarkeit für die überwiegende Mehrheit der Anwendungsfälle ausreicht. Wir brauchen geringe Latenzzeiten, Leistung und eine gute Benutzererfahrung. Das Internet ist asynchron, und es funktioniert ziemlich verdammt gut, indem es all das abstrahiert. Komponierbarkeit ist ein enormer Mehrwert der Kryptowährung, aber Komponierbarkeit ≠ Synchronie.

Abgesehen von den Vorteilen der Flexibilität und Souveränität würden die meisten Menschen zustimmen, dass wir letztendlich sowieso viele Ketten für die Skalierung benötigen. Das bedeutet, dass wir am Ende viele Systeme haben werden, die wir vereinheitlichen müssen, daher ist die modulare Richtung hier unvermeidlich.

Ethereum + Preconfs → Solana?

Lassen Sie uns jetzt die Endspiele hier vergleichen. Insbesondere werden wir das Solana-Endspiel mit dem Endspiel von Ethereum vergleichen, wenn es diesen Weg der Maximierung von Einheit und Benutzerfreundlichkeit mit basierten Rollups + Preconfs geht.

In dieser Vision haben wir eine Reihe dieser BRs, die den Ethereum-basierten Sequencer verwenden. Gate.iowege werden kontinuierlich Vorschläge ohne Konsensgewicht (d.h. ohne Konsensgewicht) an Benutzer mit geringer Latenz streamen, dann setzen Ethereum-Proposers sie von Zeit zu Zeit in einen vollständigen Block um. Das mag Ihnen bekannt vorkommen, denn das ist im Grunde das, was wir zuvor für Solana mit Shred-Streaming beschrieben haben!

Ist dies also nur ein komplizierteres Solana? Der große Unterschied liegt hier in den Slot-Zeiten:

Ethereum versucht, dies auf einer langsamen Kette hinzuzufügen, was auf den ersten Blick offensichtliche Probleme aufwirft:

• Ethereums Konsens ist für Benutzer viel zu langsam, daher ist der einzige Weg, eine glaubwürdig neutrale schnelle Benutzererfahrung zu erhalten, die Verwendung von vom Vorschlagenden versprochenen Vorbestätigungen auf freiwilliger Basis. Der primäre Engpass heute ist die Signaturaggregation aufgrund seiner riesigen Validator-Set-Größe.MaxEBUnd verbesserte Signaturaggregation könnte hier helfen).
• Dies führt zu viel längeren Vorschlagsmonopolen, die höhere Anreize und Freiheit bieten, um mehr MEV zu erfassen, indem sie unehrlich handeln (z.B. Vorabbestätigungen zurückhalten).
• Wenn Gate.ioways beginnt, Preconfs zu verzögern oder zurückzuhalten, dann fällt der schlimmste Fall für Benutzer zurück und ist abhängig von den Ethereum-Slot-Zeiten. Selbst wenn Solana-Blockproduzenten das kontinuierliche Blockieren und Streaming innerhalb ihrer zugewiesenen Monopole stoppen würden,da es wahrscheinlich vernünftig ist, dass sie aus demselben genauen Grund in gewissem Maße dasselbe tun.) dann fällt der schlimmste Fall auf die Abhängigkeit von einem schnell rotierenden Konsens zurück.Der Vier-Slot-Monopol heute ist jedoch für die Netzwerkzuverlässigkeit erforderlich.
• In der Praxis wird es wahrscheinlich sehr wenige Gate.iowege geben, zumindest zu Beginn, was zu einem zentralisierteren Betreiber-Set im Vergleich zu Ketten wie Solana führt.
• potenziell unglaublich hohe Sicherheitsleistungen für Antragsteller (unter Berücksichtigung, dass der Gestaltungsspielraum noch in Arbeit ist).
• Bedenken über die hier auftretenden Lebensfähigkeitsprobleme sind unglaublich kostspielig (da Betreiber-Lebensfähigkeitsprobleme zu abgewiesenen Vorabkonfigurationen führen und somit zu Sicherheitsfehlern für Benutzer führen, und daher stark strafbar sein müssen).

All dies wird mit einem schnellen Konsens gelöst. Genau aus diesem Grund erstellen wir überhaupt BFT-Systeme. Warum sollte Ethereum also nicht einfach dafür sorgen, dass sein Konsens schneller wird? Gibt es weniger offensichtliche Kompromisse bei extrem niedrigen Latenzzeiten für Blockzeiten auf der Basisebene?

Glücklicherweise habe ich nichts Besseres zu tun, als einen Aufsatz darüber zu schreiben, ob kürzere Blockzeiten gut sind. Die große Sorge bei kürzeren Slot-Zeiten betrifft die Zentralisierung von Validatoren und Betreibern. Insbesondere gibt es Bedenken hinsichtlich der Interaktion von kurzen Slot-Zeiten mit Timing-Spiele:

Wir sehen, dass Timing-Spiele auf Ethereum bereits fortschreiten. Die Antragsteller schlagen Blöcke später in ihren Slots vor und verdienen so auf Kosten anderer mehr Geld. Relais bieten auch „Zeitmessungsspiele als Service„ wodurch sie ähnlich Blöcke später im Slot verzögern:

Quelle: Daten immer

Timing-Spiele waren ein großes Thema der Diskussion auf dem eher berüchtigten Justin gegen Toly Bankless Podcastvor ein paar Wochen:

Zum Beispiel sind Sie 100 ms schneller als alle anderen

Wenn Sie 1s Schlitze haben, können Sie 10% mehr als alle anderen verdienen

Wenn Sie 10-Sekunden-Steckplätze haben, können Sie 1% mehr als alle anderen verdienen.

— jon charbonneau (@jon_charb) 4. Juni 2024

Justin argumentierte hauptsächlich, dass das Timing bei Spielen ein Problem sein wird und die inkrementellen Belohnungen immer relevant sein werden. Toly argumentierte hauptsächlich, dass das Timing bei Spielen kein Problem darstellen wird und dass die inkrementellen Belohnungen, die aus zusätzlicher MEV-Extraktion erzielt werden, nicht ausreichend besorgniserregend sind.

Ich persönlich finde es schwierig, die Bedeutung des Timings von Spielen hier zu ignorieren:

• Wir sehen sie bereits heute in der Praxis auf Ethereum.Das Solana-ArgumentDas ist nur deshalb so, weil MEV in Ethereum früher sozial normalisiert wurde, aber das ist nicht überzeugend, wenn esStarke öffentliche Empörung gegen das Timing von Spielen von Anfang an das sich seither in Akzeptanz verwandelt hatdieser neuen Realität gestaltet werden.
• Mev-Belohnungen sind bedeutend - wir sprechen bereits überMilliarden von Dollar an MEV-Zahlungen hier, nicht ein paar Pfennige unter dem Sofakissen. Selbst "nur ein paar Prozent mehr" damit zu verdienen, ist eine riesige Summe.
• Auch wenn Sie nicht glauben, dass Staker am Rand ausreichend ertragsempfindlich sind, Die tatsächlichen Betreiber führen Unternehmenund das geht direkt auf ihre Gewinne.
• Es ist einfacher für Solana, sich auf altruistische Großaktionäre zu verlassen (z. B. die Stiftung und Großinvestoren) zu einem früheren Zeitpunkt in ihrem Lebenszyklus, Das ist nicht nachhaltig, wenn sich ein Netzwerk weiter dezentralisiert..

Ich denke klar, dass sowohl Solana als auch Ethereum einen enormen Wert in der Richtung haben. Wenn nichts anderes, werden wir es alles in der Praxis sehen. Strategisch gesehen macht es auch für Ethereum Sinn, sich hier auf das zu konzentrieren, was es ausmacht. Maximierung der Dezentralisierung als Mittel zur Erreichung von Zensurbeständigkeit unter widrigen Umständen. Ethereum hat viele Opfer gebracht, um ein unglaublich dezentralisiertes Protokoll zu halten, weil das für das langfristige Spiel notwendig ist. Es hat eine unvergleichliche Vielfalt an Clients, eine Verteilung des Netzwerkbesitzes, Ökosystembeteiligte, Dezentralisierung der Betreiber und mehr. Wenn (und wahrscheinlich wann) Solana in Zukunft ernsthaften Zensurdruck erfährt, wird immer deutlicher, warum Ethereum die Entscheidungen getroffen hat, die es getroffen hat.

preconf.wtf fand erst letzte Woche in Zuberlin statt, und es überrascht vielleicht nicht, dass alle über Preconfs und basierte Rollups sprachen. Und das war alles echt cool. aber ich persönlich fand Vitaliks VortragaufEin-Bit-pro-Attester-Einschlusslistenund Barnabés Rede überÜberlasten Sie stattdessen den Ausführungsvorschlagenden (von mev-boost zu epbs zu aps) das Wichtigste für die Zukunft von Ethereum zu sein.

Quelle: Barnabé monnot, Von mev-boost zu epbs zu aps

Die Preconf- und Based-Rollup-Konversationen haben in letzter Zeit an Dynamik gewonnen, und ich bin definitiv immer noch auf der vorsichtigeren Seite. Vitalik hat bekanntlich das Folgende dargelegt Endspiel:

Allerdings sind wir ziemlich tief in die „zentralisierte Produktion“ eingetaucht, ohne jedoch die stärkeren Anti-Zensur-Schutzmaßnahmen wie Inklusionslisten bereits umgesetzt zu haben. Im Grunde genommen befindet sich Ethereum halb in der unteren Reihe des untenstehenden Bildes. (Ich sage halb, weil Zensur eigentlich nicht schwarz-weiß ist, und Ethereum hat nur „schwache Zensur“, d.h. die meisten, aber nicht alle Blöcke werden zensiert, also müssen Sie vielleicht nur ein wenig warten, aber dann werden Sie inkludiert)

Quelle: Nachweis der Regierungsführung

Empirisch zensiert die Ethereum L1 MEV-Lieferkette derzeit in Echtzeit mehr Blöcke als alle diese L2s mit zentralisierten Sequenzern.

L2s können bereits die endgültige CR von L1 (was immer noch sehr gut ist) erhalten, ohne dass sie basiert sind. Basierende Preconfs erhalten nicht die Echtzeit-Sicherheit des Ethereum-Protokolls, sondern die Echtzeit-Sicherheit der kleinen Handvoll relativ zentralisierten Infrastrukturanbieter um sie herum. Für eine bessere Echtzeit-CR ist die beste Option wahrscheinlich die Auslagerung der Sequenzierung an eine Art dezentralen Sequenzer, der einen einfachen BFT-Konsens ausführt. Dies wird weitaus robuster sein als die Zentralisierung vieler Chains in einen derzeit relativ zentralisierten Engpass. Diese Situation könnte sich mit Änderungen wie Ausführungsauktionen und Inklusionslisten verbessern, aber das steht nicht unmittelbar bevor.

In Anbetracht all dessen ist es mir nicht klar, ob es eine großartige Idee ist, die Abhängigkeit von der MEV-Infrastruktur von Ethereum L1 zu erweitern und sie dann für L2-Infrastruktur zu verankern In dieser Phase, in der es eine Handvoll Leute gibt, die alle Ethereum-Blöcke erstellen und weiterleiten, verlassen sich die meisten zensurfreien Ethereum-Blöcke heute auf einen einzigen Builder (Titan), Und keines der CR-Tools ist bisher im Protokoll implementiert. Das fühlt sich an einer fragilen Stelle aggressiv akzelerationistisch an. Ethereum sollte sicherlich daran arbeiten, die UX von L2s zu verbessern, aber nicht auf Kosten aller zugrunde liegenden Eigenschaften, die wir von vornherein wollten.

Schlussfolgerung

Wir bauen alle dasselbe.

naja, irgendwie. Offensichtlich sind diese Dinge nicht alle buchstäblich dasselbe. Es wird immer praktische Unterschiede zwischen diesen Systemen geben. Der übergeordnete Megatrend in der Kryptobranche ist jedoch klar, dass wir uns alle auf immer ähnlichere Architekturen zubewegen.

Die nuancierten technischen Unterschiede zwischen ihnen können in der Praxis bedeutende Auswirkungen darauf haben, wo sie letztendlich landen, und wir dürfen nicht unterschätzen, welch wichtige Rolle der Pfadabhängigkeit in diesen Systemen zukommt, auch wenn sie sich auf ähnliche Endspiele zubewegen.

Außerdem ist es verdammt unmöglich, über einige dieser Dinge zu vernünftigen.Wie Vitalik es ausdrückte:

„Eine Warnung, die ich für APS habe, ist, dass ich rein technisch gesehen denke, dass es ziemlich leicht ist und wir es problemlos mit sehr geringer Wahrscheinlichkeit für technische Fehler schaffen können... aber aus wirtschaftlicher Sicht gibt es viel mehr Möglichkeiten, dass Dinge schiefgehen können...

Wie bei EIP-1559 konnten wir mit Hilfe der Theorie herausfinden. Wir besuchten einige schöne Wirtschaftskonferenzen und lernten die Gefahren von Erstpreisauktionen und wie schlecht sie sind. Wir stellten fest, dass Zweitpreisauktionen nicht glaubwürdig sind, und entdeckten dann, hey, lasst uns einen Mechanismus verwenden, der innerhalb jedes Blocks einen lokalisierten Festpreis hat, und wir konnten viel mit Mikroökonomie erreichen.

Aber aps ist nicht so, oder? Und die Frage, ob aps dazu führen wird, dass Citadel oder Jane Street oder Justin Sun oder wer auch immer 1% aller Ethereum-Blöcke oder 99% produzieren, ist sehr, sehr schwierig, wahrscheinlich unmöglich, aus den ersten Prinzipien herauszufinden.

Und daher ist das, was ich an dieser Stelle sehen möchte, Live-Experimente... Für mich persönlich liegt der Unterschied zwischen heute und dem Punkt, an dem ich mich wirklich tief mit Aps wohl fühle, darin, dass Aps erfolgreich auf einem Ethereum L2 laufen, der eine mittlere Menge an Wert, Aktivität, Gemeinschaft und tatsächlichen Kontroversen aufweist und das für ein Jahr oder länger anhält, und dass wir tatsächlich in der Lage sind, einige Live-Konsequenzen zu sehen.

Also ja, ich weiß auch nicht, was passieren wird. Wir müssen einfach abwarten und sehen. Auf jeden Fall haben wir während wir uns alle auf dieses Endspiel zubewegen, viel mehr Gemeinsamkeiten als Unterschiede, also lasst uns sicherstellen, dass wir bitte...

Haftungsausschluss:

1. Dieser Artikel wurde aus [wiedergedrucktdba].Weiterleiten des Originaltitels 'We're all building the same thing'. Alle Urheberrechte gehören dem Originalautor [Jon Charbonneau].. Wenn es Einwände gegen diesen Nachdruck gibt, kontaktieren Sie bitte das Gate.io lernen Team, und sie werden sich umgehend darum kümmern.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate.io Learn Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.