Kakarot: Explorando el camino compatible con EVM de Starknet

Autor: Cínico

TL;RD

• Una máquina virtual es un sistema informático simulado por software que proporciona un entorno de ejecución para los programas. Puede emular varios dispositivos de hardware para que los programas puedan ejecutarse en un entorno controlado y compatible. La máquina virtual de Ethereum (EVM) es una máquina virtual basada en pilas que se utiliza para ejecutar contratos inteligentes de Ethereum.
• zkEVM es un EVM que integra tecnología de prueba de validez/prueba de conocimiento cero. Permite verificar la ejecución de la EVM utilizando pruebas de conocimiento cero sin requerir que todos los verificadores vuelvan a ejecutar la EVM. Hay varios productos zkEVM en el mercado, cada uno con su propio enfoque y diseño.
• El motivo de zkEVM es la necesidad de una máquina virtual que admita la ejecución de contratos inteligentes en la Capa 2. Además, algunos proyectos eligen usar zkEVM para aprovechar el amplio ecosistema de usuarios de EVM y diseñar un conjunto de instrucciones que sea más amigable para las pruebas de conocimiento cero.
• Kakarot es zkEVM implementado en Starknet usando el lenguaje Cairo. Simula la pila, la memoria, la ejecución y otros aspectos de EVM en forma de contratos inteligentes de Cairo. Kakarot enfrentó desafíos como la compatibilidad con el sistema de cuentas de Starknet, la optimización de costos y la estabilidad, ya que el idioma de El Cairo aún era experimental.
• Warp es un traductor del código Solidity al código Cairo, que brinda compatibilidad a un nivel de lenguaje de alto nivel. Kakarot, por otro lado, proporciona compatibilidad a nivel de EVM mediante la implementación de códigos de operación y precompilación de EVM.

¿Qué es una máquina virtual?

Para aclarar qué es una máquina virtual, primero debemos hablar sobre el proceso de ejecución de la computadora bajo la arquitectura convencional actual de von Neumann. Varios programas que se ejecutan en una computadora generalmente se transforman mediante capas de lenguajes de alto nivel y, finalmente, generan códigos de máquina comprensibles para la máquina para su ejecución. De acuerdo con la forma de convertir a código de máquina, los lenguajes de alto nivel se pueden dividir aproximadamente en lenguajes compilados y lenguajes interpretados.

Un lenguaje compilado significa que después de escribir el código, un compilador debe procesarlo para convertir el código de lenguaje de alto nivel en código de máquina y generar un archivo ejecutable. Una vez compilado, se puede ejecutar varias veces con mayor eficiencia. La ventaja de un lenguaje compilado es que el código se ha convertido en código de máquina durante la compilación, por lo que la velocidad de ejecución es rápida y el programa se puede ejecutar en un entorno sin compilador, lo cual es conveniente para los usuarios y no necesita para instalar software adicional. Los lenguajes compilados comunes incluyen C, C++, Go, etc.

La contrapartida de los lenguajes compilados son los lenguajes interpretados. Un lenguaje interpretado significa que el código se interpreta y ejecuta línea por línea a través de un intérprete, y se ejecuta directamente en la computadora, y el proceso de traducción debe volver a traducirse cada vez que se ejecuta. Las ventajas de los lenguajes interpretados son la alta eficiencia de desarrollo y la fácil depuración del código, pero la velocidad de ejecución es relativamente lenta. Los lenguajes interpretados comunes incluyen Python, Java, Ruby, etc.

Es necesario enfatizar que el lenguaje no distingue entre tipos compilados e interpretados en esencia, pero habrá algunas tendencias en el diseño inicial. C/C++ se compila y ejecuta en la mayoría de los casos, pero también se puede interpretar y ejecutar (Cint, Cling). Muchos lenguajes interpretados en el sentido tradicional ahora se compilan en códigos intermedios y se ejecutan en máquinas virtuales (Python, Lua).

Conociendo el proceso de ejecución de la máquina física, hablemos ahora de la máquina virtual.

