Snelle blockchains introduceren nieuwe uitdagingen voor bandbreedtebeheer en RPC-rechtheid. Vandaag introduceren we een mechanisme voor het vormgeven van RPC-toegang met behulp van liquid staking verplichtingen. Het systeem is live via FastLane's ShMonad RPC. Deze thread verkent de architectuur en de rationale. 🧵

Netwerken met hoge doorvoer zoals Monad (~0,5s bloktijd, ~1s finaliteit) laten weinig ruimte voor reactieve throttling. Tegen de tijd dat een RPC-eindpunt detecteert dat het onder spamaanval staat, is de schade al aangericht. Mitigatie moet proactief en incentive-gericht zijn. /2

De belangrijkste beperking is bandbreedte. Validator-buur nodes zijn beperkt in middelen en gevoelig voor latentie. Als onbeperkte toegang ondoordacht wordt verleend, kunnen vijandige cliënten eerlijke deelnemers verdringen, wat resulteert in een verslechterde gebruikerservaring en kosten voor validators zonder mogelijkheid tot terugvordering. /3

Onze oplossing maakt gebruik van ShMonad, een programmeerbare liquid staking token (LST) met on-chain verbintenis mogelijkheden. Gebruikers ontvangen een privé RPC-URL in ruil voor het inzetten van ShMON op een on-chain "RPC-beleid." Deze verbintenis regelt de toegangssnelheidslimieten. /4

Bandbreedte wordt proportioneel toegewezen: RPS van de gebruiker = (gecommitteerde ShMON van de gebruiker / totale gecommitteerde ShMON) × RPS_max-global Dit resulteert in een dynamisch deelbare, stake-gewogen bandbreedtemodel zonder gecentraliseerde off-chain rate-limiters in te voeren. 5/

Stake is gecommitteerd voor een duur (momenteel 20 blokken), wat caching mogelijk maakt. De relay polst af en toe en maakt snapshots van de on-chain commitment status. Dit voorkomt EVM-aanroepen in het kritieke pad en ondersteunt gebruik met hoge frequentie zonder extra latentie. 6/

Empirisch gezien resulteert dit systeem in consistent lagere latentie. Tijdens meerdere onafhankelijke benchmarksessies vertoont FastLane’s ShMonad RPC een ~20ms lagere mediaan/gemiddelde responstijd dan de op één na snelste aanbieder, met een grotere kloof ten opzichte van de publieke RPC's. 7/

ShMON dat is toegewijd aan het RPC-beleid, is gestaked bij validators die deelnemen aan het FastLane relay-netwerk (momenteel >90% van de Monad validators). Dit creëert afstemming: bandbreedteconsumenten ondersteunen dezelfde validators die hun verkeer bedienen, en validators hebben de mogelijkheid om rechtstreeks gecompenseerd te worden via overage boetes. 8/

Maar om bandbreedtebeperkingen geloofwaardig en zonder vertrouwen af te dwingen, hebben we meer nodig dan snelheidslimieten... we hebben bewijsbare handhaving nodig. Voor nu worden gebruikers beperkt bij de relay. Maar de roadmap omvat on-chain bewijs systemen gebaseerd op nonce-delta's en ondertekende gebruiksontvangsten. 9/

Een minimalistisch ontwerp zou de account nonces kunnen vergelijken tussen blokhoogtes n en m, en overtollig gebruik boven de maximale RPS kunnen bestraffen (d.w.z. 'toeslag toepassen' en deze aan de validator geven). Maar er is een probleem: dit is kwetsbaar voor batch-release aanvallen door een relay die de tx's als bursty laat lijken.

Om dit te verlichten, introduceren we een tweede kanaal: asynchrone tijdstempelgebruikontvangsten. Wanneer een transactie wordt ingediend, wordt deze uitgezonden naar zowel de validator als een aparte "ontvangstuitgever." De uitgever retourneert een ondertekend object naar de afzender, tijdgestempeld en inclusief metadata van de pre-executie nonce. Het haalt de tracking- en verificatie-overhead uit het hete pad tussen de gebruiker en de validator. 11/

Deze ontvangstbewijzen (die ondertekend zullen worden) dienen een dubbele functie: 1. Gebruikersfeedback: Als de ontvangstbewijzen niet meer binnenkomen, kunnen klanten vrijwillig het verkeer stopzetten om overlastkosten te vermijden. 2. On-chain bewijs: Ontvangstbewijzen verankeren temporele activiteit, waardoor echte spam wordt onderscheiden van relay-geïnduceerde batching. 12/

Dit model ondersteunt zowel EOA's als 4337 userOps (ervan uitgaande dat er geen gedeelde bundels zijn of verticale integratie met onze eigen paymaster). In toekomstige versies kunnen we afdwingen dat de ondertekenaar van de transactie overeenkomt met de beleidshouder of tijdens de beleidsverbintenis op de witte lijst stond. TBD. 13/

Ons doel is om handhaving on-chain te verplaatsen zonder in te boeten op prestaties. Dankzij de overvloedige blockspace van Monad en snelle finaliteit is het indienen van staatbewijzen, het verifiëren van ontvangstbewijzen en het in rekening brengen van extra kosten on-chain haalbaar... iets wat onhaalbaar is op netwerken met hogere kosten. 14/

Bovenmatige boetes (vergelijkbaar met congestieprijzen) zijn nog in ontwerp. We wachten op de definitieve structuur van de vergoedingenmarkt van Monad voordat we een toeslagenschema finaliseren - het zou voor ons geen zin hebben om de bovenmatige vergoeding te ontwerpen zonder te weten wat de basisvergoeding is. 15/

De RPC-doorvoer wordt momenteel gemeten in totaal (txs + eth_call), maar toekomstige upgrades zullen de bandbreedteklassen ontleden. Leesverzoeken worden gerouteerd via regionaal geoptimaliseerde knooppunten, waardoor ze worden verwijderd uit de bottleneck die is ontstaan door de bandbreedtebeperkingen van de validator. 16/

Voor latency-gevoelige toepassingen (bijv. volledige knooppunten, market makers) ondersteunen we peering en directe blokfeed via p2p. Voor volledige blokken zal de propagatieprioriteit stake-gewogen zijn (LSWQoS): gebruikers met een hogere gecommitteerde ShMON ontvangen blokken marginaal eerder, onder voorbehoud van inclusiedrempels. 17/

Dit vertegenwoordigt een afwijking van de traditionele "beste inspanning" RPC. Bij leesverzoeken aan een RPC bepaalt het gecommitteerde inzetbedrag het aantal verzoeken. Voor blokken die van onze knooppunten worden verzonden, bepaalt het gecommitteerde inzetbedrag de volgorde van verzending. 18/

Trustless toegangscontrole is haalbaar op chains met hoge doorvoer als prikkels, handhaving en observeerbaarheid zijn ontworpen vanuit de eerste principes. De ShMonad RPC is een referentie-implementatie van die stelling. We kijken uit naar iteratie en externe controle. 19/