[Verifiquei brevemente o AlignedLayer porque estava pensando em participar.] Falar que ZK é bom já virou algo comum. Os cálculos são feitos off-chain, apenas a prova é enviada on-chain, e o Ethereum apenas precisa verificar essa prova. Parece muito limpo só de ouvir. Mas é aí que os problemas realmente começam. Criar a prova também é difícil, verificar a prova é caro, como o custo de verificação é alto, não se pode enviá-la com frequência, e como não se pode enviá-la com frequência, a UX fica lenta. No fim, é verdade que “usar ZK aumenta a escalabilidade”, mas a pergunta que permanece é: quem vai verificar essas provas ZK de forma barata e rápida? Aligned é um projeto que está se concentrando exatamente nesse ponto. Em termos simples, é uma camada de verificação ZK que permite verificar provas ZK no Ethereum de forma mais barata e rápida. O documento oficial descreve o Aligned como uma pilha verticalmente integrada para criar a “verifiable internet”. A frase soa grandiosa, mas, explicando de forma mais clara: Eles estão criando uma camada de verificação ZK, um serviço de agregação de provas, facilitando o deploy de ZK rollups como RaaS, wallet-as-a-service, meta proving, e interoperabilidade — tudo junto — “para que equipes que querem construir aplicativos verificáveis não precisem começar do zero toda vez.” Na minha opinião, o ponto central do Aligned não é sobre o token ou o airdrop, mas sim que, quanto mais aplicativos ZK surgirem, mais a verificação de provas se tornará um gargalo inevitável. Hoje em dia, todos falam muito sobre zkVM, zkML, zkTLS, ZK rollup, ZK identity. Mas e daí se você cria muitas provas? Se o custo de verificação for tão alto que não consiga ser enviado on-chain, então essa prova acaba sendo apenas um arquivo que roda dentro do serviço. Aligned quer resolver isso com duas abordagens: Proof Verification Layer e Proof Aggregation Service. A primeira é a Proof Verification Layer. Ela usa o restaking do EigenLayer: alguns validadores do Ethereum — mais precisamente, os operators — verificam as provas, assinam o resultado com BLS signature, e quando 2/3 ou mais concordam, enviam esse resultado para o Ethereum. O usuário envia a prova por CLI ou SDK, o batcher coleta as provas, os operators as verificam, o aggregator reúne as assinaturas e registra o resultado no Ethereum. Soa complicado só de ouvir, mas a ideia é simples: Não gaste gas caro no EVM para verificar provas. Verifique-as rapidamente no ambiente nativo e envie apenas o resultado para o Ethereum. Segundo o documento, o Aligned suporta sistemas de prova que o Ethereum sozinho não consegue processar e torna o custo de verificação menos dependente do sistema de prova específico. Suporta verificadores como Groth16, Plonk, SP1, Risc0, Circom, e já suporta verificadores relacionados ao Mina na rede de teste. Também estão no roadmap projetos como Jolt e Nexus. Isso é importante porque quando um desenvolvedor escolhe um sistema de prova, não precisa mais se preocupar com: “Será que isso pode ser verificado no Ethereum?” “Consigo pagar o custo de gas?” “E se não houver precompile?” Antes, cada sistema de prova tinha custos diferentes para verificação on-chain; alguns eram tão caros que era inviável verificá-los no Ethereum; e para adicionar um novo sistema de proving, era preciso esperar por contratos inteligentes otimizados em gas ou precompiles. Aligned quer tornar isso muito mais flexível. A segunda abordagem é o Proof Aggregation Service. É um método que comprime várias provas em uma única prova recursiva, de modo que apenas uma prova final seja verificada no Ethereum L1. Enquanto a Proof Verification Layer foca em verificação rápida e barata, o Aggregation Service se alinha mais com uma finalidade forte e direta no L1 do Ethereum. Por isso, o documento recomenda escolher conforme a necessidade: Se você precisa de UX rápida, baixa latência e grande volume de provas → use a Verification Layer. Se você precisa de finalidade L1 completa e segurança máxima, querendo consolidar várias provas em um único checkpoint final → use o Aggregation Service. É possível usar os dois juntos. Por exemplo: trate a UX do usuário com a Verification Layer para velocidade, e periodicamente use o Aggregation Service para criar um checkpoint final no L1. Essa estrutura se encaixa perfeitamente em muitos casos: ZK rollups precisam gerar provas constantemente; bridges precisam verificar provas do estado da chain de origem; zkTLS precisa provar dados do web2 — como saldo bancário ou KYC — sem expor os dados brutos; zkML precisa provar que uma inferência de IA foi executada corretamente; protocolos de identidade precisam validar idade ou elegibilidade sem expor dados pessoais; jogos on-chain precisam provar continuamente pontuações ou lógicas anti-cheat. Todos exigem provas. Mas quanto mais provas forem criadas, maior será o problema do custo de verificação. Aligned vê isso como: “Quando chegarmos à era em que todos criam provas, também precisaremos de infraestrutura para verificá-las.” Esse é um ponto muito mais importante do que parece. O mercado hoje fala do ZK como uma tecnologia incrível, mas, na prática, para aplicativos reais, tudo se resume a custo e UX. Se o custo para verificar uma única prova for muito alto, ninguém vai usar; se levar muito tempo para confirmar, os usuários vão desistir;Se o desenvolvedor levar meses para adicionar o verifier, o lançamento do produto será atrasado. No final, mesmo uma tecnologia excelente se for cara, lenta e difícil, ficará apenas nos documentos de pesquisa. Aligned parece querer trazer isso para o lado da produto. RaaS segue o mesmo raciocínio. No documento da Aligned, explica-se que combinará RISC-V zkVM, cliente de execução Ethrex e camada de verificação ZK para oferecer implantação de ZK-rollup com um clique. Especialmente enfatiza o based rollup. O based rollup não depende de um sequencer centralizado separado, mas utiliza a infraestrutura de proposer/builder do Ethereum L1 para sequenciamento. Em termos simples, significa que o rollup utilizará diretamente a infraestrutura de construção de blocos do Ethereum. Se isso funcionar, poderá reduzir problemas como fragmentação de liquidez, risco de sequencer, resistência à censura e composabilidade do Ethereum. Claro, isso ainda é uma área em experimentação por todo o mercado, então não se pode assumir que “funcionará automaticamente”; o que importa é até onde a Aligned conseguirá atrair clientes e tráfego reais. Mas a direção em si é clara. Aligned não é um projeto que cria uma L2 e termina por aí. Na própria FAQ oficial, a Aligned afirma que não é uma L2 do Ethereum. Pelo contrário, é mais próximo de uma pilha de infraestrutura ZK nativa do Ethereum, que integra verificação ZK, agregação de provas, implantação de rollup, carteira, prova e interoperabilidade. Portanto, ao analisar a Aligned, em vez de perguntar “Que cadeia é essa?”, é mais apropriado perguntar: “No futuro, com cada vez mais provas ZK, quem será responsável pela verificação?” Se as aplicações ZK não aumentarem, infraestruturas como a Aligned serão naturalmente irrelevantes. Mas se rollups, bridges, zkTLS, provas de IA, identidade, oráculos, jogos — todos começarem a usar provas, então, em vez da criação de provas, a verificação barata e rápida delas poderá se tornar o gargalo mais crítico. No fim, a Aligned é um projeto que tenta responder à pergunta: “Já criei a prova — agora, onde vou verificá-la?” Quando o mercado estiver bom, todos colocarão palavras como ZK, AI, Ethereum alignment, restaking, based rollup e se divertirão com isso, mas os que realmente sobreviverão não serão os que usarem mais palavras bonitas, e sim aqueles que ajudam os desenvolvedores a economizar dinheiro, os usuários a esperarem menos e as aplicações a fazerem mais provas com frequência. A Aligned, pelo menos, está olhando para esse problema. Só dizer “É uma infraestrutura ZK” e passar adiante não captura o quão preciso é o gargalo que ela está abordando.
