Blockchain (substantivo): Uma máquina de coordenação que permite que participantes de todo o mundo colaborem ao longo de um conjunto de regras comumente acordadas sem a necessidade de qualquer terceiro facilitador.

Os computadores são projetados para fazer três coisas: armazenar dados, calcular e se comunicar entre si e com humanos. As blockchains acrescentam uma quarta dimensão: garantias adicionais de que essas três coisas (armazenamento, cálculo e comunicação) aconteçam de maneira acordada. Essas garantias possibilitam a cooperação entre estranhos sem a necessidade de uma terceira parte confiável para facilitá-la (descentralizada).

Essas garantias adicionais podem ser econômicas (teoria dos jogos de confiança e incentivos/desincentivos) ou criptográficas (matemática de confiança), mas a maioria das aplicações utiliza uma combinação dos dois - criptoecônomico. Isso atua como um contraste marcante com o status quo atual dos sistemas em grande parte baseados em reputação.

Embora a Web3 seja frequentemente descrita como "ler, escrever, possuir", acreditamos que uma melhor noção para a terceira iteração da internet seja "ler, escrever, verificar", dado que o principal benefício das blockchains públicas é computação garantidae fácil verificação de que essas garantias foram cumpridas. A propriedade pode ser um subconjunto de computação garantida se construirmos artefatos digitais que possam ser comprados, vendidos e controlados. No entanto, muitos casos de uso de blockchains se beneficiam da computação garantida, mas não envolvem diretamente a propriedade. Por exemplo, se sua saúde em um jogo totalmente on-chain é 77/100 - você possui essa saúde ou é apenas aplicável on-chain de acordo com regras comumente acordadas? Argumentaríamos que é o último, mas Chris Dixonpode discordar.

Web3 = Ler, Escrever, Verificar

ZK e Modularidade - Duas Tendências Que Irão Acelerar

As blockchains oferecem muito para se animar, mas o modelo descentralizado também adiciona sobrecarga e ineficiência por meio de funções adicionais como mensagens P2P e consenso. Além disso, a maioria das blockchains ainda valida transições de estado corretas por meio de reexecução, significando que cada nó na rede tem que reexecutar transações para verificar a correção da transição de estado proposta. Isso é desperdiçador e em forte contraste com o modelo centralizado onde apenas uma entidade executa. Enquanto um sistema descentralizado sempre contém alguma sobrecarga e replicação, o objetivo deve ser se aproximar assintoticamente de um benchmark centralizado em termos de eficiência.

Mesmo que a infraestrutura subjacente tenha melhorado significativamente na última década, ainda há muito trabalho a ser feito antes que as blockchains possam lidar com a escala do nível da internet. Vemos compensações ao longo de dois eixos principais - expressividade e dificuldade - e acreditamos que a modularidade permite experimentação mais rápida ao longo da fronteira de compensação, enquanto o ZK a expande:

• Expressividade - O que você pode criar garantias sobre? Contém escalabilidade (custo, latência, throughput, etc), privacidade (ou gerenciamento de fluxo de informações), programabilidade e composabilidade.
• Dureza - Quão rígidas são essas garantias? Contém segurança, descentralização e segurança do usuário e do código.

A modularidade é o grau em que os componentes de um sistema podem ser separados e recombinados. Através de ciclos de feedback mais rápidos e barreiras mais baixas à entrada com menos capital necessário (tanto econômico quanto humano) - a modularidade permite experimentação e especialização mais rápidas. A questão da modular vs integrado não é binária, mas sim um espectro para experimentar e descobrir quais partes fazem sentido para desacoplar e quais não fazem.

Zero Knowledge Proofs, ou ZKPs, por outro lado, permitem que uma parte (o provador) prove a outra parte (o verificador) que eles sabem que algo é verdadeiro, sem revelar nenhuma informação adicional além de sua validade. Isso pode aumentar a escalabilidade e eficiência evitando a reexecução (passando de um modelo de todos executam para verificar, para um modelo de um executa, todos verificam), bem como a expressividade, permitindo a privacidade (com limitações). ZKPs também melhoram a dificuldade das garantias substituindo garantias criptoeconômicas mais fracas por garantias mais fortes, o que é representado empurrando a fronteira de compensação para fora (fazendo referência ao gráfico acima).

Acreditamos que tanto a modularidade quanto a "ZKficação de tudo" são tendências que continuarão a acelerar. Embora ambos forneçam lentes interessantes através das quais explorar o espaço individualmente - estamos particularmente interessados na interseção dos dois. As duas principais questões em que estamos interessados são:

1. Quais partes do stack modular já incorporaram ZKPs e quais ainda estão por explorar?
2. Quais problemas poderiam ser aliviados com ZKPs?

No entanto, antes de podermos entrar nessas perguntas, precisamos de uma visão atualizada de como a pilha modular se parece em 2024.

Pilha Modular em 2024

A imagem frequentemente usada da pilha modular com quatro componentes (execução, publicação de dados, consenso, liquidação) é útil como um modelo mental simples, mas não a consideramos mais uma representação adequada, dada a evolução do espaço modular. A desagregação adicional leva a novos componentes que antes eram considerados parte de um todo maior, ao mesmo tempo que cria novas dependências e a necessidade de interoperabilidade segura entre os diferentes componentes (mais sobre isso mais adiante). Dado o ritmo acelerado com que o espaço está avançando, pode ser difícil se manter atualizado sobre todas as inovações em diferentes níveis da pilha.

Tentativas anteriores de explorar o stack web3 incluem as feitas por Kyle Samani (Multicoin) - originalmente publicado em 2018e atualizado em2019. Ele abrange tudo, desde o acesso à internet descentralizado de última milha (como Hélio) para a gestão de chaves do usuário final. Embora os princípios por trás disso possam ser reciclados, algumas peças, como a prova e verificação, estão completamente ausentes.

Levando isso em consideração, tentamos criar uma representação atualizada de como a pilha modular se parece em 2024, expandindo a pilha modular existente em quatro partes. Ela é dividida por componente em vez de funcionalidade, o que significa que a rede P2P, por exemplo, está incluída no consenso em vez de ser separada como um componente separado - principalmente porque é difícil construir um protocolo em torno disso.

