1. O que é um co-processador e o que não é?

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

Eu acho que o que o Dr. Dong Mo disse pode estar muito próximo da resposta padrão - para ser franco, o co-processador está "dando ao contrato inteligente a capacidade de fazer Dune Analytics".

Como deconstruir esta frase?

Imagine o cenário em que usamos Dune - você quer 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 APR das taxas de manuseio nos últimos 7 dias e os pares de negociação principais. As faixas de flutuação superiores e inferiores, etc...

Ou talvez, quando o StepN se tornou popular, você começou a especular sobre sapatos e não sabia quando vendê-los, então você encarava 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 planejava vender quando houvesse crescimento. Se a tendência desacelerar ou cair, corra rapidamente.

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

Estes dados são muito significativos - não só podem ajudar a julgar mudanças nas tendências, mas também podem ser usados para criar mais truques, tal como a abordagem de “big data” comummente utilizada por grandes empresas de Internet.

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

Por exemplo, com base no tempo que os usuários mantêm os sapatos Chuangshi, um "Programa de Recompensa de Fidelidade do Usuário" será lançado para oferecer aos usuários leais mais airdrops 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 ou Trader na Uniswap, dando ao Trader redução de taxa de transação ou aumento de participação na taxa do LP.

……

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

Mas no lado Web3, transparência e ausência de confiança são nossa correção política natural, e rejeitamos caixas pretas!

Então, quando você quiser realizar o cenário acima, você enfrentará um dilema - ou você pode alcançá-lo através de meios centralizados, "manualmente" usar Duna para contar os dados de índice em segundo plano e, em seguida, implantá-lo e implementá-lo; ou você pode escrever um Configurar contratos inteligentes para capturar automaticamente esses dados na cadeia, concluir cálculos e implantar pontos automaticamente.

O primeiro pode deixá-lo com problemas de confiança "politicamente incorretos".

A taxa de gás gerada por este último na cadeia será uma cifra astronômica, e sua carteira (lado do projeto) não pode arcar com isso.

Este é o momento do co-processador entrar em cena. Combine os dois métodos agora, e ao mesmo tempo use o passo de "manual em segundo plano" para "auto-provar inocência" por meio de meios técnicos. Em outras palavras, use a tecnologia ZK para "índice +" fora da cadeia. A parte do "cálculo" "auto-prova inocência", e então a alimenta para o contrato inteligente. Dessa forma, o problema de confiança é resolvido, e as enormes taxas de gás desaparecem. Perfeito!

Por que é chamado de "coprocessador"? Na verdade, isso é derivado da "GPU" na história de desenvolvimento do 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 era porque sua arquitetura de design podia lidar com alguns cálculos que eram fundamentalmente difíceis para a CPU lidar, como cálculos repetidos em grande escala paralelamente, cálculos gráficos, etc. É precisamente por causa dessa arquitetura de "coprocessador" que temos filmes de CG maravilhosos, jogos, modelos de IA, etc. hoje, 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 no Web3.0. A blockchain aqui é semelhante à CPU do Web3.0. Seja L1 ou L2, elas são inerentemente inadequadas para tarefas de "dados pesados" e "lógica de cálculo complexa", então um coprocessador de blockchain é introduzido para ajudar a lidar com esses cálculos, expandindo assim enormemente as possibilidades das aplicações de blockchain.

Então, o que o coprocessor faz pode ser resumido em duas coisas:

1. Obtenha os dados do blockchain e prove através de ZK que os dados que obtive são verdadeiros e não adulterados;
2. Faça 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 dos cálculos podem ser chamados pelo smart contract "Baixa Taxa + Sem Confiança".

Algum tempo atrás, a Starkware tinha um conceito popular chamado Storage Proof, também chamado de State Proof. Basicamente faz o passo 1, representado por Herodoto, Langrage, etc. O foco técnico de muitas pontes entre cadeias baseadas na tecnologia ZK também está no passo 1. 1.

O co-processador não é nada mais do que adicionar o passo 2 depois que o passo 1 é concluído. Após extrair os dados sem confiança, ele pode então fazer um cálculo livre de confiança.

Portanto, para usar um termo relativamente técnico para descrevê-lo com precisão, o coprocessador deve ser um superset de Storage Proof/State Proof e um subconjunto de Verifiable Computation.

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

Falando tecnicamente, a prova ZK do Rollup é semelhante à etapa 2 acima, e o processo da etapa 1 'obtenção de dados' é implementado diretamente através do Sequencer. Mesmo um Sequencer descentralizado usa apenas algum tipo de mecanismo de competição ou consenso. Pegue-o em vez de Prova de Armazenamento na forma de ZK. O que é mais importante é que, além da camada de cálculo, o ZK Rollup também precisa implementar uma camada de armazenamento semelhante à blockchain L1. Este armazenamento é permanente, enquanto o Coprocessador ZK é 'sem estado'. Após o cálculo ser concluído, nenhum estado é 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/2, enquanto o Rollup recria uma camada de execução para ajudar a expandir a camada de liquidação.

