À medida que o conceito de coprocessadores se tornou popular nos últimos meses, este novo caso de uso do ZK começou a receber cada vez mais atenção.

No entanto, descobrimos que a maioria das pessoas ainda não está familiarizada com o conceito de coprocessadores, especialmente com o posicionamento preciso dos coprocessadores - o que é e o que não é um coprocessador ainda é relativamente vago. Quanto à comparação das soluções técnicas de diversas faixas de coprocessador do mercado, ninguém ainda resolveu sistematicamente. Este artigo espera dar ao mercado e aos usuários uma compreensão mais clara da trilha do coprocessador.

1. O que é coprocessador e o que não é?

Se lhe pedissem para explicar os coprocessadores para um desenvolvedor ou não técnico em apenas uma frase, como você o descreveria?

Acho que o que o Dr. Dong Mo disse pode estar muito próximo da resposta padrão – para ser franco, um coprocessador está “dando aos contratos inteligentes a capacidade de realizar Dune Analytics”.

Como desconstruir esta frase?

Imagine o cenário em que usamos o Dune - você deseja fazer LP no Uniswap V3 para ganhar algumas taxas de manuseio, então você abre o Dune e encontra o volume de negociação recente de vários pares de negociação no Uniswap, a TAEG das taxas de manuseio nos últimos 7 dias, e os principais pares de negociação. As faixas de flutuação superior e inferior, etc.

Ou talvez quando o StepN se tornou popular, você começou a especular sobre sapatos e não tinha certeza de quando vendê-los, então olhou os dados do StepN no Dune todos os dias, o volume diário de transações, o número de novos usuários, o preço mínimo dos sapatos… e planejado assim que houvesse crescimento. Se a tendência desacelerar ou diminuir, corra rapidamente.

Claro, você pode não estar apenas olhando para esses dados, mas as equipes de desenvolvimento do Uniswap e StepN também estão prestando atenção a esses dados.

Estes dados são muito significativos – podem não só ajudar a avaliar as mudanças nas tendências, mas também utilizá-los para criar mais truques, tal como a abordagem de “big data” normalmente utilizada pelas principais empresas da Internet.

Por exemplo, com base no estilo e no preço dos sapatos que os usuários costumam comprar e vender, sapatos semelhantes são recomendados.

Por exemplo, um “Programa de Recompensa de Fidelidade do Usuário” será lançado com base no tempo que os usuários mantêm os Creation Shoes para oferecer aos usuários fiéis mais lançamentos aéreos ou benefícios.

Por exemplo, um plano VIP semelhante ao Cex pode ser lançado com base no TVL ou volume de negociação fornecido pelo LP no Uniswap ou Trader, proporcionando redução na taxa de transação do Trader ou aumento de benefícios na participação da taxa do LP…

Neste momento, surge o problema - o big data + IA das grandes empresas de Internet é basicamente uma caixa preta. Eles podem fazer o que quiserem. Os usuários não podem ver e não se importam.

Mas aqui na Web3, a transparência e a falta de confiança são o nosso politicamente correto natural, e rejeitamos as caixas pretas!

Portanto, quando você quiser realizar o cenário acima, enfrentará um dilema - ou você pode alcançá-lo por meios centralizados, usar o Dune “manualmente” para contar os dados do índice em segundo plano e, em seguida, implantá-los e implementá-los; ou você pode escrever um Configure contratos inteligentes para capturar automaticamente esses dados na cadeia, concluir cálculos e implantar pontos automaticamente.

O primeiro o levará a questões de confiança “politicamente incorretas”.

A taxa de gás gerada por este último na cadeia será um valor astronômico, e sua carteira (do projeto) não pode pagar por isso.

Este é o momento do coprocessador entrar no palco. Combine os dois métodos agora mesmo e, ao mesmo tempo, use a etapa do “manual de back-end” para “autocertificar a inocência” por meios técnicos. Em outras palavras, use a tecnologia ZK para “indexar + A parte de “cálculo” “comprovar inocência” e, em seguida, alimentá-la no contrato inteligente. Desta forma, o problema da confiança é resolvido e as enormes taxas do gás desaparecem. Perfeito!