ZK Na Pilha Modular

Agora que temos uma visão atualizada da pilha modular, podemos começar a olhar para a questão real, ou seja, quais partes da pilha o ZK já penetrou e quais problemas em aberto poderiam ser resolvidos introduzindo o ZK (evitando reexecução ou recursos de privacidade). Abaixo está um resumo de nossas descobertas, antes de nos aprofundarmos em cada componente separadamente.

1 - Abstração da Operação do Usuário

Os usuários atuais de blockchains precisam navegar por várias cadeias, carteiras e interfaces, o que é complicado e atua como um obstáculo para uma adoção mais ampla. A abstração da operação do usuário é um termo genérico para qualquer tentativa de abstrair essa complexidade e permitir que os usuários interajam com apenas uma interface (por exemplo, um aplicativo específico ou uma carteira), com toda a complexidade ocorrendo nos bastidores. Alguns exemplos de abstrações de nível de infraestrutura incluem:

• A abstração de conta (AA) permite que contratos inteligentes realizem transações sem exigir assinaturas de usuário para cada operação (“conta de cripto programável”). Ele pode ser usado para definir quem pode assinar (gerenciamento de chaves), o que assinar (carga útil tx), como assinar (algoritmo de assinatura) e quando assinar (condição de aprovação da transação). Combinados, esses recursos permitem coisas como usar o login social para interagir com dApps, 2FA, recuperação de conta e automação (assinando tx automaticamente). Embora a discussão muitas vezes se concentre em torno do Ethereum (ERC-4337passou na primavera de 2023), muitas outras cadeias já têm abstração de conta integrada e nativa (Aptos, Sui, Perto, ICP, Starknet, e zkSync.
• A Abstração de Cadeia permite aos usuários assinar transações em diferentes cadeias enquanto interagem apenas com uma conta (uma interface, várias cadeias). Várias equipes estão trabalhando nisso, incluindo Perto, ICP, e dWalletEssas soluções aproveitam MPC e assinaturas de cadeia, onde a chave privada da outra rede é dividida em vários pedaços pequenos e compartilhada entre os validadores na cadeia de origem que assinam as transações entre cadeias. Quando os usuários desejam interagir com outra cadeia, um número suficiente de validadores precisa assinar a transação para satisfazer a criptografia de limite. Isso mantém a segurança, já que a chave privada nunca é totalmente compartilhada em nenhum lugar. No entanto, ela enfrenta o risco de colusão de validadores, razão pela qual a segurança criptoecônomico e a descentralização de validadores da cadeia subjacente ainda são altamente relevantes.
• Intenções, em um nível elevado, permitem a ponte entre desejos e necessidades do usuário em operações que podem ser executadas por um blockchain. Isso requer solucionadores de intenções - agentes especializados off-chain encarregados de encontrar a melhor solução possível para a intenção do usuário. Já existem vários aplicativos que usam intenções especializadas, como DEX-agregadores ("melhor preço") e agregadores de pontes ("pontes mais baratas/mais rápidas"). Redes gerais de resolução de intençõesAnoma, Essencial, Suave) visam facilitar para os usuários expressarem intenções mais complicadas e para os desenvolvedores construírem aplicações centradas em intenções. Ainda existem muitas perguntas em aberto, no entanto, incluindo como formalizar o processo, como seria uma linguagem centrada em intenções, se uma solução ótima sempre existe e se pode ser encontrada.

Integrações ZK existentes

• Autenticação usando AA x ZK: Um exemplo disso é Sui’szkLogin, que permite aos usuários fazer login usando credenciais familiares como um endereço de e-mail. Ele usa ZKPs para impedir que terceiros vinculem um endereço Sui ao seu identificador OAuth correspondente.
• Verificação de assinatura mais eficiente para carteiras AA: Verificar transações em contratos AA pode ser significativamente mais caro do que aquelas iniciadas por uma conta tradicional (EOA).Orbitertenta lidar com isso com um serviço de compactação que alavanca ZKPs para verificar a correção das assinaturas de transação e manter o valor de nonce e o saldo de gás da conta AA (através de uma árvore de estado mundial de Merkle). Com a ajuda da agregação de provas e compartilhando o custo de verificação on-chain igualmente entre todos os usuários, isso pode levar a economias significativas de custos.

Problemas Abertos Que ZKPs Poderiam Resolver

• Prova de melhor execução ou cumprimento de intenções: Embora intenções e AA possam abstrair a complexidade dos usuários, também podem atuar como uma força centralizadora e nos fazer depender de atores especializados (solvers) para encontrar os caminhos de execução ideais. Em vez de simplesmente confiar na boa vontade do solver, as ZKPs poderiam potencialmente ser usadas para provar que o caminho ideal para o usuário foi escolhido entre os escolhidos pelo solver.
• Privacidade para resolução de intenções: Protocolos como Taigavisa permitir liquidação de intenções totalmente protegida para preservar a privacidade dos usuários - parte de um movimento mais amplo em direção à adição de privacidade (ou pelo menos confidencialidade) às redes blockchain. Ele usa ZKPs (Halo2) para ocultar informações sensíveis sobre as transições de estado (tipos de aplicativos, partes envolvidas, etc).
• Recuperação de senha para carteiras AA: A ideia por trás esta propostaé permitir que os usuários recuperem suas carteiras se perderem suas chaves privadas. Armazenando um hash (senha, nonce) na carteira do contrato, os usuários podem gerar um ZKP com a ajuda de sua senha para verificar que é sua conta e solicitar uma alteração da chave privada. Um período de confirmação (3 dias ou mais) serve como uma salvaguarda contra tentativas de acesso não autorizadas.

2 - Sequenciamento

As transações precisam ser ordenadas antes de serem adicionadas a um bloco, o que pode ser feito de várias maneiras: ordenando por lucratividade para o proponente (transações de maior pagamento primeiro), na ordem em que foram enviadas (primeiro a entrar, primeiro a sair), dando prioridade a transações de memórias privadas, etc.

