Transaktionsgebührenmechanismen sind zu den Arbeitspferd-Modellen geworden, um die Vermittlung von Blockproduzenten zwischen Nutzern, die Transaktionen durchführen möchten, und "der Kette" (oder "dem Protokoll"), auf der die Nutzer Transaktionen durchführen, zu verstehen. Angesichts der Möglichkeit, einen Teil des von der Chain bereitgestellten Angebots zu nutzen, müssen die Blockproduzenten entscheiden, welche Nutzer die knappe Ressource der On-Chain-Ausführung nutzen können und zu welchen Kosten. Bei Ethereum sind die Blockproduzenten in Bezug auf die Kosten durch den EIP-1559-Gebührenmechanismus eingeschränkt, der dynamisch einen Reservepreis von Block zu Block festlegt, der als "Basisgebühr" bezeichnet wird. Die Grundgebühr ist ein Preis, ausgedrückt pro Gaseinheit, den eine Benutzertransaktion zahlen muss, um einbezogen und ausgeführt zu werden. Der Nutzer kann über die Grundgebühr hinaus sogenannte "Priority Fees" vorsehen, um den Blockproduzenten in Zeiten der Überlastung weitere Anreize zu bieten.

In diesem Hinweis untersuchen wir die Frage der eingebetteten Gebührenmärkte, d. h. Gebührenmärkte, die innerhalb anderer Gebührenmärkte „leben“. Diese Frage wurde in einem anderen Zusammenhang in einem kürzlich erschienenen Artikel von Maryam Bahrani, Pranav Garimidi und Tim Roughgarden diskutiert: „Mechanismusdesign der Transaktionsgebühr in einer Post-MEV-Welt 9In dieser Arbeit modellieren die Autoren die Nutzung von Suchenden, die den Zugang zur Kette zwischen Benutzern und Blockproduzenten weiter vermitteln. Blockproduzenten erhalten "Hinweise" von Suchenden, verkörpert durch atomare Bündel von Transaktionen, die von der Kette aufgenommen werden sollen. Der Gebührenmarkt der Suchenden wird durch das Maximierungsziel einer Größe namens MEV (maximal extrahierbarer Wert) gesteuert.

In unserer Umgebung möchten Benutzer auf die Kette zugreifen, drücken jedoch ihre Nachfrage nicht mit protokolllesbaren Transaktionen aus. Stattdessen erstellen Benutzer „Operationen“, die von Entitäten namens „Bundler“ gebündelt werden, die dann eine protokolllesbare Transaktion erstellen, in der die Operationen für die Ausführung zusammengefasst werden. Somit sind Bundler gemäß dem EIP-1559-Gebührenmechanismus die Benutzer der Kette, aber die tatsächlichen Benutzer müssen zuerst in das Bundle eines Bundlers aufgenommen werden, bevor sie in die Kette aufgenommen werden können. Mit anderen Worten, wir können diese Einstellung als Teil der größeren Frage sehen vonBlock Co-Creation, die bei (teilweisen) Erstellern/Suchern sowie Einbeziehunglisten entsteht.

Unsere Hoffnung ist, dass diese Dynamiken so transparent wie möglich sind, so dass es weder mehr kognitiven Overhead noch Möglichkeiten für den Benutzer gibt, vom Bündler im Vergleich zur direkten On-Chain-Nutzung unangemessen ausgenutzt zu werden. Wir hoffen auf noch stärkere Ergebnisse, Fälle, in denen die Benutzer tatsächlich von der Bündler-Vermittlung profitieren, wenn die amortisierten Kosten es den Benutzern ermöglichen, ein größeres Wohlergehen zu genießen.

Um den Unterschied zwischen direkten Gebührenmärkten und ihren eingebetteten (Teil-)Mechanismen zu untersuchen, müssen wir die wirtschaftlichen Zwänge präzisieren, denen ein Bündler unterliegt. Im folgenden Abschnitt bieten wir ein einfaches Modell der Bündler-Kostenfunktion an, das durch die Praxis motiviert ist, insbesondere durch Bündler, die am ERC-4337-Protokoll teilnehmen, das wir kurz zusammenfassen.

Modell

