Blockchain (substantivo): Uma máquina de coordenação que permite aos participantes de todo o mundo colaborar ao longo de um conjunto de regras comuns acordadas sem a intervenção de terceiros.

Os computadores são projetados para fazer três coisas: armazenar dados, computar e comunicar entre si e com os humanos. As blockchains adicionam uma quarta dimensão: garantias adicionais de que essas três coisas (armazenamento, computação e comunicação) aconteçam de forma acordada. Essas garantias permitem a cooperação entre estranhos sem uma terceira parte confiável para facilitá-la (descentralizada).

Essas garantias adicionais podem ser econômicas (teoria do jogo 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 - criptoeconômica. Isso atua como um contraste acentuado com o status quo atual de sistemas amplamente baseados em reputação.

Embora o Web3 seja frequentemente descrito como "ler, escrever, possuir", acreditamos que uma melhor noção para a terceira iteração da internet é "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 honradas. 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 beneficiam da computação garantida, mas não envolvem diretamente a propriedade. Por exemplo, se a sua saúde em um jogo totalmente na cadeia for 77/100 - você possui essa saúde ou ela é apenas aplicável na cadeia de acordo com regras comumente acordadas? Nós argumentaríamos que é esta última, mas Chris Dixonpode discordar.

Web3 = Ler, Escrever, Verificar

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

As blockchains oferecem muito para se entusiasmar, 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 reexecução, o que significa 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. Embora um sistema descentralizado sempre contenha 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 fazer antes que as blockchains possam lidar com a escala ao nível da internet. Vemos compromissos ao longo de dois eixos principais - expressividade e dificuldade - e acreditamos que a modularidade permite uma experimentação mais rápida ao longo da fronteira de compromisso, enquanto o ZK a expande:

• Expressividade - Sobre o que pode criar garantias? Inclui escalabilidade (custo, latência, débito, etc), privacidade (ou gestão do fluxo de informação), programabilidade e componibilidade.
• Dureza - Quão firmes 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 de entrada mais baixas com menos capital necessário (tanto econômico quanto humano) - a modularidade permite uma experimentação mais rápida e especialização. A questão da modularidade versus integração não é binária, mas sim um espectro para experimentar e descobrir quais partes fazem sentido para desacoplar e quais não fazem.

As Provas de Conhecimento Zero, ou ZKPs, por outro lado, permitem que uma parte (o provador) prove a outra parte (o verificador) que sabem que algo é verdadeiro, sem revelar qualquer informação adicional além da 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 em que um executa, todos verificam), bem como a expressividade, permitindo a privacidade (com limitações). As ZKPs também melhoram a dificuldade das garantias, substituindo garantias criptoeconômicas mais fracas por mais fortes, o que é representado empurrando a fronteira de compensação para fora (referenciando o gráfico acima).

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

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

No entanto, antes de podermos abordar essas questões, 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 consideramos mais uma representação adequada, dada a evolução do espaço modular. A desconstrução adicional leva a novos componentes que anteriormente eram considerados parte de um todo maior, criando também novas dependências e a necessidade de interoperabilidade segura entre os diferentes componentes (mais sobre isso mais tarde). Dada a velocidade com que o espaço está avançando, pode ser difícil manter-se atualizado em todas as inovações nos diferentes níveis da pilha.

