Kakarot: explorando a estrada compatível com EVM da Starknet

Autor: Cínico

TL;DR

• Uma máquina virtual é um sistema de computador simulado por software que fornece um ambiente de execução para programas. Ele pode emular vários dispositivos de hardware, para que os programas possam ser executados em um ambiente controlado e compatível. A Ethereum Virtual Machine (EVM) é uma máquina virtual baseada em pilha usada para executar contratos inteligentes Ethereum.
• zkEVM é um EVM que integra tecnologia de prova de conhecimento zero/prova de validade. Ele permite que a execução do EVM seja verificada usando provas de conhecimento zero sem exigir que todos os verificadores reexecutem o EVM. Existem vários produtos zkEVM no mercado, cada um com sua própria abordagem e design.
• O motivo do zkEVM é a necessidade de uma máquina virtual que suporte a execução de contratos inteligentes na Camada 2. Além disso, alguns projetos optam por usar o zkEVM para aproveitar o amplo ecossistema de usuários do EVM e projetar um conjunto de instruções mais amigável para provas de conhecimento zero.
• Kakarot é zkEVM implementado em Starknet usando a linguagem do Cairo. Ele simula a pilha, memória, execução e outros aspectos do EVM na forma de contratos inteligentes do Cairo. Kakarot enfrentou desafios como compatibilidade com o sistema de contas Starknet, otimização de custos e estabilidade, já que o idioma do Cairo ainda era experimental.
• Warp é um tradutor de código Solidity para código Cairo, proporcionando compatibilidade em um nível de linguagem de alto nível. Kakarot, por outro lado, fornece compatibilidade no nível EVM implementando opcodes EVM e pré-compilação.

O que é uma máquina virtual?

Para esclarecer o que é uma máquina virtual, devemos primeiro falar sobre o processo de execução do computador sob a arquitetura atual de von Neumann. Vários programas executados em um computador geralmente são transformados por camadas de linguagens de alto nível e, finalmente, geram códigos de máquina compreensíveis para execução. De acordo com a forma de conversão para código de máquina, as linguagens de alto nível podem ser divididas aproximadamente em linguagens compiladas e linguagens interpretadas.

Uma linguagem compilada significa que depois que o código é escrito, ele precisa ser processado por um compilador para converter o código da linguagem de alto nível em código de máquina e gerar um arquivo executável. Uma vez compilado, pode ser executado várias vezes com maior eficiência. A vantagem de uma linguagem compilada é que o código foi convertido em código de máquina durante a compilação, portanto a velocidade de execução é rápida e o programa pode ser executado em um ambiente sem compilador, o que é conveniente para os usuários usarem e não requer para instalar software adicional. Linguagens compiladas comuns incluem C, C++, Go, etc.

A contrapartida das linguagens compiladas são as linguagens interpretadas. Uma linguagem interpretada significa que o código é interpretado e executado linha por linha por meio de um interpretador, e é executado diretamente no computador, e o processo de tradução precisa ser retraduzido toda vez que é executado. As vantagens das linguagens interpretadas são alta eficiência de desenvolvimento e fácil depuração de código, mas a velocidade de execução é relativamente lenta. Linguagens interpretadas comuns incluem Python, Java, Ruby, etc.

É necessário enfatizar que a linguagem não distingue entre tipos compilados e interpretados em essência, mas haverá algumas tendências no design inicial. C/C++ é compilado e executado na maioria dos casos, mas também pode ser interpretado e executado (Cint, Cling). Muitas linguagens interpretadas no sentido tradicional agora são compiladas em códigos intermediários e executadas em máquinas virtuais (Python, Lua).

Conhecendo o processo de execução da máquina física, vamos falar agora da máquina virtual.

As máquinas virtuais geralmente fornecem um ambiente de computador virtual simulando diferentes dispositivos de hardware. Os dispositivos de hardware que podem ser simulados por diferentes máquinas virtuais são diferentes, mas geralmente incluem CPU, memória, disco rígido, interface de rede e assim por diante.

Pegue a Ethereum Virtual Machine (EVM) como exemplo. EVM é uma máquina virtual baseada em pilha que é usada para executar contratos inteligentes Ethereum. O EVM fornece um ambiente de computador virtual simulando dispositivos de hardware como CPU, memória, armazenamento e pilha.

Especificamente, o EVM é uma máquina virtual baseada em pilha que usa uma pilha para armazenar dados e executar instruções. O conjunto de instruções do EVM inclui vários opcodes, como operações aritméticas, operações lógicas, operações de armazenamento, operações de salto, etc. Essas instruções podem ser executadas na pilha do EVM para concluir a execução de contratos inteligentes.

A memória e o armazenamento emulados pelo EVM são dispositivos usados para armazenar o estado e os dados dos contratos inteligentes. O EVM trata a memória e o armazenamento como duas áreas distintas e pode acessar o estado e os dados dos contratos inteligentes lendo e gravando na memória e no armazenamento.

