Desmontando as vantagens técnicas do coprocessador Ethereum ZK Axiom

Autor: Rede Máscara

Na cúpula ETHShanghai 2023, o fundador da Axiom, Yi Sun, apresentou o coprocessador ZK da Ethereum, Axiom, e sua importância em termos de acesso a dados e poder de computação. O Axiom realiza a expansão do acesso e cálculo de dados por meio do conceito de operação Reflection e realiza a validade da consulta verificando a cadeia de hash e mantendo o cache. Os aplicativos para Axiom incluem aplicativos de alto custo, maior acesso a dados, aplicativos baseados em protocolos de gerenciamento de dados históricos e muito mais. Por meio da Axiom, os contratos inteligentes podem obter dados e poder de computação mais amplos, promovendo ainda mais o desenvolvimento de aplicativos Ethereum.

O texto a seguir é a versão compilada em chinês do discurso de Yi Sun e o link é o vídeo ao vivo:

Primeiro, vamos entender a jornada do usuário para realmente acessar as informações do Ethereum. Quando estávamos usando o Ethereum pela primeira vez, a maneira como realmente recebíamos informações sobre o que estava acontecendo na cadeia era por meio de chamadas JSON-RPC para arquivar anotações. O objetivo da API JSON-RPC é realmente apresentar informações sobre o histórico on-chain ao usuário. Essencialmente, todas as informações que vemos sobre o blockchain são extraídas dessas chamadas de API e apresentadas como uma entrada no site para o usuário ler.

Agora, à medida que os usuários se tornam mais hábeis em interagir com o blockchain, estamos começando a exigir visualizações cada vez mais complexas da cadeia. Portanto, diferentes tipos de nós de arquivo estão sendo desenvolvidos para diferentes compensações do usuário. Então havia Geth, Erigon, Nethermind e agora Reth. Podemos escolher o nó de arquivo mais adequado de acordo com nossas próprias necessidades.

Se os usuários não estiverem satisfeitos com uma API JSON-RPC separada, um indexador pode ser escolhido para aplicar o pós-processamento durante o rastreamento das transações. Para diferentes aplicações, os usuários podem estar interessados em dados retornados de The Graph ou Covalent.

Mais recentemente, também surgiram carteiras e outros produtos que oferecem simulação de transações em nós de arquivo. Isso significa que podemos ver o resultado real de uma transação virtual antes de confirmá-la. Em geral, a forma como interagimos com o Ethereum como usuários finais está ficando mais sofisticada, usando mais computação sobre os dados que lemos.

Agora, se pensarmos nisso não da perspectiva de um usuário, mas da perspectiva de um contrato inteligente no Ethereum. Obviamente, os contratos também desejam acessar dados e realizar cálculos neles, mas isso é mais desafiador. De fato, se formos ao OpenSea e olharmos a lista de CryptoPunk, veremos que de todas as informações da página, apenas uma pequena parte é acessível no contrato inteligente da cadeia.

Na verdade, para as listagens do CryptoPunk, essas informações são apenas para os detentores atuais. Claro, há muitas outras informações na página, mas todas as informações relacionadas a informações históricas de transferência, preços históricos e detentores históricos são realmente inacessíveis ao contrato inteligente porque pertencem ao histórico passado. Esses históricos constituem informações on-chain, mas não estão disponíveis para contratos inteligentes porque precisamos evitar forçar cada nó Ethereum completo a manter essas informações em seu acesso aleatório para verificar transações.