Outra questão é quem tem permissão para ordenar as transações. Em um mundo modular, várias partes diferentes podem fazer isso, incluindo o sequenciador de rollup (centralizado ou descentralizado), sequenciamento L1 (com base em rollups) e uma rede de sequenciamento compartilhada (rede descentralizada de sequenciadores usada por vários rollups). Todos esses têmdiferentes pressupostos de confiança e capacidades de escalabilidade. Na prática, a ordenação real de transações e o agrupamento delas em um bloco também podem ser feitos fora do protocolo por atores especializados (construtores de blocos).

Integrações ZK existentes

• Verificando a criptografia correta da mempool: Raioé uma rede de sequenciamento compartilhada que possui uma mempool criptografada com Criptografia de Atraso Verificável PráticaPVDE). Os usuários geram um ZKP que é usado para provar que resolver os quebra-cabeças de bloqueio de tempo levará à descriptografia correta das transações válidas, ou seja, que a transação inclui uma assinatura válida e nonce e que o remetente tem saldo suficiente para pagar a taxa de transação.

Problemas Abertos Que ZKPs Poderiam Resolver

• Regras de Sequenciamento Verificáveis (VSR): Sujeitando o proponente/sequenciador a conjunto de regras sobre a ordem de execuçãocom garantias adicionais de que essas regras são seguidas. A verificação pode ser feita por ZKPs ou provas de fraude, das quais a última requer uma fiança econômica grande o suficiente que é cortada se o proponente/sequenciador se comportar mal.

3 - Execução (Escalonamento de Gravações)

A camada de execução contém a lógica de como o estado é atualizado e é onde os contratos inteligentes são executados. Além de retornar uma saída da computação, os zkVMs também permitem comprovar que as transições de estado foram feitas corretamente. Isso permite que outros participantes da rede verifiquem a execução correta apenas verificando a prova, em vez de terem que reexecutar transações.

Além da verificação mais rápida e eficiente, outro benefício da execução comprovável é possibilitar computações mais complexas, uma vez que você não enfrenta os problemas típicos de gás e recursos limitados on-chain com computação off-chain. Isso abre as portas para novas aplicações inteiramente novas que são computacionalmente mais intensas para serem executadas em blockchains e aproveitam a computação garantida.

Integrações ZK existentes

• zkEVM rollups: Um tipo especial de zkVM otimizado para ser compatível com Ethereum e provar o ambiente de execução EVM. Quanto mais próxima a compatibilidade com Ethereum, no entanto, maior a compensação no desempenho. Vários zkEVMs lançados em 2023, incluindo Polygon zkEVM, Era zkSync, Rolar, e Linea. A Polygon anunciou recentemente seu prover zkEVM tipo 1, que permite provar blocos principais da Ethereum na mainnet por $0.20-$0.50 por bloco (com otimizações futuras para reduzir custos ainda mais).RiscZero também tem uma soluçãoque permite provar blocos Ethereum, mas a um custo mais elevado com a limitada avaliação disponível.
• Alternative zkVMs: Alguns protocolos estão seguindo um caminho alternativo e otimizando para desempenho/provabilidadeStarknet, Zorp) ou facilidade para desenvolvedores, em vez de tentar ser maximamente compatível com o Ethereum. Exemplos disso incluem protocolos zkWASM (Fluente, Delphinus Labs) and zkMOVE (M2ezkmove).
• zkVMs focados na privacidade: Neste caso, as ZKPs são usadas para duas coisas: evitar a reexecução e alcançar a privacidade. Embora a privacidade que pode ser alcançada apenas com ZKPs seja limitada (apenas estado privado pessoal), os protocolos futuros adicionam muita expressividade e programabilidade às soluções existentes. Exemplos incluem o da Aleo’s snarkVM, Aztec’sAVM e do PolygonMidenVM.
• ZK-coprocessors: Permite a computação externa de dados na cadeia (mas sem estado). As provas de conhecimento zero são usadas para comprovar a execução correta, proporcionando liquidação mais rápida do que os co-processadores otimistas, mas há um tradeoff em termos de custo. Devido ao custo e/ou dificuldade de gerar ZKPs, estamos vendo algumas versões híbridas, como Brevis coCadeia, que permite aos desenvolvedores escolher entre o modo ZK ou otimista (compromisso entre custo e dificuldade de garantias).

Problemas em aberto que as ZKPs poderiam resolver

• ZkVM consagrado: A maioria das camadas base (L1s) ainda usa reexecução para verificar transições de estado corretas. Consagrar um zkVM na camada base evitaria isso, já que os validadores poderiam verificar a prova em vez disso. Isso melhoraria a eficiência operacional. A maioria dos olhos está voltada para o Ethereum com um zkEVM consagrado, mas muitos outros ecossistemas também dependem da reexecução.
• zkSVM: Enquanto o SVM é principalmente usado dentro do Solana L1 hoje, equipes como Eclipse estão tentando aproveitar o SVM para rollups que se estabelecem no Ethereum. Eclipse também está planejando usar Risc Zero para provas de fraude ZKpara os desafios potenciais das transições de estado no SVM. No entanto, um zkSVM completo ainda não foi explorado - provavelmente devido à complexidade do problema e ao fato de que o SVM é otimizado para outras coisas além da provabilidade.

4 - Consulta de Dados (Leituras em Escala)

Consulta de dados, ou leitura de dados no blockchain, é uma parte essencial da maioria das aplicações. Enquanto grande parte das discussões e esforços nos últimos anos têm se concentrado em escalar gravações (execução) - escalar leituras é ainda mais importante devido ao desequilíbrio entre os dois (particularmente em um ambiente descentralizado). A relação entre leitura/escrita difere entre blockchains, mas um ponto de dados é Estimativa da Sigque >96% de todas as chamadas para nós na Solana foram chamadas de leitura (com base em 2 anos de dados empíricos) - uma proporção de leitura/escrita de 24:1.

Escalonar leituras inclui tanto obter mais desempenho (mais leituras por segundo) com clientes validadores dedicados (como Sig na Solana) quanto permitir consultas mais complexas (combinando leituras com cálculos), por exemplo, com a ajuda de co-processadores.

