Novos casos de uso ZK, discussão aprofundada de coprocessadores e várias soluções

À 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á relativamente familiarizada com o conceito de coprocessadores, especialmente o posicionamento preciso dos coprocessadores - o que é um coprocessador e o que não é, ainda é relativamente vago. Quanto à comparação das soluções técnicas de várias faixas de coprocessadores no mercado, ainda ninguém resolveu-se sistematicamente. Este artigo espera dar ao mercado e aos utilizadores uma compreensão mais clara da faixa do coprocessador.

1. O que é o Co-Processador e o que não é?

Se lhe pedissem que explicasse os coprocessadores a um não técnico ou a um programador numa única frase, como o descreveria?

Acho que o que o Dr. Dong Mo disse pode estar muito próximo da resposta padrão — para ser francamente, um coprocessador é “dar aos contratos inteligentes a capacidade de executar o Dune Analytics”.

Como desconstruir esta frase?

Imagine o cenário em que usamos o Dune - Quer fazer LP no Uniswap V3 para ganhar algumas taxas de manuseio, então 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 manipulação nos últimos 7 dias e os pares de negociação mainstream Os intervalos de flutuação superior e inferior, etc...

Ou talvez quando o StepN se tornou popular, começou a especular sobre sapatos e não tinha a certeza de quando vendê-los, então olhava para os dados StepN no Dune todos os dias, o volume diário de transações, o número de novos utilizadores, o preço baixo dos sapatos... e planeava assim que houvesse crescimento. Se a tendência abrandar ou descer, corra rapidamente.

Claro, pode não estar apenas a olhar para estes dados, mas as equipas de desenvolvimento da Uniswap e da StePN também estão a prestar atenção a esses dados.

Estes dados são muito significativos - podem não só ajudar a julgar as mudanças nas tendências, mas também usá-los para criar mais truques, tal como a abordagem de “big data” comumente usada pelas grandes empresas de Internet.

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

Por exemplo, será lançado um “Programa de Recompensas de Fidelidade do Utilizador” com base no período de tempo que os utilizadores têm Creation Shoes para dar aos utilizadores leais mais airdrops ou benefícios.

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

Neste momento, surge o problema - o big data + IA das grandes empresas de Internet é basicamente uma caixa preta. Podem fazer o que quiserem. Os utilizadores não conseguem 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 negras!

Então, quando quiser perceber 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á-los e implementá-los; ou pode escrever um Configure contratos inteligentes para capturar automaticamente esses dados na cadeia, concluir cálculos e implantar pontos automaticamente.

O primeiro vai levá-lo 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 a sua carteira (do lado do projeto) não pode pagar.

Este é o momento do co-processador subir ao palco. Combine os dois métodos agora e, ao mesmo tempo, use o passo “manual de back-end” para “autocertificar a inocência” através de meios técnicos. Por outras palavras, use a tecnologia ZK para “indexar + A parte do “cálculo” “prova a inocência” e, em seguida, alimenta-a ao contrato inteligente. Desta forma, o problema da confiança está resolvido e as enormes taxas de gás desapareceram. Perfeito!

Porque é que se chama “coprocessador”? Na verdade, isso vem da “GPU” no histórico de 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 altura foi porque a sua arquitetura de design podia lidar com alguns cálculos que eram fundamentalmente difíceis para a CPU manipular, tais como cálculos repetidos paralelos em grande escala, cálculos gráficos, etc. É precisamente por causa desta arquitetura de “co-processador” que temos filmes CG maravilhosos, jogos, modelos de IA, etc. hoje em dia, então esta arquitetura de coprocessador é na verdade um salto na arquitetura de computação. Agora, várias equipas de co-processadores também esperam introduzir esta arquitectura na Web3.0. A cadeia de blocos aqui é semelhante à CPU da Web3.0. Quer se trate de L1 ou L2, são inerentemente inadequados para tais tarefas de “dados pesados” e “Lógica de cálculo complexa”, pelo que é introduzido um coprocessador blockchain para ajudar a lidar com esses cálculos, expandindo assim grandemente as possibilidades das aplicações blockchain.

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

1. Obtenha os dados da blockchain e use o 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 receber e, mais uma vez, use o 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, o Starkware tinha um conceito popular chamado Storage Proof, também chamado State Proof. Basicamente faz 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á no passo 1. 1 em.

O coprocessador nada mais é do que o passo 1 seguido do passo 2. Depois de extrair os dados sem confiança, faça um cálculo sem confiança e é isso.

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

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

