Zum Inhalt springen
Financial Context Wiki

RPC für private Transaktionen

Ein RPC für private Transaktionen leitet eine signierte Transaktion oder ein Bundle vor der Verbreitung im öffentlichen Mempool an eine begrenzte Gruppe von Providern, Relays oder Buildern weiter; er ändert die anfängliche Offenlegung, nicht die Garantien für Gültigkeit, Aufnahme, Preis oder Finalität.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Ein RPC für private Transaktionen sendet eine signierte Transaktion oder ein geordnetes Bundle über einen begrenzten Dienstpfad, bevor sie im öffentlichen Mempool verbreitet wird. Dieser Pfad kann einen RPC-Provider, ein Relay, ausgewählte Builder und bei offengelegten Hinweisen auch Searcher umfassen. „Privat“ beschreibt somit die anfängliche Verteilung, nicht Verschlüsselung, Anonymität oder Unsichtbarkeit für Intermediäre.

Der Dienst kann die Gefahr von Kopien, Frontrunning oder Sandwich-Angriffen aus dem öffentlichen Mempool verringern, garantiert aber weder Aufnahme noch EVM-Erfolg, bestmögliche Ausführung, MEV-Rückerstattung oder Finalität. Eine Provider-Bestätigung oder ein zurückgegebener Transaktions-Hash belegt nur, dass die Anfrage diese Schnittstelle erreicht hat. Verteilung an Builder, Auswahl des Payloads, Blockaufnahme, status des Belegs, Zugehörigkeit zur kanonischen Kette und Finalität sind getrennte Zustände.

Private Methoden sind nicht austauschbar. Eine einzelne eth_sendPrivateTransaction, ein älteres eth_sendBundle und ein mev_sendBundle können sich bei Zielblöcken, geordneten Inhalten, zulässigen Reverts, Ersetzung oder Stornierung, Builder-Auswahl, Privacy Hints und Erstattungsregeln unterscheiden. Entscheidend sind die exakte Chain, der Endpoint, die API-Version und der signierte Payload.

Funktionsweise

Die Wallet erstellt und signiert zunächst eine gewöhnliche Chain-Transaktion mit Chain-ID, Nonce, Ziel, Wert, Calldata, Gaslimit und EIP-1559-Gebührenobergrenzen. Privates Routing ändert nur den Einreichungsort dieser signierten Bytes; Nonce-Reihenfolge, Saldo- und Allowance-Prüfungen, Vertragsausführung, Base-Fee-Regeln und Konsensvalidierung bleiben bestehen. Dieselben signierten Bytes ergeben beim erneuten Senden denselben Hash; eine Ersetzung mit derselben Nonce, aber anderen Gebühren oder Calldata, hat einen anderen Hash.

Der Provider kann den Payload gegen einen bezeichneten Zustand simulieren und an einen oder mehrere Builder verteilen. Die Simulation gilt nur für diesen Zustand: Salden, Storage, Orakelwerte, konkurrierende Transaktionen und Base Fee können sich vor der Blockerstellung ändern. Ein Builder kann eine gültige Transaktion auslassen, weil sie zu spät kam, zu wenig zahlte, gegen einen wertvolleren Block verlor oder den vom Proposer gewählten Builder nie erreichte.

Bundles ergänzen eine geordnete Ausführungsregel. Ein erforderlicher Revert kann ein Bundle unzulässig machen; ein ausdrücklich erlaubter Revert kann Gas verbrauchen und frühere erfolgreiche Zustandsänderungen des Bundles bestehen lassen. Das ist kein automatischer vollständiger Rollback. Privacy Hints können Transaktions-Hash, Vertragsadresse, Funktionsselektor, Calldata oder Logs offenlegen; ein schneller Modus oder breiter Builder-Fanout erhöht Reichweite sowie meist den Vertrauens- und Offenlegungskreis.

