Philip DiSarro informa de dos fallas críticas en la implementación de CIP-113 de Aiken

Philip DiSarro, fundador y director ejecutivo de Anastasia Labs y autor de CIP-143, dijo el 24 de julio que identificó dos vulnerabilidades críticas mientras revisaba la implementación en Aiken del marco de tokens programables CIP-113 de Cardano. En el mismo hilo, publicó benchmarks actualizados que comparan la base de código de Aiken con la implementación original en Plutarch desarrollada por DiSarro y el equipo de Input Output. La revelación llega mientras CIP-113 permanece en la etapa Last Check y su implementación sigue en revisión de seguridad.

Plutarch registra menores costos en los benchmarks de CIP-113

El archivo de benchmarks publicado compara las dos implementaciones bajo el presupuesto máximo de transacción de Cardano de 10 mil millones de unidades de CPU y 14 millones de unidades de memoria. Tanto Aiken como Plutarch compilan finalmente a Untyped Plutus Core, el código que ejecutan los nodos de Cardano.

Plutarch registró un menor consumo total de CPU y memoria en cada uno de los cinco escenarios destacados.

En la prueba de transferencia estándar, Aiken usó 1.19 veces más CPU y 1.17 veces más memoria que Plutarch. La mayor diferencia entre los escenarios mostrados apareció en la prueba que combina una acción de incautación, un script externo y 50 entradas de clave pública, donde Aiken consumió 3.23 veces más CPU y 2.36 veces más memoria.

Ambas implementaciones se mantuvieron dentro de los límites de transacción de Cardano en la prueba de 16 swaps de $NIGHT DEX. Plutarch usó 6.66% del presupuesto de CPU disponible y 11.68% del presupuesto de memoria, frente a 7.59% y 15.25% para Aiken.

La publicación de DiSarro también incluyó proyecciones lineales sobre cuántos elementos podrían caber en una transacción. Las estimaciones ubicaron a Plutarch en 658 entradas frente a 162 para Aiken, 472 salidas frente a 334, 36,489 tokens frente a 1,661 y 527 políticas frente a 160. Estas cifras son proyecciones de capacidad de los scripts derivadas de los costos de ejecución probados, no de un rendimiento medido en mainnet.

La comparación de scripts compilados produjo scripts de Plutarch más pequeños en seis de siete categorías. El script directoryNodeSpending midió 331 bytes en Plutarch y 1,698 bytes en Aiken. La excepción fue programmableLogicGlobal, donde Aiken produjo un script de 3,157 bytes frente a 3,437 bytes para Plutarch.

CIP-113 añade reglas programables a los activos nativos de Cardano

CIP-113 propone un marco para añadir reglas de validación programables a los activos nativos de Cardano sin requerir un cambio en el libro mayor ni una bifurcación dura. Los emisores podrían definir condiciones que se ejecutan durante las transferencias de tokens, la acuñación y la quema.

Las reglas pueden incluir listas de permitidos, listas de denegados, restricciones de transferencia, bloqueos temporales y funciones opcionales de congelamiento o incautación. El marco está destinado a stablecoins, valores tokenizados y activos del mundo real que requieren controles sobre la propiedad y el movimiento.

Según la arquitectura propuesta, los tokens programables se mantienen en una dirección de contrato inteligente compartida, mientras que la propiedad se representa mediante credenciales de stake. Un registro en cadena conecta cada política de tokens con sus reglas de transferencia, la lógica de emisión y cualquier control autorizado de terceros.

Las wallets tendrían que resolver las credenciales de stake para mostrar los saldos correctamente. Los intercambios descentralizados, indexadores, exploradores y otras aplicaciones también tendrían que admitir el proceso de validación adicional antes de que los usuarios puedan interactuar con tokens programables a través de la infraestructura existente de Cardano.

Aiken y Plutarch ofrecen enfoques de desarrollo diferentes aunque compilan al mismo formato de código en cadena. La documentación para desarrolladores de Cardano presenta Aiken como un punto de partida accesible con pruebas integradas y una sintaxis diseñada para ese fin. Plutarch es un lenguaje incrustado basado en Haskell que ofrece a los desarrolladores un control más detallado sobre el código generado y los costos de ejecución.

DiSarro es autor de CIP-143, Interoperable Programmable Tokens y trabajó con el equipo de Input Output en su implementación de referencia original en Plutarch. El repositorio de Cardano Foundation indica que los validadores actuales en Aiken se migraron desde esa implementación y se adaptaron al marco más amplio de CIP-113.

Su participación directa en la arquitectura y la base de código originales sitúa la nueva comparación de benchmarks dentro de la historia de desarrollo del proyecto. CIP-143 ahora figura como inactivo tras incorporarse al CIP-113 candidato, que permanece en la etapa de revisión Last Check por parte de los editores de CIP.

Dos vulnerabilidades reportadas esperan su divulgación técnica

DiSarro dijo que su revisión de la implementación en Aiken descubrió dos vulnerabilidades críticas que se pasaron por alto durante el proceso de auditoría. Su hilo no identificó el código afectado, las posibles rutas de ataque, el impacto potencial ni el estado de remediación.

El repositorio ya contiene hallazgos públicos de la auditoría inicial, incluidos dos issues cerrados etiquetados como críticos. Issue 56 describió una vía por la cual los tokens recién acuñados podrían escapar de la custodia programable durante una acción de terceros. Issue 64 abordó la posible contaminación de UTxOs no relacionados mediante la misma función administrativa.

Esos hallazgos se reportaron durante la auditoría inicial y no pueden identificarse como las dos vulnerabilidades que DiSarro dijo haber encontrado después sin una divulgación técnica adicional.

También se han planteado preocupaciones de seguridad dentro de la discusión de revisión de CIP-113. Un colaborador dijo el 20 de julio que se habían pasado por alto múltiples vulnerabilidades de alta gravedad y que algunos cambios de usabilidad propuestos introducían problemas de seguridad adicionales. Durante la revisión posterior del CIP, los participantes acordaron que el siguiente paso debería incluir una auditoría más integral mientras la propuesta permanece en Last Check.

El repositorio de Cardano Foundation indica que los hallazgos de la auditoría inicial y de una reauditoría posterior han sido remediados en la rama principal. Sin embargo, el informe final de auditoría sigue sin publicarse y el repositorio designa la implementación como no apta para uso en producción con activos reales hasta que se completen el informe, las pruebas más amplias y una revisión adicional por expertos.

Antes de que la implementación de CIP-113 pueda avanzar hacia despliegues con activos reales, quedan pendientes tres entregables concretos: la publicación del informe final de auditoría, la divulgación y remediación de las dos vulnerabilidades reportadas por DiSarro, y la finalización de la revisión de seguridad más amplia solicitada durante el proceso de CIP. Esos entregables definirán qué cambios de código y de especificación se incorporan antes de que la propuesta se fusione y la implementación se considere para uso en producción.