El cliente IBC de Cardano añade verificación de stake con Mithril

Cardano Foundation lanzó la versión v0.1.6 de su núcleo de light client IBC de Cardano experimental el 16 de octubre. Cada nuevo cliente ahora parte de una distribución de stake certificada por Mithril, incorporando datos de stake autenticados a la infraestructura para mensajes y transferencias de tokens entre cadenas.

Mithril certifica las distribuciones de stake de Cardano

Una distribución de stake registra cuánta ADA se delega a cada stake pool. El cliente IBC usa esa información al verificar bloques de Cardano y al evaluar si se han cumplido las condiciones para aceptar el estado IBC de Cardano.

Mithril certifica datos de Cardano mediante firmas de los operadores de stake pools participantes. En esta implementación, sus certificados autentican la distribución de stake asociada con una época en particular, un período definido en el protocolo de Cardano.

Según la documentación del cliente, los montos de stake eran el componente restante sin firmar de sus datos de época. Por lo tanto, una distribución suministrada por un relayer, el servicio que transporta información entre redes, llevaba una ventana de impugnación de seis horas.

Una distribución certificada ahora tiene prioridad sobre una tabla cargada. Si un certificado de Mithril contradice datos de stake aceptados previamente, el cliente se congela. La versión también alinea la verificación de firmas con la implementación de referencia de Mithril e introduce comprobaciones de pruebas más estrictas.

Cómo afecta el cambio a las transferencias IBC de Cardano

IBC, o Inter Blockchain Communication, es un protocolo para intercambiar mensajes y tokens entre blockchains. Cardano IBC Incubator desarrolla la implementación de Cardano, incluidos componentes que admiten transferencias de tokens fungibles.

Un light client se ejecuta en la cadena receptora y comprueba información de otra red antes de que se acepte un mensaje IBC. Para Cardano, esto implica seguir los bloques, verificar a sus productores y reunir evidencia suficiente mediante la producción de bloques posterior.

Un certificado de Mithril coincidente elimina la espera de verificación de stake. Las épocas posteriores sin esa certificación siguen sujetas al proceso de impugnación.

Otros requisitos de aceptación continúan aplicándose. El modelo actual exige al menos 24 bloques construidos después del bloque observado, al menos cinco pools que cumplan los requisitos, y un umbral de stake especificado. Alcanzar el recuento mínimo de bloques por sí solo no garantiza la aceptación.

Los tiempos de transferencia individuales aún dependen de la finalización de bloques, las actualizaciones del cliente y el procesamiento de mensajes IBC.

El despliegue de IBC en Cardano sigue siendo experimental

El repositorio continúa describiendo el proyecto como un software experimental que está incompleto y probado de forma insuficiente para un puente de producción. Los desarrolladores pueden probar transferencias de tokens, incluida ADA de prueba, mientras que la seguridad de la implementación también depende de las fuentes de datos configuradas y de los parámetros de aceptación.

Una cadena de Cosmos participante debe integrar el cliente de Cardano y permitir explícitamente su uso. El nuevo núcleo se lanzó junto con adaptadores para dos versiones compatibles de ibc-go.

Los clientes existentes que usan el antiguo formato de almacenamiento en línea deben recrearse antes de que la cadena anfitriona actualice al nuevo módulo.

Los operadores establecen una configuración inicial de Mithril confiable al crear un cliente. La inicialización se completa solo después de que la distribución de stake importada coincide con un certificado verificado, lo que convierte los datos de stake autenticados en un punto de partida obligatorio para la verificación posterior entre cadenas del cliente.