Bündelung in ERC-4337

Ein Benutzer, der über Bündler eine Aktivität on-chain durchführen möchte, gibt eine Benutzeroperation (UserOp oder Operation) aus. Diese UserOp wird aus der Brieftasche des Benutzers ausgestrahlt, z. B. nach der Interaktion mit einer DApp. Sobald die UserOp gesendet wurde, kann ein Bündler, der die Operation empfängt, entscheiden, sie in ein Bündel aufzunehmen. Ein Bündel ist eine „externally-owned account“ (EOA) Meta-Transaktion, die die Daten der enthaltenen UserOps in ihrem bundle.calldata-Feld speichert. Der Bündler sendet das Bündel zur Aufnahme in einen Block durch einen Blockproduzenten (wir diskutieren das Verhältnis zwischen Bündler und Blockproduzenten in einer zukünftigen Notiz).

Sobald das Bündel in den Block aufgenommen ist und der Block seinen Weg zur Kette gefunden hat, wird das Bündel zusammen mit anderen Transaktionen im Block ausgeführt. Im Wesentlichen lauten die Schritte zur Bündelausführung wie folgt:

• Vorabprüfung: Eine EOA-Transaktion eines Bündlers verbraucht 21.000 Gas, und der Aufruf des EntryPoint-Vertrags richtet Schlüsselvariablen ein, um die Ausführung der Operationen in der Operations-Schleife zu verfolgen.
• Vorgangsschleife 3: Für jede Operation, die im Bundle enthalten ist, finden die folgenden zwei Schritte statt:
  • Verifizierungsschritt: UserOps führen Operationen durch, die einen Verifizierungsschritt enthalten, der ursprünglich vom Benutzer in einer „Smart Contract Wallet“ codiert wird (während einer anfänglichen UserOp bereitgestellt). Der Verifizierungsschritt kann einfach eine Signatur überprüfen oder komplexere Operationen durchführen, um das Recht für die Ausführung der UserOp zu „gewähren“. Der Verifizierungsschritt wird durch op.verificationGasLimit gemessen.
  • Ausführungsschritt: Der Kern des UserOp, der Ausführungsschritt führt die in op.callData beschriebene Operation aus. Dieser Schritt wird auch mit op.callGasLimit gemessen.

Wie aus der vorherigen Zerlegung ersichtlich wird, wird der Vorverifikationsschritt einmal ausgeführt, was die Möglichkeit bietet, die Vorverifizierungskosten auf alle enthaltenen Benutzer zu verteilen. Wenn das Bündel ausgeführt wird, werden alle Kosten (z. B. block.basefee + Prioritätsgebühren, die der Bündler dem Blockproduzenten zahlt und einschließt) dem Bündler in Rechnung gestellt, der sicherstellen muss, dass die Benutzeroperationen sie ausreichend für die entstandenen Kosten entschädigen. Wir präzisieren diese Aussagen im folgenden Abschnitt.

Gebührenmarktmodell für Bündel

Wir versuchen, konsistent mit klassischen Gebührenmarktmodellen zu bleiben. Ein Benutzer t, der eine Operation ausführen möchte, hat einen Wert vt für die Ausführung der Operation. Wir nehmen an, dass alle Operationen die gleiche Größe S haben (d. h. dasselbe Gas für die Verifizierungs- und Ausführungsschritte verwendet wird), und wir drücken daher alle Mengen als Preise pro Einheit Gas aus.

Benutzer geben ihren Wunsch an, indem sie ein Gebot bt zusammen mit ihrer Operation abgeben. Derzeit gehen wir nicht davon aus, dass der Benutzer eine spezifische Grammatik verwendet, um sein Gebot für die Aufnahme auszudrücken, z. B. die Möglichkeit, eine maximale Gebühr und Prioritätsgebühr zusammen mit seiner Operation auszudrücken, wie es bei EIP-1559 der Fall wäre. Benutzeroperationen werden in einem Mempool M gesammelt, der den ausstehenden Status dieser Operationen bis zur Aufnahme darstellt.