Nonce- und Timeout-Verwaltung benötigen eine ausdrückliche Zustandsmaschine. Eine private Pending-Transaktion kann in der gewöhnlichen Pending-Sicht eines öffentlichen RPC fehlen und spätere Nonces blockieren. Eine Provider-Stornierung beendet nur künftige Übermittlungen auf kontrollierten Pfaden; bereits geteilte, öffentlich gesendete oder aufgenommene Kopien werden nicht zurückgerufen. Eine Same-Nonce-Ersetzung oder ein öffentlicher Fallback konkurriert mit allen verbleibenden Versionen und legt den Orderflow wieder öffentlich offen.

Gehen Sie wie folgt vor:

  1. Chain-ID, Provider und API-Version festlegen; Methode für Einzeltransaktion oder Bundle wählen und Logging, Verteilung an Builder oder Searcher, Privacy Hints, Reverts, Erstattung und öffentlichen Fallback dokumentieren.
  2. Exakte unsignierte Absicht und signierten Payload dekodieren: Absender, Nonce, Ziel, Wert, Calldata, Allowances, Gaslimit, Gebührenobergrenzen, Deadline, Mindestausgabe, Zielblockbereich und jedes geordnete Bundle-Element.
  3. Gegen einen identifizierten Block und Zustand simulieren; Erfolg, Revert, Zustandsänderung, Slippage, Saldoänderungen, zulässige Fehler, Gesamtgas und das schlechteste wirtschaftlich gültige Ergebnis testen.
  4. Über den vorgesehenen Endpoint einreichen und Transaktions- oder Bundle-Hash, Request-ID, Authentifizierungsidentität, Zeitstempel, Ziel- oder Maximalblock, Builder, Hints und Original-Payload aufbewahren.
  5. Provider-Bestätigung, Simulation, Builder-Verteilung, private Nonce und Ablauf getrennt vom kanonischen Beleg überwachen; Zielblock- und Gebührenannahmen vor erneutem Senden aktualisieren.
  6. Zur Deadline ausdrücklich warten, stornieren, mit derselben Nonce ersetzen oder über einen öffentlichen Fallback offenlegen; nie annehmen, dass eine Stornierung Kopien zurückruft, und konkurrierende Versionen nur mit Race-Überwachung senden.
  7. Auf der richtigen Chain status des Belegs, Logs, Salden, Ausgabe, effektiven Gaspreis und Erstattung abstimmen; danach den benötigten Zustand safe oder finalized abwarten und Reorgs, Lecks oder unerklärte Ausführungsabweichungen untersuchen.

Beispiele

  • Ausgabeschutz ist keine bestmögliche Ausführung. Ein Swap nennt 100,000 USDC Eingabe und 98,800 USDC Mindestausgabe. Die öffentliche Ausführung liefert 98,950 USDC, also 1,050 USDC oder 1.05% unter Parität, aber nur 150 USDC über dem Minimum. Privates Routing kann Beobachtung verringern, garantiert aber keine bessere Ausgabe als ein anderer öffentlicher Handelsplatz oder RFQ.
  • EIP-1559-Aufnahmegrenze. Eine Transaktion nutzt 180,000 gas; die Base Fee beträgt 30 gwei, die Priority-Obergrenze 2 gwei und die maximale Gebühr 40 gwei. Der effektive Preis ist min(40, 30 + 2) = 32 gwei, die Gebühr somit 180,000 x 32 = 5,760,000 gwei = 0.005760 ETH. Beträgt die Base Fee eines Kandidatenblocks 42 gwei, deckt die maximale Gebühr von 40 gwei sie nicht; privates Routing macht die Transaktion dort nicht aufnahmefähig.
  • Same-Nonce-Fallback-Race. Privater Payload A und öffentlicher Fallback B verwenden beide Nonce 42. Es gibt zwei Einreichungen, doch die kanonische Chain kann Nonce 42 nur einmal verbrauchen. Wird A in Block N + 2 aufgenommen, ist B veraltet; landet B zuerst, ist A veraltet. Eine Stornierungsbestätigung ist kein Undo; jede verbleibende Kopie muss überwacht werden.
  • Erlaubter Revert ist kein atomarer Rollback. In einem geordneten Bundle nutzt die Genehmigung 45,000 gas, und ein Swap revertiert nach 120,000 gas bei effektiv 25 gwei. Ohne Allowed-Revert-Regel wird das Bundle gemäß dieser Regel ausgeschlossen. Ist der Swap-Revert erlaubt und wird das Bundle aufgenommen, kann die Genehmigung bestehen bleiben, der Swap hat status = 0, und die Gaskosten betragen (45,000 + 120,000) x 25 gwei = 0.004125 ETH.