Las máquinas virtuales suelen proporcionar un entorno informático virtual mediante la simulación de diferentes dispositivos de hardware. Los dispositivos de hardware que pueden ser simulados por diferentes máquinas virtuales son diferentes, pero generalmente incluyen CPU, memoria, disco duro, interfaz de red, etc.

Tomemos como ejemplo la máquina virtual de Ethereum (EVM), que es una máquina virtual basada en pilas que se utiliza para ejecutar contratos inteligentes de Ethereum. EVM proporciona un entorno informático virtual mediante la simulación de dispositivos de hardware como CPU, memoria, almacenamiento y pila.

Específicamente, EVM es una máquina virtual basada en pilas que usa una pila para almacenar datos y ejecutar instrucciones. El conjunto de instrucciones de EVM incluye varios códigos de operación, como operaciones aritméticas, operaciones lógicas, operaciones de almacenamiento, operaciones de salto, etc. Estas instrucciones se pueden ejecutar en la pila de EVM para completar la ejecución de contratos inteligentes.

La memoria y el almacenamiento emulados por EVM son dispositivos que se utilizan para almacenar el estado y los datos de los contratos inteligentes. El EVM trata la memoria y el almacenamiento como dos áreas distintas, y puede acceder al estado y los datos de los contratos inteligentes al leer y escribir en la memoria y el almacenamiento.

La pila emulada por EVM se usa para almacenar los operandos y los resultados de las instrucciones. La mayoría de las instrucciones en el conjunto de instrucciones de EVM están basadas en pilas, leen operandos de la pila y empujan los resultados de regreso a la pila.

En resumen, EVM proporciona un entorno informático virtual mediante la simulación de dispositivos de hardware como CPU, memoria, almacenamiento y pila, que pueden ejecutar las instrucciones de los contratos inteligentes y almacenar el estado y los datos de los contratos inteligentes. En la operación real, el EVM cargará el código de bytes del contrato inteligente en la memoria y ejecutará la lógica del contrato inteligente mediante la ejecución del conjunto de instrucciones. Lo que EVM realmente reemplaza es la parte del sistema operativo + hardware en la figura anterior.

El proceso de diseño de EVM obviamente es de abajo hacia arriba. Primero, se finaliza el entorno de hardware simulado (pila, memoria) y luego se diseña un conjunto de instrucciones de ensamblaje (Opcode) y bytecode (Bytecode) de acuerdo con el entorno correspondiente. Aunque el conjunto de instrucciones de ensamblado es para que la gente lo lea, implica mucho conocimiento de bajo nivel, tiene altos requisitos para los desarrolladores y es engorroso de desarrollar. Por lo tanto, se necesita un lenguaje de alto nivel para proteger el bajo nivel oscuro y engorroso. llamadas y proporcionar a los desarrolladores una mejor experiencia. Debido al diseño personalizado del conjunto de instrucciones de ensamblaje de EVM, es difícil usar directamente los lenguajes tradicionales de alto nivel y simplemente recrear un nuevo lenguaje de alto nivel para adaptarlo a la máquina virtual. La comunidad de Ethereum ha diseñado dos lenguajes de alto nivel compilados, Solidity y Vyper, para la eficiencia de ejecución de EVM. No es necesario enfatizar Solidity, Vyper es un lenguaje de alto nivel EVM diseñado por Vitalik después de mejorar algunos de los defectos de Solidity, pero no ha sido adoptado ampliamente en la comunidad, por lo que gradualmente se desvanece del escenario de la historia.

¿Qué es zkEVM?

En pocas palabras, zkEVM es un EVM que utiliza tecnología de prueba de conocimiento cero/prueba de validez, de modo que el proceso de ejecución de EVM se puede verificar de manera más eficiente y a bajo costo a través de prueba de conocimiento cero/prueba de validez sin requerir que todos los verificadores lleven el proceso de ejecución de la EVM.

