Las cadenas de bloques rápidas presentan 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 mediante compromisos de staking líquido. El sistema está en vivo a través del RPC ShMonad de FastLane. Este hilo explora la arquitectura y la lógica. 🧵

Las redes de alto rendimiento como Monad (~0,5 s de tiempo de bloqueo, ~1 s de finalidad) dejan poco espacio para la limitación reactiva. En el momento en que un punto de conexión RPC detecta que está bajo un ataque de spam, el daño ya está hecho. La mitigación debe ser proactiva y estar 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 permisos se concede indiscriminadamente, los clientes adversarios pueden desplazar a los participantes honestos, lo que resulta en una degradación de los costos de UX y validador sin recurso. /3

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

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

La participación se compromete durante 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 la 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 da como resultado una latencia consistentemente más baja. A lo largo de múltiples sesiones de evaluación comparativa independientes, el RPC ShMonad de FastLane exhibe un tiempo de respuesta medio/medio ~ 20 ms 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 se apuesta con los validadores que participan en la red de retransmisión FastLane (actualmente el >90% de los validadores de Monad). Esto crea alineación: los consumidores de ancho de banda admiten los mismos validadores que atienden su tráfico, y los validadores tienen el potencial de ser compensados directamente a través de penalizaciones por exceso de uso. 8/

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 a prueba en la cadena basados en deltas de nonce y recibos de uso firmados. 9/

Un diseño mínimo podría comparar los números de cuenta entre las alturas de bloque n y m, y reducir el uso excesivo (es decir, 'aplicar un recargo' y dárselo al validador) por encima del RPS máximo. Pero hay un problema: esto es vulnerable a los ataques de liberación por lotes de un relé, lo que hace que las txs parezcan ráfagas.

Para mitigar esto, introducimos un segundo canal: recibos de uso asincrónicos con marca de tiempo. Cuando se envía una transacción, se transmitirá por múltiples medios tanto al validador como a un "emisor de recibos" separado. 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) tienen una doble finalidad: 1. Comentarios de los usuarios: Si los recibos dejan de llegar, los clientes pueden detener voluntariamente el tráfico para evitar cargos por exceso de uso. 2. Prueba en cadena: Los recibos anclan la actividad temporal, desambiguando el spam real del procesamiento por lotes inducido por retransmisión. 12/

Este modelo es compatible tanto con EOAs como con 4337 userOps (asumiendo paquetes no compartidos o integración vertical con nuestro propio pagador). En versiones futuras, es posible que impongamos que el firmante de la transacción coincida con el titular de la póliza o que se haya incluido en la lista blanca durante el compromiso de la póliza. TBD. 13/

Nuestro objetivo es trasladar la aplicación de la ley a la cadena sin sacrificar el rendimiento. Gracias al abundante espacio de bloques y a la rápida finalidad de Monad, la presentación de pruebas de estado, la verificación de recibos y el cobro de tarifas por exceso son viables en la cadena... algo inviable en redes de mayor costo. 14/

Las penalizaciones por exceso de uso (análogas a la tarifa de congestión) aún están en diseño. Estamos a la espera de la estructura final del mercado de tarifas de Monad antes de finalizar un programa de recargos: no tendría sentido que diseñáramos la tarifa por exceso sin saber cuál es la tarifa de referencia. 15/

Actualmente, el rendimiento de RPC se mide 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ándolas del cuello de botella creado por las restricciones de ancho de banda del validador. 16/

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

Esto representa una desviación del RPC tradicional de "mejor esfuerzo". Con las solicitudes de lectura a una RPC, la cantidad de apuesta comprometida determina el número de solicitudes. Para los bloques enviados desde nuestros nodos, la cantidad de apuesta 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 a partir de los primeros principios. El RPC de ShMonad es una implementación de referencia de esa tesis. Esperamos con interés la iteración y el escrutinio externo. 19/