Snabba blockkedjor introducerar nya utmaningar för bandbreddshantering och rättvis RPC. Idag introducerar vi en mekanism för att forma RPC-åtkomst med hjälp av likvida insatsåtaganden. Systemet är live via FastLanes ShMonad RPC. Den här tråden utforskar arkitekturen och logiken. 🧵

Nätverk med högt dataflöde som Monad (~0,5 s blocktid, ~1 s slutgiltighet) lämnar lite utrymme för reaktiv begränsning. När en RPC-slutpunkt upptäcker att den är under skräppostattack har skadan redan skett. Begränsningen måste vara proaktiv och inriktad på incitament. /2

Den viktigaste begränsningen är bandbredd. Valideringsrelaterade noder är resursbegränsade och latenskänsliga. Om behörighetslös åtkomst beviljas urskillningslöst kan angripare tränga ut ärliga deltagare, vilket resulterar i försämrade UX- och valideringskostnader utan regressrätt. /3

Vår lösning utnyttjar ShMonad, en programmerbar likvid staking-token (LST) med funktioner för engagemang i kedjan. Användare får en privat RPC-URL i utbyte mot att de förbinder ShMON till en "RPC-policy" i kedjan. Det här åtagandet styr gränserna för åtkomsthastigheten. /4

Bandbredden fördelas proportionellt: användarens RPS = (användarens bekräftade ShMON / totalt antal bekräftade ShMON) × RPS_max-global Detta ger en dynamiskt delbar, insatsviktad bandbreddsmodell utan att introducera centraliserade hastighetsbegränsare utanför kedjan. 5/

Insatsen är engagerad under en varaktighet (för närvarande 20 block), vilket möjliggör cachelagring. Reläet avsöker och ögonblicksbilder regelbundet av åtagandetillståndet i kedjan. Detta förhindrar EVM-anrop i den kritiska linjen och stöder högfrekvent användning utan ytterligare latens. 6/

Empiriskt sett resulterar detta system i konsekvent lägre latens. Över flera oberoende benchmarkingsessioner uppvisar FastLanes ShMonad RPC ~20 ms lägre median/genomsnittlig svarstid än den näst snabbaste leverantören, med ett större gap mot de offentliga RPC:erna. 7/

ShMON som har åtagit sig att följa RPC-policyn är engagerad i validerare som deltar i FastLane-relänätverket (för närvarande >90 % av Monad-validerarna). Detta skapar anpassning: bandbreddskonsumenter stöder samma validerare som betjänar deras trafik, och validerare har potential att kompenseras direkt via straffavgifter för överskott. 8/

Men för att upprätthålla bandbreddsgränser på ett trovärdigt och förtroendefullt sätt behöver vi mer än hastighetsgränser ... Vi behöver ett bevisbart verkställande. För närvarande stryps användarna vid reläet. Men färdplanen inkluderar on-chain-säkra system baserade på nonce-deltan och signerade användningskvitton. 9/

En minimal design skulle kunna jämföra konto-nonces mellan blockhöjderna n och m, och minska (dvs. "tillämpa tilläggsavgift" och ge den till valideraren) överdriven användning över den maximala RPS. Men det finns ett problem: detta är sårbart för batch-release-attacker från ett relä som gör att txs ser sprucken ut.

För att åtgärda detta introducerar vi en andra kanal: asynkrona tidsstämplade användningskvitton. När en transaktion skickas in kommer den att multicastas till både valideraren och en separat "kvittoutfärdare". Utfärdaren returnerar ett signerat objekt till avsändaren, tidsstämplat och inklusive nonce-metadata före körning. Det tar bort spårnings- och verifieringskostnaderna från den heta vägen mellan användaren och valideraren. 11/

Dessa kvitton (som kommer att undertecknas) har ett dubbelt syfte: 1. Användarfeedback: Om kvitton slutar komma fram kan kunder frivilligt stoppa trafiken för att undvika överskottsavgifter. 2. On-chain-bevis: Kvitton förankrar temporal aktivitet och skiljer verklig skräppost från reläinducerad batchning. 12/

Den här modellen stöder både EOA:er och 4337 userOps (förutsatt att det finns icke-delade paket eller vertikal integration med vår egen betalningshanterare). I framtida versioner kan vi kräva att transaktionsundertecknaren matchar försäkringstagaren eller vitlistades under försäkringsåtagandet. TBD. 13/

Vårt mål är att flytta verkställigheten i kedjan utan att offra prestanda. Tack vare Monads rikliga blockutrymme och snabba slutgiltighet är det lönsamt att skicka in tillståndsbevis, verifiera kvitton och ta ut överskottsavgifter på kedjan... något som är ogenomförbart i nätverk med högre kostnader. 14/

Straffavgifter för överförbrukning (liknande avgifter på grund av trängsel) håller fortfarande på att utformas. Vi väntar på Monads slutliga avgiftsmarknadsstruktur innan vi slutför ett tilläggsavgiftsschema - det skulle inte vara meningsfullt för oss att utforma överskottsavgiften utan att veta vad grundavgiften är. 15/

RPC-dataflödet mäts för närvarande i aggregerat (txs + eth_call), men framtida uppgraderingar kommer att dela upp bandbreddsklasser. Läsförfrågningar kommer att dirigeras genom regionalt optimerade noder, vilket tar bort dem från flaskhalsen som skapats av validerarens bandbreddsbegränsningar. 16/

För latenskänsliga applikationer (t.ex. fullständiga noder, market makers) stöder vi peering och direkt blockmatning via p2p. För fullständiga block kommer spridningsprioriteten att vara insatsviktad (LSWQoS): användare med högre engagerade ShMON får block marginellt tidigare, med förbehåll för inkluderingströsklar. 17/

Detta representerar en avvikelse från traditionell RPC med "bästa ansträngning". Med läsbegäranden till en RPC avgör det bekräftade insatsbeloppet antalet förfrågningar. För block som skickas från våra noder avgör det utlovade insatsbeloppet i vilken ordningen de skickas. 18/

Trustless åtkomstkontroll är genomförbar i kedjor med högt dataflöde om incitament, tillämpning och observerbarhet utformas från de första principerna. ShMonad RPC är en referensimplementation av den tesen. Vi ser fram emot iteration och extern granskning. 19/