Além disso, como qualquer desenvolvedor de blockchain pode dizer, a execução de cálculos na cadeia é proibitivamente cara, embora o Ethereum tenha operações de máquina virtual (VM) relativamente eficientes e a pré-compilação torne certos tipos de operações mais baratos. Por exemplo, o Ethereum fornece suporte relativamente barato para operações de curva elíptica na curva BN254. No entanto, para algumas aplicações específicas, a Ethereum Virtual Machine ainda é um ambiente de tempo de execução muito caro. Ao projetar uma máquina virtual blockchain, deve-se escolher um conjunto inerente de operações que precisam ser cuidadosamente medidas para garantir que cada nó possa verificar as transações em um momento consistente. Além disso, a segurança de pior caso e a estabilidade de consenso também devem ser consideradas. Portanto, o desafio aqui é como implementar o dimensionamento específico do aplicativo para aplicativos on-chain. A Axiom visa expandir o acesso a dados e os recursos de computação para contratos inteligentes para atender às necessidades de expansão de diferentes aplicativos.

O que a Axiom está construindo é o que chama de Ethereum Coprocessor (ZK Coprocessor), que permite que certos contratos inteligentes deleguem sem confiança ao nosso sistema off-chain para que possam delegar leituras de dados e cálculos verificáveis para a Axiom. Para emitir uma consulta à Axiom, um contrato inteligente pode enviar uma transação para nosso sistema on-chain. Nosso nó off-line receberá a transação e gerará um resultado com base na consulta histórica do Ethereum e anexará uma prova de conhecimento zero para provar a exatidão do resultado. Por fim, verificamos os resultados na cadeia e entregamos os resultados com credibilidade aos contratos inteligentes downstream.

Isso é semelhante a como a CPU em um computador delega a computação à GPU e recupera os resultados quando eles são conhecidos. Esse conceito foi chamado de coprocessador (Coprocesso) nos primeiros dias. No slide, mostro uma imagem de um coprocesso de matemática avançada do início dos anos 1990 que é análogo ao que o Axiom faz.

Podemos obter informações sobre quais tipos de operações o Axiom pode executar. Cada consulta ao Axiom pode ser dividida em três partes.

A primeira é a parte de leitura, que é como as consultas do Axiom são inseridas - podemos ler com segurança os dados históricos na cadeia.

A segunda parte é que podemos executar cálculos de validação nesses dados. Isso pode começar com uma análise básica, como somar alguns números, encontrar o máximo ou o mínimo, até cálculos mais complexos. Por exemplo, alguma agregação de assinatura ou verificação de criptografia e até aprendizado de máquina baseado em conhecimento zero, como verificar a operação de determinados algoritmos de reputação em dados sociais na cadeia ou usar determinados algoritmos de aprendizado de máquina em aplicativos financeiros. Por fim, forneceremos funções compostas de computação programáveis por meio de máquinas virtuais.

A última parte, após as etapas de leitura e cálculo, obtemos um resultado e sempre associamos esse resultado a uma prova de conhecimento zero de que o cálculo do resultado foi válido. Portanto, verificamos essa prova no contrato inteligente Ethereum e, em seguida, armazenamos o resultado para uso pelo contrato.

Como todos os resultados retornados pelo Axiom são realmente verificados com provas de conhecimento zero, isso significa que a segurança de tudo retornado pelo Axiom é criptograficamente equivalente à do próprio Ethereum. A filosofia da Axiom é que não queremos impor nenhuma suposição adicional aos usuários além das suposições criptográficas que eles já têm usando o Ethereum.

A seguir, apresentarei em detalhes o seu princípio de implementação, que envolve o conceito de operação de Reflexão mencionado no título do discurso. O princípio fundamental que torna tudo isso possível é que cada bloco na blockchain contém um histórico completo. Podemos começar no bloco Ethereum atual e voltar aos blocos anteriores nos quais estamos interessados. Tomando todos os cabeçalhos de bloco entre o bloco passado e o bloco atual e verificando a cadeia de hash desses cabeçalhos de bloco, podemos realmente reverter o compromisso do bloco passado para o bloco atual.

Então, quais são os benefícios do Reflection?