Outro ângulo é descentralizar os métodos de consulta de dados. Hoje, a maioria das solicitações de consulta de dados em blockchains são facilitadas por terceiros confiáveis (baseados em reputação), como nós RPC (Infura) e indexadores (Duna). Exemplos de opções mais descentralizadas incluem O Gráficoe operadores à prova de armazenamento (também verificáveis). Existem também várias tentativas de criar uma rede RPC descentralizada, como Infura DINouRede Lava(além do RPC descentralizado, Lava pretende oferecer serviços adicionais de acesso a dados posteriormente).

Integrações ZK existentes

• Provas de armazenamento: Permite consultar dados históricos e atuais de blockchains sem usar terceiros confiáveis. Provas de conhecimento-zero são usadas para compressão e para provar que os dados corretos foram recuperados. Exemplos de projetos que estão construindo nesse espaço incluem Axioma, Brevis, Heródoto, e Lagrange.

Problemas em aberto que ZKPs poderiam resolver

• Consulta eficiente do estado privado: Os projetos de privacidade frequentemente utilizam uma variação do modelo UTXO, que possibilita melhores recursos de privacidade do que o modelo de conta, mas isso vem com o custo de ser menos amigável para os desenvolvedores. O modelo UTXO privado também pode ocasionar problemas de sincronização - algo Zcash tem lutado comdesde 2022, após experimentar um aumento significativo no volume de transações protegidas. As carteiras devem sincronizar com a cadeia antes de poderem gastar os fundos, então este é um desafio bastante fundamental para o funcionamento da rede. Em antecipação a este problema,Aztec recentemente postou um RFPpara ideias sobre descoberta de notas, mas ainda não foi encontrada uma solução clara.

5 - Provando

Com cada vez mais aplicações incorporando ZKPs, a prova e verificação estão rapidamente se tornando uma parte essencial do stack modular. No entanto, hoje, a maioria da infraestrutura de prova ainda é permissionada e centralizada, com muitas aplicações dependendo de um único provador.

Embora a solução centralizada seja menos complexa, descentralizar a arquitetura de prova e dividir em um componente separado na pilha modular traz vários benefícios. Um benefício chave vem na forma de garantias de vivacidade que são cruciais para aplicações que dependem da geração frequente de provas. Os usuários também se beneficiam de uma resistência maior à censura e de taxas mais baixas impulsionadas pela competição e compartilhamento da carga de trabalho entre vários provadores.

Acreditamos que as redes de provadores de propósito geral (muitos aplicativos, muitos provadores) são superiores às redes de provadores de aplicação única (um aplicativo, muitos provadores) devido à maior utilização do hardware existente e menor complexidade para os provadores. Uma maior utilização também beneficia os usuários em termos de taxas mais baixas, uma vez que os provadores não precisam ser compensados pela redundância através de taxas mais altas (ainda é necessário cobrir custos fixos).

Figment Capitalforneceu uma boa visão geral do estado atual da cadeia de suprimentos de prova, que consiste tanto na geração de prova quanto na agregação de prova (que por si só é geração de prova, mas apenas tomando duas provas como entrada em vez de rastreamento de execução).

Origem: Figment Capital

Integrações ZK existentes

• STARK com invólucro SNARK: Os provadores STARK são rápidos e não requerem uma configuração confiável, mas a desvantagem é que produzem provas grandes, que são proibitivamente caras de verificar na Ethereum L1. Envolver o STARK em um SNARK como último passo torna significativamente mais barato verificar na Ethereum. Por outro lado, isso adiciona complexidade, e a segurança desses 'sistemas de prova compostos' não foi estudada em profundidade. Exemplos de implementações existentes incluem Polygon zkEVM, Boojum na Era zkSync, e RISC Zero.
• Redes de prova descentralizadas de propósito geral: Integrar mais aplicativos em uma rede de prova descentralizada a torna mais eficiente para os provadores (maior utilização de hardware) e mais barata para os usuários (não precisam pagar pela redundância de hardware). Projetos nesse campo incluem GevuloteSucinto.

Problemas abertos que as ZKPs poderiam resolver

• ZK Provas de Fraude: Em soluções otimistas, qualquer pessoa pode desafiar a transição de estado e criar uma prova de fraude durante o período de desafio. No entanto, verificar a prova de fraude ainda é bastante complicado, pois é feito através de reexecução. As provas de fraude ZK têm como objetivo resolver esse problema, criando uma prova da transição de estado que está sendo desafiada, o que permite uma verificação mais eficiente (sem a necessidade de reexecução) e possivelmente um acordo mais rápido. Isso está sendo trabalhado por pelo menosOtismo(em colaboração com O1 Labs e RiscZero), e AltLayer x RiscZero.
• A agregação de prova mais eficiente: Uma ótima característica das ZKPs é que você pode agregar várias provas em uma única prova, sem aumentar significativamente os custos de verificação. Isso permite amortizar o custo da verificação ao longo de várias provas ou aplicações. A agregação de prova também é uma forma de prova, mas a entrada são duas provas em vez de um rastreamento de execução. Exemplos de projetos nesse espaço incluem NEBRAeGevulot.

Origem: Capital da Figment

6 - Publicação de Dados (Disponibilidade)

A publicação de dados (DP) garante que os dados estejam disponíveis e facilmente recuperáveis por um curto período (1-2 semanas). Isso é crucial tanto para a segurança (rollups otimistas requerem dados de entrada para verificar a execução correta por meio de reexecução durante o período de desafio, 1-2 semanas) quanto para a vivacidade (mesmo que um sistema utilize provas de validade, os dados de transação subjacentes podem ser necessários para comprovar a propriedade de ativos para saídas de emergência, transações forçadas ou para verificar se as entradas correspondem às saídas). Os usuários (como zk-bridges e rollups) enfrentam um pagamento único, que cobre o custo de armazenar transações e estados por um curto período até que sejam podados. As redes de publicação de dados não são projetadas para armazenamento de dados em longo prazo (em vez disso, consulte a próxima seção para possíveis soluções).