Der Gebührenmarkt EIP-1559 legt einen Reservierungspreis r fest, der als "Grundgebühr" bekannt ist und den Bündler tragen muss, wenn sein Paket ausgeführt wird. Wenn das Paket n Operationen enthält, muss der Bündler mindestens n × S × r ausgeben. Zusätzlich, da das Paket "Vorprüfgas" verbraucht, sagen wir, eine Menge F, wird der Bündler zusätzlich F × r bezahlen.

. Die in dem Bundle enthaltenen Operationen werden durch die Menge B gegeben.

Bundler Kostenfunktionen

Wir betrachten nun die Kosten, die von den Bündlern für die Aufnahme ihrer Bündel in den Block getragen werden.

On-Chain-Kostenfunktion: Ein Bündler, der das Bundle B ausgibt, wenn die Basengebühr r beträgt, verursacht eine Kosten:

Das Bündelproblem spiegelt das Blockproduzentenproblem wider, das im [Roughgarden 2021] 3. Dort musste der Blockproduzent sicherstellen, dass er einen gewissen Wert μ bereitstellt, der sie für die Kosten der Aufnahme einer zusätzlichen Transaktion in ihren Block entschädigt (z.B. μ kann für die zusätzliche Last des Blocks entschädigen, was seine Verbreitung verzögert und das Re-Org-Risiko erhöht). Der Gebührenmarkt auf Blockebene muss dann sicherstellen, dass der Blockproduzent zumindest für die Gesamtkosten n × S × μ entschädigt wird, wenn der Blockproduzent n Transaktionen in seinen Block aufnimmt. Der Gebührenmarkt auf Bundesebene wird zumindest die Verursacher von exogenen Kosten entschädigen müssen.

Con-Chain(B,r), die sie aus dem größeren Gebührenmarkt generieren, in den sie eingebettet sind.

ERC-4337 bietet die Möglichkeit, Kosten über die gemeinsame Nutzung der Vorverifizierungsgaskosten hinaus abzuschreiben. Wenn alle Operationen das gleiche Signaturschema für ihren Verifizierungsschritt verwenden, können die Signaturen dieser Operationen möglicherweise sein.aggregiert 2durch den Bündler, so dass anstelle der Überprüfung von n Signaturen on-chain eine einzelne Signatur überprüft werden kann. In diesem Fall muss die Kostenfunktion des Bündlers die außerhalb der Kette anfallenden Kosten berücksichtigen, die beim Durchführen der Aggregation entstehen. Im Folgenden gehen wir davon aus, dass diese Kosten linear mit der Anzahl der Operationen sind, eine ähnliche Annahme wie [Wang et al., 2024] 2, zu einem marginalen Kosten ω.

Wir berücksichtigen auch den reduzierten Gasverbrauch jedes Betriebs, der auf die Einsparungen durch die Aggregation zurückzuführen ist. Bei aggreGated ist es nicht erforderlich, dass Vorgänge ihre Signatur veröffentlichen, aber sie erfordern einen zusätzlichen Kopplungsvorgang. Bei Chains, bei denen die Kosten für Aufrufdaten teuer sind, aber die Paarungsoperationen/Berechnungen billig sind, bietet die Aggregation somit Einsparungen pro Vorgang. In diesem Fall bezeichnen wir mit S′ < S die reduzierte Größe einer Transaktion. Wir müssen auch den erhöhten Gasverbrauch vor der Verifizierung berücksichtigen F′ > F, der nun die Veröffentlichung und Verifizierung der einzelnen aggreGated On-Chain-Signatur enthält.

AggreGated Kostenfunktion: Ein Bundler, der Bundle B mit aggreGated Signaturen ausgibt, wenn die Grundgebühr r ist, verbraucht Kosten:

In dieser Notiz werden wir nicht weiter gehen, aber man kann auch die Kosten für die Datenveröffentlichung in Betracht ziehen, die ein Bündler möglicherweise aufwenden muss, wenn ihr Bundle in einem Rollup abgewickelt wird. Wir schlagen zwei Möglichkeiten vor, dies zu modellieren, und lassen diese Frage für zukünftige Arbeiten offen.

