Cardano propone alertas descentralizadas para pools de stake y aplicaciones

CIP-0201 propone una red de comunicación descentralizada para alertas de seguridad de Cardano, anuncios de pools de stake, actualizaciones de gobernanza y notificaciones de aplicaciones. Los mensajes viajarían entre nodos participantes, con firmas que permiten a los destinatarios verificar su origen. La propuesta se convirtió en candidata a CIP el 29 de septiembre y continúa bajo revisión técnica.

Alertas firmadas para operadores y usuarios de Cardano

El CPS-0038 asociado identifica cuatro necesidades de comunicación: advertencias de incidentes para operadores de pools de stake, anuncios de pools para delegadores, información de votación para participantes de la gobernanza y notificaciones de aplicaciones sobre posiciones o cambios de protocolo.

Un pool que se prepara para retirarse, por ejemplo, necesita notificar a los delegadores mientras aún tienen tiempo de mover su delegación. Una aplicación puede necesitar alertar a los usuarios antes de una fecha límite que afecte a sus posiciones.

Actualmente, estos mensajes pasan por listas de correo, plataformas de comunicación e infraestructura de proveedores. CPS-0038 describe la ausencia de un estándar común de Cardano que combine autenticación del emisor, integridad de mensajes y resistencia medible a la supresión dirigida.

La autenticación por sí sola no resuelve la entrega. El documento examina ataques en los que participantes maliciosos controlan las conexiones de red de un destinatario y retienen mensajes. Ese destinatario puede no tener evidencia de que se envió una alerta, lo que convierte la selección de pares en parte del problema de comunicación.

Cómo distribuiría CIP-0201 las notificaciones

El sistema propuesto utiliza un modelo de publicación y suscripción. Los emisores envían mensajes firmados a temas designados, y los nodos suscriptores los reciben y los reenvían a pares conectados.

Los nodos PubSub operarían por separado de los nodos de Cardano. Sus registros de inscripción se ubicarían en la cadena de bloques, mientras que el contenido de las notificaciones permanecería fuera de cadena.

Para cada período de difusión, una aleatoriedad compartida determina qué pares de nodos registrados pueden conectarse. Cada nodo selecciona en privado pares de ese conjunto elegible. Las conexiones rotan periódicamente, lo que da a un suscriptor aislado otra oportunidad de alcanzar a participantes que reenvían mensajes.

Los números de secuencia revelan huecos en el flujo de mensajes de un emisor. Los nodos retienen temporalmente copias para que los pares puedan solicitar notificaciones faltantes. Este mecanismo de recuperación proporciona oportunidades adicionales de entrega, aunque la rotación no garantiza la recepción dentro de un solo período.

Cada nodo registrado bloquearía un depósito reembolsable en ADA, lo que hace más costoso crear identidades en grandes cantidades. El ADA bloqueado no gana recompensas de stake y no otorga al operador peso adicional en la red de mensajería. El retiro de fondos se realiza tras la retirada del registro y un período de espera requerido.

La implementación requiere pruebas de recuperación e integración con monederos

El prototipo de referencia admite experimentos pero aún no implementa la especificación completa. La implementación requiere reglas de interoperabilidad finalizadas, una fuente de aleatoriedad seleccionada y pruebas que cubran la rotación de conexiones y la recuperación. Los criterios de activación también exigen dos implementaciones que interoperan y resultados de conformidad publicados.

La operación durante una detención o bifurcación de la cadena de Cardano sigue sin resolverse porque los registros de participantes y las configuraciones compartidas dependen de datos de la cadena de bloques. La propuesta no requiere una hard fork de Cardano.

Los proveedores de monederos se encargarían del paso final de entrega. CPS-0038 distingue entre que un mensaje llegue a la infraestructura participante y que llegue a un usuario individual. En el escenario de retiro de un pool, la red llevaría el anuncio firmado al backend de un monedero, y luego el monedero tendría que hacer visible ese aviso a los delegadores afectados antes de que cambien de pool.