Por que é chamado de “coprocessador”? Na verdade, isso vem da “GPU” na história do desenvolvimento da Web2.0. A razão pela qual a GPU foi introduzida como um hardware de computação separado e existia independentemente da CPU naquela época foi porque sua arquitetura de design podia lidar com alguns cálculos que eram fundamentalmente difíceis de serem realizados pela CPU, como cálculos repetidos paralelos em grande escala, gráficos cálculos, etc. É precisamente por causa dessa arquitetura de “coprocessador” que temos hoje maravilhosos filmes CG, jogos, modelos de IA, etc., então essa arquitetura de coprocessador é na verdade um salto na arquitetura de computação. Agora, várias equipes de coprocessadores também esperam introduzir essa arquitetura na Web3.0. O blockchain aqui é semelhante à CPU da Web3.0. Quer seja L1 ou L2, eles são inerentemente inadequados para tarefas de “dados pesados” e “lógica de cálculo complexo”, portanto, um coprocessador blockchain é introduzido para ajudar a lidar com tais cálculos, expandindo assim enormemente as possibilidades de aplicações blockchain.

Portanto, o que o coprocessador faz pode ser resumido em duas coisas:

1. Obtenha os dados do blockchain e use ZK para provar que os dados que obtive são verdadeiros e não adulterados;
2. Faça os cálculos correspondentes com base nos dados que acabei de obter e, mais uma vez, use ZK para provar que os resultados que calculei são verdadeiros e não adulterados. Os resultados do cálculo podem ser chamados pelo contrato inteligente “Low Fee + Trustless”.

Há algum tempo, a Starkware tinha um conceito popular chamado Storage Proof, também chamado de State Proof. Basicamente realiza o passo 1, representado por Heródoto, Langrage, etc. O foco técnico de muitas pontes de cadeia cruzada baseadas na tecnologia ZK também está na etapa 1.1 em diante.

O coprocessador nada mais é do que o passo 1 seguido do passo 2. Após extrair os dados sem confiança, faça um cálculo sem confiança e pronto.

Portanto, para usar um termo relativamente técnico para descrevê-lo com precisão, o coprocessador deve ser um superconjunto de Prova de Armazenamento/Prova de Estado e um subconjunto de Computação Verificável.

Uma coisa a observar é que o coprocessador não é Rollup.

Tecnicamente falando, a prova ZK do Rollup é semelhante à etapa 2 acima, e o processo da etapa 1 “obter dados” é implementado diretamente através do Sequencer. Mesmo um sequenciador descentralizado usa apenas algum tipo de competição ou mecanismo de consenso para conseguir isso. Pegue, em vez da Prova de Armazenamento, esta forma de ZK. O mais importante é que, além da camada de cálculo, o ZK Rollup também precisa implementar uma camada de armazenamento semelhante ao blockchain L1. Este armazenamento é permanente, enquanto o Coprocessador ZK é “sem estado”. Após a conclusão do cálculo, nenhum status Todos será retido.

Do ponto de vista dos cenários de aplicação, o coprocessador pode ser considerado como um plug-in de serviço para todas as Camadas 1/Camada 2, enquanto o Rollup recria uma camada de execução para ajudar a expandir a camada de liquidação.

2. Por que devo usar o ZK? Posso usar OP?

Depois de ler o texto acima, você pode ter uma dúvida: o ZK deve ser usado como coprocessador? Parece muito com um “Gráfico com ZK adicionado”, e não parecemos ter “grandes dúvidas” sobre os resultados do Gráfico.

Isso ocorre porque quando você usa o Graph, basicamente não há dinheiro real envolvido. Esses índices atendem a serviços fora da cadeia. O que você vê na interface do usuário front-end é o volume de transações, o histórico de transações, etc. Os dados podem ser fornecidos por meio de vários provedores de índice de dados, como Graph, Alchemy, Zettablock, etc., mas esses dados não podem ser inseridos de volta no contrato inteligente, porque, uma vez inseridos de volta, você adicionará confiança adicional no serviço de índice. Quando os dados estão ligados a dinheiro real, especialmente TVL de grande volume, esta confiança extra torna-se importante. Imagine que da próxima vez que um amigo lhe pedir emprestado 100 yuans, você poderá emprestá-los sem piscar. Sim, e quando eu lhe pedir emprestado 10.000 yuans, ou mesmo 1 milhão de yuans?

Mas, novamente, precisamos realmente usar ZK para coprocessar todos os cenários acima? Afinal, temos duas rotas técnicas, OP e ZK, em Rollup. O recentemente popular ZKML também possui o conceito OPML de rotas de ramificação correspondentes. Questionado, o coprocessador também possui um ramo do OP, como o OP-Coprocessador?

