Las cadenas de bloques rápidas introducen nuevos desafíos para la gestión del ancho de banda y la equidad de RPC. Hoy presentamos un mecanismo para dar forma al acceso a RPC utilizando compromisos de participación líquida. El sistema está en vivo a través de ShMonad RPC de FastLane. Este hilo explora la arquitectura y la justificación. 🧵

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

La restricción clave es el ancho de banda. Los nodos adyacentes al validador tienen recursos limitados y son sensibles a la latencia. Si el acceso sin permiso se otorga indiscriminadamente, los clientes adversarios pueden desplazar a los participantes honestos, lo que resulta en una experiencia de usuario degradada y costos de validador sin recurso. /3

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

La anchura de banda se asigna proporcionalmente: RPS del usuario = (ShMON confirmado del usuario / ShMON total confirmado) × RPS_max-global Esto produce un modelo de ancho de banda ponderado por participación que se puede compartir dinámicamente sin introducir limitadores de velocidad centralizados fuera de la cadena. 5/

El stake se compromete por una duración (actualmente 20 bloques), lo que permite el almacenamiento en caché. El relé sondea y toma instantáneas de forma intermitente del estado de compromiso en cadena. Esto evita las llamadas EVM en la ruta crítica y admite el 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 velocidad ... 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 mínimo podría comparar los nunces de la cuenta entre las alturas de bloque n y m, y reducir (es decir, 'aplicar recargo' y dárselo al validador) el uso excesivo por encima del RPS máximo. Pero hay un problema: esto es vulnerable a los ataques de liberación por lotes de un relé que hace que los txs parezcan en ráfagas.

Para mitigar esto, presentamos un segundo canal: recibos de uso asíncronos con marca de tiempo. Cuando se envía una transacción, se hará multidifusión tanto para el validador como para un "emisor de recibos" independiente. El emisor devuelve un objeto firmado al remitente, con marca de tiempo e incluyendo metadatos nonce previos a la ejecución. Elimina la sobrecarga de seguimiento y verificación de la ruta activa 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 EOA y 4337 userOps (asumiendo paquetes no compartidos o integración vertical con nuestro propio pagador). En versiones futuras, podemos exigir que el firmante de la transacción coincida con el titular de la póliza o que haya sido incluido en la lista blanca durante el compromiso de la póliza. TBD. 13/

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

Las sanciones por exceso de uso (análogas a la tarifa de congestión) aún están en diseño. Estamos esperando la estructura de mercado de tarifas finalizada de Monad antes de finalizar un programa de recargos: no tendría sentido para nosotros diseñar la tarifa por exceso sin saber cuál es la tarifa de referencia. 15/

El rendimiento de RPC se mide actualmente en agregado (txs + eth_call), pero las actualizaciones futuras desagregarán las clases de ancho de banda. Las solicitudes de lectura se enrutarán a través de nodos optimizados regionalmente, eliminándolos del cuello de botella creado por las restricciones 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/