Blockchain-urile rapide introduc noi provocări pentru gestionarea lățimii de bandă și corectitudinea RPC. Astăzi introducem un mecanism de modelare a accesului RPC folosind angajamente de miză lichidă. Sistemul este live prin ShMonad RPC de la FastLane. Acest subiect explorează arhitectura și raționamentul. 🧵

Rețelele cu randament ridicat precum Monad (~0.5s block time, ~1s finalitate) lasă puțin loc pentru limitarea reactivă. În momentul în care un endpoint RPC detectează că este sub atac de spam, daunele au fost deja făcute. Atenuarea trebuie să fie proactivă și aliniată la stimulente. /2

Constrângerea cheie este lățimea de bandă. Nodurile adiacente validatorului sunt limitate de resurse și sensibile la latență. Dacă accesul fără permisiune este acordat fără discriminare, clienții adversari pot exclude participanții onești - ceea ce duce la costuri degradate de UX și validare fără recurs. /3

Soluția noastră folosește ShMonad, un token de miză lichidă programabil (LST) cu capabilități de angajament on-chain. Utilizatorii primesc o adresă URL RPC privată în schimbul angajării ShMON într-o "politică RPC" on-chain. Acest angajament reglementează limitele ratei de acces. /4

Lățimea de bandă este alocată proporțional: RPS al utilizatorului = (ShMON angajat al utilizatorului / total ShMON angajat) × RPS_max-global Acest lucru produce un model de lățime de bandă dinamic, partajabil dinamic, ponderat în funcție de miză, fără a introduce limitatori de rată centralizați în afara lanțului. 5/

Miza este angajată pentru o durată (în prezent 20 de blocuri), ceea ce permite stocarea în cache. Releul sondează și instantanează intermitent starea de angajament on-chain. Acest lucru previne apelurile EVM pe calea critică și acceptă utilizarea de înaltă frecvență fără latență suplimentară. 6/

Empiric, acest sistem are ca rezultat o latență constant mai mică. În mai multe sesiuni de benchmarking independente, ShMonad RPC de la FastLane prezintă un timp de răspuns median/mediu cu ~20 ms mai mic decât al doilea cel mai rapid furnizor, cu un decalaj mai mare față de RPC-urile publice. 7/

ShMON angajat în politica RPC este mizat cu validatorii care participă la rețeaua de releu FastLane (în prezent >90% dintre validatorii Monad). Acest lucru creează aliniere: consumatorii de lățime de bandă susțin aceiași validatori care le deservesc traficul, iar validatorii au potențialul de a fi compensați direct prin penalizări de depășire. 8/

Dar pentru a impune limitele lățimii de bandă în mod credibil și fără încredere, avem nevoie de mai mult decât limite de rată... avem nevoie de o aplicare dovedită Deocamdată, utilizatorii sunt limitați la releu. Dar foaia de parcurs include sisteme de probă on-chain bazate pe nonce delta și chitanțe de utilizare semnate. 9/

Un design minim ar putea compara nonciurile de cont între înălțimile blocurilor n și m și slash (adică "aplicați suprataxa" și dați-l validatorului) utilizarea în exces peste RPS-ul maxim. Dar există o problemă: acest lucru este vulnerabil la atacurile de eliberare în lot de către un releu, ceea ce face ca tx-urile să pară explozive.

Pentru a atenua acest lucru, introducem un al doilea canal: chitanțele de utilizare asincrone cu marcaj temporal. Când o tranzacție este trimisă, aceasta va fi multicast atât pentru validator, cât și pentru un "emitent de chitanțe" separat. Emitentul returnează un obiect semnat expeditorului, cu marcaj temporal și incluzând metadate nonce înainte de execuție. Elimină cheltuielile generale de urmărire și verificare din calea fierbinte dintre utilizator și validator. 11/

Aceste chitanțe (care vor fi semnate) au un dublu scop: 1. Feedback-ul utilizatorilor: Dacă chitanțele încetează să mai ajungă, clienții pot opri voluntar traficul pentru a evita taxele de depășire. 2. Dovada în lanț: chitanțele ancorează activitatea temporală, dezambiguizând spamul real de lotul indus de relee. 12/

Acest model acceptă atât EOA, cât și 4337 userOps (presupunând pachete nepartajate sau integrare verticală cu propriul nostru plătitor). În versiunile viitoare, este posibil să impunem ca semnatarul tranzacției să corespundă deținătorului poliței sau să fie inclus pe lista albă în timpul angajamentului politicii. TBD. 13/

Scopul nostru este să mutăm aplicarea în lanț fără a sacrifica performanța. Datorită spațiului abundent de blocare al Monad și finalității rapide, trimiterea dovezilor de stat, verificarea chitanțelor și perceperea taxelor suplimentare este viabilă în lanț... ceva nefezabil pe rețelele cu costuri mai mari. 14/

Sancțiunile de depășire a prețurilor sunt încă în curs de proiectare. Așteptăm structura finală a pieței de taxe a Monad înainte de a finaliza un program de suprataxă - nu ar avea sens pentru noi să proiectăm taxa de depășire fără a ști care este taxa de bază. 15/

Debitul RPC este măsurat în prezent în agregat (txs + eth_call), dar upgrade-urile viitoare vor dezagrega clasele de lățime de bandă. Cererile de citire vor fi direcționate prin noduri optimizate regional, eliminându-le din blocajul creat de constrângerile de lățime de bandă ale validatorului. 16/

Pentru aplicațiile sensibile la latență (de exemplu, noduri complete, formatori de piață), acceptăm peering și flux direct de blocuri prin p2p. Pentru blocurile complete, prioritatea de propagare va fi ponderată în funcție de miză (LSWQoS): utilizatorii cu ShMON mai angajat primesc blocuri puțin mai devreme, sub rezerva pragurilor de includere. 17/

Aceasta reprezintă o abatere de la RPC-ul tradițional "cel mai bun efort". Cu cererile de citire către un RPC, suma mizei angajate determină numărul de solicitări. Pentru blocurile trimise din nodurile noastre, suma mizei angajate determină ordinea de trimitere. 18/

Controlul accesului fără încredere este viabil pe lanțurile de debit ridicat dacă stimulentele, aplicarea și observabilitatea sunt concepute pe baza primelor principii. RPC ShMonad este o implementare de referință a acestei teze. Așteptăm cu nerăbdare iterația și controlul extern. 19/