Na verdade, existe mesmo - mas estamos mantendo os detalhes específicos confidenciais por enquanto e divulgaremos informações mais detalhadas em breve.

3. Qual coprocessador é o melhor – Comparação de diversas soluções técnicas de coprocessadores comuns no mercado

Brevis

A arquitetura do Brevis consiste em três componentes: zkFabric, zkQueryNet e zkAggregatorRollup.

A seguir está um diagrama da arquitetura Brevis:

zkFabric: coleta cabeçalhos de bloco de todos os blockchains conectados e gera provas de consenso ZK comprovando a validade desses cabeçalhos de bloco. Através do zkFabric, Brevis implementa um coprocessador interoperável para múltiplas cadeias, que permite que uma blockchain acesse quaisquer dados históricos de outra blockchain.

zkQueryNet: um mercado aberto de mecanismo de consulta ZK que aceita consultas de dados de dApps e as processa. As consultas de dados processam essas consultas usando cabeçalhos de bloco verificados do zkFabric e geram provas de consulta ZK. Esses mecanismos possuem funções altamente especializadas e linguagens de consulta gerais para atender a diferentes necessidades de aplicativos.

zkAggregatorRollup: Um blockchain convolucional ZK que atua como uma camada de agregação e armazenamento para zkFabric e zkQueryNet. Ele verifica as provas de ambos os componentes, armazena os dados verificados e confirma sua raiz de estado validada por zk para todos os blockchains conectados.

ZK Fabric é uma parte fundamental na geração de provas para o cabeçalho do bloco. É muito importante garantir a segurança desta parte. A seguir está o diagrama de arquitetura do zkFabric:

O cliente leve baseado em prova de conhecimento zero (ZKP) do zkFabric o torna completamente confiável, sem depender de qualquer entidade de verificação externa. Não há necessidade de confiar em nenhuma entidade de verificação externa, pois sua segurança vem inteiramente do blockchain subjacente e de provas matematicamente confiáveis.

A rede zkFabric Prover implementa circuitos para cada protocolo lightclient do blockchain e a rede gera provas de validade para cabeçalhos de bloco. Os provadores podem aproveitar aceleradores como GPUs, FPGAs e ASICs para minimizar o tempo e o custo da prova.

zkFabric depende das suposições de segurança do blockchain e dos protocolos criptográficos subjacentes e das suposições de segurança dos protocolos criptográficos subjacentes. No entanto, para garantir a eficácia do zkFabric, é necessário pelo menos um retransmissor honesto para sincronizar o fork correto. Portanto, o zkFabric usa uma rede de retransmissão descentralizada em vez de uma única retransmissão para otimizar a eficácia do zkFabric. Esta rede de retransmissão pode aproveitar as estruturas existentes, como a rede de guarda estadual na rede Celer.

Alocação de provadores: A rede de provadores é uma rede descentralizada de provadores ZKP que seleciona um provador para cada tarefa de geração de provas e paga taxas a esses provadores.

Implantação atual:

Protocolos de clientes leves atualmente implementados para vários blockchains, incluindo Ethereum PoS, Cosmos Tendermint e BNB Chain, servem como exemplos e provas de conceito.

Brevis atualmente coopera com o gancho uniswap, que adiciona muito pools uniswap personalizados. No entanto, em comparação com o CEX, o UnisWap ainda carece de capacidades eficazes de processamento de dados para criar projetos que dependam de grandes dados de transações de usuários (como programas de fidelidade baseados no volume de transações). Função.

Com a ajuda de Brevis, Hook resolveu o desafio. Os ganchos agora podem ler os dados completos da cadeia histórica de um usuário ou LP e executar cálculos personalizáveis de maneira totalmente confiável.

Heródoto

Herodotus é um poderoso middleware de acesso a dados que fornece contratos inteligentes com as seguintes funções para acessar de forma síncrona dados atuais e históricos na cadeia através da camada Ethereum:

1. Estados L1 de L2s
2. Estados L2 de L1s e de outros L2s
3. Estados L3/App-Chain para L2s e L1s

Heródoto propôs o conceito de prova de armazenamento, que combina prova de inclusão (confirmando a existência de dados) e prova computacional (verificando a execução de fluxo de trabalho em várias etapas) para provar que um grande conjunto de dados (como todo o blockchain Ethereum ou rollup) ou a validade de múltiplos elementos.