Risiken

  • Die Wallet verwendet die falsche Chain, den falschen Provider, Endpoint oder die falsche API-Version.
  • DNS, TLS, API-Key oder RPC-Schnittstelle werden durch Phishing oder Kompromittierung angegriffen.
  • Der Provider verknüpft IP, Konto, Zeitpunkt und signierte Payload-Daten.
  • Ein Relay protokolliert, leakt, kopiert oder sendet die vollständige Transaktion erneut.
  • Privacy Hints legen Hash, Selektor, Vertrag, Calldata oder Logs offen.
  • Schneller Modus oder breiter Builder-Fanout vergrößern Vertrauens- und Offenlegungskreis.
  • Ein Builder oder Searcher zensiert, kopiert oder nutzt privaten Orderflow aus.
  • Die Simulation verwendet den falschen Block oder veraltet vor der Blockerstellung.
  • Vertragszustand, Salden, Preise oder Reihenfolge ändern sich und verursachen einen Revert.
  • Base Fee, Maximal- oder Priority-Gebühr machen den Payload unattraktiv oder ungültig.
  • Eine Nonce-Lücke oder unsichtbare private Pending-Transaktion blockiert spätere Nonces.
  • Stornierung oder Same-Nonce-Ersetzung verliert ein zeitliches Race.
  • Ein stiller öffentlicher Fallback stellt die MEV-Exposition des öffentlichen Mempools wieder her.
  • Zielblock, Maximalblock, Zeitstempel oder Dienst-TTL werden missverstanden.
  • Bundle-Reihenfolge oder Allowed-Revert-Regel hinterlässt eine unbeabsichtigte Zustandsänderung.
  • Builder-, Relay- oder Proposer-Abdeckung beziehungsweise Zensur verhindert die Aufnahme.
  • Provider-Ausfall, Rate Limiting oder Latenz verpasst das gültige Zeitfenster.
  • Privates Routing wird mit Slippage-Schutz oder bestmöglicher Ausführung verwechselt.
  • Belegstatus, Logs, Salden, Gebühren oder Erstattungen werden falsch abgestimmt.
  • Ein Reorg, eine verfrühte Finalitätsannahme oder eine L2-Sequencer-Grenze kehrt die Schlussfolgerung um.

Häufige Irrtümer

  • Privat bedeutet verschlüsselt, anonym und unsichtbar. Provider und ausgewählte nachgelagerte Parteien können den vollständigen Payload oder offengelegte Hints sehen.
  • Ein privater RPC garantiert kein MEV und den besten Preis. Er ändert die Verteilung; Vertragsgrenzen, Handelsplatzvergleich und Ausführungsqualität bleiben maßgeblich.
  • RPC-Erfolg oder Transaktions-Hash bedeuten Aufnahme, Erfolg und Finalität. Bestätigung, Beleg, EVM-Status und Finalität sind getrennte Zustände.
  • Stornierung oder Same-Nonce-Ersetzung sind garantiert. Kopien und konkurrierende Versionen laufen gegeneinander, bis eine aufgenommen wird oder alle ablaufen.
  • Eine private Transaktion ist automatisch ein atomares Bundle. Einzeltransaktionen und Bundle-Formate haben unterschiedliche Reihenfolge- und Revert-Semantik.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...