Le blockchain veloci introducono nuove sfide per la gestione della larghezza di banda e l'equità dell'RPC. Oggi stiamo introducendo un meccanismo per modellare l'accesso all'RPC utilizzando impegni di staking liquido. Il sistema è attivo tramite l'RPC ShMonad di FastLane. Questo thread esplora l'architettura e la logica. 🧵

Le reti ad alta capacità come Monad (~0,5s di tempo di blocco, ~1s di finalità) lasciano poco spazio per un throttling reattivo. Quando un endpoint RPC rileva di essere sotto attacco spam, il danno è già stato fatto. La mitigazione deve essere proattiva e allineata agli incentivi. /2

Il vincolo principale è la larghezza di banda. I nodi adiacenti ai validatori sono limitati in termini di risorse e sensibili alla latenza. Se l'accesso senza permesso viene concesso indiscriminatamente, i clienti avversari possono escludere i partecipanti onesti, causando un'esperienza utente degradata e costi per i validatori senza possibilità di ricorso. /3

La nostra soluzione sfrutta ShMonad, un token di staking liquido programmabile (LST) con capacità di impegno on-chain. Gli utenti ricevono un URL RPC privato in cambio dell'impegno di ShMON a una "Politica RPC" on-chain. Questo impegno regola i limiti di accesso.

La larghezza di banda è allocata proporzionalmente: RPS dell'utente = (ShMON impegnato dall'utente / ShMON totale impegnato) × RPS_max-global Questo produce un modello di larghezza di banda dinamicamente condivisibile e ponderato per stake senza introdurre limitatori di velocità centralizzati off-chain. 5/

Lo stake è impegnato per una durata (attualmente 20 blocchi), il che consente la memorizzazione nella cache. Il relay interroga periodicamente e acquisisce istantanee dello stato di impegno on-chain. Questo previene le chiamate EVM nel percorso critico e supporta un uso ad alta frequenza senza latenza aggiuntiva. 6/

Empiricamente, questo sistema porta a una latenza costantemente inferiore. In diverse sessioni di benchmarking indipendenti, il RPC ShMonad di FastLane mostra un tempo di risposta mediano/medio di circa 20 ms inferiore rispetto al secondo fornitore più veloce, con un divario maggiore rispetto ai RPC pubblici. 7/

ShMON impegnato nella politica RPC è messo in staking con i validatori che partecipano alla rete di relay FastLane (attualmente >90% dei validatori Monad). Questo crea allineamento: i consumatori di banda supportano gli stessi validatori che gestiscono il loro traffico, e i validatori hanno la possibilità di essere compensati direttamente tramite penali per eccesso.

Ma per applicare i limiti di larghezza di banda in modo credibile e senza fiducia, abbiamo bisogno di più dei limiti di velocità... abbiamo bisogno di un'applicazione dimostrabile. Per ora, gli utenti sono limitati al relay. Ma la roadmap include sistemi di prova on-chain basati su delta nonce e ricevute d'uso firmate. 9/

Un design minimale potrebbe confrontare i nonce degli account tra le altezze dei blocchi n e m, e penalizzare (cioè, 'applicare un sovrapprezzo' e darlo al validatore) l'uso eccessivo oltre il massimo RPS. Ma c'è un problema: questo è vulnerabile ad attacchi di rilascio in batch da parte di un relay che fa apparire le transazioni come esplosive.

Per mitigare questo, introduciamo un secondo canale: ricevute d'uso timestampate asincrone. Quando una transazione viene inviata, verrà multicast sia al validatore che a un "emittente di ricevute" separato. L'emittente restituisce un oggetto firmato al mittente, timestampato e includente metadati nonce pre-esecuzione. Questo elimina il sovraccarico di tracciamento e verifica dal percorso principale tra l'utente e il validatore. 11/

Queste ricevute (che saranno firmate) servono a un duplice scopo: 1. Feedback degli utenti: Se le ricevute smettono di arrivare, i clienti possono interrompere volontariamente il traffico per evitare costi aggiuntivi. 2. Prova on-chain: Le ricevute ancorano l'attività temporale, disambiguando lo spam reale dal batching indotto dal relay. 12/

Questo modello supporta sia gli EOA che gli userOps 4337 (supponendo bundle non condivisi o integrazione verticale con il nostro paymaster). Nelle versioni future, potremmo imporre che il firmatario della transazione corrisponda al titolare della policy o sia stato inserito nella whitelist durante l'impegno della policy. TBD. 13/

Il nostro obiettivo è spostare l'applicazione della legge on-chain senza sacrificare le prestazioni. Grazie all'abbondante spazio di blocco di Monad e alla rapida finalità, inviare prove di stato, verificare le ricevute e addebitare le spese per eccedenza è fattibile on-chain... qualcosa di impraticabile su reti a costo più elevato. 14/

Le penali per l'eccesso (analoghe alla tariffazione per congestione) sono ancora in fase di progettazione. Stiamo aspettando la struttura del mercato delle commissioni finalizzata di Monad prima di finalizzare un programma di sovrattassa - non avrebbe senso per noi progettare la commissione per l'eccesso senza sapere qual è la commissione di base. 15/

Il throughput RPC è attualmente misurato in aggregato (txs + eth_call), ma gli aggiornamenti futuri disaggregano le classi di larghezza di banda. Le richieste di lettura saranno instradate attraverso nodi ottimizzati a livello regionale, rimuovendole dal collo di bottiglia creato dai vincoli di larghezza di banda dei validatori. 16/

Per le applicazioni sensibili alla latenza (ad es. nodi completi, market maker), supportiamo il peering e il feed diretto dei blocchi tramite p2p. Per i blocchi completi, la priorità di propagazione sarà ponderata in base allo stake (LSWQoS): gli utenti con ShMON impegnato più alto ricevono i blocchi marginalmente prima, soggetti a soglie di inclusione. 17/

Questo rappresenta una deviazione dalla tradizionale RPC "best effort". Con le richieste di lettura a un RPC, l'importo dello stake impegnato determina il numero di richieste. Per i blocchi inviati dai nostri nodi, l'importo dello stake impegnato determina l'ordine di invio. 18/

Il controllo degli accessi senza fiducia è fattibile su catene ad alta capacità se incentivi, applicazione e osservabilità sono progettati a partire dai principi fondamentali. Il RPC ShMonad è un'implementazione di riferimento di questa tesi. Non vediamo l'ora di iterazioni e di un'analisi esterna. 19/