Podemos pegar um bloco do Ethereum atual e voltar para um bloco anterior no qual estamos interessados. Se obtivermos os cabeçalhos de bloco entre o bloco anterior e o bloco atual, podemos reverter a confirmação do bloco anterior no bloco atual verificando o caminho de hash entre esses cabeçalhos de bloco. Então, se estivermos interessados em alguma informação de um bloco passado, podemos dar uma prova de inclusão no compromisso desse bloco. Especificamente, isso poderia ser uma prova de Merkle Patricia Trie de que a informação existe na trie de estado do bloco, trie de transação ou trie de recebimento. No EVM, pelo menos em princípio, qualquer informação passada na cadeia pode ser acessada apenas por meio do conhecimento de hashes de bloco recentes.

Infelizmente, fazer isso no EVM é caro. Como acabamos de mencionar, você deve verificar as cadeias de hash e as provas Merkle de todos os cabeçalhos de bloco, o que envolve muitos cálculos de hash Keccak em uma grande quantidade de dados. Então, quando você volta no tempo, fica muito difícil. Portanto, aplicamos a operação Reflection envolvendo essa prova com ZK no EVM. Portanto, em vez de colocar todos os cabeçalhos de bloco anteriores e todas essas provas de Merkle on-chain e depois verificá-los, verificamos com conhecimento zero se há uma sequência de cabeçalhos de bloco anteriores e algumas provas de verificação.

Isso tem duas vantagens. Primeiro, evita que tenhamos que colocar dados de prova nos dados da chamada. Em segundo lugar, permite-nos agregar provas, o que é impensável sem o uso do ZK. A ideia aqui é que, ao verificar qualquer número de cálculos no Ethereum, o custo do gás seja fixo, para que possamos usar uma única prova ZK para verificar uma grande quantidade de acesso a dados históricos.

Deixe-me abordar brevemente as vantagens e desvantagens do conceito de operação Reflection baseado em ZK.

Existem duas maneiras de acessar os dados. A primeira é a maneira como você sabe disso antes - você pode acessar dados no Ethereum diretamente do contrato inteligente. Isso tem a grande vantagem de que o acesso é síncrono. Portanto, você pode chamar diretamente a função de leitura no contrato inteligente para obter o valor atual. Por exemplo, quando você negocia no Uniswap, precisa dessa sincronicidade. No entanto, também tem muitas limitações. Seu poder de computação é limitado pelos custos de combustível e você não tem acesso a nenhum dado histórico.

Em segundo lugar, se você quiser aproveitar a capacidade do ZK de refletir no Ethereum, porque precisa gerar provas de que seu acesso está correto, não há como fazer isso de forma síncrona. Portanto, na verdade, não há acesso direto ao estado atual da cadeia, porque você precisa atestar um estado.

Por outro lado, se você se permitir acessar dados históricos de forma assíncrona, poderá aplicar cálculos quase ilimitados a eles e ter acesso a grandes quantidades de dados. Portanto, relaxando o conceito de sincronização, o acesso aos dados operacionais do Reflection baseado em ZK pode ser amplamente expandido.

Em seguida, veremos como implementar operações de reflexão por meio do Axiom.

Primeiro, temos que manter um cache de todos os blocos anteriores em nosso contrato inteligente. No EVM, os últimos 256 hashes de bloco estão disponíveis nativamente. Podemos provar que a cada lote de 1024 blocos, o hash do último bloco do lote anterior é confirmado no próximo bloco. Da mesma forma, o hash do penúltimo bloco no lote anterior é confirmado no último bloco e assim por diante. Portanto, podemos reverter a verificação dessa cadeia de hash e provar a validade dessa cadeia de hash por meio de conhecimento zero.

Isso nos permite armazenar hashes de bloco em cache, começando do bloco mais recente até o bloco de gênese. Na verdade, implementamos isso em nosso contrato inteligente de rede principal, que contém caminhos Merkle em cache a cada 1.024 hashes de bloco do bloco de gênese.

Outro recurso que estamos adicionando é Merkle Mountain Range. Ele é construído sobre esse cache de hash de bloco, uma estrutura de dados que nos permite fazer referência a cada hash de bloco no Ethereum em um DNA limitado.

