Philip DiSarro relata duas falhas críticas na implementação do CIP-113 do Aiken

Philip DiSarro, fundador e CEO da Anastasia Labs e autor do CIP-143, disse em 24 de julho que identificou duas vulnerabilidades críticas enquanto revisava a implementação do Aiken do framework de tokens programáveis CIP-113 da Cardano. Na mesma sequência, ele divulgou benchmarks atualizados que comparam a base de código do Aiken com a implementação original em Plutarch desenvolvida por DiSarro e pela equipe da Input Output. A divulgação ocorre enquanto o CIP-113 permanece na etapa Last Check e sua implementação continua em revisão de segurança.

Plutarch registra custos menores em benchmarks do CIP-113

O arquivo de benchmarks publicado compara as duas implementações sob o orçamento máximo de transação da Cardano de 10 bilhões de unidades de CPU e 14 milhões de unidades de memória. Tanto Aiken quanto Plutarch acabam compilando para Untyped Plutus Core, o código executado pelos nós da Cardano.

Plutarch registrou menor consumo total de CPU e memória em cada um dos cinco cenários destacados.

No teste de transferência padrão, Aiken usou 1,19 vezes mais CPU e 1,17 vezes mais memória do que Plutarch. A maior diferença entre os cenários exibidos apareceu no teste que combina uma ação de apreensão, um script externo e 50 entradas de chave pública, em que Aiken consumiu 3,23 vezes mais CPU e 2,36 vezes mais memória.

Ambas as implementações permaneceram dentro dos limites de transação da Cardano no teste de 16 swaps do DEX $NIGHT. Plutarch usou 6,66% do orçamento de CPU disponível e 11,68% do orçamento de memória, em comparação com 7,59% e 15,25% para Aiken.

A publicação de DiSarro também incluiu projeções lineares de quantos elementos caberiam em uma transação. As estimativas colocaram Plutarch em 658 entradas contra 162 para Aiken, 472 saídas contra 334, 36.489 tokens contra 1.661 e 527 políticas contra 160. Esses números são projeções de capacidade de script derivadas de custos de execução testados, não de throughput medido na mainnet.

A comparação dos scripts compilados produziu scripts menores em Plutarch em seis das sete categorias. O script directoryNodeSpending mediu 331 bytes em Plutarch e 1.698 bytes em Aiken. A exceção foi programmableLogicGlobal, em que Aiken produziu um script de 3.157 bytes, em comparação com 3.437 bytes para Plutarch.

CIP-113 adiciona regras programáveis aos ativos nativos da Cardano

O CIP-113 propõe um framework para adicionar regras de validação programáveis aos ativos nativos da Cardano sem exigir uma mudança no ledger ou um hard fork. Emissores poderiam definir condições que são executadas durante transferências, cunhagem e queima de tokens.

As regras podem incluir allowlists, denylists, restrições de transferência, time locks e funções opcionais de congelamento ou apreensão. O framework é voltado para stablecoins, valores mobiliários tokenizados e ativos do mundo real que exigem controles sobre propriedade e movimentação.

Na arquitetura proposta, tokens programáveis ficam em um endereço de contrato inteligente compartilhado, enquanto a propriedade é representada por credenciais de stake. Um registro on-chain conecta cada política de token às suas regras de transferência, lógica de emissão e a quaisquer controles de terceiros autorizados.

Carteiras precisariam resolver as credenciais de stake para exibir saldos corretamente. Corretoras descentralizadas, indexadores, exploradores e outros aplicativos também precisariam dar suporte ao processo adicional de validação antes que os usuários pudessem interagir com tokens programáveis por meio da infraestrutura existente da Cardano.

Aiken e Plutarch oferecem abordagens de desenvolvimento diferentes, embora compilem para o mesmo formato de código on-chain. A documentação para desenvolvedores da Cardano apresenta Aiken como um ponto de partida acessível, com testes integrados e uma sintaxe criada para esse fim. Plutarch é uma linguagem embutida baseada em Haskell que dá aos desenvolvedores controle mais detalhado sobre o código gerado e os custos de execução.

DiSarro é autor do CIP-143, Interoperable Programmable Tokens e trabalhou com a equipe da Input Output em sua implementação de referência original em Plutarch. O repositório da Cardano Foundation afirma que os validadores atuais em Aiken foram migrados dessa implementação e adaptados para o framework mais amplo do CIP-113.

Seu envolvimento direto na arquitetura e na base de código originais insere a nova comparação de benchmarks no histórico de desenvolvimento do projeto. O CIP-143 agora está marcado como inativo após ser incorporado ao CIP-113 candidato, que permanece na etapa de revisão Last Check pelos editores de CIPs.

Duas vulnerabilidades relatadas aguardam divulgação técnica

DiSarro disse que sua revisão da implementação em Aiken revelou duas vulnerabilidades críticas que passaram despercebidas durante o processo de auditoria. Sua sequência não identificou o código afetado, caminhos de ataque possíveis, impacto potencial ou o status de correção.

O repositório já contém achados públicos da auditoria inicial, incluindo duas issues encerradas rotuladas como críticas. A Issue 56 descreveu um caminho pelo qual tokens cunhados recentemente poderiam escapar da custódia programável durante uma ação de terceiro. A Issue 64 abordou a possível contaminação de UTxOs não relacionados por meio da mesma função administrativa.

Esses achados foram relatados durante a auditoria inicial e não podem ser identificados como as duas vulnerabilidades que DiSarro afirmou ter encontrado posteriormente sem uma divulgação técnica adicional.

Preocupações de segurança também foram levantadas na discussão de revisão do CIP-113. Um colaborador disse em 20 de julho que múltiplas vulnerabilidades de alta gravidade haviam passado despercebidas e que algumas mudanças de usabilidade propostas introduziram problemas adicionais de segurança. Durante a revisão subsequente do CIP, os participantes concordaram que o próximo passo deveria incluir uma auditoria mais abrangente enquanto a proposta permanece em Last Check.

O repositório da Cardano Foundation afirma que os achados da auditoria inicial e de uma reauditoria subsequente foram remediados no branch principal. No entanto, o relatório final de auditoria permanece não publicado, e o repositório designa a implementação como inadequada para uso em produção com ativos reais até que o relatório, testes mais amplos e nova revisão por especialistas sejam concluídos.

Antes que a implementação do CIP-113 possa avançar para implantações com ativos reais, três entregáveis concretos permanecem pendentes: a publicação do relatório final de auditoria, a divulgação e a correção das duas vulnerabilidades relatadas por DiSarro e a conclusão da revisão de segurança mais ampla solicitada durante o processo de CIP. Esses entregáveis definirão quais mudanças de código e de especificação serão incorporadas antes que a proposta seja mesclada e a implementação seja considerada para uso em produção.