Celestiafoi a primeira camada DP alternativa a lançar sua mainnet (31 de outubro), mas em breve haverá muitas alternativas para escolher como Disponível, EigenDA, e Perto de DAsão todos esperados para serem lançados durante 2024. Além disso, EIP 4844 do Ethereumatualizar a publicação de dados dimensionados na Ethereum (além de criar um mercado de taxas separado para armazenamento de blobs) e preparar o terreno para o completo dank-sharding. DP também está se expandindo para outros ecossistemas - um exemplo sendo@nubit_org/riema-secures-angel-investment-for-launching-the-first-bitcoin-native-data-availability-layer-49ccf0487380">Nubit que tem como objetivo construir o DP nativo no Bitcoin.

Muitas soluções de DP também oferecem serviços além da mera publicação de dados, incluindo segurança compartilhada para rollups soberanos (como CelestiaeDisponível) ou interoperabilidade mais suave entre rollups (como Avail’sNexus). Também existem projetos (DomiconeZero Gravity) que oferecem tanto a publicação de dados quanto o armazenamento de estado a longo prazo, o que é uma proposta convincente. Este é também um exemplo de reagrupamento de dois componentes na pilha modular, algo que provavelmente veremos mais no futuro (experimentação tanto com desagregação adicional quanto com reagrupamento).

Integrações ZK existentes

• Comprovação da correção da codificação de apagamento: A codificação de apagamento traz um certo nível de redundância para que os dados originais sejam recuperáveis mesmo que parte dos dados codificados não esteja disponível. Também é um pré-requisito para DAS, onde os nós leves amostram apenas uma pequena parte do bloco para garantir probabilisticamente que os dados estão lá. Se um proponente malicioso codificar os dados de forma incorreta, os dados originais podem não ser recuperáveis mesmo se os nós leves amostrarem partes únicas suficientes. A comprovação da codificação de apagamento correta pode ser feita usando provas de validade (ZKPs) ou provas de fraude - estas últimas sofrendo de latência relacionada ao período de desafio. Todas as outras soluções, exceto Celestia, estão trabalhando no uso de provas de validade.
• Clientes leves ZK alimentando pontes de dados: Rollups que usam camadas de publicação de dados externos ainda precisam se comunicar com a camada de liquidação para garantir que os dados tenham sido publicados corretamente. Para isso servem as pontes de atestação de dados. O uso de ZKPs torna a verificação das assinaturas de consenso da cadeia de origem mais eficiente no Ethereum. Tanto o Avail'sVectorX) e Celestia's ( BlobstreamX) pontes de atestação de dados são alimentadas por clientes leves ZK construídos em conjunto com Succinct.

Problemas em Aberto Que as ZKPs Poderiam Resolver

• Celestia incorporando provas de validade para codificação de apagamento correta: Celestia é atualmente uma exceção entre as redes de publicação de dados, poisusa provas de fraude para codificação de apagamento correta. Se um proponente de bloqueio malicioso codificar os dados incorretamente, qualquer outro nó completo pode gerar uma prova de fraude e contestar isso. Embora essa abordagem seja um pouco mais simples de implementar, ela também introduz latência (o bloco só é final após a janela de prova de fraude) e requer que os nós de luz confiem em um nó completo honesto para gerar a prova de fraude (não é possível verificá-la por conta própria). Contudo Celestia está explorandocombinando sua codificação Reed-Solomon atual com um ZKP para provar a codificação correta, o que reduziria significativamente a finalidade. A última discussão sobre este tópico pode ser encontradaaquicom gravações de grupos de trabalho anteriores (além de tentativas mais gerais de adicionar ZKPs à camada base da Celestia).
• ZK-prova DAS: Houve algumas explorações sobre Prova de disponibilidade de dados ZK, onde nós leves simplesmente verificariam a raiz de merkle e um ZKP, em vez de ter que fazer a amostragem habitual baixando pequenos pedaços de dados. Isso reduziria ainda mais os requisitos para os nós leves, mas parece que o desenvolvimento estagnou.

7 - Armazenamento de Longo Prazo (Estado)

Armazenar dados históricos é importante principalmente para fins de sincronização e atendimento a solicitações de dados. No entanto, não é viável para cada nó completo armazenar todos os dados e a maioria dos nós completos poda dados antigos para manter os requisitos de hardware razoáveis. Em vez disso, contamos com partes especializadas (nós de arquivamento e indexadores) para armazenar todos os dados históricos e disponibilizá-los a pedido dos usuários.

Também existem fornecedores de armazenamento descentralizado, como FilecoinouArweave, que oferecem soluções de armazenamento descentralizado de longo prazo a um preço razoável. Embora a maioria das blockchains não tenha um processo formal de armazenamento de arquivos (simplesmente confiam em alguém para armazená-los), os protocolos de armazenamento descentralizado são bons candidatos para armazenar histórico e adicionar alguma redundância (pelo menos X nós armazenam os dados) através dos incentivos integrados à rede de armazenamento.

Integrações ZK existentes

• Prova de armazenamento: Os provedores de armazenamento de longo prazo precisam gerar ZKPs regularmente para provar que armazenaram todos os dados que afirmam. Um exemplo disso éprova de espaço-tempo do Filecoin (PoSt), onde os provedores de armazenamento ganham recompensas de bloco cada vez que respondem com sucesso a um desafio PoSt.

Problemas Abertos Que ZKPs Poderiam Resolver

• Provando a procedência dos dados e autorização para visualizar dados sensíveis: Com duas partes não confiáveis que desejam trocar dados sensíveis, ZKPs poderiam ser usados para provar que uma parte possui as credenciais necessárias para visualizar os dados sem ter que fazer upload de documentos reais ou divulgar senhas e detalhes de login.

8 - Consenso

Dado que as blockchains são sistemas distribuídos P2P, não há uma terceira parte confiável que determine a verdade global. Em vez disso, os nós da rede concordam com qual é a verdade atual (qual bloco é o correto) por meio de um mecanismo chamado consenso. Métodos de consenso baseados em PoS podem ser categorizados como baseados em BFT (onde o quórum tolerante a falhas bizantinas de validadores decide o estado final) ou baseados em cadeia (onde o estado final é decidido retrospectivamente pela regra de escolha de bifurcação). Embora a maioria das implementações de consenso de PoS existentes sejam baseadas em BFT, Cardanoé um exemplo de implementação da cadeia mais longa. Também há um crescente interesse em mecanismos de consenso baseados em DAG, como o Narwhal-Bullshark, que é implementado em algumas variações em Aleo, Aptos e Sui.