Tentativas anteriores de explorar a pilha web3 incluem as feitas por Kyle Samani(Multicoin) - originalmente publicado em2018 e atualizado em 2019. Abrange tudo, desde o acesso à internet descentralizado até ao último quilómetro (como Héliopara gestão de chaves de utilizador final. Embora os princípios por trás disso possam ser reciclados, algumas peças, como a prova e verificação, estão completamente em falta.

Com isso em mente, tentamos criar uma representação atualizada de como a pilha modular se parece em 2024, expandindo a pilha modular existente de quatro partes. Ela está 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 distinto - principalmente porque é difícil construir um protocolo em torno dela.

ZK No Modular Stack

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 abertos poderiam ser resolvidos introduzindo o ZK (evitando re-execução ou recursos de privacidade). Abaixo está um resumo de nossas descobertas, antes de nos aprofundarmos em cada componente separadamente.

1 - Abstração de Operação do Utilizador

Os utilizadores atuais das blockchains precisam de 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 utilizador é um termo genérico para qualquer tentativa de abstrair esta complexidade e permitir que os utilizadores interajam apenas com uma interface (por exemplo, uma aplicação específica ou carteira), com toda a complexidade a acontecer nos bastidores. Alguns exemplos de abstrações ao nível da 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 criptografia programável”). Pode ser usado para definir quem pode assinar (gestão de chaves), o que assinar (carga útil da tx), como assinar (algoritmo de assinatura) e quando assinar (condição de aprovação da transação). Em conjunto, essas funcionalidades permitem coisas como usar o login social para interagir com dApps, autenticação de dois fatores, recuperação de conta e automação (assinatura automática de tx). Embora a discussão frequentemente se centre em Ethereum (Gate.ioERC-4337passou na primavera de 2023), muitas outras cadeias já têm abstração de conta incorporada e nativaAptos, Sui, Perto, ICP, Starknet, e zkSync).
• A Abstração de Cadeia permite que os utilizadores assinem transações em diferentes cadeias, interagindo apenas com uma conta (uma interface, várias cadeias). Várias equipas estão a trabalhar nisso, incluindo Próximo, ICP, e dWallet. Estas soluções aproveitam o MPC e assinaturas em cadeia, onde a chave privada da outra rede é dividida em várias pequenas partes e partilhada entre validadores na cadeia de origem que assinam as transações entre cadeias. Quando os utilizadores querem interagir com outra cadeia, um número suficiente de validadores precisa de assinar a transação para satisfazer a encriptação do limiar. Isto mantém a segurança, uma vez que a chave privada nunca é totalmente partilhada em nenhum lugar. No entanto, enfrenta o risco de colusão de validadores, razão pela qual a segurança criptoeconómica e a descentralização de validadores da cadeia subjacente continuam a ser altamente relevantes.
• Os intents, a um nível elevado, permitem a ponte entre os desejos e necessidades do utilizador e as operações que podem ser executadas por um blockchain. Isto requer solucionadores de intents - agentes especializados off-chain encarregados de encontrar a melhor solução possível para o intento do utilizador. Já existem várias aplicações que utilizam intents especializados, como os agregadores DEX ("melhor preço") e os agregadores de pontes ("pontes mais baratas/mais rápidas"). Redes gerais de resolução de intentsAnoma, Essencial, ElegantePretendo facilitar aos utilizadores a expressão de intenções mais complicadas e aos programadores a construção de aplicações centradas em intenções. No entanto, ainda existem muitas questões em aberto, 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 utilizadores iniciar sessão utilizando credenciais familiares, como um endereço de email. Utiliza ZKPs para impedir que terceiros associem 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).Orbitertentar resolver este problema com um serviço de agrupamento que alavanca ZKPs para verificar a correção das assinaturas de transações 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 da partilha do custo de verificação on-chain igualmente entre todos os utilizadores, isto pode levar a poupanças significativas de custos.

Problemas Abertos Que ZKPs Podem Resolver

• Prova da melhor execução ou cumprimento da intenção: Embora as intenções e AA possam abstrair a complexidade dos utilizadores, também podem atuar como uma força centralizadora e exigir que confiemos em atores especializados (solvers) para encontrar os caminhos de execução ótimos. Em vez de simplesmente confiar na boa vontade do solver, as ZKPs poderiam potencialmente ser usadas para provar que o caminho ótimo para o utilizador foi escolhido entre aqueles amostrados pelo solver.
• Privacidade para liquidação de intenções: Protocolos como Taigapretendemos permitir a liquidação totalmente protegida da intenção para preservar a privacidade dos utilizadores - parte de um movimento mais amplo em direção à adição de privacidade (ou pelo menos confidencialidade) às redes blockchain. Utiliza ZKPs (Halo2) para ocultar informações sensíveis sobre as transições de estado (tipos de aplicação, partes envolvidas, etc).
• Recuperação de senha para carteiras AA: A ideia por trásesta 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 de ser ordenadas antes de serem adicionadas a um bloco, o que pode ser feito de várias maneiras: ordenando por rentabilidade para o proponente (transações mais lucrativas primeiro), na ordem em que foram submetidas (primeiro a entrar, primeiro a sair), dando prioridade às transações das mem pools privadas, etc.