O núcleo do blockchain é o banco de dados, no qual os dados são criptografados e protegidos usando estruturas de dados como árvores Merkle e árvores Merkle Patricia. O que há de único nessas estruturas de dados é que, uma vez que os dados sejam confirmados com segurança nelas, evidências podem ser geradas para confirmar que os dados estão contidos na estrutura.

O uso de árvores Merkle e árvores Merkle Patricia aumenta a segurança do blockchain Ethereum. Ao fazer hash criptográfico dos dados em cada nível da árvore, é quase impossível alterar os dados sem detecção. Quaisquer alterações em um ponto de dados exigem a alteração do hash correspondente na árvore para o hash raiz, que é publicamente visível no cabeçalho do blockchain. Esta característica fundamental do blockchain fornece um alto nível de integridade e imutabilidade de dados.

Em segundo lugar, estas árvores permitem uma verificação eficiente dos dados através de provas de inclusão. Por exemplo, ao verificar a inclusão de uma transação ou o estado de um contrato, não há necessidade de pesquisar todo o blockchain Ethereum, mas apenas o caminho dentro da árvore Merkle relevante.

A prova de armazenamento conforme definida por Heródoto é uma fusão de:

1. Provas de contenção: Estas provas confirmam a existência de dados específicos numa estrutura de dados criptográficos (como uma árvore Merkle ou árvore Merkle Patricia), garantindo que os dados em questão estão de facto presentes no conjunto de dados.
2. Prova Computacional: Verifique a execução de um fluxo de trabalho de várias etapas, comprovando a validade de um ou mais elementos em um amplo conjunto de dados, como todo o blockchain Ethereum ou um agregado. Além de indicar a presença de dados, também verificam transformações ou operações aplicadas a esses dados.
3. Provas de conhecimento zero: simplifique a quantidade de dados com os quais os contratos inteligentes precisam interagir. As provas de conhecimento zero permitem que contratos inteligentes confirmem a validade de uma reivindicação sem processar todos os dados subjacentes.

Fluxo de trabalho

1.Obter hash de bloco

Cada dado no blockchain pertence a um bloco específico. O hash do bloco serve como identificador exclusivo do bloco e resume todo o seu conteúdo por meio do cabeçalho do bloco. No fluxo de trabalho de prova de armazenamento, primeiro precisamos determinar e verificar o hash do bloco que contém os dados de nosso interesse. Este é o primeiro passo de todo o processo.

2.Obter cabeçalho do bloco

Uma vez obtido o hash do bloco relevante, o próximo passo é acessar o cabeçalho do bloco. Para fazer isso, o cabeçalho do bloco associado ao hash do bloco obtido na etapa anterior precisa ser hash. O hash do cabeçalho do bloco fornecido é então comparado ao hash do bloco resultante:

Existem duas maneiras de obter o hash:

1. Use opcode BLOCKHASH para recuperar
2. Consulte o hash de blocos que foram verificados no histórico do Block Hash Accumulator

Esta etapa garante que o cabeçalho do bloco que está sendo processado seja autêntico. Assim que esta etapa for concluída, o contrato inteligente poderá acessar qualquer valor no cabeçalho do bloco.

3.Determine as raízes necessárias (opcional)

Com o cabeçalho do bloco em mãos, podemos nos aprofundar em seu conteúdo, especificamente:

stateRoot: um resumo criptográfico de todo o estado do blockchain no momento em que o blockchain ocorreu.

recibosRoot: resumo criptografado de todos os resultados da transação (recibos) no bloco.

TransactionsRoot: um resumo criptográfico de todas as transações que ocorreram no bloco.

pode ser decodificado, permitindo verificar se uma conta, recibo ou transação específica está incluída no bloco.

4.Validar dados em relação à raiz selecionada (opcional)

Com a raiz que selecionamos, e considerando que o Ethereum utiliza uma estrutura Merkle-Patricia Trie, podemos utilizar a prova de inclusão Merkle para verificar se os dados existem na árvore. As etapas de verificação variarão dependendo dos dados e da profundidade dos dados dentro do bloco.

Redes atualmente suportadas:

1. De Ethereum a Starknet
2. De Ethereum Goerli a Starknet Goerli
3. De Ethereum Goerli a zkSync Era Goerli

Axioma

Axiom fornece uma maneira para os desenvolvedores consultarem cabeçalhos de bloco, contas ou valores de armazenamento de todo o histórico do Ethereum. AXIOM apresenta um novo método de ligação baseado em criptografia. Todos os resultados retornados pela Axiom são verificados na cadeia por meio de provas de conhecimento zero, o que significa que contratos inteligentes podem usá-los sem suposições de confiança adicionais.

