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

Se lhe pedissem para explicar coprocessadores a alguém não técnico ou programador em apenas uma frase, como descreveria?

Penso que o que o Dr. Dong Mo disse pode estar muito perto da resposta padrão - para ser franco, o co-processador está a dar à smart contract 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 superior e inferior, etc...

Ou talvez quando o StepN se tornou popular, começaste a especular sobre sapatos, e não tinhas a certeza de quando os vender, então ficaste a olhar para os dados do StepN no Dune todos os dias, o volume diário de transações, o número de novos utilizadores, o preço base dos sapatos... e planeaste vender uma vez que houvesse crescimento. Se a tendência abrandar ou descer, foge rapidamente.

Claro que você pode não estar apenas 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 as mudanças nas tendências, mas também utilizá-los para criar mais truques, tal como a abordagem de “big data” comummente utilizada pelas principais empresas da Internet.

Por exemplo, com base no estilo e preço dos sapatos que os utilizadores compram e vendem frequentemente, são recomendados sapatos semelhantes.

Por exemplo, com base no tempo que os utilizadores mantêm os sapatos Chuangshi, será lançado um 'Programa de Recompensas de Fidelidade do Utilizador' para oferecer aos utilizadores fiéis mais airdrops ou benefícios.

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

……

Neste momento, surge o problema - quando as principais empresas de Internet brincam com big data + IA, é basicamente uma caixa preta. Podem fazer o que quiserem. Os utilizadores não conseguem ver nem se importam.

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

Portanto, quando quiser realizar o cenário acima, enfrentará um dilema - ou pode alcançá-lo através de meios centralizados, usar “manualmente” o Dune para contar os dados do índice em segundo plano e depois implementá-lo; ou pode escrever contratos inteligentes para capturar automaticamente esses dados na cadeia, completar cálculos e implantar pontos automaticamente.

O primeiro pode deixar você com problemas de confiança "politicamente incorretos".

A taxa de gás gerada por este último na cadeia será uma figura astronómica, e a sua carteira (lado do projeto) não pode suportá-la.

Este é o momento para o 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" através de meios técnicos. Em outras palavras, use a tecnologia ZK para "indexar +" fora da cadeia. A parte de "cálculo" "auto-prova inocência" e, em seguida, alimenta 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 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 naquele tempo era porque sua arquitetura de design conseguia 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 hoje filmes de CG maravilhosos, 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 no Web3.0. A blockchain aqui é semelhante à CPU do Web3.0. Seja L1 ou L2, elas são inerentemente inadequadas para tarefas como “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.

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

1. Obtenha os dados da 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 contrato inteligente "Taxa Baixa + Sem Confiança".

Algum tempo atrás, a Starkware tinha um conceito popular chamado Prova de Armazenamento, também chamado de Prova de Estado. Basicamente, ele faz o passo 1, representado por Herodotus, Langrage, etc. O foco técnico de muitas pontes entre blockchains 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 de o passo 1 ser concluído. Após extrair os dados sem confiança, pode então fazer um cálculo sem 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.

Tecnicamente falando, a prova ZK da Rollup é semelhante ao passo 2 acima, e o processo do passo 1 'obter dados' é implementado diretamente através do Sequencer. Mesmo um Sequencer descentralizado usa apenas algum tipo de mecanismo de competição ou consenso. Tome-o em vez da Prova de Armazenamento sob a 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 à blockchain L1. Este armazenamento é permanente, enquanto o ZK Coprocessor é '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, pode ter dúvidas, será que tem de ser feito com ZK como coprocessador? Parece muito um “Gráfico com ZK adicionado”, e não parecemos ter quaisquer “grandes dúvidas” sobre os resultados no Gráfico.

Isso acontece porque quando você usa o Graph, basicamente você não envolve dinheiro real. Estes índices servem para serviços off-chain. O que você vê na interface do usuário front-end são o volume de transações, o 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 estes dados não podem ser inseridos de volta no contrato inteligente, porque uma vez que você os insira de volta, você adicionará confiança adicional no serviço de indexação. Quando os dados estão vinculados ao dinheiro real, especialmente em TVL de grande volume, esta confiança adicional se torna importante. Imagine que da próxima vez que um amigo lhe pedir emprestado 100 yuan, você pode simplesmente emprestar sem pestanejar. Sim, e se eu lhe pedir emprestado 10.000 yuan, ou mesmo 1 milhão de yuan?

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

Na verdade, há - mas estamos a manter os detalhes específicos confidenciais por agora e iremos divulgar mais informações detalhadas em breve.

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

1. Brevis:

A arquitetura da Brevis é composta por três componentes: zkFabric, zkQueryNet e zkAggregatorRollup.

O seguinte é um diagrama de arquitetura Brevis:

zkFabric: Recolhe 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, a Brevis implementa um coprocessador interoperável para várias cadeias, o que permite que uma blockchain acesse quaisquer dados históricos de outra blockchain.

zkQueryNet: Um mercado de mecanismos de consulta ZK aberto 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 às diferentes necessidades de aplicação.

