Rychlé blockchainy přinášejí nové výzvy pro správu šířky pásma a férovost RPC. Dnes představujeme mechanismus pro formování přístupu k RPC pomocí závazků liquid stakingu. Systém je v provozu prostřednictvím ShMonad RPC společnosti FastLane. Toto vlákno zkoumá architekturu a zdůvodnění. 🧵

Sítě s vysokou propustností, jako je Monad (~0,5s doba bloku, ~1s konečnost) ponechávají malý prostor pro reaktivní throttling. V okamžiku, kdy koncový bod RPC zjistí, že je vystaven nevyžádanému útoku, je již škoda způsobena. Zmírňování rizik musí být proaktivní a v souladu s pobídkami. /2

Klíčovým omezením je šířka pásma. Uzly sousedící s validátorem jsou omezené na prostředky a citlivé na latenci. Pokud je přístup bez oprávnění udělen bez rozdílu, mohou nepřátelští klienti vytěsnit poctivé účastníky – což má za následek snížení nákladů na UX a validátor bez postihu. /3

Naše řešení využívá ShMonad, programovatelný token pro liquid staking (LST) s možností závazku v řetězci. Uživatelé obdrží soukromou adresu URL RPC výměnou za to, že se ShMON zaváže k "zásadám RPC" v řetězci. Tento závazek řídí omezení rychlosti přístupu. /4

Šířka pásma je alokována proporcionálně: RPS uživatele = (ShMON odevzdaný uživatelem / celkový počet potvrzených ShMON) × RPS_max-global Výsledkem je dynamicky sdílený, sázkami vážený model šířky pásma bez zavádění centralizovaných off-chain omezovačů rychlosti. 5/

Stake je potvrzen na dobu trvání (aktuálně 20 bloků), což umožňuje ukládání do mezipaměti. Přenos se občas dotazuje a vytváří snímky stavu závazku v řetězci. To zabraňuje volání EVM v kritické cestě a podporuje vysokofrekvenční použití bez další latence. 6/

Empiricky má tento systém za následek konzistentně nižší latenci. V několika nezávislých srovnávacích relacích vykazuje ShMonad RPC společnosti FastLane o ~20 ms nižší medián/průměrnou dobu odezvy než druhý nejrychlejší poskytovatel, s větším rozdílem oproti veřejným RPC. 7/

ShMON zavázaný k zásadám RPC je vsazen u validátorů účastnících se přenosové sítě FastLane (v současné době >90 % validátorů Monad). Tím se vytváří soulad: spotřebitelé šířky pásma podporují stejné validátory, kteří obsluhují jejich provoz, a validátoři mají potenciál být kompenzováni přímo prostřednictvím penalizací za překročení. 8/

Ale abychom mohli věrohodně a bez důvěry vynucovat limity šířky pásma, potřebujeme víc než jen limity rychlosti... Potřebujeme prokazatelné vymáhání. Prozatím jsou uživatelé na relé omezeni. Plán však zahrnuje systémy odolné vůči řetězci založené na deltách nonce a podepsaných účtenkách o použití. 9/

Minimální návrh by mohl porovnávat nonce účtu mezi výškami bloků n a m a lomítko (tj. "použít příplatek" a dát jej validátoru) nadměrné využití nad maximální RPS. Je tu však problém: je zranitelné vůči útokům dávkového vydání ze strany relé, díky nimž se vysílací frekvence zdají být nárazové.

Abychom tento problém zmírnili, zavádíme druhý kanál: asynchronní účtenky za využití s časovým razítkem. Když je transakce odeslána, bude vícesměrová jak pro validátora, tak pro samostatného "vydavatele účtenky". Vystavitel vrátí odesílateli podepsaný objekt s časovým razítkem a včetně metadat nonce před provedením. Odstraňuje režijní náklady na sledování a ověřování z horké cesty mezi uživatelem a validátorem. 11/

Tyto stvrzenky (které budou podepsány) slouží dvojímu účelu: 1. Zpětná vazba od uživatelů: Pokud přestanou přicházet účtenky, mohou klienti dobrovolně zastavit provoz, aby se vyhnuli poplatkům za překročení. 2. Důkaz v řetězci: Účtenky ukotvují časovou aktivitu a odlišují skutečný spam od dávkování vyvolaného relé. 12/

Tento model podporuje jak EOA, tak 4337 userOps (za předpokladu nesdílených balíčků nebo vertikální integrace s naším vlastním paymasterem). V budoucích verzích můžeme vynutit, aby se podepisující transakce shodoval s držitelem zásady nebo byl během závazku k porušení zásad zařazen na seznam povolených položek. TBD. 13/

Naším cílem je přesunout vymáhání v řetězci, aniž bychom obětovali výkon. Díky bohatému blokovému prostoru Monad a rychlé finalitě je v řetězci proveditelné předkládání státních důkazů, ověřování účtenek a účtování poplatků za překročení... něco neproveditelného v sítích s vyššími náklady. 14/

Pokuty za překročení limitu (analogické k zpoplatnění přetížení) se stále připravují. Čekáme na konečnou strukturu trhu s poplatky společnosti Monad, než dokončíme sazebník příplatků - nemělo by smysl, abychom navrhovali poplatek za překročení, aniž bychom věděli, jaký je základní poplatek. 15/

Propustnost protokolu RPC se v současné době měří v souhrnu (txs + eth_call), ale budoucí upgrady budou třídy šířky pásma rozčlenit. Požadavky na čtení budou směrovány přes regionálně optimalizované uzly, čímž se odstraní z úzkého hrdla vytvořeného omezeními šířky pásma validátoru. 16/

Pro aplikace citlivé na latenci (např. full nodes, tvůrci trhu) podporujeme peering a přímý blokový feed prostřednictvím p2p. U celých bloků bude priorita šíření vážená sázkami (LSWQoS): uživatelé s vyšším potvrzením ShMON obdrží bloky o něco dříve, v závislosti na prahových hodnotách pro zahrnutí. 17/

To představuje odklon od tradičního RPC "s maximálním úsilím". U požadavků na čtení vzdáleného volání procedur určuje počet požadavků potvrzená částka vkladu. U bloků odeslaných z našich uzlů určuje pořadí odesílání potvrzená částka vkladu. 18/

Řízení přístupu bez důvěry je životaschopné v řetězcích s vysokou propustností, pokud jsou pobídky, vynucování a pozorovatelnost navrženy od prvních principů. ShMonad RPC je referenční implementací této teze. Těšíme se na iteraci a externí kontrolu. 19/