Resumo Técnico: Integração Segura de AltDA para Ethereum L2s

Declaração do Problema

Sistemas de Disponibilidade de Dados Alternativos (AltDA) permitem que rollups de Camada 2 (L2) do Ethereum escalem ao publicar dados em massa para redes externas (ex: Celestia, EigenDA, Avail) enquanto postam apenas referências compactas para o Ethereum. Embora isso alivie os gargalos de throughput da disponibilidade de dados (DA) nativa do Ethereum, introduz uma lacuna de segurança crítica na fronteira de integração.

Os frameworks existentes no ecossistema identificam riscos de alto nível, como suposições de confiança em relação ao provedor de DA ou a existência de um verificador de DA. No entanto, eles falham em fornecer uma especificação completa de como um L2 deve se integrar à AltDA. Essa falta de uma especificação rigorosa de ponta a ponta cria "lacunas de conhecimento" onde:

1. Verificadores de DA podem autenticar uma afirmação sobre dados externos sem provar que o estado do L2 é derivado especificamente desses dados.
2. Compromissos (Commitments) podem ser válidos na criação, mas inseguros para consumo posterior se o sistema de DA descartar (pruning) os dados ou se a janela de tempo para recuperação expirar.
3. Ambiguidade pode existir onde um compromisso válido se vincula a um blob que decodifica em múltiplos payloads de rollup ou em um payload não canônico.

Essas lacunas podem levar a modos de falha graves, incluindo paralisações de L2 (halts), derivações inconsistentes entre nós honestos, asserções de estado inválidas e ataques de ponte (bridge attacks) onde fundos são sacados com base em transições de estado não verificadas ou conflitantes.

Metodologia

O artigo propõe um framework de validação canônica que modela a fronteira de integração AltDA como um pipeline de tradução tipado, determinístico e total. Os autores definem o fluxo como:
$$\text{InboxBytes} \rightarrow \text{AltDACommitment} \rightarrow \text{Blob} \rightarrow \text{RollupPayload}$$

A metodologia central envolve a definição de uma Função de Validação Total ($F$) que mapeia qualquer string de bytes arbitrária de um inbox do L1 para exatamente um de três resultados:

1. RollupPayload(p): Um payload único e válido para a lógica de execução do L2.
2. Drop: Um input inválido que deve ser rejeitado deterministicamente.
3. Stall: Uma condição temporária (ex: indisponibilidade de dados) que interrompe o processamento, mas não causa uma falha de consenso, sujeita a políticas de tentativa/timeout.

O framework identifica seis obrigações semânticas que devem ser aplicadas ao longo deste pipeline:

• Parsing Canônico: Lidar com bytes arbitrários do inbox sem causar crashes de implementação.
• Verificação de DA: Validar que o compromisso é autêntico sob o sistema de DA externo.
• Recência: Garantir que o compromisso seja recente o suficiente para que as partes honestas ainda possam recuperar os dados dentro da janela de liquidação (settlement window).
• Vinculação Compromisso-Blob (Commitment-to-Blob Binding): Provar que o blob recuperado corresponde unicamente ao compromisso.
• Unicidade do Payload: Garantir que o blob decodifica em exatamente um payload de rollup canônico.
• Tratamento Determinístico de Falhas: Garantir que todos os inputs inválidos resultem em um Drop ou Stall definido, em vez de comportamento indefinido.

Os autores analisam três padrões de integração para determinar onde essas obrigações podem ser aplicadas:

1. Prova de Falha Interativa (Interactive Fault Proof): Aplicar a validação de DA dentro do processo de resolução de disputas.
2. Prova de Validade (Validity Proof): Incluir a relação de DA (verificação, vinculação, recência) dentro da declaração da prova sucinta.
3. Verificação Eager de Inbox (Eager Inbox Verification): Validar compromissos no nível do contrato de inbox do L1 antes que eles entrem no pipeline de derivação.

Principais Contribuições