zkAggregatorRollup: Um blockchain convolucional ZK que atua como a camada de agregação e armazenamento para zkFabric e zkQueryNet. Verifica provas de ambos os componentes, armazena os dados verificados e compromete a raiz do estado zk-validada a todas as blockchains conectadas.

ZK Fabric é uma parte fundamental 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 é necessário depender de qualquer entidade de verificação externa, pois a sua segurança advém inteiramente da blockchain subjacente e de provas matematicamente fiá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.

O 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és descentralizada em vez de um único relé para otimizar a eficácia do zkFabric. Esta rede de relés pode tirar partido de estruturas existentes, como a rede de guardas de estado na rede Celer.

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

Implementação atual:

Os protocolos de cliente leve 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, que adiciona significativamente pools uniswap personalizados. No entanto, em comparação com CEX, UnisWap ainda carece de capacidades eficazes de processamento de dados para criar projetos que dependem de grandes volumes de transações de usuários (como programas de fidelidade baseados no volume de transações). Função.

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

1. Heródoto

Heródoto é um middleware poderoso 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:

Estados L1 dos L2s

Estados L2 tanto de L1s como de outros L2s

Estados da Cadeia de Aplicações 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 todo o blockchain do Ethereum ou um rollup) ou a validade de vários elementos.

O núcleo da blockchain é a base de dados, na qual os dados são encriptados e protegidos utilizando estruturas de dados como árvores de Merkle e árvores de Merkle Patricia. O que é único sobre estas estruturas de dados é que uma vez que os dados são seguramente comprometidos com elas, pode ser gerada evidência para confirmar que os dados estão contidos na estrutura.

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

Em segundo lugar, estas árvores permitem uma verificação eficiente de 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 é necessário pesquisar toda a blockchain Ethereum, mas apenas o caminho dentro da árvore de Merkle relevante.

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

• Provas de contenção: Estas provas confirmam a existência de dados específicos numa estrutura de dados criptográfica (como uma árvore de Merkle ou árvore de Merkle Patricia), garantindo que os dados em questão estão de facto presentes no conjunto de dados.
• Prova Computacional: Verificar a execução de um fluxo de trabalho com várias etapas, provando a validade de um ou mais elementos em um conjunto de dados amplo, como o blockchain completo 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 reivindicação sem processar todos os dados subjacentes.

Fluxo de trabalho:

1. Obter hash do bloco

Cada dado na blockchain pertence a um bloco específico. O hash do bloco serve como o identificador único do bloco e resume todo o seu conteúdo através 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 nos quais estamos interessados. Este é o primeiro passo em todo o processo.

1. Obter cabeçalho de bloco

Uma vez obtido o hash do bloco relevante, o próximo passo é aceder ao cabeçalho do bloco. Para tal, o cabeçalho do bloco associado ao hash do bloco obtido no passo anterior precisa de ser hash. O hash do cabeçalho do bloco fornecido é então comparado com o hash do bloco resultante:

Existem duas maneiras de obter o hash:

(1) Utilize o opcode BLOCKHASH para recuperar

(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ído este passo, o contrato inteligente pode aceder a 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 aprofundar-nos no seu conteúdo, especificamente:

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

receiptsRoot: Digesto encriptado 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 a verificação se uma conta específica, recibo ou transação está incluída no bloco.

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

Com a raiz que selecionamos, e considerando que o Ethereum usa uma estrutura de Árvore Merkle-Patricia, podemos usar a prova de inclusão de Merkle para verificar que os dados existem na árvore. Os passos de verificação variarão dependendo dos dados e da profundidade dos dados dentro do bloco.

Redes atualmente suportadas:

De Ethereum para Starknet

Do Ethereum Goerlipara Starknet Goerli

Do Ethereum Goerlipara zkSync Era Goerli

1. Axioma

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

Axiom lançou recentementeHalo2-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 é composto por dois componentes de tecnologia principais:

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

AxiomV1Query — Contrato inteligente que executa consultas contra AxiomV1.

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

O contrato inteligente AxiomV1 armazena em cache os hashes de bloco 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. Estas raízes de Merkle são atualizadas via provas ZK, 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 à EVM ou um hash de bloco que já existe na cache AxiomV1.

Em segundo lugar. A Axiom armazena a Merkle Mountain Range dessas raízes de Merkle a partir do bloco genesis. A Merkle Mountain Range é construída on-chain atualizando a primeira parte do cache, a raiz de Merkle Keccak.

(2) Executar a consulta em AxiomV1Query:

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

Estas provas 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

O 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 da máquina e suporta risc 5/ WebAssembly/ EVM. O Nexus usa o sistema de prova 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 está dividida em duas partes:

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

Nexus: Uma rede descentralizada de computação em nuvem 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 suportando Rust, com mais linguagens a caminho.

Os aplicativos Nexus são executados em uma rede de computação em nuvem descentralizada, 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 privada que alcança consenso interno e fornece "provas" verificáveis de computação (não provas verdadeiras) 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, uma vez que são programas universais com provas de conhecimento zero que podem ser verificados on-chain na curva elíptica BN-254.

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

Aviso legal:

1. Este artigo foi reproduzido a partir de [Médio]. Todos os direitos autorais pertencem ao autor original [ABCDE]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.