Outra questão é quem fica responsável por ordenar as transações. Num mundo modular, várias partes diferentes podem fazê-lo, incluindo o sequenciador de rollup (centralizado ou descentralizado), a sequência L1 (baseada em rollups) e uma rede de sequenciamento partilhada (rede descentralizada de sequenciadores usada por vários rollups). Todos estes têm diferentes pressupostos de confiança e capacidades de escalaNa prática, a ordenação real das 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 encriptação correta da mempool: Raioé uma rede de sequenciamento partilhada que tem uma mempool encriptada com Encriptação Prática de Atraso Verificável (PVDE). Os utilizadores geram um ZKP que é usado para provar que a resolução dos quebra-cabeças de bloqueio temporal levará à descriptografia correta de transações válidas, ou seja, que a transação inclui uma assinatura e nonce válidos e que o remetente tem saldo suficiente para pagar a taxa de transação.

Problemas em Aberto Que as Provas de Conhecimento Zero Podem Resolver

• Regras de Sequenciamento Verificáveis (VSR): Sujeitando o proponente/sequenciador a um conjunto de regras sobre a ordem de execuçãocom garantias adicionais de que essas regras são seguidas. A verificação pode ser feita através de ZKPs ou provas de fraude, sendo que estas últimas requerem um vínculo econômico grande o suficiente que é cortado se o proponente/sequenciador se comportar mal.

3 - Execução (Escalonamento de Escrita)

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 provar 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.

Para além da verificação mais rápida e eficiente, outro benefício da execução comprovável é permitir uma computação mais complexa, uma vez que não se depara com os problemas típicos de gás e recursos limitados on-chain com a computação off-chain. Isto abre a porta a aplicações inteiramente novas que são computacionalmente mais intensivas 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 o Ethereum e provar o ambiente de execução do EVM. No entanto, quanto maior for a compatibilidade com o Ethereum, maior será o compromisso em termos de desempenho. Vários zkEVMs foram lançados em 2023, incluindo Polygon zkEVM, Era zkSync, Rolagem, e Linea. A Polygon anunciou recentemente o seu prover zkEVM do tipo 1, que permite provar blocos principais do Ethereum na mainnet por $0.20-$0.50 por bloco (com otimizações futuras para reduzir ainda mais os custos). RiscZero também tem uma soluçãoque permite provar blocos Ethereum, mas a um custo mais elevado com a limitada avaliação disponível.
• ZkVMs alternativos: Alguns protocolos estão a seguir um caminho alternativo e a otimizar o desempenho/provabilidade (kStarknet, Zorp) ou facilidade de desenvolvimento, em vez de tentar ser maximamente compatível com Ethereum. Exemplos disso incluem protocolos zkWASM (Fluente, Delphinus Labs) e zkMOVE (M2ezkmove.
• zkVMs focados na privacidade: Neste caso, ZKPs são usados para duas coisas: evitar a reexecução e alcançar privacidade. Embora a privacidade que pode ser alcançada apenas com ZKPs seja limitada (apenas estado privado pessoal), os próximos protocolos adicionam muita expressividade e programabilidade às soluções existentes. Exemplos incluem a Aleo’s snarkVM, AztecsAVM e do Polygon’sMidenVM.
• Coprocessadores ZK: Permite cálculos fora da cadeia de blocos com base em dados da cadeia de blocos (mas sem estado). As provas de conhecimento zero são usadas para comprovar a execução correta, proporcionando um ajuste mais rápido do que os coprocessadores otimistas, mas existe um compromisso em termos de custos. Devido ao custo e/ou dificuldade de gerar provas de conhecimento zero, estamos a ver algumas versões híbridas, como Brevis coChain, que permite aos desenvolvedores escolher entre o modo ZK ou otimista (compromisso entre custo e dificuldade de garantias).

Problemas em Aberto Que as ZKPs Podem Resolver

• zkVM consagrado: A maioria das camadas base (L1s) ainda usa a reexecução para verificar as transições de estado corretas. Consagrar um zkVM na camada base evitaria isso, pois os validadores poderiam verificar a prova. 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: Embora o SVM seja principalmente usado dentro do Solana L1 hoje, equipes como a Eclipse estão tentando alavancar o SVM para rollups que liquidam no Ethereum. A Eclipse também planeja usar Risc Zero para provas de fraude ZKpara os potenciais desafios 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 de Escala)

