Schnelle Blockchains bringen neue Herausforderungen für das Bandbreitenmanagement und die Fairness von RPC mit sich. Heute führen wir einen Mechanismus zur Gestaltung des RPC-Zugangs mithilfe von Liquid Staking-Verpflichtungen ein. Das System ist über FastLane's ShMonad RPC aktiv. Dieser Thread untersucht die Architektur und die Gründe dafür. 🧵

Hochdurchsatznetzwerke wie Monad (~0,5s Blockzeit, ~1s Finalität) lassen wenig Raum für reaktive Drosselung. Bis ein RPC-Endpunkt erkennt, dass er unter einem Spam-Angriff steht, ist der Schaden bereits angerichtet. Die Minderung muss proaktiv und anreize-aligniert sein. /2

Die wichtigste Einschränkung ist die Bandbreite. Validator-nahe Knoten sind ressourcenbeschränkt und latenzsensibel. Wenn der uneingeschränkte Zugang ohne Differenzierung gewährt wird, können feindliche Clients ehrliche Teilnehmer verdrängen – was zu einer verschlechterten Benutzererfahrung und Validator-Kosten ohne Abhilfe führt. /3

Unsere Lösung nutzt ShMonad, ein programmierbares Liquid Staking Token (LST) mit On-Chain-Commitment-Funktionen. Benutzer erhalten eine private RPC-URL im Austausch für das Committen von ShMON zu einer On-Chain "RPC-Richtlinie". Dieses Commitment regelt die Zugriffsrate.

Die Bandbreite wird proportional zugewiesen: RPS des Benutzers = (ShMON des Benutzers / insgesamt zugewiesenes ShMON) × RPS_max-global Dies ergibt ein dynamisch teilbares, stake-gewichtetes Bandbreitenmodell, ohne zentrale Off-Chain-Rate-Limiter einzuführen. 5/

Stake ist für eine Dauer (derzeit 20 Blöcke) gebunden, was Caching ermöglicht. Der Relay fragt intermittierend ab und erstellt Schnappschüsse des On-Chain-Commitment-Zustands. Dies verhindert EVM-Aufrufe im kritischen Pfad und unterstützt die hochfrequente Nutzung ohne zusätzliche Latenz. 6/

Empirisch führt dieses System zu konstant niedrigeren Latenzzeiten. In mehreren unabhängigen Benchmarking-Sitzungen zeigt FastLane’s ShMonad RPC eine um ~20 ms niedrigere Median-/Mittelwert-Antwortzeit als der zweit-schnellste Anbieter, mit einem größeren Abstand zu den öffentlichen RPCs. 7/

ShMON, das sich an die RPC-Richtlinie hält, wird bei Validierern gestaked, die am FastLane-Relay-Netzwerk teilnehmen (derzeit >90 % der Monad-Validierer). Dies schafft eine Ausrichtung: Bandbreitenverbraucher unterstützen die gleichen Validierer, die ihren Datenverkehr bedienen, und Validierer haben die Möglichkeit, direkt über Überziehungsstrafen entschädigt zu werden. 8/

Um Bandbreitenlimits glaubwürdig und vertrauenslos durchzusetzen, benötigen wir mehr als nur Ratenlimits... wir brauchen nachweisbare Durchsetzung. Derzeit werden die Nutzer am Relay gedrosselt. Aber der Fahrplan umfasst On-Chain-Nachweissysteme, die auf Nonce-Deltas und signierten Nutzungsbelegen basieren. 9/

Ein minimales Design könnte die Nonces von Konten zwischen den Blockhöhen n und m vergleichen und übermäßige Nutzung über die maximale RPS hinweg bestrafen (d.h. 'Aufschlag anwenden' und ihn dem Validator geben). Aber es gibt ein Problem: Dies ist anfällig für Batch-Release-Angriffe durch einen Relay, der die Transaktionen sprunghaft erscheinen lässt.

Um dies zu mildern, führen wir einen zweiten Kanal ein: asynchrone, zeitgestempelte Nutzungsbelege. Wenn eine Transaktion eingereicht wird, wird sie sowohl an den Validator als auch an einen separaten "Belegaussteller" multicast. Der Aussteller gibt ein signiertes Objekt an den Absender zurück, das zeitgestempelt ist und Metadaten zum Pre-Execution-Nonce enthält. Dadurch wird der Tracking- und Verifizierungsaufwand aus dem heißen Pfad zwischen dem Benutzer und dem Validator entfernt. 11/

Diese Quittungen (die unterschrieben werden) dienen einem doppelten Zweck: 1. Benutzerfeedback: Wenn die Quittungen nicht mehr ankommen, können die Kunden freiwillig den Verkehr einstellen, um Übergebühren zu vermeiden. 2. On-Chain-Beweis: Quittungen verankern zeitliche Aktivitäten und unterscheiden zwischen echtem Spam und durch Relay induzierten Batching. 12/

Dieses Modell unterstützt sowohl EOAs als auch 4337 userOps (vorausgesetzt, es handelt sich um nicht geteilte Bundles oder eine vertikale Integration mit unserem eigenen Paymaster). In zukünftigen Versionen könnten wir durchsetzen, dass der Transaktionsunterzeichner mit dem Policeninhaber übereinstimmt oder während des Policenengagements auf die Whitelist gesetzt wurde. TBD. 13/

Unser Ziel ist es, die Durchsetzung on-chain zu verlagern, ohne die Leistung zu opfern. Dank des reichlichen Blockraums und der schnellen Finalität von Monad ist es möglich, Statusnachweise einzureichen, Quittungen zu überprüfen und Übergebühren on-chain zu erheben... etwas, das in teureren Netzwerken nicht machbar ist. 14/

Überziehungsstrafen (analog zur Staugebühr) sind noch in der Planung. Wir warten auf die endgültige Gebührenmarktstruktur von Monad, bevor wir einen Zuschlagsplan festlegen - es wäre nicht sinnvoll, die Überziehungsgebühr zu gestalten, ohne zu wissen, was die Basisgebühr ist. 15/

Der RPC-Durchsatz wird derzeit aggregiert (txs + eth_call) gemessen, aber zukünftige Upgrades werden die Bandbreitenklassen disaggregieren. Leseanfragen werden über regional optimierte Knoten geleitet, wodurch sie aus dem Engpass entfernt werden, der durch die Bandbreitenbeschränkungen der Validatoren entsteht. 16/

Für latenzempfindliche Anwendungen (z. B. Vollknoten, Market Maker) unterstützen wir Peering und direkte Blockübertragung über p2p. Bei vollständigen Blöcken wird die Verbreitungspriorität stake-gewichtet (LSWQoS): Benutzer mit höherem eingesetztem ShMON erhalten Blöcke geringfügig früher, vorbehaltlich der Einschlussgrenzen. 17/

Dies stellt einen Abgang von der traditionellen "Best-Effort"-RPC dar. Bei Leseanfragen an eine RPC bestimmt der eingesetzte Betrag die Anzahl der Anfragen. Für Blöcke, die von unseren Knoten gesendet werden, bestimmt der eingesetzte Betrag die Reihenfolge des Sendens. 18/

Vertrauensloser Zugriffskontrolle ist auf Hochdurchsatz-Blockchains möglich, wenn Anreize, Durchsetzung und Beobachtbarkeit von Grund auf neu gestaltet werden. Das ShMonad RPC ist eine Referenzimplementierung dieser These. Wir freuen uns auf Iteration und externe Überprüfung. 19/