2. Por que você tem que usar ZK? Está tudo bem usar OP?

Depois de ler o acima, você pode ter uma dúvida, isso tem que ser feito com ZK como um coprocessador? Soa muito como um "Graph com ZK adicionado", e parece que não temos "grandes dúvidas" sobre os resultados no Graph.

Isso ocorre porque quando você usa o Graph, basicamente você não envolve dinheiro real. Esses índices servem para serviços off-chain. O que você vê na interface do usuário do front-end são volume de transações, histórico de transações, etc. Os dados podem ser fornecidos por vários provedores de índices de dados, como Graph, Alchemy, Zettablock, etc., mas esses dados não podem ser inseridos de volta no contrato inteligente, porque uma vez que você os insere, adicionará confiança adicional no serviço de indexação. Quando os dados estão vinculados a dinheiro real, especialmente TVL de grande volume, essa confiança adicional se torna importante. Imagine que da próxima vez que um amigo pedir emprestado 100 yuan, você pode simplesmente emprestar sem piscar os olhos. Sim, e se eu pedir emprestado 10.000 yuan, ou mesmo 1 milhão de yuan?

Mas, por outro lado, será que realmente precisamos usar ZK para coprocessar todos os cenários acima? Afinal, temos duas rotas técnicas, OP e ZK, no Rollup. O ZKML recentemente popular também tem o conceito OPML de rotas de ramificação correspondentes. Pergunta-se, o coprocessador também tem uma ramificação de OP, como OP-Coprocessor?

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

3. Qual é o coprocessador melhor - Comparação de várias soluções de tecnologia de coprocessador comuns no mercado

1. Brevis:

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

A seguir está um diagrama de arquitetura Brevis:

zkFabric: Coleta cabeçalhos de bloco de todas as blockchains conectadas e gera provas de consenso ZK provando a validade desses cabeçalhos de bloco. Através do zkFabric, Brevis implementa um coprocessador interoperável para várias cadeias, que permite que uma blockchain acesse quaisquer dados históricos de outra blockchain.

zkQueryNet: Um mercado de mecanismo de consulta ZK aberto que aceita consultas de dados de dApps e as processa. 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 às diferentes necessidades de aplicativos.

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

ZK Fabric é uma parte chave na geração de prova para o cabeçalho do bloco. É muito importante garantir a segurança desta parte. O seguinte é o diagrama de arquitetura do zkFabric:

O cliente leve baseado em Prova de Conhecimento Zero (ZKP) do zkFabric torna-o completamente livre de confiança sem depender de qualquer entidade de verificação externa. Não há necessidade de depender de qualquer entidade de verificação externa, pois sua segurança vem inteiramente da blockchain subjacente e de provas matematicamente confiáveis.

A rede zkFabric Prover implementa circuitos para o protocolo lightclient de cada 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 baseia-se nas suposições de segurança da blockchain e do protocolo de criptografia subjacente e nas suposições de segurança do protocolo de criptografia subjacente. No entanto, para garantir a eficácia do zkFabric, é necessário pelo menos um relayer honesto para sincronizar o fork correto. Portanto, o zkFabric adota uma rede de relé descentralizada em vez de um único relé para otimizar a eficácia do zkFabric. Essa rede de relé pode alavancar estruturas existentes, como a rede de guarda de estado na rede Celer.

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

Implantação atual:

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

Brevis atualmente cooperou com uniswap hook, o que adiciona consideravelmente pools uniswap personalizadas. No entanto, em comparação com CEX, Uniswap ainda carece de capacidades eficazes de processamento de dados para criar projetos que dependem de grandes dados de transações de usuários (como programas de fidelidade baseados no volume de transações). Função.

Com a ajuda da Brevis, o hook resolveu o desafio. Agora, os hooks podem ler os dados completos do histórico da cadeia de um usuário ou LP e executar cálculos personalizáveis de forma totalmente confiável.

1. Heródoto

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

Estados L1 dos L2s

Estados L2 tanto de L1s quanto de outros L2s

Estados da L3/App-Chain para L2s e L1s

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

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

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

Em segundo lugar, essas árvores permitem uma verificação eficiente de dados por meio de provas de inclusão. Por exemplo, ao verificar a inclusão de uma transação ou o estado de um contrato, não é necessário pesquisar toda a blockchain do Ethereum, mas apenas o caminho dentro da árvore de Merkle relevante.

Prova de armazenamento, conforme definido por Heródoto, é uma fusão de:

• Provas de contenção: Essas provas confirmam a existência de dados específicos em uma estrutura de dados criptográficos (como uma árvore de Merkle ou árvore de Merkle Patricia), garantindo que os dados em questão estejam realmente presentes no conjunto de dados.
• Prova computacional: Verificar a execução de um fluxo de trabalho multi-etapa, comprovando a validade de um ou mais elementos em um conjunto amplo de dados, como o blockchain inteiro do Ethereum ou um agregado. Além de indicar a presença de dados, eles também verificam transformações ou operações aplicadas a esses dados.
• Provas de conhecimento zero: Simplificar a quantidade de dados com a qual os contratos inteligentes precisam interagir. As provas de conhecimento zero permitem que os contratos inteligentes confirmem a validade de uma alegação sem processar todos os dados subjacentes.