A consulta de dados, ou a leitura de dados a partir da blockchain, é uma parte essencial da maioria das aplicações. Embora grande parte da discussão e esforços ao longo dos últimos anos tenham se concentrado na escalabilidade das escritas (execução) - a escalabilidade das leituras é ainda mais importante devido ao desequilíbrio entre as duas (particularmente num 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 em Solana eram chamadas de leitura (com base em 2 anos de dados empíricos) - uma taxa de leitura/escrita de 24:1.

A escalabilidade de leituras inclui tanto obter mais desempenho (mais leituras/segundo) com clientes validadores dedicados (como Sig na Solana) quanto permitir consultas mais complexas (combinando leituras com computação), por exemplo com a ajuda de co-processadores.

Outra perspetiva consiste em descentralizar os métodos de consulta de dados. Hoje, a maioria das solicitações de consulta de dados em blockchains é facilitada por terceiros confiáveis (baseados na reputação), como nós RPC (Infura) e indexadores (Dune. Exemplos de opções mais descentralizadas incluem O Gráficoe operadores à prova de armazenamento (que também são verificáveis). Também existem várias tentativas de criar uma rede RPC descentralizada, como Infura DINouRede Lava(além do RPC descentralizado, a Lava visa oferecer mais tarde serviços adicionais de acesso a dados).

Integrações ZK existentes

• Provas de armazenamento: Permite consultar dados históricos e atuais de blockchains sem recorrer a terceiros de confiança. ZKPs são usadas para compressão e para provar que os dados corretos foram recuperados. Exemplos de projetos a desenvolver neste espaço incluem Axioma, Brevis, Heródoto, e Lagrange.

Problemas abertos que as ZKPs poderiam resolver

• Consulta eficiente do estado privado: Os projetos de privacidade frequentemente usam uma variação do modelo UTXO, que permite melhores recursos de privacidade do que o modelo de conta, mas à custa da facilidade de uso para desenvolvedores. O modelo UTXO privado também pode levar a 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 fundos, o que representa um desafio bastante fundamental para o funcionamento da rede. Antecipando-se a este problema,Aztec recentemente publicou um RFPpara ideias sobre a descoberta de notas, mas ainda não foi encontrada uma solução clara.

5 - Proving

Com mais e mais aplicações a incorporar ZKPs, a prova e a verificação estão a tornar-se rapidamente uma parte essencial da pilha modular. No entanto, hoje em dia, a maioria da infraestrutura de prova ainda é permitida e centralizada, com muitas aplicações a depender de um único provador.

Embora a solução centralizada seja menos complexa, descentralizar a arquitetura de prova e dividi-la num componente separado na pilha modular traz vários benefícios. Um benefício chave surge na forma de garantias de vitalidade que são cruciais para aplicações que dependem da geração frequente de provas. Os utilizadores também beneficiam de uma maior resistência à censura e de taxas mais baixas impulsionadas pela concorrência e pela partilha 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 aplicativos únicos (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 utilizadores em termos de taxas mais baixas, uma vez que os provadores não precisam de ser compensados pela redundância através de taxas mais elevadas (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 pegando dois argumentos como entrada em vez de rastreamento de execução).

Fonte: Capital de Figment

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 no Ethereum L1. Envolver o STARK em um SNARK como o passo final torna significativamente mais barato verificar no 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 Polígono zkEVM, Boojum em zkSync Era, e RISC Zero.
• Redes de prova descentralizadas de uso geral: Integrar mais aplicações numa rede de prova descentralizada torna-a mais eficiente para os provadores (maior utilização de hardware) e mais barata para os utilizadores (não precisam de pagar pela redundância do hardware). Os projetos neste campo incluem GevuloteConciso.

Problemas Abertos Que as ZKPs Podem Resolver

• Provas de Fraude ZK: Nas 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 este problema criando uma prova da transição de estado que está a ser desafiada, o que permite uma verificação mais eficiente (sem necessidade de reexecução) e potencialmente um processo de resolução mais rápido. Este trabalho está a ser realizado por pelo menosOptimismo(em colaboração com O1 Labs e RiscZero), e AltLayer x RiscZero.
• A agregação de prova mais eficiente: Uma ótima característica das Provas de Conhecimento Zero é que você pode agregar várias provas em uma única prova, sem aumentar significativamente os custos de verificação. Isso permite amortizar o custo de verificação ao longo de várias provas ou aplicações. A agregação de provas também é uma forma de comprovação, mas a entrada são duas provas em vez de um rastreamento de execução. Exemplos de projetos nesse espaço incluem NEBRAeGevulot.

Origem: Figment Capital

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 (os rollups otimistas requerem dados de entrada para verificar a execução correta por 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 do ativo para escotilhas de fuga, transações forçadas ou para verificar se as entradas correspondem às saídas). Os usuários (como pontes zk e rollups) enfrentam um pagamento único, que cobre o custo de armazenar transações e estado 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 a 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 a sua mainnet (31 de outubro), mas em breve haverá muitas alternativas para escolher como Aproveite, EigenDA, e Perto de DAsão todos esperados para serem lançados durante 2024. Além disso, EIP 4844 da Ethereumatualização da publicação de dados em escala na Ethereum (além de criar um mercado separado de taxas para armazenamento de blob) e preparar o terreno para o dank-sharding completo. 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 visa construir DP nativo sobre Bitcoin.

Muitas soluções de DP também oferecem serviços para além da simples publicação de dados, incluindo segurança partilhada para rollups soberanos (como CelestiaeDisponível) ou uma interoperabilidade mais suave entre rollups (como o Avail'sNexus. Existem também projetos (DomiconeZero Gravity) que oferecem tanto a publicação de dados como 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 a desagregação adicional como com o reagrupamento).

Integrações ZK existentes

• Provar a 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 o 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 que os nós leves amostrarem partes únicas suficientes. Provar a correção da codificação de apagamento pode ser feito usando provas de validade (ZKPs) ou provas de fraude - sendo que estas últimas sofrem de latência relacionada com o período de desafio. Todas as outras soluções, exceto Celestia, estão a trabalhar na utilização de provas de validade.
• Clientes leves ZK a alimentar pontes de dados: Rollups que usam camadas externas de publicação de dados ainda precisam de comunicar à camada de liquidação que os dados foram publicados corretamente. Para isso, existem 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. Ambos os produtos da Avail (Gate.io)VectorX) e de Celestia (BlobstreamX) os bridges de atestação de dados são alimentados por clientes leves ZK construídos em conjunto com o Succinct.

Problemas em Aberto que as ZKPs Podem Resolver

• Celestia incorporando provas de validade para codificação de apagamento correta: Celestia é atualmente uma anomalia entre as redes de publicação de dados, poisusa provas de fraude para codificação de apagamento correta. Se um proponente de bloco malicioso codificar os dados de forma incorreta, qualquer outro nó completo pode gerar uma prova de fraude e desafiar isso. Embora esta abordagem seja um pouco mais simples de implementar, também introduz latência (o bloco só é final após a janela de prova de fraude) e requer que os nós leves confiem em um nó completo honesto para gerar a prova de fraude (não podem verificá-la por si mesmos). No entanto, Celestia está a explorarcombinando sua codificação atual de Reed-Solomon 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 encontrada aquicom gravações de grupos de trabalho anteriores (além de tentativas mais gerais de adicionar ZKPs à camada base da Celestia).
• ZK-proving DAS: Houve algumas explorações sobreDados de disponibilidade de prova ZK, onde os nós leves simplesmente verificariam a raiz de Merkle e uma ZKP, em vez de terem que fazer a amostragem usual 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 a Longo Prazo (Estado)

Armazenar dados históricos é importante principalmente para fins de sincronização e atendimento a pedidos de dados. No entanto, não é viável para cada nó completo armazenar todos os dados e a maioria dos nós completos elimina dados antigos para manter os requisitos de hardware razoáveis. Em vez disso, dependemos de partes especializadas (nós de arquivo 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 a 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 informações históricas e adicionar alguma redundância (pelo menos X nós armazenam os dados) através dos incentivos incorporados na 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 reivindicam. Um exemplo disso é Prova de espaço de tempo do Filecoin(PoSt), onde os fornecedores de armazenamento ganham recompensas de bloco cada vez que respondem com sucesso a um desafio PoSt.

Problemas em Aberto que as ZKPs Podem Resolver

• Provar a proveniê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 carregar 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 sobre qual é a verdade atual (qual bloco é o correto) por meio de um mecanismo chamado consenso. Os 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 do garfo). Embora a maioria das implementações existentes de consenso PoS sejam baseadas em BFT, Cardanoé um exemplo de implementação da cadeia mais longa. Há também um interesse crescente em mecanismos de consenso baseados em DAG, como 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 EigenDA).

Integrações ZK existentes

• Staking em redes de privacidade baseadas em ZK: As redes de privacidade baseadas em PoS representam um desafio, uma vez que os detentores dos tokens de staking devem escolher entre privacidade e participação no consenso (e receber recompensas de staking).Penumbra tem como objetivo resolver istoao eliminar recompensas de staking, tratando em vez disso as apostas desvinculadas e vinculadas como ativos separados. Este método mantém as delegações individuais privadas, enquanto o montante total vinculado a cada validador continua público.
• Governança privada: Conseguir votações anónimas tem sido há muito um desafio no mundo das criptomoedas, com projetos como Votação Privada de Nounstentando fazer avançar isso. O mesmo também se aplica à governança, onde a votação anônima sobre propostas está a ser trabalhada, pelo menos, pela Penumbra. Neste caso, os ZKPs podem ser usados para provar que alguém tem o direito de voto (por exemplo, através da posse de tokens) e que certos critérios de votação são cumpridos (não ter votado previamente, por exemplo).

Problemas em Aberto Que as ZKPs Podem Resolver

• Eleição privada de líder: Atualmente, o Ethereum elege os próximos 32 proponentes de bloco 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 lidar com este problema, Batedoré uma proposta de protocolo de preservação da privacidade para eleger proponentes de blocos na Ethereum. Os ZKPs são usados pelos validadores para provar que a mistura e a aleatorização foram realizadas honestamente. Existem outras abordagens também para alcançar um objetivo semelhante, algumas das quais são abordadas nestepostagem no blog da a16z.
• Agregação de assinaturas: Usar ZKPs para agregar assinaturas poderia reduzir significativamente a sobrecarga de comunicação e computação da verificação de assinaturas (verificar uma prova agregada em vez de cada assinatura individual). Isso é algo que já está sendo aproveitado em clientes leves de ZK, mas poderia ser potencialmente expandido também para o consenso.

9 - Liquidação

A liquidação é semelhante ao tribunal de justiça mais alto - 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 se torna irreversível (ou no caso de finalidade probabilística - no momento em que seria suficientemente difícil revertê-la). O tempo de finalização depende da camada de liquidação subjacente usada, que por sua vez depende da regra de finalidade específica usada e do tempo de bloco.

A finalidade lenta é particularmente um problema na comunicação entre rollups, onde os rollups precisam esperar pela confirmação do Ethereum antes de poderem aprovar uma transação (7 dias para rollups otimistas, 12 minutos e tempo de prova para rollups de validade). Isso resulta numa experiência de utilizador fraca. Existem vários esforços para resolver este problema usando pré-confirmações com um certo nível de segurança. Exemplos incluem soluções específicas do ecossistemaPolygon AggLayerouzkSync HyperBridge) e soluções de uso geral como Camada de Finalidade Rápida da Nearque visa conectar vários ecossistemas de rollup diferentes, aproveitando a segurança econômica da EigenLayer. Existe também a opção depontes de rollup nativas que tiram partido da EigenLayerpara confirmações suaves para evitar esperar pela plena finalidade.

Integrações ZK existentes

• Resolução mais rápida com rollups de validade: Ao contrário dos rollups otimistas, os rollups de validade não requerem um período de desafio, pois dependem de ZKPs para provar a transição de estado correta, independentemente de alguém contestar (rollups pessimistas). Isso torna o settlement 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 com a solidez das garantias e é uma parte crucial da proposta de valor das blockchains. No entanto, criar segurança cripto-económica é difícil - aumentando as barreiras à entrada e atuando como fricção para a inovação nas aplicações que mais precisam 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 riscos adicionais de penalização (condições de punição), em vez de cada componente tentar inicializar o seu próprio. Já houve algumas tentativas anteriores de fazer o mesmo em redes PoWmineração combinada.)), mas os incentivos desalinhados tornaram mais fácil para os mineiros colaborarem e explorarem um protocolo (mais difícil punir comportamentos inadequados, uma vez que o trabalho ocorre no mundo físico, ou seja, mineração usando poder computacional). A segurança do PoS é mais flexível para ser usada por outros protocolos, uma vez que possui incentivos positivos (rendimento de participação) e negativos (penalização).