1. Modelo de Validação Tipado: O artigo introduz um modelo formal que separa bytes de inbox do L1, compromissos de AltDA, blobs externos e payloads de rollup, esclarecendo que a validade em um domínio não implica validade em outro.
2. Obrigações Semânticas: Define explicitamente as seis obrigações centrais necessárias para uma integração segura, indo além das classificações de risco de alto nível para requisitos semânticos concretos.
3. Taxonomia de Ataques: Os autores derivam vetores de ataque concretos resultantes da ausência de obrigações, incluindo:
   • Liquidação sub-restrita (Under-constrained settlement): Onde uma transição de estado é aceita sem estar vinculada aos dados autenticados.
   • Paralisações de derivação (Derivation halts): Onde inputs inválidos fazem com que nós honestos travem ou divirjam.
   • Falhas de segurança de ponte (Bridge safety failures): Onde reivindicações de estado conflitantes são aceitas devido à ambiguidade na vinculação de dados.
4. Avaliação de Arquiteturas Representativas: O framework é aplicado a integrações do mundo real, incluindo Celestia-Blobstream (OP e Arbitrum), EigenDA (OP e Arbitrum) e Avail-ZKsync. A análise revela quais obrigações são aplicadas por componentes específicos (ex: bridges de DA, contratos de inbox, sistemas de prova) e identifica áreas onde as especificações são atualmente "não identificadas" ou requerem auditoria adicional.

Resultados

A avaliação das integrações existentes demonstra que a presença de um verificador de DA ou de uma bridge é insuficiente para a segurança.

• Integrações com Celestia: Embora o Blobstream forneça autenticação, a análise descobriu que alguns designs (ex: Hana/OP) careciam de aplicação explícita de ponta a ponta da relação de vinculação entre o compromisso autenticado e os dados consumidos pela derivação. Regras de recência também não foram explicitamente identificadas nos materiais examinados.
• Integrações com EigenDA: Estes designs (ex: Hokulea/OP e Arbitrum) mostraram maior alinhamento com o framework. A integração do Arbitrum utiliza "verificação eager" no inbox, enquanto a integração do OP depende de provas de validade para aplicar o predicado de DA. Os autores não encontraram verificações ausentes nos padrões examinados, embora notem que isso não é uma prova de segurança completa.
• Avail-ZKsync: Semelhante ao EigenDA, este utiliza verificação eager no inbox. No entanto, como no caso da Celestia, uma condição de recência explícita ligada à janela de liquidação não foi identificada nas especificações públicas.

Os resultados confirmam que a integração segura de AltDA não é determinada apenas pelo provedor de DA, mas é uma propriedade de todo o stack de integração do L2.

Significância e Alegações

O artigo alega que a integração segura de AltDA é uma propriedade de ponta a end (end-to-end) do inbox, derivação, prova e caminho de liquidação, e não uma propriedade do provedor de DA ou de uma única chamada de verificação.

Os autores argumentam que a indústria tem focado excessivamente no "verificador de DA" (que responde se um fato sobre um sistema externo é verdadeiro) e negligenciado a "relação de integração" (que responde se cada input adversário na fronteira do L2 leva a um resultado determinístico e aplicado na liquidação).

A significância deste trabalho reside na mudança do paradigma de segurança:

• Move o foco de "suposições de confiança" para "obrigações de validação".
• Fornece uma especificação rigorosa para auditores e desenvolvedores garantirem que a camada de liquidação do L2 imponha a relação completa entre os inputs do L1 e os estados aceitos do L2.
• Destaca que, sem a aplicação dessas semânticas de validação total, os L2s enfrentam riscos de liquidação sub-restrita e ataques de ponte, independentemente da força criptográfica do sistema de DA subjacente.

O artigo conclui que, à medida que os L2s apoiados por AltDA asseguram cada vez mais valor, a fronteira de integração deve ser especificada e auditada com o mesmo rigor que os próprios sistemas de execução e liquidação de rollup.