Fluxo de trabalho :

1. Obter hash de bloco

Todos os dados na blockchain pertencem a um bloco específico. O hash do bloco serve como o identificador único 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 contendo os dados nos quais estamos interessados. Este é o primeiro passo em todo o processo.

1. Obter cabeçalho de bloco

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

Existem duas maneiras de obter o hash:

(1) Use BLOCKHASH opcode to retrieve

(2) Consulte os hashes dos blocos que foram verificados na história a partir do Acumulador de Hash de Bloco

Este passo garante que o cabeçalho do bloco em processamento é autêntico. Uma vez concluída esta etapa, o contrato inteligente pode acessar qualquer valor no cabeçalho do bloco.

1. Determinar as raízes necessárias (opcional)

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

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

receiptsRoot: Digesto criptografado de todos os resultados de transações (recibos) no bloco.

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

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

1. Validar dados contra raiz selecionada (opcional)

Com a raiz que selecionamos, e considerando que o Ethereum usa uma estrutura de árvore Merkle-Patricia Trie, podemos usar a prova de inclusão de Merkle para verificar que 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:

Do Ethereum para Starknet

Do Ethereum Goerlipara Starknet Goerli

Do Ethereum Goerlipara zkSync Era Goerli

1. Axioma

Axiom fornece uma maneira para os desenvolvedores consultarem cabeçalhos de blocos, valores de contas ou armazenamento de toda a história do Ethereum. AXIOM introduz um novo método de ligação baseado em criptografia. Todos os resultados retornados pelo Axiom são verificados on-chain através de provas de conhecimento zero, o que significa que contratos inteligentes podem usá-los sem suposições adicionais de confiança.

Axiom recentemente lançadoHalo2-repl , é um REPL halo2 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 principais de tecnologia:

AxiomV1 — cache de blockchain Ethereum, começando com Genesis.

AxiomV1Query - Contrato inteligente que executa consultas contra AxiomV1.

(1) Valor do hash de bloco de cache em AxiomV1:

O contrato inteligente AxiomV1 armazena em cache hashes de blocos do Ethereum desde o bloco de gênese em duas formas:

Primeiro, a raiz de Merkle Keccak de 1024 hashes de bloco consecutivos é armazenada em cache. Essas raízes de Merkle são atualizadas via provas de conhecimento zero, verificando que o hash do cabeçalho do bloco forma uma cadeia de compromisso terminando 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. A Axiom armazena a Cadeia de Montanha de Merkle dessas raízes de Merkle a partir do bloco genesis. A Cadeia de Montanha de Merkle é construída on-chain atualizando a primeira parte do cache, a raiz de Merkle Keccak.

(2) Execute a consulta em AxiomV1Query:

O contrato inteligente AxiomV1Query é usado para consultas em lote para permitir acesso sem confiança aos cabeçalhos de bloco históricos do Ethereum, contas e dados arbitrários armazenados nas contas. As consultas podem ser feitas on-chain e são concluídas on-chain via provas ZK contra hashes de bloco em cache do AxiomV1.

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

1. Nexus

Nexus tenta construir uma plataforma comum para computação em nuvem verificável usando provas de conhecimento zero. Atualmente, é agnóstico em relação à arquitetura de máquinas e suporta risc 5/ WebAssembly/ EVM. Nexus usa o sistema de provas da supernova. A equipe testou que a memória necessária para gerar a prova é de 6GB. No futuro, será otimizado com base nisso para que dispositivos e computadores comuns do lado do usuário possam gerar provas.

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

Nexus zero: Uma rede de computação em nuvem descentralizada e verificável alimentada por provas de conhecimento zero e zkVM universal.

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

As aplicações Nexus e Nexus Zero podem ser escritas em linguagens de programação tradicionais, atualmente com suporte para Rust, e mais linguagens serão adicionadas no futuro.

As aplicações Nexus são executadas em uma rede de computação em nuvem descentralizada, que é essencialmente uma “blockchain sem servidor” de propósito geral conectada diretamente ao Ethereum. Portanto, as aplicações Nexus não herdam a segurança do Ethereum, mas em troca ganham acesso a uma maior potência de computação (como computação, armazenamento e E/S orientado a eventos) devido ao tamanho reduzido de sua rede. As aplicações Nexus são executadas em uma nuvem privada que alcança consenso interno e fornece “provas” verificáveis de computação (não são provas reais) por meio de assinaturas de limite verificáveis em toda a rede dentro do Ethereum.

As aplicações Nexus Zero herdam a segurança do Ethereum, pois são programas universais com provas de conhecimento zero que podem ser verificados na cadeia de blocos na curva elíptica BN-254.

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

Aviso Legal:

1. Este artigo é reproduzido a partir de [Médio]. Todos os direitos autorais pertencem ao autor original [ABCDE]. Se houver objeções a esse reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As 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.