Protocolos construídos em torno da premissa de segurança partilhada incluem:

• A EigenLayer tem como objetivo aproveitar a segurança existente do Ethereum para garantir uma ampla gama de aplicações. O whitepaper foi lançado no início de 2023, e a EigenLayer está atualmente em mainnet alpha, com o lançamento completo da mainnet previsto para mais tarde este ano.
• Cosmos lançou o seu Segurança Interchain(ICS) em maio de 2023, que permite o Cosmos Hub - uma das maiores cadeias no Cosmos e apoiada por ~$2.4bn de ATOM apostados- para alugar a sua segurança às cadeias de consumo. Ao utilizar o mesmo conjunto de validadores que alimenta o Cosmos Hub para também validar blocos na cadeia de consumo, tem como objetivo reduzir a barreira para lançar novas cadeias em cima da pilha Cosmos. No entanto, atualmente, apenas duas cadeias de consumidores estão ativas (Neutron e Stride).
• Babilônia está tentando permitir que o BTC seja usado para segurança compartilhada também. Para combater os problemas relacionados à mineração mesclada (difícil de punir comportamento ruim), está construindo uma camada virtual de PoS onde os usuários podem bloquear BTC em um contrato de staking no Bitcoin (sem pontes). Como o Bitcoin não possui uma camada de contratos inteligentes, as regras de slashing dos contratos de staking são expressas em termos de transações UTXO escritas no script do Bitcoin.
• Restaking em outras redes incluem Polvoem Near e Picasso em Solana. PolkadotParacadeiastambém tira partido do conceito de segurança partilhada.