• Entweder ist die Bündlerin selbst für die Veröffentlichung der Daten verantwortlich (z. B. als Sequenzerin) und muss daher von den Benutzern die erforderliche Menge an Geldern erhalten, um eventuelle Kosten für die Veröffentlichung der Daten zu decken.
• Oder der Gebührenmarkt auf Bundle-Ebene ist eingebettet in einen größeren Gebührenmarkt auf Batch-Ebene, über den das Rollup den Rollup-Benutzern (einschließlich des Bundlers) den Betrag preisgibt, den sie aufgrund von Überlastung (z. B. eine Grundgebühr) und eventuellen Kosten für die Datenveröffentlichung zahlen müssen. In diesem Fall ist der Rollup dafür verantwortlich, seine eigenen zukünftigen Kosten mit seinen aktuellen Einnahmen auszugleichen.

Überprüfung der Gebührenmarktmengen

Wir können nun die relevanten Konzepte für den Gebührenmarkt auf Bundle-Ebene formal ausdrücken und sie unkompliziert aus der bisherigen Literatur ableiten, wobei wir die Einbettung berücksichtigen.

Bundle-Level-Allokationsregel: Eine (Bundle-Level)-Zuweisung x bestimmt die Menge der Benutzeroperationen, die der Bündler in sein Bündel aufnimmt, basierend auf dem aktuellen Mempool M und der Basisgebühr r.

Bundle-Level-Zahlungsregel: Angesichts des ausgewählten Betriebs B weist eine Zahlungsregel jedem eingeschlossenen Benutzer eine Gebühr zu:

Benutzer-Nutzenfunktion:

Im Prinzip könnten wir das Vorhandensein einer Brennregel qt(B) zulassen, die besagt, dass der Bündler nicht die Gesamtheit aller enthaltenen Benutzerzahlungen erhalten darf. Wir betrachten dies jedoch nicht in dieser Notiz.

(Myopic) Bündler-Hilfsfunktion:

Ein Bundle-Level-TFM (x,p) ist für kurzfristig orientierte Bündler (MBIC) anreizkompatibel, wenn ein kurzsichtiger Bündler unabhängig von der Mempool M und der Basisgebühr r seinen Nutzen maximiert, indem er dem Vorschlag der Zuordnungsregel x folgt (d.h. B = x(M,r) festlegt).

Bildung mehrerer Bündel

In dem vorangegangenen Abschnitt haben wir nur die Möglichkeit in Betracht gezogen, dass der Bündler nur ein einziges Bündel ausgeben kann. Allerdings könnten wir an der Möglichkeit interessiert sein, dass der Bündler mehr als ein Bündel aus den in der Mempool verfügbaren Operationen erstellen kann. Angenommen die Mempool M, dann stellt P(M) die Menge der Partitionen der Mempool dar, die jede Operation einem einzelnen Bündel zuweisen (wir können annehmen, dass für jede Partition ein Satz mit dem Index 0 existiert, der alle Operationen enthält, die nicht einem Bündel zur Aufnahme zugewiesen sind). Die Zuordnungsregel gibt dann den Index des Satzes in der Partition zurück, dem die Operation zugewiesen ist.

Wir können die Menge der Bündel, die von der Partition x(M,β) ausgegeben werden, als B(x(M,r)) schreiben. Intuitiv werden diese Bündel aus den Operationen zusammengesetzt, die nicht zur Menge indiziert 0 gehören. Bei einem Satz von Bündeln B lautet die Zahlungsregel dann:

Die Benutzerdienstprogrammfunktion wird zu:

und die Bündelungsdienstprogrammfunktion wird:

Das Bundler-Spiel

Die Aufnahme von Transaktionen in Blöcke muss den Blockproduzenten eine bestimmte Menge μ als Vergütung zukommen lassen, die beispielsweise linear von der Transaktionsgröße abhängt.[Roughgarden, 2021] 3. Diese Menge bezeichnet den Opportunitätskosten für den Blockproduzenten, um eine zusätzliche Transaktion zu ihrem Block hinzuzufügen, z.B. durch Erhöhung ihrer Gossiping-Verzögerung und damit Erhöhung ihrer Chancen, dass der Block neu organisiert wird. Im Proof-of-Stake, auch wenn der Zeitplan des Protokolls genügend Zeit für die vollständige Verbreitung eines Blocks erlaubt, Timing-Spielehaben "Last-Second"-Propagationsdynamiken induziert, die diesen μ-Parameter erneut relevant gemacht haben.