O consenso é uma parte crucial de muitos componentes diferentes da pilha modular, incluindo sequenciador compartilhado, provas descentralizadas e redes de publicação de dados baseadas em blockchain (não baseadas em comitê, como o EigenDA).

Integrações ZK existentes

• Staking em redes de privacidade baseadas em ZK: Redes de privacidade baseadas em PoS representam um desafio, já que os detentores dos tokens de staking devem escolher entre privacidade e participar do consenso (e receber recompensas de staking).Penumbra tem como objetivo resolver issoao eliminar recompensas de staking, tratando em vez disso stakes desvinculados e vinculados como ativos separados. Este método mantém as delegações individuais privadas, enquanto o valor total vinculado a cada validador ainda é público.
• Governança privada: Alcançar votações anônimas tem sido há muito tempo um desafio no mundo das criptomoedas, com projetos como Subsídios Gate de Votação Privadatentando fazer avançar isso. O mesmo também se aplica à governança, onde a votação anônima em propostas está sendo trabalhada pelo menos pela Penumbra. Neste caso, ZKPs podem ser usados para provar que alguém tem o direito de votar (por exemplo, através da propriedade de tokens) e que certos critérios de votação são cumpridos (não votou ainda, por exemplo).

Problemas Abertos Que ZKPs Poderiam Resolver

• Eleição de líder privado: Ethereum atualmente elege os próximos 32 proponentes de blocos no início de cada época e os resultados desta eleição são públicos. Isso impõe o risco de uma parte maliciosa lançar um ataque DoS contra cada proponente sequencialmente para tentar desativar o Ethereum. Em uma tentativa de enfrentar este problema,Batedoré uma proposta de protocolo de preservação da privacidade para a eleição de proponentes de bloco no Ethereum. Os ZKPs são usados pelos validadores para provar que a mistura e a randomização foram realizadas de forma honesta. Há também outras abordagens para alcançar um objetivo semelhante, algumas das quais são abordadas nestepostagem no blog da a16z.
• Agregação de assinaturas: O uso de ZKPs para agregar assinaturas pode reduzir significativamente a sobrecarga de comunicação e computação da verificação de assinatura (verifique uma prova agregada em vez de cada assinatura individual). Isso é algo que já está alavancado em clientes ZK light, mas poderia ser potencialmente expandido para consenso também.

9 - Liquidação

A liquidação é semelhante ao mais alto tribunal de justiça - a fonte final da verdade onde a correção das transições de estado é verificada e as disputas são resolvidas. Uma transação é considerada final no momento em que é irreversível (ou no caso da finalidade probabilística - no momento em que seria suficientemente difícil de reverter). O tempo até a finalização depende da camada de liquidação subjacente usada, que por sua vez depende da regra de finalização específica usada e do tempo de bloco.

A finalidade lenta é particularmente um problema na comunicação cross-rollup, onde os rollups precisam esperar pela confirmação do Ethereum antes de serem capazes de aprovar uma transação (7 dias para rollups otimistas, 12 minutos e tempo de prova para rollups de validade). Isso leva a uma experiência ruim do usuário. Há vários esforços para resolver esse problema usando pré-confirmações com um certo nível de segurança. Exemplos incluem soluções específicas do ecossistema (Camada AggLayer do PolygonouzkSync HyperBridge) e soluções de propósito geral como Camada de Finalidade Rápida do Nearque tem como objetivo conectar vários ecossistemas rollup diferentes, aproveitando a segurança econômica da EigenLayer. Também há a opção depontes de rollup nativas alavancando EigenLayerpara confirmações suaves para evitar esperar pela plena finalidade.

Integrações ZK existentes

• Assentamento mais rápido com rollups de validade: Em contraste com rollups otimistas, rollups de validade não requerem um período de desafio, pois eles dependem de ZKPs para provar a transição de estado correta, quer haja ou não desafios (rollups pessimistas). Isso torna o assentamento na camada base muito mais rápido (12 minutos vs 7 dias no Ethereum) e evita a reexecução.

10 - Segurança

A segurança está relacionada à solidez das garantias e é uma parte crucial da proposta de valor das blockchains. No entanto, a segurança criptoecônica inicial é difícil - aumentando as barreiras de entrada e atuando como atrito para a inovação para aquelas aplicações que necessitam dela (vários middleware e L1s alternativos).

A ideia de segurança compartilhada é usar a segurança econômica existente das redes PoS e sujeitá-la a risco adicional de slashing (condições de punição), em vez de cada componente tentar inicializar o seu próprio. Houve algumas tentativas anteriores de fazer o mesmo em redes PoW (mineração combinada.)), mas incentivos desalinhados tornaram mais fácil para os mineradores conluio e explorar um protocolo (mais difícil punir comportamentos ruins, já que o trabalho acontece no mundo físico, ou seja, mineração usando poder computacional). A segurança de PoS é mais flexível para ser usada por outros protocolos, pois possui incentivos positivos (rendimento de staking) e negativos (slashing).

Protocolos construindo em torno da premissa de segurança compartilhada incluem:

• EigenLayer está buscando alavancar a segurança existente do Ethereum para proteger uma ampla gama de aplicações. O whitepaper foi lançado no início de 2023, e EigenLayer está atualmente em mainnet alpha, com o lançamento completo da mainnet esperado para mais tarde neste ano.
• Cosmos lançou seu Segurança Interchain(ICS) em maio de 2023, o que permite o Cosmos Hub - uma das maiores cadeias no Cosmos e apoiada por ~$2.4bn de ATOM apostado- para alugar sua segurança para cadeias de consumidores. Ao usar o mesmo conjunto de validadores que alimenta o Cosmos Hub para validar também blocos na cadeia do consumidor, o objetivo é reduzir a barreira para lançar novas cadeias no topo da pilha Cosmos. Atualmente, no entanto, apenas duas cadeias de consumidores estão ativas(Neutron e Stride).
• Babilônia está tentando habilitar o BTC a ser usado para segurança compartilhada também. Para combater os problemas relacionados à mineração combinada (difícil punir comportamentos ruins), está construindo uma camada virtual de PoS onde os usuários podem bloquear BTC em um contrato de stake no Bitcoin (sem pontes). Como o Bitcoin não tem uma camada de contratos inteligentes, as regras de slashing dos contratos de stake são expressas em termos de transações UTXO escritas no script do Bitcoin.
• Restaking em outras redes incluem Polvoem Near e Picasso na Solana. PolkadotParachainstambém alavanca o conceito de segurança compartilhada.

