ACE Runtime - A ZKP-Native Blockchain Runtime with Sub-Second Cryptographic Finality

O artigo apresenta o ACE Runtime, uma camada de execução nativa de ZKP que utiliza a separação entre autorização e identidade para substituir verificações de assinatura por transação por atestações HMAC leves e uma prova agregada por bloco, alcançando finalidade criptográfica em subsegundos com custos de verificação constantes e requisitos de hardware reduzidos.

O essencial

Imagine que você está organizando uma festa gigante onde milhares de pessoas querem entrar ao mesmo tempo. O problema é que, na porta, um segurança precisa verificar o passaporte de cada pessoa individualmente antes de deixá-la entrar. Se houver 10.000 pessoas, o segurança leva horas. Isso é como as blockchains atuais (como a Solana): elas gastam muito tempo e energia verificando a assinatura digital de cada transação, o que cria um gargalo, custa caro (exige computadores potentes com placas de vídeo) e deixa o sistema lento para confirmar que a transação foi realmente aceita.

O ACE Runtime é uma nova ideia para resolver isso. O autor, Jian Sheng Wang, propõe uma mudança radical: separar quem você é (identidade) do que você está fazendo (autorização).

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Problema: O "Porteiro" Exausto

Nas blockchains atuais, cada transação é como um convidado que chega com um passaporte complexo. O sistema precisa ler e validar cada passaporte na hora.

• Consequência: Se a festa ficar cheia, a fila para entrar para. Para aguentar a multidão, você precisa contratar porteiros superpoderosos (placas de vídeo/GPUs), o que encarece a festa e impede que pessoas comuns participem.

2. A Solução: O "Crachá de Entrada" vs. O "Selinho de Confirmação"

O ACE Runtime muda a regra do jogo usando uma técnica chamada Attest–Execute–Prove (Atestar, Executar, Provar).

Fase 1: O Crachá Rápido (Atestar e Executar)

Em vez de verificar um passaporte complexo para cada pessoa, o sistema usa um crachá simples e rápido (uma "atestação HMAC").

• A Analogia: Imagine que, ao entrar, você só precisa mostrar um crachá colorido que diz "Eu sou o João". O segurança olha o crachá em 1 microssegundo (quase instantâneo) e deixa você entrar.
• O Truque: O sistema não verifica quem é o João agora. Ele apenas verifica se o crachá parece legítimo. Isso é tão rápido que o computador comum (CPU) aguenta milhares de pessoas por segundo sem precisar de placas de vídeo caras.

Fase 2: A Execução

Como a verificação foi super rápida, o sistema processa todas as transações (a festa acontece) quase imediatamente. O bloco é publicado em 400 milissegundos.

Fase 3: O "Selinho de Confirmação" (Provar)

Aqui está a mágica. Enquanto a festa acontece, um computador especial (o "Construtor", que tem uma placa de vídeo) trabalha no fundo para criar uma prova matemática única para todo o grupo de pessoas que entrou.

• A Analogia: Em vez de verificar 10.000 passaportes, o sistema cria um único selo que diz: "Eu garanto que todos os 10.000 crachás que entraram eram legítimos".
• O Resultado: Para confirmar que a festa foi segura, o sistema só precisa verificar esse único selo. Isso leva menos de 1 milissegundo, independentemente de terem entrado 10 ou 100.000 pessoas.

3. Por que isso é revolucionário?

• Finalidade em Segundos (ou menos):

  • Antes: Você esperava cerca de 12 segundos para ter certeza absoluta de que sua transação não poderia ser revertida (como na Solana).
  • Agora: Com o ACE, a confirmação matemática final leva cerca de 600 milissegundos (menos de 1 segundo). É como se o selo chegasse quase ao mesmo tempo que a festa começava.

• Economia e Descentralização:

  • Antes: Todo validador (aqueles que mantêm a rede segura) precisava de uma placa de vídeo cara (GPU). Isso custava milhares de dólares.
  • Agora: A maioria dos validadores só precisa de um computador comum. Apenas o "Construtor" (que gera o selo) precisa da placa de vídeo. Isso reduz o custo em até 50% e permite que mais pessoas participem da rede, tornando-a mais segura e descentralizada.

• Futuro Quântico:

  • As criptomoedas atuais usam chaves que computadores quânticos futuros poderiam quebrar. O ACE foi desenhado desde o início para ser resistente a isso. Se a tecnologia mudar, o sistema pode se adaptar sem precisar aumentar o tamanho dos dados, mantendo tudo leve e rápido.

Resumo da Ópera

O ACE Runtime é como transformar uma fila de banco lenta, onde cada cliente precisa de um gerente para assinar um documento, em um sistema de catracas automáticas.

1. Você passa pela catraca (verificação rápida) e entra.
2. O sistema processa tudo.
3. No final do dia, um auditor gera um único relatório que prova que ninguém trapaceou.

Isso torna a rede 20 vezes mais rápida na confirmação final, 4.000 vezes mais barata para verificar em grande escala e não exige que todo mundo tenha um computador superpotente para manter a rede segura. É uma mudança de arquitetura que prioriza a eficiência e o futuro.

Resumo técnico

Resumo Técnico: ACE Runtime

1. O Problema

As blockchains de alto desempenho atuais, como o Solana, enfrentam gargalos fundamentais devido ao seu modelo de verificação de assinaturas:

• Custo de Verificação O(N): A verificação de assinaturas criptográficas (ex: Ed25519) ocorre no caminho crítico de execução. O custo escala linearmente com o número de transações no bloco, limitando o throughput e aumentando a latência.
• Custo de Hardware: Para manter a velocidade, todos os validadores (não apenas os produtores de blocos) precisam de GPUs poderosas para verificação em lote de assinaturas, elevando o custo de entrada para validação e centralizando a rede.
• Vulnerabilidade Pós-Quântica: A migração para esquemas de assinatura pós-quântica (como ML-DSA-44) aumentaria drasticamente o tamanho dos dados de autorização (de ~96 bytes para ~3.732 bytes por transação), tornando a arquitetura atual inviável devido ao aumento de tamanho dos blocos.
• Latência de Finalidade: A finalidade criptográfica (hard finality) em sistemas como o Solana leva cerca de 12 segundos, o que é lento para aplicações que exigem confirmação instantânea.

2. Metodologia e Arquitetura

O ACE Runtime propõe uma nova camada de execução baseada na separação entre Identidade e Autorização, utilizando o primitivo criptográfico ACE-GF (Atomic Cryptographic Entity Generative Framework).

2.1 Separação Identidade-Autorização

Em vez de anexar uma assinatura completa a cada transação, o sistema utiliza:

• REV (Root Entropy Value): Um segredo de alta entropia que gera chaves derivadas via HKDF.
• Attestation (Atestação): Substitui a assinatura tradicional por uma credencial leve baseada em HMAC (~1 µs para verificar em CPU).
• Compromisso de Identidade (id_com): Apenas um hash (Poseidon) do segredo raiz é exposto on-chain, protegendo a identidade contra ataques "colher agora, descriptografar depois".

2.2 Pipeline de Execução: Attest–Execute–Prove

A arquitetura introduz um pipeline de três fases que desacopla a verificação de autorização da geração de provas:

1. Attest (Atestar): Verificação leve da credencial HMAC no caminho crítico (CPU).
2. Execute (Executar): Processamento das transações e atualização de estado.
3. Prove (Provar): Geração de provas de conhecimento zero (ZK) de forma assíncrona (GPU), fora do caminho crítico.

2.3 Finalidade de Duas Camadas

• Finalidade Suave (Soft Finality): Alcançada em ~400 ms através de votação BFT (2/3 dos validadores).
• Finalidade Dura (Hard Finality): Alcançada em ~600 ms através da verificação de um único Groth16 (prova ZK) que valida todo o bloco, independentemente do número de transações.

2.4 Geração de Provas em Pipeline

A geração de provas é realizada por um "Builder" dedicado em hardware GPU. Utiliza agregação recursiva em árvore para condensar milhares de provas de transações individuais em uma única prova de bloco (256 bytes) dentro do intervalo entre blocos.

3. Principais Contribuições

O artigo apresenta as seguintes inovações:

1. Pipeline Attest–Execute–Prove: Desacopla a verificação de autorização (O(1) por transação em CPU) da geração de prova ZK (assíncrona), permitindo tempos de bloco de 400 ms.
2. Verificação de Bloco O(1): A verificação de autorização de um bloco inteiro custa o mesmo, independentemente de conter 1.000 ou 100.000 transações (apenas uma verificação de prova Groth16).
3. Modelo de Finalidade de Duas Camadas: Formaliza a transição de finalidade suave (BFT) para dura (ZK) em menos de 1 segundo, garantindo irreversibilidade computacional.
4. Eliminação de GPU para Validadores Comuns: Apenas os "Builders" (produtores de prova) necessitam de GPUs; validadores normais operam apenas com CPU.
5. Preparação Pós-Quântica: A camada de identidade e atestação é resistente a ataques quânticos desde o dia 1. A migração para assinaturas pós-quânticas não aumenta o custo de verificação on-chain, pois a prova ZK comprime a verificação.

4. Resultados e Avaliação Quantitativa

Baseado em modelagem analítica e benchmarks de protótipo (Rust em CPU Apple M3 Pro):

• Throughput: Projeta-se um throughput conservador de ~16.000 TPS, escalando para ~32.000 TPS com otimizações moderadas.
• Latência de Finalidade: Redução de ~20x na latência de finalidade dura em comparação ao Solana (600 ms vs. ~12 s).
• Custo de Verificação:
  • Redução de ~4.000x no custo de verificação por bloco em comparação ao Solana para blocos grandes (100k transações).
  • O tempo de verificação permanece constante em ~0,5 ms (uma verificação Groth16), enquanto o Solana escala linearmente (O(N)).
• Eficiência de Largura de Banda:
  • Redução de ~5x no tamanho dos dados on-chain por transação (eliminação de assinaturas e chaves públicas no bloco).
  • O tamanho total do bloco para 2.000 transações cai de ~2,4 MB (Solana) para ~488 KB (ACE).
• Custo de Hardware: Redução de 30%–50% no custo de hardware para validadores não-Builders, eliminando a necessidade de GPUs.

5. Significância e Conclusão

O ACE Runtime representa uma mudança de paradigma na arquitetura de blockchains de Camada 1 (L1). Ao separar a identidade da autorização e mover a verificação criptográfica pesada para fora do caminho crítico de execução, o sistema resolve o dilema entre desempenho, descentralização (custo de hardware) e segurança futura (pós-quântica).

A principal contribuição teórica é a demonstração de que a separação identidade-autorização, combinada com provas de conhecimento zero, permite:

1. Finalidade criptográfica sub-segundo.
2. Verificação de blocos constante (O(1)).
3. Uma rede mais acessível economicamente, sem sacrificar a segurança.

O trabalho sugere que essa separação é um princípio arquitetural fundamental para a próxima geração de sistemas blockchain, superando as limitações inerentes aos modelos atuais que dependem de verificação de assinatura linear por transação.