Integrações ZK existentes

• Mistura 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 gerar a prova demora demasiado tempo. Um exemplo disto é Brevis coCadeia, que é um co-processador que obtém sua segurança econômica de ETH re-stakers e garante otimisticamente a computação (com provas de fraude ZK). dApps podem escolher entre o modo puro-ZK ou coChain, dependendo de suas necessidades específicas em termos de segurança e compensações de custo.

11 - Interoperabilidade

A interoperabilidade segura e eficiente continua a ser um grande problema num mundo multi-cadeias, exemplificado pelo $2.8bn perdidos em hacks de pontesNos sistemas modulares, a interoperabilidade torna-se ainda mais importante - Não só está a comunicar entre outras cadeias, mas as blockchains modulares também requerem que diferentes componentes comuniquem entre si (como a camada DA e de liquidação). Por conseguinte, já não é viável simplesmente executar um nó completo ou verificar uma única prova de consenso como nas blockchains integradas. Isto adiciona mais peças em movimento à equação.

A interoperabilidade inclui tanto a ponte de tokens como a passagem de mensagens mais geral entre blockchains. Existem várias opções diferentes disponíveis que fazem todos diferentes compromissos em termos de segurança, latência e custo. Otimizar para os três é muito difícil, o que normalmente 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 publicação por Dino(co-fundador da Fluent & Modular Media) dá uma boa introdução. A maioria dos clientes leves hoje em dia apenas verifica o consenso, mas idealmente teríamos clientes leves que pudessem verificar a execução e o DA também 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

