Snelle blockchains introduceren nieuwe uitdagingen voor bandbreedtebeheer en RPC-eerlijkheid. 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 draad onderzoekt de architectuur en de grondgedachte. 🧵

High-throughput netwerken zoals Monad (~0,5s bloktijd, ~1s finaliteit) laten weinig ruimte voor reactieve throttling. Tegen de tijd dat een RPC-eindpunt detecteert dat het wordt aangevallen door spam, is er al schade aangericht. Mitigatie moet proactief en op prikkels afgestemd zijn. /2

De belangrijkste beperking is de bandbreedte. Aan validators grenzende knooppunten zijn beperkt aan bronnen en latentiegevoelig. Als zonder toestemming zonder onderscheid toegang wordt verleend, kunnen vijandige klanten eerlijke deelnemers verdringen, wat resulteert in verslechterde UX- en validatorkosten zonder verhaal. /3

Onze oplossing maakt gebruik van ShMonad, een programmeerbaar liquid staking token (LST) met on-chain commitment-mogelijkheden. Gebruikers ontvangen een privé RPC-URL in ruil voor het vastleggen van ShMON op een on-chain "RPC-beleid". Deze toezegging regelt de limieten voor toegangspercentages. /4

Bandbreedte wordt proportioneel toegewezen: RPS van de gebruiker = (door de gebruiker toegezegde ShMON / totaal toegezegde ShMON) × RPS_max-globaal Dit levert een dynamisch deelbaar, stake-gewogen bandbreedtemodel op zonder gecentraliseerde off-chain snelheidsbegrenzers te introduceren. 5/

Stake is vastgelegd voor een duur (momenteel 20 blokken), waardoor caching mogelijk is. Het relais peilt en momentopnamen met tussenpozen de on-chain commitment-status. Dit voorkomt EVM-aanroepen op het kritieke pad en ondersteunt hoogfrequent gebruik 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 bandbreedtelimieten geloofwaardig en betrouwbaar af te dwingen, hebben we meer nodig dan snelheidslimieten... We hebben aantoonbare handhaving nodig. Voorlopig worden gebruikers gesmoord bij het relais. Maar de roadmap omvat on-chain proof-systemen op basis van nonce-delta's en ondertekende gebruiksbewijzen. 9/

Een minimaal ontwerp zou accountnonces kunnen vergelijken tussen blokhoogtes n en m, en overtollig gebruik boven de maximale RPS kunnen verminderen (d.w.z. 'toeslag toepassen' en aan de validator geven). Maar er is een probleem: dit is kwetsbaar voor batch-release-aanvallen door een relais waardoor de txs bursty lijken.

Om dit te beperken, introduceren we een tweede kanaal: asynchrone gebruiksbonnen met tijdstempels. Wanneer een transactie wordt ingediend, wordt deze gemulticast naar zowel de validator als een afzonderlijke 'uitgever van het ontvangstbewijs'. De uitgever stuurt een ondertekend object terug naar de afzender, voorzien van een tijdstempel en inclusief nonce-metagegevens vóór uitvoering. Het haalt de tracking- en verificatieoverhead 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 (uitgaande van niet-gedeelde bundels of verticale integratie met onze eigen paymaster). In toekomstige versies kunnen we afdwingen dat de ondertekenaar van de transactie overeenkomt met de polishouder of op de witte lijst stond tijdens de beleidstoezegging. TBD. 13/

Ons doel is om handhaving on-chain te brengen zonder in te boeten aan prestaties. Dankzij de overvloedige blokruimte en snelle finaliteit van Monad, is het indienen van staatsbewijzen, het verifiëren van bonnen en het in rekening brengen van overschrijdingskosten haalbaar on-chain... iets onhaalbaars op duurdere netwerken. 14/

Boetes voor overschrijding (analoog aan congestieheffingen) zijn nog in ontwikkeling. We wachten op de definitieve marktstructuur van Monad voordat we een toeslagschema afronden - het zou voor ons niet logisch zijn om de overschrijdingsvergoeding te ontwerpen zonder te weten wat de basisvergoeding is. 15/

RPC-doorvoer wordt momenteel gemeten in geaggregeerde (txs + eth_call), maar toekomstige upgrades zullen bandbreedteklassen uitsplitsen. Leesverzoeken worden gerouteerd via regionaal geoptimaliseerde knooppunten, waardoor ze worden verwijderd uit het knelpunt dat wordt gecreëerd 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/