Depois de construir o cache, podemos consultar o Axiom validando os blocos no cache. Para que isso funcione, temos que provar que todos os dados no histórico do Ethereum que estamos tentando acessar estão realmente comprometidos em estar no cache de algum bloco. Em segundo lugar, temos que provar que todos os cálculos que realizamos nesta consulta estão corretos. Para verificar isso na cadeia, verificamos a validade da prova de conhecimento zero. Também verificamos se ele se correlaciona com as informações que registramos na cadeia. Sempre construímos confiança em nossos caches ou caches de bloco e comparamos as informações nesses caches de bloco com informações públicas em provas de conhecimento zero.

Agora vamos falar sobre as possíveis aplicações da operação Reflection imaginada.

O eixo horizontal representa a complexidade dos dados, quantos dados realmente precisam ser acessados para implementar o aplicativo. O eixo vertical representa a complexidade computacional, que é quantos recursos computacionais realmente precisam ser aplicados para concluir a tarefa.

Portanto, o primeiro tipo de aplicativo é um aplicativo que o Axiom ou qualquer tipo de mecanismo de operação Reflection pode ser implementado no Ethereum, mas o custo é um pouco maior.

Alguns exemplos disso incluem a leitura de nonces de grau de consenso de cabeçalhos de bloco na camada de consenso Ethereum, verificação de idades históricas de contas ou leitura de diferentes tipos de dados de oráculo de informações históricas de preços. No EVM, várias soluções podem ser empregadas para implementar esses aplicativos, mas ao colocar essas soluções em conhecimento zero, a eficiência pode ser aumentada.

Agora, há outra classe de aplicativos que geralmente requerem mais acesso a dados e, portanto, mais computação. Na minha opinião, essas aplicações não seriam possíveis sem o uso do coprocessador ZK.

Como exemplo, uma aplicação interessante é permitir que um Roll-up no Ethereum leia o estado da camada base ou outro Roll-up de forma confiável, usando conhecimento zero para interagir. Um desses aplicativos pode permitir que Roll-ups leiam instantâneos de saldo total de tokens ERC20.

Se voltarmos nossa atenção do armazenamento para o histórico de transações das contas, você pode imaginar a construção de uma reputação confiável, identidade ou sistema de pontuação de crédito registrando o histórico completo dos endereços Ethereum. Isso pode ser usado para pontuação de crédito ou para fornecer acesso a algum tipo de DAO on-chain ou para emitir NFTs personalizados.

Há também uma classe de aplicativos que usam dados históricos na cadeia para realmente gerenciar o protocolo. Geralmente conhecido como contabilidade de acordos.

A ideia aqui é que existem protocolos para coordenar o comportamento dos participantes, e o princípio básico da coordenação é a capacidade de recompensar ou punir os participantes por seu comportamento. Se você observar muitos protocolos no Ethereum, o registro das ações dos participantes é mantido inteiramente na cadeia. Assim, com o Axiom, podemos imaginar que com base no conjunto completo de ações dos participantes do protocolo, o protocolo pode determinar a estrutura de pagamento ou até mesmo impor algum tipo de penalidade aos participantes, o que achamos que pode realmente expandir o espaço de design do protocolo formulários.

Finalmente, se realmente subirmos o nível de computação, achamos que pode ser muito interessante usar modelos de aprendizado de máquina para ajustar parâmetros na cadeia. Se você pensar em aplicações financeiras tradicionais, é muito comum modelar parâmetros futuros complexos com base em grandes quantidades de dados históricos, como dados de preços, dados econômicos etc. E quando olhamos para o DeFi atual, está longe de atingir esse patamar. Não acho que o DeFi deva funcionar exatamente da mesma maneira que as finanças tradicionais, mas acreditamos que a injeção de alguns bancos de dados históricos e modelos e informações baseados em aprendizado de máquina pode ajudar a criar um protocolo DeFi mais dinâmico.

Estas são apenas algumas ideias do que as operações de reflexão podem trazer para o blockchain.