Hay muchos productos zkEVM en el mercado, y la pista está de moda. Los principales jugadores incluyen Starknet, zkSync, Scroll, Taiko, Linea, Polygon zkEVM (anteriormente Polygon Hermez), etc., que se dividen en 5 categorías (1, 2 , 2.5, 3, 4) de vitalik . El contenido específico se puede ver en el blog de Vitalik.

Por qué se necesita zkEVM

Esta pregunta necesita ser vista desde dos perspectivas.

Los intentos iniciales de zk Rollup solo pueden lograr funciones de transferencia y transacción relativamente simples, como zkSync Lite, Loopring, etc. Pero en el pasado, el mar era difícil y la gente solía usar el EVM completo de Turing en Ethereum. Cuando era imposible crear varias aplicaciones a través de la programación, la gente comenzó a pedir máquinas virtuales en L2. La necesidad de escribir contratos inteligentes es una.

Dado que algunos diseños en el EVM no son compatibles con la generación de prueba de conocimiento cero/prueba de validez, algunos jugadores optan por utilizar un conjunto de instrucciones que es compatible con la prueba de conocimiento cero/prueba de validez en la capa inferior, como la Asamblea de El Cairo de Starknet y la de zkSync. Instrucción de zinc. Pero al mismo tiempo, nadie está dispuesto a renunciar a la enorme ecología de usuarios de EVM, por lo que eligen ser compatibles con EVM en la capa superior, que es de tipo 3 y 4 zkEVM. Algunos jugadores aún insisten en el conjunto de instrucciones EVM tradicional Opcode y se enfocan en generar pruebas más eficientes para Opcode, que son Tipo 1 y Tipo 2 zkEVM. La enorme ecología de EVM se divide en dos.

Kakarotto: ¿Una máquina virtual en una máquina virtual?

¿Por qué se puede hacer otra máquina virtual en la máquina virtual? Esto es un lugar común para los profesionales de la informática, pero puede que no sea tan obvio para los usuarios que no entienden de informática. De hecho, es fácil de entender. Son como bloques de construcción. Siempre que la capa inferior sea lo suficientemente fuerte (con un entorno de ejecución completo de Turing), los bloques de construcción se pueden apilar en la capa superior sin límite. Pero no importa cuántas capas se construyan, la ejecución final aún debe ser manejada por el hardware físico de nivel más bajo, por lo que aumentar la cantidad de capas conducirá a una disminución en la eficiencia. Al mismo tiempo, debido a los diferentes diseños de diferentes bloques de construcción (diferentes diseños de máquinas virtuales), a medida que los bloques de construcción se construyen más y más alto, la posibilidad de que los bloques de construcción colapsen (errores de ejecución) es mayor, lo que requiere un nivel más alto. de soporte técnico.

Kakarot es un EVM implementado en lenguaje Cairo en Starknet. Utiliza contratos inteligentes de Cairo para simular la pila, la memoria, la ejecución, etc. en el EVM. En términos relativos, no es difícil implementar EVM. Además del EVM escrito en Golang en Go-Ethereum, que tiene la tasa de uso más alta, también existen EVM escritos en Python, Java, Java y Rust.

La dificultad técnica de Kakarot zkEVM es que el protocolo existe como un contrato en la cadena Starknet, lo que genera dos problemas clave.

1. Compatibilidad Starknet utiliza un sistema de cuentas completamente diferente al de Ethereum. Las cuentas en Ethereum se dividen en EOA (cuenta de propiedad externa) y CA (cuenta de contrato). Sin embargo, Starknet admite la abstracción de cuenta nativa y todas las cuentas son contratos. Al mismo tiempo, debido a los diferentes algoritmos criptográficos utilizados, los usuarios no pueden utilizar la misma entropía para generar la misma dirección en Starknet que en Ethereum.
2. Costo Dado que kakarot zkEVM existe en la cadena como un contrato, tiene altos requisitos para la implementación del código y debe optimizarse para Gas tanto como sea posible para reducir los costos de interacción.
3. Estabilidad A diferencia del uso de lenguajes tradicionales de alto nivel como Golang, Rust, Python, etc., el lenguaje Cairo aún se encuentra en etapa experimental, desde Cairo 0 a Cairo 1 a Cairo 2 (o si lo prefiere, Cairo 1 versión 2), el equipo oficial sigue siendo Las características del idioma se revisan constantemente. Al mismo tiempo, Cairo VM no se ha probado lo suficiente y no se puede descartar la posibilidad de posteriores reescrituras a gran escala.