In jedem Fall können wir feststellen, dass das Kostenbeteiligungsproblem auf Blockebene und auf Bündelebene sehr unterschiedlich sind. Auf Blockebene muss eine Transaktion nicht wissen, was sonst noch im Block passiert, um ihr Einbeziehungsgebot gemäß EIP-1559 zu entwerfen (sie möchte möglicherweise wissen, was in Bezug auf MEV passiert.[Bahrani et al., 2024] 9, aber wir werden dies vorerst als separates Problem betrachten). Auf Bündelebene sind die Bündel-Overhead-Kosten nicht mehr linear zur Anzahl der Transaktionen, sondern ein fester Overhead kann durch viele Transaktionen amortisiert werden. Darüber hinaus sollten die Aggregationskosten der Benutzeroperationen nicht linear zur Anzahl der Transaktionen sein (z.B. sind einige Beweise effektiv sublinear in der Größe, die bewiesen wird), wodurch die Möglichkeit besteht, die Gesamtkosten über viele Benutzer zu amortisieren.

Dies führt zu folgendem Spiel: Der Bündler wünscht, dass Benutzer ihre Gebote so platzieren, als ob sie für den schlimmsten Fall bieten würden, in dem der Benutzer allein im Bündel ist und den vollen Overhead-Gas F selbst kompensieren muss. Praktisch gesehen wäre der Benutzer mit dem Problem konfrontiert, drei relevante Parameter für ihre Operation festzulegen:

• op.maxPriorityFeePerGas und op.maxFeePerGas können gemäß den Heuristiken festgelegt werden, die ein Benutzer unter EIP-1559 verwenden würde, d.h. bei einer geschätzten Menge an Gas, die ihre Operation verbrauchen wird, würde der Benutzer diese Attribute einstellen, um zu kalibrieren, wie viel er im schlimmsten Fall bereit ist zu zahlen (maxFee) und wie viel er bereit ist aufzustocken, um den eventuellen Blockproduzenten zu bezahlen (maxPriority). Aber wie soll der Benutzer das Gas schätzen?
• op.preVerificationGas ist ein Attribut von UserOperation, das festgelegt werden muss, um die Menge an "zusätzlichem Gas" anzugeben, die der Betrieb des Benutzers verbrauchen möchte. In unserem Modell lassen wir
• F bezeichnet diesen "festen Gas-Overhead". Wenn n Benutzer in das Bundle aufgenommen wurden, sollte jeder Benutzer preVerificationGas = F / n setzen. Wenn der Benutzer jedoch sein Verfahren mit einem Worst-Case-Szenario im Hinterkopf vorbereitet, würde er preVerificationGas = F setzen.

preVerificationGas ist dann der Hauptvektor, über den Benutzer ihre Gebote vermitteln und versuchen, die Amortisation der Kosten durch den Bündler zu berücksichtigen. Nehmen wir an, n Benutzer kommen mit ihren Operationen auf den Markt und werden alle vom Bündler überzeugt, im schlimmsten Fall alleine im Bundle zu bieten. Wir nehmen auch an, dass die Benutzer ihren maxPriorityFeePerGas für dieses Beispiel auf null setzen. Dann setzen diese n Benutzer alle preVerificationGas = F und der Bündler ist in der Lage, ein Bundle auszugeben, das sie vergütet mit:

während sie Kosten tragen müssen:

Sobald sie das Bundle veröffentlicht haben, bündeln sie alle n Vorgänge in einem Block. Dies bringt dem Bündler einen Gewinn π = (n−1)×F×r.

Diese Situation kann als zweistufiges Spiel dargestellt werden, bei dem die Benutzer zunächst ihre Benutzeroperationen erstellen und der Bündler anschließend entscheidet, ob er sie bündelt. Wir nehmen an, dass Benutzer keine Informationen über die aktuelle Anzahl ausstehender Benutzer besitzen und daher nicht in der Lage sind, die wahre Fähigkeit des Bündlers zur Amortisierung ihrer Fixkosten abzuschätzen.

