Les blockchains rapides introduisent de nouveaux défis pour la gestion de la bande passante et l'équité des RPC. Aujourd'hui, nous introduisons un mécanisme pour façonner l'accès aux RPC en utilisant des engagements de staking liquide. Le système est en ligne via le RPC ShMonad de FastLane. Ce fil explore l'architecture et la logique. 🧵

Les réseaux à haut débit comme Monad (~0,5s de temps de bloc, ~1s de finalité) laissent peu de place à un throttling réactif. Au moment où un point de terminaison RPC détecte qu'il est sous attaque par spam, les dégâts sont déjà faits. L'atténuation doit être proactive et alignée sur les incitations. /2

La contrainte clé est la bande passante. Les nœuds adjacents aux validateurs sont limités en ressources et sensibles à la latence. Si l'accès sans permission est accordé de manière indiscriminée, des clients adverses peuvent évincer les participants honnêtes, entraînant une dégradation de l'expérience utilisateur et des coûts pour les validateurs sans recours.

Notre solution s'appuie sur ShMonad, un jeton de staking liquide programmable (LST) avec des capacités d'engagement sur la chaîne. Les utilisateurs reçoivent une URL RPC privée en échange de l'engagement de ShMON à une "Politique RPC" sur la chaîne. Cet engagement régit les limites de taux d'accès. /4

La bande passante est allouée proportionnellement : RPS de l'utilisateur = (ShMON engagé de l'utilisateur / ShMON total engagé) × RPS_max-global Cela donne un modèle de bande passante partageable dynamiquement, pondéré par le stake, sans introduire de limiteurs de taux centralisés hors chaîne. 5/

Le staking est engagé pour une durée (actuellement 20 blocs), ce qui permet la mise en cache. Le relais interroge de manière intermittente et prend des instantanés de l'état d'engagement sur la chaîne. Cela empêche les appels EVM dans le chemin critique et supporte une utilisation à haute fréquence sans latence supplémentaire. 6/

Empiriquement, ce système entraîne une latence systématiquement plus faible. Lors de plusieurs sessions de benchmarking indépendantes, le RPC ShMonad de FastLane présente un temps de réponse médian/moyen d'environ 20 ms inférieur à celui du deuxième fournisseur le plus rapide, avec un écart plus important par rapport aux RPC publics. 7/

ShMON engagé dans la politique RPC est mis en jeu avec des validateurs participant au réseau de relais FastLane (actuellement >90% des validateurs Monad). Cela crée un alignement : les consommateurs de bande passante soutiennent les mêmes validateurs qui gèrent leur trafic, et les validateurs ont la possibilité d'être compensés directement via des pénalités de dépassement. 8/

Mais pour appliquer des limites de bande passante de manière crédible et sans confiance, nous avons besoin de plus que des limites de taux... nous avons besoin d'une application prouvable. Pour l'instant, les utilisateurs sont ralentis au niveau du relais. Mais la feuille de route inclut des systèmes de preuve sur chaîne basés sur des deltas de nonce et des reçus d'utilisation signés. 9/

Un design minimal pourrait comparer les nonces de compte entre les hauteurs de bloc n et m, et pénaliser (c'est-à-dire, 'appliquer une surcharge' et la donner au validateur) l'utilisation excessive au-delà du RPS maximum. Mais il y a un problème : cela est vulnérable aux attaques de libération par lots par un relais faisant apparaître les transactions comme étant par à-coups.

Pour atténuer cela, nous introduisons un deuxième canal : des reçus d'utilisation horodatés asynchrones. Lorsqu'une transaction est soumise, elle sera diffusée à la fois au validateur et à un "émetteur de reçus" séparé. L'émetteur renvoie un objet signé à l'expéditeur, horodaté et incluant des métadonnées de nonce pré-exécution. Cela élimine la surcharge de suivi et de vérification du chemin critique entre l'utilisateur et le validateur. 11/

Ces reçus (qui seront signés) ont un double objectif : 1. Retour d'expérience utilisateur : Si les reçus cessent d'arriver, les clients peuvent volontairement arrêter le trafic pour éviter des frais supplémentaires. 2. Preuve on-chain : Les reçus ancrent l'activité temporelle, clarifiant le vrai spam du regroupement induit par le relais. 12/

Ce modèle prend en charge à la fois les EOA et les userOps 4337 (en supposant des bundles non partagés ou une intégration verticale avec notre propre paymaster). Dans les versions futures, nous pourrions exiger que le signataire de la transaction corresponde au titulaire de la politique ou ait été mis sur liste blanche lors de l'engagement de la politique. À déterminer. 13/

Notre objectif est de déplacer l'exécution sur la chaîne sans sacrifier la performance. Grâce à l'abondance d'espace de bloc de Monad et à la rapidité de la finalité, soumettre des preuves d'état, vérifier des reçus et facturer des frais de dépassement est viable sur la chaîne... quelque chose d'infaisable sur des réseaux à coût plus élevé. 14/

Les pénalités de dépassement (analogues à la tarification de congestion) sont encore en cours de conception. Nous attendons la structure de marché des frais finalisée de Monad avant de finaliser un calendrier de surtaxe - il ne serait pas logique pour nous de concevoir le frais de dépassement sans connaître quel est le frais de base. 15/

Le débit RPC est actuellement mesuré en agrégé (txs + eth_call), mais les futures mises à jour désagrégeront les classes de bande passante. Les requêtes de lecture seront acheminées via des nœuds optimisés régionalement, les retirant du goulot d'étranglement créé par les contraintes de bande passante des validateurs. 16/

Pour les applications sensibles à la latence (par exemple, les nœuds complets, les teneurs de marché), nous supportons le peering et l'alimentation directe de blocs via p2p. Pour les blocs complets, la priorité de propagation sera pondérée par le stake (LSWQoS) : les utilisateurs ayant un ShMON engagé plus élevé reçoivent les blocs légèrement plus tôt, sous réserve des seuils d'inclusion. 17/

Cela représente un départ de la RPC traditionnelle « meilleur effort ». Avec les requêtes de lecture à une RPC, le montant de la mise engagée détermine le nombre de requêtes. Pour les blocs envoyés depuis nos nœuds, le montant de la mise engagée détermine l'ordre d'envoi. 18/

Le contrôle d'accès sans confiance est viable sur des chaînes à haut débit si les incitations, l'application et l'observabilité sont conçues à partir des premiers principes. Le RPC ShMonad est une mise en œuvre de référence de cette thèse. Nous attendons avec impatience l'itération et l'examen externe. 19/