Raske blokkjeder introduserer nye utfordringer for båndbreddestyring og RPC-rettferdighet. I dag introduserer vi en mekanisme for å forme RPC-tilgang ved hjelp av likvide innsatsforpliktelser. Systemet er live via FastLanes ShMonad RPC. Denne tråden utforsker arkitekturen og begrunnelsen. 🧵

Nettverk med høy gjennomstrømning som Monad (~0,5 s blokktid, ~1 s endelighet) gir lite rom for reaktiv struping. Når et RPC-endepunkt oppdager at det er under spamangrep, er skaden allerede skjedd. Avbøtende tiltak må være proaktive og insentivtilpasset. /2

Den viktigste begrensningen er båndbredde. Validatortilstøtende noder er ressursbegrensede og latenssensitive. Hvis tillatelsesfri tilgang gis vilkårlig, kan motstanderens klienter fortrenge ærlige deltakere – noe som resulterer i forringede UX- og validatorkostnader uten regress. /3

Løsningen vår utnytter ShMonad, et programmerbart flytende staking-token (LST) med forpliktelsesmuligheter på kjeden. Brukere mottar en privat RPC-URL i bytte mot å forplikte ShMON til en «RPC-policy» på kjeden. Denne forpliktelsen styrer tilgangsgrenser. /4

Båndbredde tildeles proporsjonalt: brukerens RPS = (brukerens forpliktede ShMON / totalt forpliktet ShMON) × RPS_max-global Dette gir en dynamisk delbar, innsatsvektet båndbreddemodell uten å introdusere sentraliserte hastighetsbegrensere utenfor kjeden. 5/

Innsatsen er forpliktet for en varighet (for øyeblikket 20 blokker), noe som muliggjør bufring. Reléet avspørrer og tar øyeblikksbilder av forpliktelsestilstanden på kjeden. Dette forhindrer EVM-anrop i den kritiske banen og støtter høyfrekvent bruk uten ekstra ventetid. 6/

Empirisk resulterer dette systemet i konsekvent lavere ventetid. På tvers av flere uavhengige benchmarking-økter viser FastLanes ShMonad RPC ~20 ms lavere median/gjennomsnittlig responstid enn den nest raskeste leverandøren, med et større gap mot de offentlige RPC-ene. 7/

ShMON forpliktet til RPC-policyen er satt med validatorer som deltar i FastLane-relénettverket (for tiden >90 % av Monad-validatorene). Dette skaper justering: båndbreddeforbrukere støtter de samme validatorene som betjener trafikken deres, og validatorer har potensial til å bli kompensert direkte via overforbruksstraffer. 8/

Men for å håndheve båndbreddegrenser troverdig og tillitsløst, trenger vi mer enn hastighetsgrenser ... vi trenger beviselig håndhevelse. Foreløpig blir brukerne strupet på reléet. Men veikartet inkluderer kjedesikre systemer basert på nonce-deltaer og signerte brukskvitteringer. 9/

Et minimalt design kan sammenligne konto-nonces mellom blokkhøyder n og m, og skråstrek (dvs. «påfør tilleggsavgift» og gi det til validatoren) overskytende bruk over maksimal RPS. Men det er et problem: dette er sårbart for batch-utgivelsesangrep fra et relé som får tx-ene til å virke bursty.

For å redusere dette introduserer vi en annen kanal: asynkrone tidsstemplede brukskvitteringer. Når en transaksjon sendes inn, vil den bli multicastet til både validatoren og en separat «kvitteringsutsteder». Utstederen returnerer et signert objekt til avsenderen, tidsstemplet og inkludert engangsmetadata for forhåndskjøring. Det tar sporings- og verifiseringskostnadene ut av den varme banen mellom brukeren og validatoren. 11/

Disse kvitteringene (som vil bli signert) tjener et dobbelt formål: 1. Tilbakemelding fra brukere: Hvis kvitteringer slutter å komme, kan klienter frivillig stoppe trafikken for å unngå overforbruksgebyrer. 2. Bevis på kjeden: Kvitteringer forankrer tidsmessig aktivitet, og skiller ekte spam fra reléindusert batching. 12/

Denne modellen støtter både EOA-er og 4337 userOps (forutsatt ikke-delte pakker eller vertikal integrasjon med vår egen paymaster). I fremtidige versjoner kan vi håndheve at transaksjonsunderskriveren samsvarer med forsikringsinnehaveren eller ble hvitelistet under forsikringsforpliktelsen. TBD. 13/

Målet vårt er å flytte håndhevelsen på kjeden uten å ofre ytelsen. Takket være Monads rikelige blokkplass og raske endelighet, er det mulig å sende inn statlige bevis, verifisere kvitteringer og belaste overforbruksgebyrer på kjeden ... noe umulig på dyrere nettverk. 14/

Overforbruksstraffer (analogt med rushtidsprising) er fortsatt under utforming. Vi venter på Monads endelige gebyrmarkedsstruktur før vi fullfører en tilleggsavgiftsplan - det ville ikke være fornuftig for oss å utforme overforbruksgebyret uten å vite hva basisgebyret er. 15/

RPC-gjennomstrømming måles for øyeblikket aggregert (txs + eth_call), men fremtidige oppgraderinger vil dele båndbreddeklasser opp. Leseforespørsler rutes gjennom regionalt optimaliserte noder, og fjerner dem fra flaskehalsen som skapes av validatorens båndbreddebegrensninger. 16/

For latenssensitive applikasjoner (f.eks. fullstendige noder, market makers) støtter vi nodenettverk og direkte blokkfeed via p2p. For hele blokker vil forplantningsprioritet være innsatsvektet (LSWQoS): brukere med høyere forpliktet ShMON mottar blokker marginalt tidligere, underlagt inkluderingsterskler. 17/

Dette representerer et avvik fra tradisjonell "best effort" RPC. Med leseforespørsler til en RPC bestemmer det forpliktede innsatsbeløpet antall forespørsler. For blokker som sendes fra nodene våre, bestemmer det forpliktede innsatsbeløpet rekkefølgen for sending. 18/

Tillitsløs tilgangskontroll er levedyktig på kjeder med høy gjennomstrømning hvis insentiver, håndhevelse og observerbarhet er utformet fra første prinsipper. ShMonad RPC er en referanseimplementering av den avhandlingen. Vi ser frem til iterasjon og ekstern gransking. 19/