In der ersten Phase senden Benutzer ihre Operationen, die sich auf ihre Attribute wie preVerificationGas beziehen. In der zweiten Phase entscheidet der Bündler, nachdem er alle Benutzertransaktionen erhalten hat, ob er einen Bundle oder eine Reihe von Bundles ausgeben soll. Interessanterweise kann der Bündler selbst dann, wenn die Benutzer wissen, wie viele andere Benutzer in der ersten Phase spielen werden, d. h. selbst wenn n allen Benutzern bekannt ist, die Benutzer dazu zwingen, den worst-case preVerificationGas = F zu setzen, indem er damit droht zu spielen.

, d.h. damit droht, jeden Benutzer in seinem eigenen separaten Paket zu behalten und ihm den maximalen Gasbetrag in Rechnung zu stellen.

Beachten Sie, dass diese Bedrohung möglicherweise nicht glaubwürdig ist, da Benutzer erwarten würden, dass der Bündler bevorzugt spielt.

, d. h. eine einzelne Bündelung mit allen darin enthaltenen Operationen ausgeben, um π zu realisieren. Allerdings haben Benutzer möglicherweise keinen Zugriff auf den wahren Wert von n und können daher ihren preVerificationGas-Wert nicht so festlegen, dass der Bündler idealerweise alle von ihnen gebündelt.

Idealfall: Die Kosten werden zwischen den Benutzern im Bundle aufgeteilt. Pessimistischer Fall: Benutzer zahlen zu viel und die Kosten werden nicht aufgeteilt.731×755 77.6 KB

Eine Erweiterung dieses Modells könnte den bayesschen Fall berücksichtigen, bei dem die Benutzer Zugriff auf eine Verteilung über n haben, d.h. sie können erwarten, dass zu jedem gegebenen Zeitschritt einige Zufallsvariablen n Benutzer auftreten, gemäß einer Verteilung (z.B. Poisson-Arrivals), selbst wenn sie das Ergebnis der Zufallsvariable im Voraus nicht kennen. Dies kann zu ineffizienten Ergebnissen führen, wie das folgende Beispiel zeigt:

Alice erwartet, dass außer ihr 9 weitere Benutzer auftauchen, und so setzt sie ihre preVerificationGas auf 1, da sie weiß, dass F = 10 ist. Alices Wert und der Wert aller anderen Benutzer ist damit kompatibel, dass sie preVerificationGas = 3 setzen, aber sie versucht, so wenig wie möglich für ihre Aufnahme zu bezahlen. Wie sich herausstellt, erscheinen nur 5 Benutzer auf dem Markt, die alle ihre preVerificationGas ebenfalls auf 1 gesetzt haben. Der Bundler wird für F = 10 Gaseinheiten nicht entschädigt, daher gibt der Bundler kein Bundle aus und die Benutzer erhalten 0 Utility. Dies ist offensichtlich suboptimal, da die Benutzer z. B. alle preVerificationGas = 2 festlegen und 1 Dienstprogramm erhalten könnten (das maximale preVerificationGas, das sie bereit waren einzustellen, abzüglich des tatsächlichen preVerificationGas, das sie bezahlt haben, um einbezogen zu werden).

Zukünftige Arbeit

Wie das Bundler-Spiel zeigt, steht der Benutzer vor einem Allokationsproblem, das vom Bundler aufgenommen werden möchte. In der nächsten Notiz werden wir verschiedene Ansätze zur Wiederherstellung einer "guten UX" für den Benutzer ansprechen, um zu verhindern, dass er einem Bundler, der besser über die Nachfrage nach seiner Bundle-Kapazität informiert ist, zu viel bezahlt. Die nächste Untersuchung erfordert ein Verständnis der Marktstruktur, die Nutzer, Bundler und Builder/Blockproduzenten miteinander verbindet.

Haftungsausschluss：

1. Dieser Artikel wurde von [ wiederveröffentlichtethresear], Alle Urheberrechte gehören dem Originalautor [ DavideRezzoli]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an den Gate LernenTeam, und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel ausgedrückt werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.