Tecnicamente falando, a prova ZK do Rollup é semelhante ao passo 2 acima, e o processo do passo 1 “obtenção de dados” é implementado diretamente através do Sequencer. Mesmo um Sequenciador descentralizado só usa algum tipo de competição ou mecanismo de consenso para conseguir isso. Tome, em vez de Prova de Armazenamento, esta 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 ZK Coprocessor é “sem estado”. Depois que o cálculo estiver concluído, não o status Todos é mantido.

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

2. Porque é que tenho de usar o ZK? Não há problema em usar OP?

Depois de ler o acima, pode ter uma dúvida, o ZK deve ser usado como coprocessador? Soa tanto como um “Gráfico com ZK adicionado”, e parece que não temos “grandes dúvidas” sobre os resultados do Gráfico.

Isso porque quando usa o Graph, o dinheiro real basicamente não está envolvido. Estes índices servem serviços fora da cadeia. O que vê na interface do utilizador front-end é o volume de transações, o histórico de transações, etc. Os dados podem ser fornecidos através de vários fornecedores de índice de dados, como Graph, Alchemy, Zettablock, etc., mas esses dados não podem ser armazenados de volta no contrato inteligente, porque depois de colocá-los de volta, irá 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, pode emprestá-lo sem piscar os olhos. Sim, e quando peço emprestado 10.000 yuans, ou mesmo 1 milhão de yuans?

Mas, novamente, temos mesmo de usar o ZK para co-processar todos os cenários acima? Afinal, temos duas rotas técnicas, OP e ZK, no Rollup. O recentemente popular ZKML também tem o conceito OPML de rotas de sucursais correspondentes. Perguntado, o coprocessador também tem uma filial do OP, tal como o OP-coprocessador?

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

3. Qual coprocessador é o melhor? Comparação de várias soluções técnicas de coprocessadores comuns no mercado

Breve

A arquitetura do Brevis consiste em três componentes: zkFabric, ZkQueryNet e ZKAggregatorRollup.

O seguinte é um diagrama de arquitetura Brevis:

ZKFabric: Recolhe cabeçalhos de bloco de todos os blockchains conectados e gera provas de consenso ZK que comprovam 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 cadeia de blocos aceda a quaisquer dados históricos de outra blockchain.

ZKQueryNet: Um mercado aberto de motores de consulta ZK que aceita consultas de dados de DApps e processa-as. As consultas de dados processam essas consultas usando cabeçalhos de bloco verificados do ZKFabric e geram provas de consulta ZK. Estes motores têm funções altamente especializadas e linguagens de consulta gerais para satisfazer diferentes necessidades de aplicação.

zkAggregatorRollup: Um blockchain convolucional ZK que atua como uma camada de agregação e armazenamento para ZKFabric e ZKQueryNet. Verifica provas de ambos os componentes, armazena os dados verificados e confirma a sua raiz de estado validada zk em todas as blockchains ligadas.

O ZK Fabric é uma parte fundamental da geração de provas 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 na prova de conhecimento zero (ZKP) do ZKFabric torna-o completamente sem confiança, sem depender de nenhuma entidade de verificação externa. Não há necessidade de depender de nenhuma entidade de verificação externa, uma vez que a sua segurança vem inteiramente da cadeia de blocos subjacente e 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 alavancar aceleradores como GPUs, FPGAs e ASICs para minimizar o tempo e o custo da prova.

O ZKFabric baseia-se nos pressupostos de segurança da cadeia de blocos e nos protocolos criptográficos subjacentes e nos pressupostos de segurança dos protocolos criptográficos subjacentes. No entanto, para garantir a eficácia do ZKFabric, é necessário pelo menos um relayer honesto para sincronizar o garfo correto. Portanto, o ZKFabric utiliza uma rede de retransmissão descentralizada em vez de um único relé para otimizar a eficácia do ZKFabric. Esta rede de relés pode alavancar estruturas existentes, como a rede de guarda estatal na rede Celer.

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

Implantação atual:

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

Brevis cooperou atualmente 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 utilizadores (tais como programas de fidelidade com base no volume de transações). Função.

Com a ajuda de Brevis, o Hook resolveu o desafio. Os ganchos podem agora ler os dados da cadeia de histórico completo de um utilizador ou LP e executar cálculos personalizáveis de uma forma completamente sem confiança.

Heródoto

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