El protocolo kakarot consta de cinco componentes principales (cuatro están escritos en el documento de GitHub, EOA no está incluido, este artículo se ha ajustado para la comodidad de los lectores):

• Kakarot (Núcleo): responsable de ejecutar transacciones en forma de Ethereum y proporcionar las cuentas correspondientes de Starknet para los usuarios de Ethereum
• Cuentas de contrato: CA en el sentido de Ethereum, responsable de almacenar el bytecode del contrato y el estado de las variables en el contrato
• Cuentas de propiedad externa: EOA en el sentido de Ethereum, responsable de reenviar las transacciones de Ethereum a Kakarot Core
• Registro de cuentas: almacena la correspondencia entre las cuentas de Ethereum y las cuentas de Starknet.
• Registro de Blockhash: como un código de operación especial, Blockhash necesita datos de bloques pasados y Kakarot no puede obtener directamente los datos de la cadena. Este componente almacena la relación de mapeo de bloque_número -> bloque_hash, que escribe el administrador y se proporciona a Kakarot Core.

De acuerdo con los comentarios del CEO de kakarot, Elias Tazartes, en la última versión del equipo, se abandonó el diseño de Account Resister y, en su lugar, se usó un mapeo de una dirección Starknet de 31 bytes a una dirección EVM de 20 bits para guardar la relación correspondiente. . En el futuro, para mejorar la interoperabilidad y permitir que los contratos de Starknet registren sus propias direcciones EVM, se puede reutilizar el diseño del registro de cuentas.

Compatible con EVM en Starknet: ¿Cuál es la diferencia entre Warp y kakarot?

De acuerdo con el tipo zkEVM definido por Vitalik, Warp pertenece al Tipo-4, mientras que kakarot actualmente pertenece al Tipo-2.5.

Warp es un traductor que convierte el código Solidity en código Cairo.La razón por la que no se llama compilador es probablemente porque la salida Cairo sigue siendo un lenguaje de alto nivel. A través de Warp, los desarrolladores de Solidity pueden mantener el estado de desarrollo original sin tener que aprender el nuevo lenguaje Cairo. Para muchas partes del proyecto, Warp reduce el umbral para ingresar al ecosistema Starknet y no necesita usar Cairo para reescribir una gran cantidad de código de ingeniería.

Aunque la idea de la traducción es simple, la compatibilidad también es la peor. Algunos códigos de Solidity no se pueden traducir bien a Cairo. La lógica del código que involucra el sistema de cuentas, el algoritmo criptográfico, etc. necesita modificar el código fuente para completar la migración. Las características específicas no admitidas se pueden ver en la documentación de Warp. Por ejemplo, muchos proyectos distinguirán la lógica de ejecución de las cuentas EOA y las cuentas de contrato, pero todas las cuentas en Starknet son cuentas de contrato, y esta parte del código debe modificarse antes de la traducción.

Warp es compatible en el nivel de lenguaje de alto nivel y kakarot es compatible en el nivel de EVM.

La reescritura completa de EVM y la implementación uno por uno de Opcode y Pre-compile permiten que Kakarot tenga una mayor compatibilidad nativa. Después de todo, la ejecución en la misma máquina virtual (EVM) siempre es más compatible que la ejecución en una máquina virtual diferente (Cairo VM). Account Registry y Blockhash Registry protegen inteligentemente las diferencias entre diferentes sistemas y minimizan la fricción de la migración de usuarios.

Equipo Kakarotto

Gracias al equipo de kakarot por sus valiosos comentarios a este artículo, en especial a Elias Tazartes. ¡Gracias Señor!