Integrações ZK existentes

• Mix entre ZK e segurança econômica: Embora as garantias de segurança baseadas em ZK possam ser mais fortes, provar ainda é proibitivamente caro para algumas aplicações e a geração da prova leva muito tempo. Um exemplo disso é Brevis coChain, que é um co-processador que obtém sua segurança econômica dos re-stakers de ETH e garante a computação de forma otimista (com provas de fraude ZK). As dApps podem escolher entre o modo puro-ZK ou coChain, dependendo de suas necessidades específicas em relação à segurança e custos.

11 - Interoperabilidade

A interoperabilidade segura e eficiente continua a ser uma grande questão em um mundo multi-cadeia, exemplificada pela $2.8bn perdidos em hacks de ponte. Em sistemas modulares, a interoperabilidade se torna ainda mais importante - Você não está apenas se comunicando entre outras cadeias, mas blockchains modulares também requerem que diferentes componentes se comuniquem entre si (como a camada DA e de liquidação). Portanto, não é mais viável simplesmente executar um nó completo ou verificar uma única prova de consenso como nos blockchains integrados. Isso adiciona mais peças em movimento à equação.

A interoperabilidade inclui tanto a ponte de tokens quanto a passagem de mensagens mais geral entre blockchains. Existem várias opções diferentes que fazem diferentes compensações em termos de segurança, latência e custo. Otimizar os três é muito difícil, o que geralmente requer sacrificar pelo menos um. Além disso, diferentes padrões entre as cadeias tornam as implementações em novas cadeias mais difíceis.

Embora ainda falte uma definição clara dos diferentes tipos de clientes leves (ou nós), esta postagem por Dino(co-fundador da Fluent & Modular Media) faz uma boa introdução. A maioria dos clientes leves hoje só verifica o consenso, mas idealmente teríamos clientes leves que também podem verificar a execução e DA para reduzir as suposições de confiança. Isso permitiria chegar perto da segurança de um nó completo, sem os altos requisitos de hardware.

Integrações ZK existentes

• ZK light clients (verificação de consenso): A maioria dos clientes leves atuais permite verificar o consenso da outra cadeia - seja o conjunto completo de validadores (se pequeno o suficiente) ou um subconjunto dos validadores totais (como Comitê de sincronização do Ethereum). Os ZKPs são usados para tornar a verificação mais rápida e mais barata, uma vez que o esquema de assinatura usado na cadeia de origem pode não ser nativamente suportado na cadeia de destino. Embora se espere que a importância dos clientes leves ZK na ponte aumente, as fricções atuais para uma adoção mais ampla incluem o custo da prova e verificação, juntamente com a implementação de clientes leves ZK para cada nova cadeia. Exemplos de protocolos neste espaço incluem Poliedros, pontes de atestação de dados da Avail e Celestia, e zkIBC pela Electron Labs.
• Provas de armazenamento: Como mencionado anteriormente, as provas de armazenamento permitem consultar dados históricos e atuais de blockchains sem o uso de terceiros confiáveis. Isso também é relevante para a interoperabilidade, pois elas poderiam ser usadas para comunicação entre cadeias. Por exemplo, um usuário poderia provar que tem tokens em uma cadeia e usar isso para governança em outra cadeia (sem a necessidade de pontes). Também há tentativas de usar provas de armazenamento para a ponte, como esta solução desenvolvida pela LambdaClass.
• ZK Oracles: Oracles atuam como intermediários e conectam dados do mundo real à blockchain. Os oráculos ZK melhoram os modelos de oráculo baseados em reputação atuais, permitindo comprovar a origem e integridade dos dados, juntamente com qualquer cálculo feito nesses dados.

Problemas Abertos Que ZKPs Poderiam Resolver

• Clientes leves completos: Em vez de confiar cegamente no conjunto de validadores da outra cadeia - clientes leves completos também verificam a execução correta e DA. Isso reduz as suposições de confiança e se aproxima de um nó completo, mantendo ainda baixos os requisitos de hardware (permitindo que mais pessoas executem clientes leves). No entanto, verificar qualquer coisa além do consenso ainda é proibitivamente caro na maioria das cadeias, especialmente no Ethereum. Além disso, clientes leves só permitem a verificação de informações (metade do problema), ou seja, eles podem identificar que as informações são falsas, mas ainda precisa haver um mecanismo adicional para que eles façam algo a respeito.
• Camadas de Agregação: AggLayer da Polygonvisa possibilitar a interoperabilidade suave entre L2s dentro do ecossistema, aproveitando provas agregadas e um contrato de ponte unificado. A prova agregada permite uma verificação mais eficiente e segura - garantindo que os estados e pacotes de cadeias dependentes sejam consistentes e assegurando que um estado de rollup não possa ser liquidado no Ethereum se depender de um estado inválido de outra cadeia.HyperChains do zkSynceDisponível Nexusestão adotando uma abordagem semelhante.

Quando ZK Comeu O Modular Stack?

Supondo que possamos alcançar um estado em que a geração de Provas de Conhecimento Zero (ZKPs) se torne muito rápida (quase à velocidade da luz) e incrivelmente barata (quase gratuita), como seria o resultado final? Em outras palavras, quando as ZKPs tiverem dominado completamente a pilha modular?

Em termos gerais, acreditamos que duas coisas seriam verdadeiras neste estado do mundo:

1. Toda reexecução desnecessária é eliminada: Ao mudar para um modelo de execução 1/N (em vez de N/N com reexecução), reduzimos significativamente a redundância geral da rede e permitimos um uso mais eficiente do hardware subjacente. Embora algum overhead permaneça, isso ajudaria as blockchains a se aproximarem assintoticamente dos sistemas centralizados em termos de eficiência computacional.
2. A maioria das aplicações depende de garantias criptográficas habilitadas para ZK em vez de segurança econômica: Quando o custo e o tempo para gerar provas não são mais considerações relevantes, acreditamos que a maioria das aplicações dependerá de ZKPs para garantias mais fortes. Isso também requer algumas melhorias em usabilidade e facilidade de uso para construir aplicações ZK, mas esses são todos problemas em que várias equipes estão trabalhando.

Uma terceira condição seria em torno da privacidade (ou gerenciamento de fluxo de informações), mas é mais complicado. ZKPs podem ser usados para algumas aplicações de privacidade com comprovação do lado do cliente, que é o que plataformas como Aleo, Aztec ou Polygon Miden estão construindo, mas alcançar a privacidade em grande escala para todos os casos de uso potenciais depende do progresso do MPC e FHE também - um possível tema para uma futura postagem no blog.

Riscos Para Nossa Tese

E se estivermos errados, e o futuro não for nem modular nem ZK'fied? Alguns riscos potenciais para a nossa tese incluem:

A modularidade aumenta a complexidade

Tanto os usuários quanto os desenvolvedores sofrem com o número cada vez maior de cadeias. Os usuários precisam gerenciar fundos em várias cadeias (e potencialmente várias carteiras). Os desenvolvedores de aplicativos, por outro lado, têm menos estabilidade e previsibilidade, dado o quanto o espaço ainda está evoluindo, tornando mais difícil decidir em qual cadeia construir. Eles também precisam pensar sobre a fragmentação do estado e da liquidez. Isso é particularmente verdadeiro agora, pois ainda estamos experimentando ao longo da fronteira de quais componentes fazem sentido para desacoplar e quais serão recoplados. Acreditamos que a abstração da operação do usuário, bem como soluções de interoperabilidade seguras e eficientes, são partes cruciais para resolver esse problema.

ZK será alguma vez eficiente o suficiente?

Não há como contornar o fato de que a geração de provas leva muito tempo e o custo tanto da prova quanto da verificação ainda é muito alto hoje. Soluções concorrentes como ambientes de execução confiáveis/TEEs (privacidade) ou soluções de segurança otimistas/criptoeconômicas (custo) ainda fazem mais sentido para muitas aplicações hoje.

Muito trabalho, no entanto, está sendo feito em relação à otimização de software e aceleração de hardware para ZKPs. A agregação de provas ajudará a reduzir ainda mais os custos de verificação, espalhando o custo por várias partes diferentes (custo inferior/usuário). Também existe a possibilidade de adaptar a camada base para ser mais otimizada para a verificação de ZKPs. Um desafio em relação à aceleração de hardware para ZKPs é o rápido desenvolvimento de sistemas de prova. Isso torna difícil criar hardware especializado (ASICs), já que correm o risco de se tornar obsoletos rapidamente se/quando os padrões dos sistemas de prova subjacentes evoluem.

Ingonyamatentou criar alguns benchmarks para o desempenho do provador por meio de uma métrica comparável chamada pontuação ZK. É baseado no custo da execução da computação (OPEX) e rastreia MMOPS/WATT, onde MMOPS significa operações de multiplicação modular por segundo. Para mais leituras sobre o assunto, recomendamos blogs por @Cysic/BJQcpVbXn?ref=blog.succinct.xyz">Cysic and @ingonyama/revisiting-paradigms-hardware-acceleration-for-zero-knowledge-proofs-5dffacdc24b4">Ingonyama, assim como esta palestra de Wei Dai.

A privacidade limitada que as Provas de Conhecimento Zero (ZKPs) podem fornecer é útil?

ZKPs só podem ser usados para alcançar privacidade para estado pessoal, não para estado compartilhado onde várias partes precisam computar em dados criptografados (como um Uniswap privado). FHE e MPC também são necessários para privacidade total, mas esses precisam melhorar muitas ordens de magnitude em termos de custo e desempenho antes de serem opções viáveis para uso em larga escala. Dito isso, ZKPs ainda são úteis para certos casos de uso que não exigem um estado compartilhado privado, como soluções de identidade ou pagamentos. Nem todos os problemas precisam ser resolvidos com a mesma ferramenta.

Resumo

Então, onde isso nos deixa? Enquanto estamos progredindo a cada dia, muito trabalho ainda resta. As questões mais urgentes a serem resolvidas são como o valor e a informação podem fluir com segurança entre diferentes componentes modulares sem sacrificar velocidade ou custo, bem como abstraindo tudo isso do consumidor final para que eles não precisem se preocupar com a ponte entre diferentes cadeias, trocar carteiras, etc.

Embora ainda estejamos muito na fase de experimentação, as coisas devem se estabilizar ao longo do tempo, à medida que descobrimos onde no espectro estão os compromissos ideais para cada caso de uso. Isso, por sua vez, permitirá que padrões (informais ou formais) surjam e ofereçam mais estabilidade aos construtores em cima destas cadeias.

Hoje em dia, ainda existem muitos casos de uso que recorrem à segurança cripto-econômica devido ao custo e à complexidade de gerar ZKPs e alguns que exigem uma combinação dos dois. No entanto, essa participação deve diminuir com o tempo à medida que projetamos sistemas de prova mais eficientes e hardware especializado para reduzir o custo e a latência da prova e verificação. Com cada redução exponencial no custo e na velocidade, novos casos de uso são desbloqueados.

Embora este artigo tenha se concentrado especificamente em ZKPs, também estamos cada vez mais interessados em como as soluções de criptografia modernas (ZKPs, MPC, FHE e TEE) acabarão interagindo juntas - algo que já estamos vendo.

Obrigado por ler!

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [equilíbrio]. Todos os direitos autorais pertencem ao autor original [ Hannes Huitula]. Se houver objeções a esta reimpressão, entre em contato com oGate Learnequipe e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.