A pilha emulada pelo EVM é utilizada para armazenar os operandos e resultados das instruções. A maioria das instruções no conjunto de instruções do EVM são baseadas em pilha, lendo operandos da pilha e colocando os resultados de volta na pilha.

Em suma, o EVM fornece um ambiente de computador virtual simulando dispositivos de hardware como CPU, memória, armazenamento e pilha, que podem executar as instruções de contratos inteligentes e armazenar o estado e os dados de contratos inteligentes. Na operação real, o EVM carregará o bytecode do contrato inteligente na memória e executará a lógica do contrato inteligente executando o conjunto de instruções. O que o EVM realmente substitui é a parte do sistema operacional + hardware na figura acima.

O processo de design do EVM é obviamente de baixo para cima. Primeiro, o ambiente de hardware simulado (pilha, memória) é finalizado e, em seguida, um conjunto de instruções de montagem (Opcode) e bytecode (Bytecode) são projetados de acordo com o ambiente correspondente. Embora o conjunto de instruções de montagem seja para as pessoas lerem, ele envolve muito conhecimento de baixo nível, tem altos requisitos para desenvolvedores e é complicado de desenvolver. chamadas e fornecer aos desenvolvedores uma melhor experiência. Devido ao design personalizado do conjunto de instruções de montagem do EVM, é difícil usar diretamente as linguagens tradicionais de alto nível e simplesmente recriar uma nova linguagem de alto nível para se adaptar à máquina virtual. A comunidade Ethereum projetou duas linguagens compiladas de alto nível - Solidity e Vyper - para eficiência de execução de EVM. O Solidity não precisa ser enfatizado, o Vyper é uma linguagem de alto nível EVM projetada por Vitalik após melhorar alguns dos defeitos do Solidity, mas não foi amplamente adotada na comunidade, então gradualmente desaparece do palco da história.

O que é zkEVM

Simplificando, o zkEVM é um EVM que usa tecnologia de prova de conhecimento zero/prova de validade, para que o processo de execução do EVM possa ser verificado com mais eficiência e baixo custo por meio de prova de conhecimento zero/prova de validade sem exigir que todos os verificadores realizem o processo de execução do EVM.

Existem muitos produtos zkEVM no mercado e a pista é quente. Os principais players incluem Starknet, zkSync, Scroll, Taiko, Linea, Polygon zkEVM (anteriormente Polygon Hermez), etc., que são divididos em 5 categorias (1, 2 , 2.5, 3, 4) por vitalik . O conteúdo específico pode ser visualizado no blog de Vitalik.

Por que o zkEVM é necessário

Essa questão precisa ser analisada sob dois pontos de vista.

As tentativas iniciais do zk Rollup só podem alcançar funções de transferência e transação relativamente simples, como zkSync Lite, Loopring, etc. Mas uma vez que o mar estava muito difícil, as pessoas costumavam usar o EVM completo de Turing no Ethereum.Quando era impossível criar vários aplicativos por meio de programação, as pessoas começaram a pedir máquinas virtuais em L2. A necessidade de escrever contratos inteligentes é uma delas.

Uma vez que alguns projetos no EVM não são amigáveis para gerar prova de conhecimento zero/prova de validade, alguns jogadores optam por usar um conjunto de instruções que é amigável para prova de conhecimento zero/prova de validade na camada inferior, como o Cairo Assembly da Starknet e o zkSync. Instrução de zinco. Mas, ao mesmo tempo, todos não estão dispostos a desistir da enorme ecologia de usuários do EVM, então eles optam por ser compatíveis com o EVM na camada superior, que é o tipo 3 e 4 zkEVM. Alguns jogadores ainda insistem no conjunto de instruções EVM tradicional Opcode, e se concentram em gerar provas mais eficientes para Opcode, que são Tipo 1 e Tipo 2 zkEVM. A enorme ecologia do EVM é dividida em duas.

Kakarot: Uma máquina virtual em uma máquina virtual?

Por que outra máquina virtual pode ser criada na máquina virtual? Isso é comum para profissionais de computação, mas pode não ser tão óbvio para usuários que não entendem de computadores. Na verdade, é fácil de entender. Isso é como blocos de construção. Desde que a camada inferior seja forte o suficiente (com um ambiente de execução Turing-completo), os blocos de construção podem ser empilhados na camada superior sem limite. Mas não importa quantas camadas sejam construídas, a execução final ainda precisa ser tratada pelo hardware físico de nível mais baixo, portanto, aumentar o número de camadas levará a uma diminuição na eficiência. Ao mesmo tempo, devido aos diferentes designs de diferentes blocos de construção (diferentes designs de máquinas virtuais), à medida que os blocos de construção são construídos cada vez mais alto, a possibilidade de colapso dos blocos de construção (erros de execução) é maior, o que requer um nível mais alto de suporte técnico.

