Las blockchains rápidas introducen nuevos desafíos para la gestión del ancho de banda y la equidad en RPC. Hoy estamos introduciendo un mecanismo para dar forma al acceso a RPC utilizando compromisos de staking líquido. El sistema está activo a través de ShMonad RPC de FastLane. Este hilo explora la arquitectura y la razón de ser. 🧵

Las redes de alto rendimiento como Monad (~0.5s de tiempo de bloque, ~1s de finalización) dejan poco margen para la limitación reactiva. Para cuando un punto final de RPC detecta que está bajo un ataque de spam, el daño ya se ha hecho. La mitigación debe ser proactiva y alineada con incentivos. /2

La principal restricción es el ancho de banda. Los nodos adyacentes a los validadores tienen recursos limitados y son sensibles a la latencia. Si se concede acceso sin permisos de manera indiscriminada, los clientes adversarios pueden desplazar a los participantes honestos, lo que resulta en una experiencia de usuario degradada y costos para los validadores sin posibilidad de recurso. /3

Nuestra solución aprovecha ShMonad, un token de staking líquido programable (LST) con capacidades de compromiso en la cadena. Los usuarios reciben una URL RPC privada a cambio de comprometer ShMON a una "Política RPC" en la cadena. Este compromiso rige los límites de tasa de acceso. /4

El ancho de banda se asigna proporcionalmente: RPS del usuario = (ShMON comprometido del usuario / ShMON total comprometido) × RPS_max-global Esto da como resultado un modelo de ancho de banda dinámicamente compartible y ponderado por participación, sin introducir limitadores de tasa centralizados fuera de la cadena. 5/

El stake está comprometido por una duración (actualmente 20 bloques), lo que permite el almacenamiento en caché. El relay consulta intermitentemente y toma instantáneas del estado de compromiso en la cadena. Esto previene llamadas EVM en la ruta crítica y soporta un uso de alta frecuencia sin latencia adicional. 6/

Empíricamente, este sistema resulta en una latencia consistentemente más baja. A través de múltiples sesiones de benchmarking independientes, el RPC ShMonad de FastLane exhibe un tiempo de respuesta mediano/promedio ~20ms más bajo que el segundo proveedor más rápido, con una brecha mayor frente a los RPC públicos. 7/

ShMON comprometido con la política RPC está apostado con los validadores que participan en la red de relé FastLane (actualmente >90% de los validadores de Monad). Esto crea alineación: los consumidores de ancho de banda apoyan a los mismos validadores que sirven su tráfico, y los validadores tienen el potencial de ser compensados directamente a través de penalizaciones por exceso.

Pero para hacer cumplir los límites de ancho de banda de manera creíble y sin confianza, necesitamos más que límites de tasa... necesitamos una aplicación demostrable. Por ahora, los usuarios están limitados en el relé. Pero la hoja de ruta incluye sistemas de prueba en cadena basados en deltas de nonce y recibos de uso firmados. 9/

Un diseño minimalista podría comparar los nonces de las cuentas entre las alturas de bloque n y m, y penalizar (es decir, 'aplicar un recargo' y dárselo al validador) el uso excesivo por encima del RPS máximo. Pero hay un problema: esto es vulnerable a ataques de liberación por lotes por parte de un relay que hace que las transacciones parezcan explosivas.

Para mitigar esto, introducimos un segundo canal: recibos de uso con marca de tiempo asíncronos. Cuando se envía una transacción, se transmitirá a ambos, el validador y un "emisor de recibos" separado. El emisor devuelve un objeto firmado al remitente, con marca de tiempo e incluyendo metadatos de nonce de pre-ejecución. Esto elimina la sobrecarga de seguimiento y verificación del camino caliente entre el usuario y el validador. 11/

Estos recibos (que serán firmados) sirven a un doble propósito: 1. Retroalimentación del usuario: Si los recibos dejan de llegar, los clientes pueden detener voluntariamente el tráfico para evitar cargos por exceso. 2. Prueba en cadena: Los recibos anclan la actividad temporal, desambiguando el spam real del agrupamiento inducido por el relé. 12/

Este modelo admite tanto EOAs como userOps 4337 (suponiendo que no haya paquetes compartidos o integración vertical con nuestro propio pagador). En versiones futuras, podemos hacer cumplir que el firmante de la transacción coincida con el titular de la política o haya sido incluido en la lista blanca durante el compromiso de la política. Por determinar. 13/

Nuestro objetivo es trasladar la aplicación de la ley a la cadena sin sacrificar el rendimiento. Gracias al abundante espacio en bloques de Monad y a la rápida finalización, enviar pruebas de estado, verificar recibos y cobrar tarifas por exceso es viable en la cadena... algo inviable en redes de mayor costo. 14/

Las penalizaciones por exceso (análogas a la tarificación por congestión) aún están en diseño. Estamos a la espera de la estructura de mercado de tarifas finalizada de Monad antes de finalizar un calendario de recargos; no tendría sentido diseñar la tarifa por exceso sin saber cuál es la tarifa base. 15/

El rendimiento de RPC se mide actualmente de forma agregada (txs + eth_call), pero las futuras actualizaciones desagregarán las clases de ancho de banda. Las solicitudes de lectura se enrutarán a través de nodos optimizados regionalmente, eliminándolas del cuello de botella creado por las limitaciones de ancho de banda del validador. 16/

Para aplicaciones sensibles a la latencia (por ejemplo, nodos completos, creadores de mercado), apoyamos el emparejamiento y la alimentación directa de bloques a través de p2p. Para bloques completos, la prioridad de propagación será ponderada por la participación (LSWQoS): los usuarios con más ShMON comprometidos reciben bloques marginalmente antes, sujeto a los umbrales de inclusión. 17/

Esto representa un alejamiento del RPC tradicional de "mejor esfuerzo". Con las solicitudes de lectura a un RPC, la cantidad de participación comprometida determina el número de solicitudes. Para los bloques enviados desde nuestros nodos, la cantidad de participación comprometida determina el orden de envío. 18/

El control de acceso sin confianza es viable en cadenas de alto rendimiento si los incentivos, la aplicación y la observabilidad se diseñan desde los primeros principios. El RPC de ShMonad es una implementación de referencia de esa tesis. Esperamos la iteración y el escrutinio externo. 19/