Autor original: Analista comercial de PSE @cryptohawk
TL;DR
Una máquina virtual es un sistema informático emulado por software que proporciona un entorno de ejecución para programas. Puede simular varios dispositivos de hardware y permitir que los programas se ejecuten en un entorno controlado y compatible.
La máquina virtual Ethereum (EVM) es una máquina virtual basada en pila que se utiliza para ejecutar contratos inteligentes de Ethereum. zkEVM ha realizado ciertas optimizaciones de eficiencia de generación a prueba de zk en la equivalencia/compatibilidad de EVM;
zkVM abandona la equivalencia/compatibilidad de EVM y aumenta la prioridad de la compatibilidad con zk;
privacidad zkVM superpone características de privacidad nativas en zkVM;
SVM, FuelVM y MoveVM tienen en común la búsqueda del máximo rendimiento mediante la ejecución paralela, pero tienen sus propias características en los detalles de diseño;
ESC VM y BitVM han realizado ciertos experimentos innovadores de capa informática en las cadenas ETH y BTC respectivamente, pero la demanda real de implementación es baja en el entorno actual.
La enorme ecología de usuarios de EVM determina que cualquier red blockchain que la abandone será difícil competir con ella en el corto plazo. Por lo tanto, la ecología no EVM introduce a los usuarios ecológicos de EVM a través de traductores/compiladores/intérpretes de códigos de bytes e incluso capas de compatibilidad de VM. utilizar funciones que no sean EVM El uso de funciones de máquinas virtuales para construir una nueva narrativa ecológica puede ser un camino necesario hacia el éxito.
1.1 ¿Qué es la máquina virtual?
Una máquina virtual (VM) es un componente básico de recursos informáticos virtualizados que realiza casi las mismas funciones que una computadora, incluida la ejecución de aplicaciones y sistemas operativos. El concepto de máquinas virtuales no es nuevo y la tecnología se utiliza ampliamente en muchos ecosistemas tecnológicos.
En el contexto de blockchain, una máquina virtual (VM) es una pieza de software que ejecuta programas, a menudo denominado entorno de ejecución que ejecuta contratos inteligentes de blockchain. Las máquinas virtuales suelen proporcionar un entorno informático virtual simulando diferentes dispositivos de hardware. Los dispositivos de hardware que pueden simular diferentes máquinas virtuales varían, pero generalmente incluyen CPU, memoria, disco duro, interfaz de red, etc. Cuando se envía una transacción en cadena, la máquina virtual es responsable de procesar la transacción y actualizar el estado de la cadena de bloques (el estado global actual de toda la red) afectado por la ejecución de la transacción. Las reglas específicas para cambiar el estado de la red las define la VM. Al procesar una transacción, la VM convierte el código del contrato inteligente a un formato que el hardware del nodo/validador pueda ejecutar.
El núcleo más importante entre las VM es LLVM (máquina virtual de bajo nivel), que puede considerarse como el núcleo más importante del compilador. La imagen muestra el esquema de operación EVM original. El contrato inteligente se convierte a través del código intermedio de LLVM IR y se convierte a Bytecode. Estos códigos de bytes se almacenarán en la cadena de bloques. Cuando se llame al contrato inteligente, los códigos de bytes se convertirán en códigos de operación correspondientes, que luego serán ejecutados por el EVM y el hardware del nodo.
1.2 VM convencional
1.2.1 EVM: Blockchain VM tiene una piedra en total, EVM tiene ocho depósitos exclusivamente y el resto se divide en dos depósitos.
Proyectos representativos: Optimismo, Arbitrum
Como ecosistema blockchain con los usuarios desarrolladores más activos de la industria, Ethereum Virtual Machine (EVM) es una máquina virtual basada en pilas que proporciona un entorno informático virtual mediante la simulación de dispositivos de hardware como CPU, memoria, almacenamiento y pilas. para ejecutar las instrucciones del contrato inteligente y almacenar el estado y los datos del contrato inteligente. El conjunto de instrucciones de EVM incluye varios códigos de operación Opcode, como operaciones aritméticas, operaciones lógicas, operaciones de almacenamiento, operaciones de salto, etc.
La memoria y el almacenamiento simulados por EVM son dispositivos que se utilizan para almacenar el estado y los datos de los contratos inteligentes. EVM trata la memoria y el almacenamiento como dos áreas diferentes y puede acceder al estado y los datos de los contratos inteligentes leyendo y escribiendo en la memoria y el almacenamiento.
La pila simulada EVM se utiliza para almacenar los operandos y resultados de las instrucciones. La mayoría de las instrucciones del conjunto de instrucciones del EVM están basadas en pila, leen operandos de la pila y envían el resultado nuevamente a la pila.
El proceso de diseño de EVM es obviamente de abajo hacia arriba, primero se finaliza el entorno de hardware simulado (pila, memoria) y luego se diseña su propio conjunto de instrucciones de ensamblaje (Opcode) y código de bytes (Bytecode) de acuerdo con el entorno correspondiente. . La comunidad Ethereum ha diseñado dos lenguajes compilados de alto nivel (Solidity y Vyper) para lograr eficiencia en la ejecución de EVM. No hace falta decir que es necesario enfatizar que Solidity es un lenguaje EVM de alto nivel diseñado por Vitalik para mejorar algunos de los defectos existentes en Solidity. Sin embargo, no obtuvo una gran adopción en la comunidad, por lo que gradualmente desapareció. el escenario de la historia.
1.2.2 zkEVM: lo quiero todo: compatible con el entorno EVM + admite la transformación de raíz de estado global para generar a prueba de zk
Proyectos representativos: Taiko, Scroll, Polygon zkEVM
Debido a que el EVM no se construyó teniendo en mente la computación a prueba de zk, tiene características que no son amigables para los circuitos de prueba, especialmente en términos de códigos de operación especiales, arquitectura basada en pila, gastos generales de almacenamiento y costos de prueba. zkEVM es una máquina virtual que ejecuta contratos inteligentes de una manera que es compatible con los cálculos a prueba de zk, de modo que el proceso de ejecución de EVM se puede verificar de manera más eficiente y rentable a través de prueba de validez/prueba de zk. En comparación con OP Rollup, la capa de ejecución solo necesita copiar EVM, y construir EVM para que sea compatible con ZK es un desafío adicional para ZK Rollup.
Los paquetes acumulativos de ZK no son fácilmente compatibles con la máquina virtual Ethereum (EVM). Probar cálculos EVM de propósito general en un circuito es más difícil y requiere más recursos que probar cálculos simples (como la transferencia de tokens descrita anteriormente).
Sin embargo, los avances en la tecnología de conocimiento cero (se abre en una pestaña nueva) han reavivado el interés en envolver los cálculos EVM en pruebas de conocimiento cero. Estos esfuerzos tienen como objetivo crear una implementación EVM de conocimiento cero (zkEVM) que pueda verificar de manera eficiente la exactitud de la ejecución del programa. .
Al igual que EVM, zkEVM realiza transiciones entre estados después de realizar cálculos en ciertas entradas. La diferencia es que zkEVM también crea pruebas de conocimiento cero para verificar la exactitud de cada paso en la ejecución del programa. Las pruebas de validez verifican la exactitud de las operaciones que involucran el estado de la máquina virtual (memoria, pila, almacenamiento) y el cálculo en sí (es decir, ¿la operación llamó a los códigos de operación correctos y los ejecutó correctamente?).
La idea es hermosa, pero la realidad es muy escasa. Actualmente, es difícil para Rollup lograr tanto la compatibilidad con ZK como la compatibilidad con EVM (o incluso la equivalencia), es decir, debe copiar la capa de ejecución de Ethereum L1 lo más completamente posible. incluyendo hash, árbol de estado y árbol de transacciones, precompilación, etc., para que el cliente de ejecución Ethereum L1 pueda usarse tal como está para procesar bloques acumulativos o descartar la compatibilidad con EVM y recrear el código de operación existente para la certificación/verificación en el circuito. , permitiendo la ejecución de contratos inteligentes.
1.2.3 zkVM: no puedes quedarte con el pastel y comértelo también: máquina virtual no evm orientada a la eficiencia y a prueba de zk
Proyectos representativos: Starknet, Zksync, RISC ZERO
zkVM abandona la compatibilidad con EVM, toma la prueba de datos y la actualización del estado como objetivos principales y encuentra un denominador común entre la criptografía y los lenguajes de alto nivel para proporcionar un marco común para varias aplicaciones.
Desde que Starkware comenzó antes en todo el campo ZK, ha acumulado suficiente tecnología y tiene cierta ventaja tecnológica. Es una arquitectura técnica representativa centrada en ZK, y Cairo VM y el lenguaje Cairo se construyen alrededor de ZK. La desventaja es que el costo de aprendizaje en El Cairo es relativamente alto.
El marco de ZKsync es compatible con las características de EVM y ZK, integra Solidity con su lenguaje de circuito de desarrollo propio Zinc y unifica los dos a nivel IR dentro del compilador. La ventaja es que el núcleo del compilador LLVM es compatible con varios idiomas.
RISC Zero utiliza la arquitectura RISC-V para construir un simulador que permite a los programadores escribir programas para zkVM utilizando lenguajes comunes como Rust, C/C++ y Go. Esto significa que la lógica de la aplicación no necesita limitarse a qué. se puede expresar en Solidity, permitiendo escribir y encadenar código irrelevante.
1.2.4 Privacidad zkVM: compatible con zk + soporte de privacidad nativo intenta encender una nueva chispa ecológica
Proyectos representativos: Aleo, Ola, Polygon Miden
Blockchain sirve como un sistema de contabilidad pública y todas las transacciones se realizan en la cadena, lo que significa que los cambios de estado que contienen información de activos relacionados con direcciones o cuentas son abiertos y transparentes. Por lo tanto, además de trabajar en soluciones escalables, algunos equipos de blockchain creen que la próxima característica clave a implementar es la privacidad.
Privacidad zkVM Además de las características de soporte de expansión compatible con zk, debido a las características de privacidad respaldadas de forma nativa por su propio lenguaje de programación, los desarrolladores de aplicaciones de capa superior pueden desarrollar dapps relacionados con la privacidad, que traerán nuevos escenarios de aplicaciones y grandes narrativas. Por ejemplo, resuelva completamente el problema MEV y proteja la propiedad de los datos del usuario. Por supuesto, la complejidad del diseño de Privacy zkVM requiere un equipo técnico más grande para implementarlo, y puede llevar varios años lograrlo.
1.2.5 SVM: después de que la marea retroceda, todavía quedan brasas: un entorno de ejecución donde el diseño de rendimiento ha llegado al extremo
Proyectos representativos: Eclipse Mainnet, Nitro, MakerDAO Chain (tal vez)
SVM, la máquina virtual Solana, se centra en un entorno de ejecución de alto rendimiento y los contratos inteligentes están escritos principalmente en lenguaje Rust. En comparación con los entornos de ejecución de un solo subproceso EVM y EOS WASM, al requerir que las transacciones de Solana describan todos los estados que una transacción leerá o escribirá durante la ejecución, SVM implementa la ejecución simultánea de transacciones que no se superponen y transacciones que solo leen el mismo estado.
Además, para permitir una verificación/difusión rápida de grandes bloques de transacciones, el proceso de verificación de transacciones en la red Solana hace un uso extensivo de optimizaciones de canalización comunes en el diseño de CPU. Para satisfacer la situación en la que el flujo de datos de entrada se procesa en una serie de pasos y cada paso tiene un hardware diferente responsable de ello. Una analogía típica es una lavadora y secadora que lavan, secan y doblan varias cargas de ropa en secuencia. La limpieza debe realizarse antes del secado y el plegado debe realizarse antes del secado, pero cada una de estas tres operaciones se realiza mediante una unidad separada.
Además, SVM se basa en registros y tiene un conjunto de instrucciones mucho más pequeño que EVM, lo que hace que la ejecución de SVM sea más fácil de probar en ZK. Para resúmenes optimistas, un diseño basado en registros facilita el establecimiento de puntos de control.
1.2.6 Fuel VM——buff stack: máquina virtual paralela bajo el marco UTXO
Proyecto representativo: Combustible
Fuel VM es una mejora basada en el marco técnico de EVM, Solana, WASM y BTC Cosmos. En comparación con EVM, tiene las siguientes características:
Lo más singular es que Fuel no solo establece listas de acceso similares a SVM, sino que también tiene la capacidad de ejecutar transacciones en paralelo con transacciones no superpuestas. También adopta el modelo UTXO, que se divide en token UTXO y contrato UTXO. mejorando la eficiencia del acceso y el rendimiento informático.
Además, Fuel VM proporciona una experiencia de desarrollador potente y fluida a través de su propio lenguaje específico de dominio Sway y la cadena de herramientas de soporte Forc. Su entorno de desarrollo conserva las ventajas de los lenguajes de contrato inteligentes como Solidity, al tiempo que adopta el paradigma introducido en. el ecosistema de herramientas Rust.
En el futuro, Fuel VM también implementará actualizaciones del lenguaje Sway, incluida la optimización del compilador en términos de tamaño de código de bytes, Sway admitirá más backends (el backend de EVM ya está en desarrollo), la abstracción será más económica y habrá más aplicaciones disponibles. Migrar de Solidity/Vyper a Sway, mejorar el análisis de reentrada a nivel de compilador y más.
1.2.7 ESC VM: el sucesor de Ordinal/Smartweave: la capa informática encima de Ethereum
Proyecto representativo: Protocolo de Ethscriptions
ESC VM, o Ethscriptions Virtual Machine, es una solución de contrato inteligente propuesta por Ethscriptions Protocol. El protocolo Ethscriptions en sí es un protocolo similar a BTC Ordinal en la cadena Ethereum, que se centra en explorar alternativas de bajo costo diferentes a los contratos inteligentes y L2.
Las ethscriptions permiten a los usuarios evitar el almacenamiento y la ejecución de contratos inteligentes a un costo muy bajo y aplicar los datos de llamada en Tx para el cálculo a través de las reglas del protocolo acordadas de antemano. En pocas palabras, siempre que haya una transacción de Ethereum exitosa, sus datos de llamada cumplan con las especificaciones de datos válidas especificadas y la dirección "a" única no sea 0, se puede considerar que se ha creado legalmente una Ethscription, la dirección "de" es el creador y el "a" La dirección pertenece al propietario.
Al comienzo del diseño, cada Ethscription prefiere la forma de NFT, como la imagen NFT. El contenido de la imagen se escribe directamente en calldata en formato Base 64:
La ética recientemente popular se basa en la especificación del protocolo brc-20 y se creó con Ethscription:
El contrato inteligente introducido por ESC VM se denomina contrato tonto y se publica como un contrato lógico, pero no interactúa en la cadena en forma de EVM. Además, ESC VM también agrega un comando de computadora de formato especial. Las ethscriptions creadas usando este formato serán reconocidas por ESC VM e interactuarán con contratos tontos, como Implementar - implementar contratos tontos, Llamar - invocar contratos tontos.
Esta solución tiene algunas limitaciones. En primer lugar, la función del contrato tonto no es pagadera, es decir, si desea enviar ETH a través del contrato tonto, debe pasar por un "contrato puente". en sí mismo implica abuso de control y robo de activos; en segundo lugar, existen barreras de entrada al ecosistema, que no permiten la creación arbitraria de contratos tontos, y sus códigos deben definirse a través de la propuesta de gobernanza del Protocolo Ethscriptions.
En resumen, ESC VM es una capa informática construida sobre Ethereum L1 como capa de almacenamiento de datos. Se implementa colocando lógica de contrato, llamadas de contrato, llamadas de contrato y otros contenidos de datos en los datos de llamada de Ethereum ESC VM. El consenso de estado es el consenso del cliente ESC VM, que es similar a la lógica de implementación de SmartWeave de Arweave, excepto que la capa de almacenamiento de datos de SmartWeave es Arweave.
1.2.8 Bit VM: un interesante experimento de investigación: canal de ejecución peer-to-peer en BTC
Proyecto representativo: ZeroSync
El fundador de ZeroSync, Robin Linus, publicó el documento técnico "BitVM: Compute Anything On Bitcoin" el 9 de octubre. Para ser precisos, no es una VM, sino un intento de crear un espacio informático completo de Turing cuyos contratos se almacenan en Bitcoin On-chain. , pero la lógica del contrato se ejecuta fuera de la cadena. Si cree que la otra parte ha incumplido el contrato, puede iniciar una impugnación en la cadena. Si la otra parte no puede responder correctamente, puede retirar todos los fondos del contrato.
La ventaja es que a Bitcoin se le puede dar la integridad de Turing sin ninguna modificación en el protocolo de Bitcoin, sin nuevos códigos de operación, sin bifurcaciones suaves, y se puede aplicar en cualquier momento.
Sus deficiencias también son obvias: en primer lugar, solo admite transacciones entre dos partes (una parte certifica y la otra verifica). En segundo lugar, la creación de un contrato requiere la creación de una gran cantidad de datos y la firma previa de una gran cantidad de transacciones. El almacenamiento de información fuera de la cadena es enorme.
La siguiente es una breve introducción a la lógica técnica:
(1) Haga clic para ingresar al compromiso
El compromiso de entrada puntual permite al probador establecer el valor de entrada 0 o 1 para la puerta lógica. En este compromiso, hay dos valores hash H (A 0) y H (A 1). , como A 0 , el valor de entrada se establece en 0 y, si se revela A 1, el valor de entrada se establece en 1 .
(2) Compromiso de puerta lógica
Una vez que tenga el valor de entrada, puede combinar cualquier puerta lógica en el script de Bitcoin combinando AND, NOT y otros códigos de operación de Bitcoin.
(3) Compromiso del circuito binario
La integridad de Turing se puede lograr componiendo cientos de millones de puertas lógicas en un circuito binario. Para enviar este circuito binario a la red Bitcoin, todas las puertas lógicas deben colocarse en un nodo hoja en una dirección Taproot.
(4) Vínculo desafío-respuesta
No basta con comprometer el circuito en la cadena. Ambas partes necesitan una forma eficaz de verificar que los resultados del cálculo del contrato sean correctos. En un mundo ideal, el contrato se ejecuta fuera de la cadena y ambas partes están felices si cooperan y no tienen disputas sobre el resultado. Sin embargo, si hay una disputa entre las dos partes de la transacción, deben ingresar al enlace de desafío-respuesta para verificar los resultados del cálculo y forzar que el saldo del canal se distribuya a través de scripts de Bitcoin.
Por lo tanto, BitVM está lejos de ser una especie de Bitcoin Rollup o L2, sin un entorno completo de ejecución de máquinas virtuales, un estado global, un lenguaje de alto nivel para publicar contratos inteligentes complejos, ni permite que un número determinado de usuarios interactúen fácilmente con estos contratos. . Usemos un ejemplo muy popular para ilustrar: BitVM es como construir una computadora gigante que es más grande que una habitación en una era en la que todos pueden usar una terminal móvil.
1.2.9 MoveVM: el producto de la herencia genética de Facebook Web2
Proyectos representativos: Aptos, Sui
Move es un lenguaje de programación para escribir contratos inteligentes seguros. Fue desarrollado originalmente por Facebook para brindar soporte a la cadena de bloques Diem. Después de que se suspendió el proyecto de la cadena de bloques Diem, los proyectos representados por Aptos y Sui continuaron usando el lenguaje Move. La característica más importante de Move blockchain es que el almacenamiento de datos utiliza almacenamiento global, que consiste en un árbol con raíz en la dirección de la cuenta. Cada dirección puede almacenar datos de recursos y código de módulo.
Move tiene dos tipos diferentes de programas: módulos y scripts. Los módulos son bibliotecas que definen tipos estructurales y funciones que operan en estos tipos. El tipo de estructura define el modo de almacenamiento global de Move y la función del módulo define las reglas para actualizar el almacenamiento. Los propios módulos también se almacenan en el almacenamiento global. El script es el punto de entrada del archivo ejecutable, similar a la función principal en los lenguajes tradicionales, y es un fragmento de código temporal que no se publica en el almacenamiento global.
En resumen, el módulo Move es similar al módulo de biblioteca dinámica que se carga cuando se ejecuta el archivo ejecutable del sistema, y el script es similar al programa principal. Los usuarios pueden escribir sus propios scripts para acceder al almacenamiento global, incluidos los módulos de llamada, mientras publican módulos o ejecutan scripts a través de Move VM.
1.3 Tendencias del desarrollo ecológico
Ahora que el efecto de la red EVM es tan poderoso, la migración de los usuarios de EVM a una ecología de cadena que no es EVM se ha convertido en el mayor punto de crecimiento para los proyectos blockchain emergentes. Esto traerá una mayor componibilidad de Dapp y una mayor conectividad en el futuro. Varios años desencadenarán usuarios más rápidos. crecimiento.
1.3.1 Compatibilidad del front-end de Wallet
La incorporación de usuarios de EVM a cadenas que no son de EVM ha sido históricamente una barrera importante, pero Metamask Snap lanzado recientemente romperá esa barrera. Los usuarios de EVM pueden seguir usando MetaMask sin cambiar de billetera. Gracias a las contribuciones de código abierto de Drift para construir la excelente implementación de MetaMask Snap, la UX equivale a interactuar con cualquier cadena EVM. Los usuarios de la red principal de Eclipse podrán interactuar con aplicaciones nativas en MetaMask o utilizar carteras nativas de Solana como Salmon.
1.3.2 Compatibilidad del backend de la máquina virtual
1.3.2.1 Traductor/Compilador
Proyecto representativo: Wrap
Warp es un traductor Solidity-Cairo desarrollado por Nethermind, un conocido equipo de infraestructura de Ethereum. Warp puede traducir el código de Solidity a Cairo, pero el programa Cairo traducido a menudo debe modificarse y agregarse funciones de Cairo (como llamar a funciones integradas, optimizar la memoria, etc.) para maximizar la eficiencia de ejecución.
1.3.2.2 Capa de compatibilidad de intérprete de código de bytes/VM
Proyectos representativos: Kakarot, Neon EVM
Kakarot es un intérprete de código de bytes de EVM escrito en El Cairo e implementado en forma de contratos inteligentes implementados en Starknet. Simula la pila, la memoria, la ejecución y otros aspectos de EVM en forma de contratos inteligentes de El Cairo. En comparación con la traducción de código, Kakarot implementa paso a paso el código de operación y la precompilación detrás de EVM, y crea componentes como el Registro de cuentas y el Registro Blockhash para realizar procesamiento adicional en la asignación de direcciones de cuentas, adquisición de información de bloques, etc., lo que permite kakarot para tener una compatibilidad nativa más alta.
Neon EVM es un EVM que se ejecuta como un contrato inteligente y se puede implementar en cualquier cadena SVM. La red principal de Eclipse utiliza SVM como entorno de ejecución, pero brinda compatibilidad total con EVM (incluido el soporte de código de bytes de EVM y Ethereum JSON-RPC) a través de Neon EVM, y el rendimiento es mayor que el de un solo subproceso. Además, cada instancia de Neon EVM tiene su propio mercado de tarifas local, es decir, hay un límite superior en las unidades informáticas relacionadas con la interacción de una sola cuenta de contrato a la altura del bloque (1/4 de las unidades informáticas del bloque), por lo que solo los usuarios necesita interactuar con contratos específicos específicos o debe pagar una tarifa de prioridad cuando el bloque esté lleno. En este sentido, las aplicaciones que implementan sus propios contratos pueden obtener las ventajas de aproximar las cadenas de aplicaciones, reduciendo así el daño a la experiencia del usuario, la seguridad o la liquidez de toda la red causado por la congestión de un tx de interacción de contrato específico.
Referencias:
1. "Kakarotto: Explorando el camino de compatibilidad EVM de Starknet", por Cynic Starknet Astro
2. "BitVM genera una acalorada discusión: ¿puede la red Bitcoin lograr la integridad de Turing?", por Haotian
3. https://ethereum.org/es/developers/docs/evm/
4. "Revisión ecológica y de arquitectura técnica de Starkware", por Maxlion
5. https://twitter.com/muneeb/status/1712461799327416491
6. "Investigación del proyecto 丨 Informe de investigación de combustible de capa de ejecución modular de alta velocidad", de Web3 CN
7. https://www.fuel.network/
8.https://docs.ethscriptions.com/overview/introducing-ethscriptions
9. “Análisis de la primera vulnerabilidad crítica de Aptos Move VM”, por Numen Cyber Labs
10. https://ethereum.org/en/developers/docs/evm/
11. “¿Qué es SVM? La máquina virtual Solana”, por Squads
12. “Presentación de la red principal de Eclipse: Ethereum SVM L2”, por Eclipse
13. https://john-hol.gitbook.io/bitvm/
14.https://bitvm.org/bitvm.pdf
15. “Los diferentes tipos de ZK-EVM”, por Vitalik Buterin
16. “Informe de investigación de Cipholio: Discusión de los planes y el futuro de ZkVM”, por YOLO SHEN, Cipholio Ventures