A Axiom lançou recentemente o Halo2-repl, um halo2 REPL baseado em navegador escrito em Javascript. Isso permite que os desenvolvedores escrevam circuitos ZK usando apenas Javascript padrão sem precisar aprender uma nova linguagem como Rust, instalar bibliotecas de prova ou lidar com dependências.

Axiom consiste em dois componentes tecnológicos principais:

1. AxiomV1 — Cache blockchain Ethereum, começando com Genesis.
2. AxiomV1Query — Um contrato inteligente que executa consultas no AxiomV1.

Armazenando hashes de bloco em cache no AxiomV1:

Os contratos inteligentes AxiomV1 armazenam em cache os hashes do bloco Ethereum desde o bloco genesis em duas formas:

Primeiro, a raiz Keccak Merkle de 1.024 hashes de bloco consecutivos é armazenada em cache. Essas raízes Merkle são atualizadas por meio de provas ZK, verificando se o hash do cabeçalho do bloco forma uma cadeia de compromisso que termina com um dos 256 blocos mais recentes diretamente acessíveis ao EVM ou um hash de bloco que já existe no cache AxiomV1.

Em segundo lugar, Axiom armazena a Cordilheira Merkle dessas raízes Merkle a partir do bloco de gênese. A Cordilheira Merkle é construída em cadeia, atualizando a primeira parte do cache, a raiz Keccak Merkle.

Execute a consulta em AxiomV1Query:

O contrato inteligente AxiomV1Query é usado para consultas em lote para permitir acesso confiável a cabeçalhos históricos de blocos Ethereum, contas e dados arbitrários armazenados nas contas. As consultas podem ser feitas na cadeia e concluídas na cadeia por meio de provas ZK contra hashes de bloco em cache do AxiomV1.

Essas provas ZK verificam se os dados relevantes na cadeia estão localizados diretamente no cabeçalho do bloco, ou na conta ou tentativa de armazenamento do bloco, verificando a prova de inclusão (ou não inclusão) da tentativa Merkle-Patricia.

Nexo

Nexus tenta usar provas de conhecimento zero para construir uma plataforma universal para computação em nuvem verificável. Atualmente é independente da arquitetura da máquina e suporta risc 5/ WebAssembly/ EVM. Nexus usa o sistema de prova da supernova. A equipe testou que a memória necessária para gerar a prova é de 6 GB. No futuro, ele será otimizado com base nisso, para que computadores de dispositivos clientes comuns possam gerar provas.

Para ser mais preciso, a arquitetura é dividida em duas partes:

1. Nexus zero: uma rede de computação em nuvem descentralizada e verificável, alimentada por provas de conhecimento zero e zkVM universal.
2. Nexus: Uma rede de computação em nuvem descentralizada e verificável alimentada por computação multipartidária, replicação de máquina de estado e uma máquina virtual WASM universal.

Os aplicativos Nexus e Nexus Zero podem ser escritos em linguagens de programação tradicionais, atualmente com suporte para Rust, com mais linguagens por vir.

Os aplicativos Nexus são executados em uma rede descentralizada de computação em nuvem, que é essencialmente um “blockchain sem servidor” de uso geral conectado diretamente ao Ethereum. Portanto, os aplicativos Nexus não herdam a segurança do Ethereum, mas em troca ganham acesso a maior poder de computação (como computação, armazenamento e E/S orientada a eventos) devido ao tamanho reduzido de sua rede. Os aplicativos Nexus são executados em uma nuvem dedicada que alcança consenso interno e fornece “provas” verificáveis de computação (em vez de provas verdadeiras) por meio de assinaturas de limite verificáveis em toda a rede dentro do Ethereum.

Os aplicativos Nexus Zero herdam a segurança do Ethereum, pois são programas universais com provas de conhecimento zero que podem ser verificadas na cadeia na curva elíptica BN-254.

Como o Nexus pode executar qualquer binário WASM determinístico em um ambiente replicado, espera-se que ele seja usado como uma fonte de prova de validade/dispersão/tolerância a falhas para aplicativos gerados, incluindo sequenciadores zk-rollup, sequenciadores rollup otimistas e outros servidores de provas, como o próprio zkVM do Nexus Zero.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [panewslab]. Todos os direitos autorais pertencem ao autor original [ABCDE]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.