• Clientes leves ZK (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 utilizado na cadeia de origem pode não ser suportado nativamente na cadeia de destino. Embora se espere que a importância dos clientes leves ZK na ponte aumente, as atuais fricções 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 certificação de dados da Avail e da Celestia, e zkIBC by Electron Labs.
• Provas de armazenamento: Como mencionado anteriormente, as provas de armazenamento permitem consultar dados históricos e atuais em blockchains sem recorrer a terceiros de confiança. 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 possui tokens em uma cadeia e usar isso para governança em outra cadeia (sem a necessidade de fazer uma ponte). Também existem tentativas de usar provas de armazenamento para pontes, como esta solução desenvolvida pela LambdaClass.
• ZK Oracles: Os Oracles atuam como intermediários e ligam dados do mundo real à blockchain. Os oráculos ZK melhoram os modelos de oráculos atuais baseados em reputação, permitindo comprovar a origem e integridade dos dados, juntamente com qualquer cálculo feito nesses dados.

Problemas em aberto que as ZKPs poderiam resolver

• Clientes leves completos: Em vez de confiar cegamente no conjunto de validadores da outra cadeia - os 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 que não seja consenso ainda é proibitivamente caro na maioria das cadeias, especialmente no Ethereum. Além disso, os clientes leves só permitem a verificação de informações (metade do problema), ou seja, eles podem identificar que a informação é falsa, mas ainda precisa haver um mecanismo adicional para que eles façam algo a respeito.
• Camadas de Agregação: AggLayer da Polygonpretende permitir uma 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 bundles da cadeia dependente 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 da zkSynceDisponível Nexusestão a adotar uma abordagem semelhante.

Quando ZK Comeu A Pilha Modular?

Supondo que possamos chegar a um estado em que a geração de ZKPs se torne muito rápida (quase à velocidade da luz) e incrivelmente barata (quase gratuita), como será o resultado final? Em outras palavras, quando é que ZK comeu o conjunto modular?

De um modo geral, acreditamos que duas coisas seriam verdadeiras neste estado do mundo:

1. Toda a 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 deixam de ser uma consideração relevante, acreditamos que a maioria das aplicações dependerá de ZKPs para garantias mais fortes. Isso também requer algumas melhorias na usabilidade e na amigabilidade do desenvolvedor para construir aplicações ZK, mas esses são todos problemas em que várias equipas estão a trabalhar.

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

Riscos Para a 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 utilizadores como os programadores sofrem com o número cada vez maior de cadeias. Os utilizadores precisam de gerir fundos em várias cadeias (e potencialmente várias carteiras). Por outro lado, os programadores de aplicações têm menos estabilidade e previsibilidade, dado o quanto o espaço ainda está a evoluir, tornando mais difícil decidir em que cadeia construir. Também precisam de pensar na fragmentação do estado e da liquidez. Isto é particularmente verdade agora, enquanto ainda estamos a experimentar ao longo da fronteira sobre quais componentes fazem sentido desacoplar e quais serão recoplados. Acreditamos que a abstração da operação do utilizador, bem como soluções de interoperabilidade seguras e eficientes, são partes cruciais para resolver este problema.

O ZK alguma vez será suficientemente performante?

Não há como contornar o facto de que a geração de provas demora demasiado tempo e o custo tanto da prova como da verificação ainda é demasiado elevado nos dias de hoje. Soluções concorrentes como ambientes de execução confiáveis/TEEs (privacidade) ou soluções de segurança otimistas/cruptoeconómicas (custo) ainda fazem mais sentido para muitas aplicações hoje em dia.

Está a ser feito muito trabalho no que diz respeito à otimização de software e à aceleração de hardware para ZKPs. A agregação de prova ajudará a reduzir ainda mais os custos de verificação, distribuindo o custo por várias partes diferentes (custo inferior/utilizador). Também existe a possibilidade de adaptar a camada base para ser mais otimizada para a verificação de ZKPs. Um desafio relativo à aceleração de hardware para ZKPs é o rápido desenvolvimento de sistemas de prova. Isto torna difícil a criação de hardware especializado (ASICs), uma vez que correm o risco de ficar rapidamente obsoletos se/ quando os padrões dos sistemas de prova subjacentes evoluem.

Ingonyamatentou criar algum referencial para o desempenho do provador através de uma métrica comparável chamada ZK score. Baseia-se no custo da execução da computação (OPEX) e acompanha MMOPS/WATT, onde MMOPS significa operações de multiplicação modular por segundo. Para mais leitura sobre o tema, recomendamos blogs de@Cysic/BJQcpVbXn?ref=blog.succinct.xyz">Cysic and @ingonyama/revisitar-paradigmas-aceleracao-de-hardware-para-provas-de-zero-conhecimento-5dffacdc24b4">Ingonyama, bem como esta palestra por Wei Dai.

A privacidade limitada que as ZKPs podem fornecer é útil?

ZKPs só podem ser usados para alcançar privacidade para estado pessoal, não estado compartilhado onde múltiplas partes precisam calcular em dados criptografados (como um Uniswap privado). FHE e MPC também são necessários para privacidade completa, mas estes precisam melhorar muitas ordens de magnitude em termos de custo e desempenho antes de serem opções viáveis para uso em maior escala. Dito isto, ZKPs ainda são úteis para certos casos de uso que não requerem 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? Embora estejamos progredindo a cada dia, ainda há muito trabalho a fazer. As questões mais prementes a resolver são como o valor e a informação podem fluir com segurança entre diferentes componentes modulares sem sacrificar a velocidade ou o custo, além de abstrair tudo isso do consumidor final, para que ele não precise se preocupar em fazer a ponte entre diferentes redes, trocar de carteiras, etc.

Embora estejamos atualmente ainda muito na fase de experimentação, as coisas devem estabilizar ao longo do tempo, à medida que descobrimos onde no espectro estão os trade-offs ótimos para cada caso de uso. Isso, por sua vez, dará espaço para que padrões (informais ou formais) surjam e proporcionem mais estabilidade aos construtores em cima dessas cadeias.

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

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

Obrigado por ler!

Aviso legal：

1. Este artigo é reproduzido a partir de [equilíbrio]. Todos os direitos de autor pertencem ao autor original [ Hannes Huitula]. Se houver objeções a esta reimpressão, entre em contato com oGate Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.