1. Estados L1 de L2s
2. Estados L2 de ambos os L1s e outros L2s
3. L3/App-Chain estados 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 (verificação da execução do fluxo de trabalho em várias etapas) para provar que um grande conjunto de dados (como todo o blockchain ou rollup Ethereum) ou a validade de vários elementos.

O núcleo da cadeia de blocos é a base de dados, na qual os dados são encriptados e protegidos usando estruturas de dados como árvores Merkle e árvores Merkle Patricia. O que é único nestas estruturas de dados é que, uma vez que os dados são confiados com segurança, podem ser geradas provas para confirmar que os dados estão contidos na estrutura.

O uso de árvores Merkle e árvores Merkle Patricia aumenta a segurança da cadeia de blocos Ethereum. Ao fazer o hash criptográfico dos dados em cada nível da árvore, é quase impossível alterar os dados sem deteção. Quaisquer alterações num ponto de dados requerem a alteração do hash correspondente na árvore para o hash raiz, que é visível publicamente no cabeçalho da cadeia de blocos. Esta característica fundamental da blockchain fornece 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 há necessidade de pesquisar toda a cadeia de blocos Ethereum mas apenas o caminho dentro da árvore Merkle relevante.

A prova de armazenamento, conforme definido 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 uma árvore Merkle Patricia), garantindo que os dados em questão estão realmente 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 num amplo conjunto de dados, como toda a cadeia de blocos Ethereum ou um agregado. Além de indicarem a presença de dados, verificam também as 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 os contratos inteligentes confirmem a validade de uma reclamação sem processar todos os dados subjacentes.

Fluxo de trabalho

1.Obter hash de bloco

Todos os dados na cadeia de blocos pertencem 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 de todo o processo.

2.Obter cabeçalho de bloco

Assim que o hash do bloco relevante for obtido, o próximo passo é aceder ao 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 de bloco fornecido é então comparado com o hash de bloco resultante:

Existem duas maneiras de obter o hash:

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

Esta etapa garante que o cabeçalho do bloco a ser processado é autêntico. Uma vez concluída esta etapa, o contrato inteligente pode aceder a 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 aprofundar o seu conteúdo, especificamente:

Stateroot: Uma análise criptográfica de todo o estado da cadeia de blocos no momento em que o blockchain ocorreu.

ReceiptsRoot: Digestão encriptada de todos os resultados da transação (recibos) no bloco.

TransactionsRoot: Um conjunto 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 seleccionada (opcional)

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

Redes atualmente suportadas:

1. Do Ethereum ao Starknet
2. Do Ethereum Goerli ao Starknet Goerli
3. Do Ethereum Goerli ao ZKSync Era Goerli

Axioma

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

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

O axiom consiste em dois componentes tecnológicos principais:

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

Caching de hashes de bloco no AxiomV1:

Os contratos inteligentes AxiomV1 armazenam hashes de bloco Ethereum desde o bloco de génese em duas formas:

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

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

Execute a consulta no AxiomV1Query:

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

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

Nexus

A Nexus tenta usar provas de conhecimento zero para construir uma plataforma universal para computação em nuvem verificável. Atualmente é agnóstico de arquetectura de máquina e suporta risc 5/ WebAssembly/ EVM. O Nexus utiliza o sistema de prova da supernova. A equipa testou que a memória necessária para gerar a prova é de 6 GB. No futuro, será otimizado nesta base para que os computadores comuns dos dispositivos clientes possam gerar provas.

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

1. Nexus zero: Uma rede de computação em nuvem verificável descentralizada alimentada por provas de conhecimento zero e zKVM universal.
2. Nexus: Uma rede de computação em nuvem verificável descentralizada 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 o Rust, com mais linguagens por vir.

As aplicações Nexus são executadas numa rede de computação em nuvem descentralizada, que é essencialmente uma “blockchain sem servidor” de propósito geral ligada diretamente ao Ethereum. Portanto, as aplicações Nexus não herdam a segurança do Ethereum, mas em troca ganham acesso a um maior poder de computação (como computação, armazenamento e E/S orientada a eventos) devido ao tamanho reduzido da sua rede. As aplicações Nexus são executadas numa nuvem dedicada que alcança consenso interno e fornece “provas” verificáveis de computação (em vez de provas verdadeiras) através de assinaturas de limiar 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 verificadas na cadeia 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 valididade/dispersão/tolerância a falhas para aplicações geradas, incluindo sequenciadores zk-rollup, sequenciadores otimistas de rollup e outras provas Server, como o próprio zKVM do Nexus Zero.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [panewslab]. Todos os direitos de autor pertencem ao autor original [ABCDE]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.