Szybkie blockchainy wprowadzają nowe wyzwania w zarządzaniu przepustowością i sprawiedliwością RPC. Dziś wprowadzamy mechanizm kształtowania dostępu do RPC przy użyciu zobowiązań związanych z płynnym stakowaniem. System działa za pośrednictwem RPC ShMonad od FastLane. Ten wątek bada architekturę i uzasadnienie. 🧵

Sieci o wysokiej przepustowości, takie jak Monad (~0,5s czas bloku, ~1s finalność), pozostawiają niewiele miejsca na reaktywne ograniczanie. W momencie, gdy punkt końcowy RPC wykryje, że jest pod atakiem spamu, szkody już zostały wyrządzone. Łagodzenie musi być proaktywne i zgodne z zachętami. /2

Kluczowym ograniczeniem jest przepustowość. Węzły sąsiadujące z walidatorami są ograniczone zasobowo i wrażliwe na opóźnienia. Jeśli dostęp bez zezwolenia zostanie przyznany bez ograniczeń, klienci wrogowie mogą wypchnąć uczciwych uczestników — co skutkuje pogorszeniem UX i kosztami walidatora bez możliwości odwołania.

Nasze rozwiązanie wykorzystuje ShMonad, programowalny token do płynnego stakowania (LST) z możliwościami zobowiązania na łańcuchu. Użytkownicy otrzymują prywatny adres URL RPC w zamian za zobowiązanie ShMON do „Polityki RPC” na łańcuchu. To zobowiązanie reguluje limity dostępu.

Pasmo jest przydzielane proporcjonalnie: RPS użytkownika = (zaangażowany ShMON użytkownika / całkowity zaangażowany ShMON) × RPS_max-global Daje to dynamicznie dzielony model pasma ważony stawką, bez wprowadzania scentralizowanych limitów prędkości poza łańcuchem. 5/

Stake jest zobowiązany na czas (obecnie 20 bloków), co umożliwia buforowanie. Relay okresowo sprawdza i wykonuje migawki stanu zobowiązania na łańcuchu. Zapobiega to wywołaniom EVM w krytycznej ścieżce i wspiera użycie o wysokiej częstotliwości bez dodatkowej latencji. 6/

Empirycznie, ten system skutkuje konsekwentnie niższą latencją. W trakcie wielu niezależnych sesji benchmarkingowych, RPC ShMonad od FastLane wykazuje średni czas odpowiedzi o ~20 ms niższy niż drugi najszybszy dostawca, z większą różnicą w porównaniu do publicznych RPC. 7/

ShMON zaangażowany w politykę RPC jest stakowany u walidatorów uczestniczących w sieci przekaźnikowej FastLane (obecnie >90% walidatorów Monad). Tworzy to zgodność: konsumenci pasma wspierają tych samych walidatorów, którzy obsługują ich ruch, a walidatorzy mają potencjał, aby być wynagradzani bezpośrednio za pomocą kar za przekroczenie.

Aby jednak wiarygodnie i bez zaufania egzekwować limity przepustowości, potrzebujemy więcej niż tylko limitów prędkości... potrzebujemy wykonalnej egzekucji. Na razie użytkownicy są ograniczani na przekaźniku. Ale mapa drogowa obejmuje systemy dowodowe na łańcuchu oparte na różnicach nonce i podpisanych potwierdzeniach użycia. 9/

Minimalistyczny projekt mógłby porównywać nonces konta między wysokościami bloków n i m oraz nałożyć karę (tj. 'nałożyć dodatkową opłatę' i przekazać ją walidatorowi) za nadmierne użycie powyżej maksymalnego RPS. Ale jest problem: jest to podatne na ataki związane z uwalnianiem wsadowym przez przekaźnik, który sprawia, że transakcje wydają się nagłe.

Aby to złagodzić, wprowadzamy drugi kanał: asynchroniczne potwierdzenia użycia z znacznikami czasowymi. Gdy transakcja jest przesyłana, jest multicastowana zarówno do walidatora, jak i do oddzielnego „wydawcy potwierdzeń”. Wydawca zwraca podpisany obiekt do nadawcy, oznaczony znacznikiem czasowym i zawierający metadane nonce przed wykonaniem. Usuwa to obciążenie śledzenia i weryfikacji z gorącej ścieżki między użytkownikiem a walidatorem. 11/

Te pokwitowania (które będą podpisane) mają podwójne znaczenie: 1. Opinie użytkowników: Jeśli pokwitowania przestaną napływać, klienci mogą dobrowolnie wstrzymać ruch, aby uniknąć opłat za przekroczenie limitu. 2. Dowód on-chain: Pokwitowania zakotwiczają aktywność czasową, rozróżniając prawdziwy spam od batching wywołanego przez relay. 12/

Ten model obsługuje zarówno EOAs, jak i 4337 userOps (zakładając, że nie są to wspólne pakiety lub pionowa integracja z naszym własnym paymasterem). W przyszłych wersjach możemy wymusić, aby podpisujący transakcję odpowiadał posiadaczowi polityki lub był na białej liście podczas zobowiązania do polityki. Do ustalenia. 13/

Naszym celem jest przeniesienie egzekucji na łańcuch bez poświęcania wydajności. Dzięki obfitej przestrzeni blokowej Monad i szybkiemu finalizowaniu, składanie dowodów stanu, weryfikacja potwierdzeń i pobieranie opłat za nadwyżki jest wykonalne na łańcuchu... coś niewykonalnego w sieciach o wyższych kosztach. 14/

Kary za przekroczenie (analogiczne do cen za zatłoczenie) są wciąż w fazie projektowania. Czekamy na ostateczną strukturę rynku opłat Monad, zanim ustalimy harmonogram dodatkowych opłat - nie miałoby sensu projektować opłaty za przekroczenie bez znajomości podstawowej opłaty. 15/

Przepustowość RPC jest obecnie mierzona w agregacie (txs + eth_call), ale przyszłe aktualizacje rozdzielą klasy przepustowości. Żądania odczytu będą kierowane przez regionalnie zoptymalizowane węzły, co usunie je z wąskiego gardła stworzonego przez ograniczenia przepustowości walidatora. 16/

Dla aplikacji wrażliwych na opóźnienia (np. pełne węzły, animatorzy rynku) wspieramy połączenia i bezpośrednie przesyłanie bloków przez p2p. Dla pełnych bloków priorytet propagacji będzie ważony stawką (LSWQoS): użytkownicy z wyższym zaangażowanym ShMON otrzymują bloki nieznacznie wcześniej, z zastrzeżeniem progów włączenia. 17/

To stanowi odejście od tradycyjnego RPC „najlepszego wysiłku”. W przypadku zapytań odczytowych do RPC, wysokość zaangażowanego stawki określa liczbę zapytań. W przypadku bloków wysyłanych z naszych węzłów, wysokość zaangażowanego stawki określa kolejność wysyłania. 18/

Bezpieczny dostęp kontrolny jest możliwy na łańcuchach o wysokiej przepustowości, jeśli zachęty, egzekwowanie i obserwowalność są zaprojektowane od podstaw. ShMonad RPC jest referencyjną implementacją tej tezy. Czekamy na iteracje i zewnętrzną kontrolę. 19/