Escrito por Pablo Gómez
Founder & CEO da Metlabs · Revisado em 11 de outubro de 2026
Um zk-STARK não usa emparelhamentos nem curvas elípticas: sua segurança se apoia em uma função hash resistente a colisões e em provas de proximidade a códigos Reed-Solomon por meio do FRI (Fast Reed-Solomon IOP of Proximity). A computação é expressa como traço de execução mais restrições algébricas (AIR), e o compromisso é feito por meio de árvores de Merkle de hashes. O tempo de prova é quase linear e a verificação é polilogarítmica, com a contrapartida de provas de dezenas a centenas de kilobytes. Foi introduzido em 2018 por Eli Ben-Sasson, Iddo Bentov, Yinon Horesh e Michael Riabzev (Cryptology ePrint 2018/046), com o suporte FRI apresentado no ICALP 2018.
Elimina o risco de cerimônia: não há toxic waste para custodiar nem destruir. Além disso, oferece preparação frente à computação quântica, já que não depende de premissas de curvas vulneráveis ao algoritmo de Shor. É a escolha natural quando a transparência e a durabilidade criptográfica prevalecem sobre o custo de publicar a prova on-chain, um critério relevante para infraestrutura de mercado que precisa durar décadas.
A StarkWare construiu sua stack sobre STARKs: o motor StarkEx, usado por dYdX v3, Immutable X e Sorare, e a rede de propósito geral Starknet, com a linguagem Cairo. Variantes recentes como os Circle STARKs, sobre o corpo Mersenne-31, buscam mais eficiência de prova. Em comparação com o zk-SNARK, compartilha o uso para escalabilidade e identidade, mas dispensa o trusted setup e apoia sua segurança na função hash e nas árvores de Merkle.
Também conhecido como
- zkSTARK