Kakarot é um EVM implementado na linguagem Cairo no Starknet. Ele usa contratos inteligentes Cairo para simular a pilha, memória, execução, etc. no EVM. Relativamente falando, não é difícil implementar o EVM. Além do EVM escrito em Golang no Go-Ethereum, que tem a maior taxa de uso, também existem EVMs escritos em Python, Java, Java e Rust.

A dificuldade técnica do Kakarot zkEVM é que o protocolo existe como um contrato na cadeia Starknet, o que traz dois problemas principais.

1. Compatibilidade Starknet usa um sistema de contas completamente diferente do Ethereum. As contas no Ethereum são divididas em EOA (conta de propriedade externa) e CA (conta de contrato). No entanto, Starknet suporta abstração de conta nativa e todas as contas são contratos. Ao mesmo tempo, devido aos diferentes algoritmos criptográficos usados, os usuários não podem usar a mesma entropia para gerar o mesmo endereço no Starknet e no Ethereum.
2. Custo Como o kakarot zkEVM existe na cadeia como um contrato, ele tem altos requisitos para implementação de código e precisa ser otimizado para Gas tanto quanto possível para reduzir os custos de interação.
3. Estabilidade Ao contrário do uso de linguagens tradicionais de alto nível como Golang, Rust, Python, etc., a linguagem Cairo ainda está em fase experimental, de Cairo 0 a Cairo 1 a Cairo 2 (ou se preferir, Cairo 1 versão 2), a equipe oficial ainda está em constante revisão. Ao mesmo tempo, o Cairo VM não foi testado o suficiente e a possibilidade de reescritas subsequentes em grande escala não pode ser descartada.

O protocolo kakarot consiste em cinco componentes principais (quatro estão escritos no documento GitHub, o EOA não está incluído, este artigo foi ajustado para conveniência dos leitores):

• Kakarot (Core): responsável por executar transações na forma de Ethereum e fornecer contas Starknet correspondentes para usuários Ethereum
• Contract Accounts: CA no sentido de Ethereum, responsável por armazenar o bytecode do contrato e o estado das variáveis no contrato
• Contas de propriedade externa: EOA no sentido de Ethereum, responsável por encaminhar transações Ethereum para Kakarot Core
• Registro de Conta: Armazena a correspondência entre contas Ethereum e contas Starknet.
• Registro Blockhash: Como um Opcode especial, o Blockhash precisa de dados de blocos anteriores e o Kakarot não pode obter os dados diretamente na cadeia. Este componente armazena o relacionamento de mapeamento de bloco_número -> bloco_hash, que é escrito pelo administrador e fornecido ao Kakarot Core.

De acordo com o feedback do CEO da kakarot, Elias Tazartes, na versão mais recente da equipe, o design do Account Resister foi abandonado e, em vez disso, um mapeamento de um endereço Starknet de 31 bytes para um endereço EVM de 20 bits foi usado diretamente para salvar o relacionamento correspondente . No futuro, para melhorar a interoperabilidade e permitir que os contratos Starknet registrem seus próprios endereços EVM, o design do Account Register pode ser reutilizado.

Compatível com EVM no Starknet: Qual é a diferença entre Warp e kakarot

De acordo com o tipo zkEVM definido por Vitalik, Warp pertence ao Tipo-4, enquanto kakarot atualmente pertence ao Tipo-2.5.

Warp é um tradutor que converte código Solidity em código Cairo.A razão pela qual não é chamado de compilador é provavelmente porque a saída Cairo ainda é uma linguagem de alto nível. Por meio do Warp, os desenvolvedores do Solidity podem manter o status de desenvolvimento original sem precisar aprender o novo idioma do Cairo. Para muitas partes do projeto, o Warp reduz o limite para entrar no ecossistema Starknet e não precisa usar o Cairo para reescrever uma grande quantidade de código de engenharia.

Embora a ideia de tradução seja simples, a compatibilidade também é a pior. Alguns códigos do Solidity não podem ser bem traduzidos para o Cairo. A lógica do código envolvendo sistema de contas, algoritmo criptográfico etc. precisa modificar o código-fonte para concluir a migração. Os recursos específicos sem suporte podem ser vistos na documentação do Warp. Por exemplo, muitos projetos irão distinguir a lógica de execução de contas EOA e contas de contrato, mas todas as contas no Starknet são contas de contrato, e esta parte do código precisa ser modificada antes da tradução.

Warp é compatível no nível de linguagem de alto nível e kakarot é compatível no nível EVM.

A reescrita completa do EVM e a implementação um por um do Opcode e da pré-compilação permitem que o kakarot tenha maior compatibilidade nativa. Afinal, a execução na mesma máquina virtual (EVM) é sempre mais compatível do que a execução em outra máquina virtual (Cairo VM). O Account Registry e o Blockhash Registry protegem de forma inteligente as diferenças em diferentes sistemas e minimizam o atrito da migração do usuário.

Equipe Kakaroto

Agradeço à equipe kakarot pelos valiosos comentários a este artigo, em especial Elias Tazartes. Obrigado, senhor!