9 de las 10 principales cadenas de TVL admiten contratos inteligentes de EVM.
Título original: "Cómo utilizar EVM bifurcados para riesgos de seguridad"
Artículo: Ethan Pociask,Eric Meng,Nadir Akhtar,Gabriela Melendez Quan,Tom Ryan
Compilador: Katie Koo
Para fortalecer las garantías de seguridad y custodia para los clientes que comercializan ERC-20 y otros activos basados en contratos inteligentes, el equipo de Coinbase Blockchain Security investigó la capa programática que define el comportamiento de estos activos: la máquina virtual Ethereum (EVM). Al evaluar proyectos que modifican el EVM de su propia red, el equipo de seguridad de blockchain de Coinbase revisa los cambios clave de EVM para determinar si el EVM modificado puede proporcionar las mismas garantías de seguridad y custodia que la implementación original de EVM.
Estado de EVM de horquilla
A partir de mayo de 2023, Ethereum Virtual Machine (EVM) ganó el título de "Gran Hermano" de la plataforma de ejecución de contratos inteligentes más popular. Según DefiLlama, 9 de las 10 cadenas principales de Total Value Locked (TVL) admiten contratos inteligentes EVM. Por lo tanto, una comprensión profunda de EVM es crucial para respaldar los contratos inteligentes en todo el ecosistema de blockchain.
EVM es una máquina virtual para la ejecución descentralizada de contratos inteligentes en la red Ethereum. Muchas cadenas de bloques compatibles con EVM aprovechan las implementaciones estándar de los populares clientes de implementación de Ethereum en diferentes idiomas, como go-ethereum (Golang) y besu (Java) directamente en su software de protocolo.
Dicho esto, bifurcar y modificar el EVM es bastante común en el ecosistema de la cadena de bloques, incluso dentro de los principales protocolos. Por ejemplo, Optimism Bedrock Stack que "alimenta" la cadena de bloques Base L2 de Coinbase utiliza una bifurcación del cliente de ejecución go-ethereum llamada op-geth, que ejecuta el mismo EVM que el popular cliente de ejecución ethereum compatible. Sin embargo, esto no significa que el EVM en Ethereum se comporte exactamente igual que el EVM en Optimism: el EVM op-geth se comporta de manera ligeramente diferente en algunos casos (es decir, la DIFICULTAD que devuelve valores aleatorios está determinada por el secuenciador).
Si bien esto suena aterrador, generalmente es beneficioso para la adopción de EVM. Si bien la implementación estándar de EVM está altamente optimizada para el protocolo base de Ethereum, las EVM bifurcadas a menudo la amplían para nuevos protocolos propios. Como resultado, los contratos pueden ejecutarse de manera diferente en algunas cadenas compatibles con EVM que en Ethereum, y las suposiciones de seguridad del comportamiento de los contratos inteligentes de EVM también pueden variar ampliamente entre diferentes protocolos.
Bifurcar el marco de seguridad de EVM
Con este fin, Coinbase ha desarrollado un marco de seguridad Web3 para evaluar el impacto en la seguridad de algunas implementaciones de EVM bifurcadas. Lo llamamos marco EVM bifurcado de Coinbase, que se explicará en detalle a continuación.
Con este marco de seguridad EVM bifurcado, Coinbase puede efectivamente:
Comprender la invalidez de los supuestos de seguridad de nuestro marco de token Ethereum nos permite habilitar de manera segura nuevas cadenas de bloques compatibles con EVM para admitir tokens ERC-20/ERC-721 en nuestros intercambios descentralizados;
Proporcionar a los auditores de contratos inteligentes un análisis de la situación de vulnerabilidad de los contratos inteligentes del EVM bifurcado, especialmente las pequeñas diferencias en la red cruzada;
Garantizar el uso y la ejecución seguros de los contratos inteligentes de EVM en la cadena de bloques Base L2 de Coinbase.
Estándar de seguridad para cadenas de bloques compatibles con EVM
Para entender cómo existen los riesgos de seguridad en la máquina virtual de Ethereum, primero debemos saber qué garantías nos brinda la implementación estándar de EVM. Definimos el EVM estándar como el EVM utilizado de manera constante por los clientes de ejecución del validador de Ethereum, tal como se describe en la Especificación de implementación de Ethereum. Con mucho, el cliente más utilizado es go ethereum (es decir, geth).
Resumimos la seguridad en dos criterios de seguridad que representan los requisitos mínimos para que cualquier implementación de EVM bifurcada sea elegible para el soporte de Coinbase.
¿Cómo auditamos los riesgos de seguridad de una implementación de EVM?
Nuestro marco EVM bifurcado se centra en los siguientes requisitos de auditoría al evaluar el cumplimiento de los criterios generales de seguridad (es decir, inmutabilidad del contrato y un entorno de ejecución seguro). Cabe señalar que los siguientes componentes de riesgo no son el alcance completo de la auditoría EVM de la bifurcación.
La modificación de la definición y la codificación de los códigos de operación EVM puede generar diferencias significativas en la forma en que se ejecutan los contratos. Por ejemplo, supongamos que alguna implementación EVM bifurcada (EVM') cambia el código de operación ADD aritmético para definir la lógica (x1 + x2) para restar dos valores (x1 - x2).
Como resultado, la EVM' desviada es desigual e incompatible en su ejecución con la EVM estándar. Las consecuencias de modificar los códigos de operación pueden ser un comportamiento beneficioso, como evitar el desbordamiento y el subdesbordamiento de enteros en los códigos de operación aritméticos, o un comportamiento más peligroso, como el comportamiento de autodestrucción que provoca la acuñación infinita de activos locales.
EVM usa contratos precompilados para definir funciones complejas (como funciones de encriptación), usando un lenguaje más conveniente y eficaz como Golang, en lugar de usar el código de bytes de EVM menos accesible.
Fundamentalmente, estas son funciones programadas a las que se accede a través de direcciones de cadena predeterminadas representadas en el software del nodo. Hay 9 precompiladores definidos en el Libro amarillo de Ethereum (a partir de mayo de 2023), y cualquier cambio en estos 9 precompiladores o la introducción de nuevos precompiladores debe auditarse.
Tomemos otro ejemplo concreto: la vulnerabilidad de BNB Smart Chain. BNB Smart Chain utiliza una implementación desviada de go-ethereum para ejecutar nodos. Con este fin, se presentan dos nuevos contratos precompilados (tmHeaderValidate, iavlMerkleProofValidate) para utilizar software de terceros (es decir, SDK de Cosmos) para realizar la validación de bloques de clientes ligeros y la validación de pruebas de Merkle. El problema es que el software Cosmos SDK tiene un error de implementación en su representación de árbol IAWL que permite que las pruebas criptográficamente inválidas pasen la verificación. En otras palabras, cualquiera puede generar dinero de la nada. Los atacantes pudieron explotar esta falla de implementación anidada en el precompilador iavlMerkleProofValidate para desviar cientos de millones de dólares del puente de cadena cruzada de Binance.
Este ejemplo de explotación pretende demostrar la necesidad de seguridad del precompilador y los riesgos potenciales de introducir nuevos contratos precompilados para desviarse de las implementaciones de EVM.
Los riesgos potencialmente fatales de introducir precompiladores adicionales incluyen:
Permitir que una de las partes modifique unilateralmente el estado de cualquier contrato implementado;
Esto incluye todas las modificaciones de almacenamiento (inserciones, actualizaciones, eliminaciones);
uso de dependencias de terceros no confiables, no verificadas o no auditadas;
Proporciona acceso al valor dentro del nodo indeterminado.
A pesar de tratar el compilador y el EVM como entidades completamente separadas, vale la pena señalar que el compilador de Solidity hace suposiciones estrictas sobre el comportamiento de los tres primeros contratos precompilados (ecrecover, sha256 y &ripemd) que se pasan a través de Solidity La función de palabra clave del idioma nativo representación en el lenguaje. Detrás de escena, el compilador de Solidity en realidad procesa estas palabras clave en código de bytes, que ejecuta llamadas estáticas entre contratos. El siguiente diagrama ilustra aún más esta forma de comunicación entre contratos.
Los riesgos de seguridad introducidos al modificar el precompilador estándar incluyen:
Permitir que las contrapartes centralizadas modifiquen unilateralmente el estado de cualquier contrato implementado;
Esto incluye todas las modificaciones de almacenamiento (inserciones, actualizaciones, eliminaciones);
La suposición de la posición de precompilación del compilador de Solidity es inconsistente;
Proporciona acceso a valores dentro de nodos indeterminados;
Uso de dependencias de terceros no confiables, no verificadas o no auditadas.
Los principales riesgos que plantea la modificación de los componentes fundamentales de la EVM incluyen:
no restringe la pila del intérprete para que sea infinitamente grande;
Cambiar el tamaño o cambiar el modelo de memoria puede conducir a una ejecución no determinista;
Evitar el control de acceso, lo que permite que cualquier contraparte acceda unilateralmente a todos los estados de la cadena;
Uso de dependencias de terceros no confiables, no verificadas o no auditadas.
¿Por qué debemos prestar atención a la seguridad de EVM?
Nuestro objetivo es construir un sistema financiero abierto basado en la tecnología blockchain y, con este fin, fomentamos el desarrollo de varias implementaciones de EVM. Sin embargo, para que Coinbase admita completamente una cadena de bloques compatible con EVM, debe cumplir con los requisitos básicos de una implementación estándar de EVM. Este documento espera generar conciencia sobre los riesgos asociados con la desviación de EVM y alentar a los emisores de activos a priorizar el desarrollo de componentes seguros cuando se desvían de EVM, aumentando la conciencia de seguridad en todo el ecosistema Web3.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
¿Cómo evaluar el riesgo de seguridad de "EVM bifurcado"?
Título original: "Cómo utilizar EVM bifurcados para riesgos de seguridad"
Artículo: Ethan Pociask,Eric Meng,Nadir Akhtar,Gabriela Melendez Quan,Tom Ryan
Compilador: Katie Koo
Para fortalecer las garantías de seguridad y custodia para los clientes que comercializan ERC-20 y otros activos basados en contratos inteligentes, el equipo de Coinbase Blockchain Security investigó la capa programática que define el comportamiento de estos activos: la máquina virtual Ethereum (EVM). Al evaluar proyectos que modifican el EVM de su propia red, el equipo de seguridad de blockchain de Coinbase revisa los cambios clave de EVM para determinar si el EVM modificado puede proporcionar las mismas garantías de seguridad y custodia que la implementación original de EVM.
Estado de EVM de horquilla
A partir de mayo de 2023, Ethereum Virtual Machine (EVM) ganó el título de "Gran Hermano" de la plataforma de ejecución de contratos inteligentes más popular. Según DefiLlama, 9 de las 10 cadenas principales de Total Value Locked (TVL) admiten contratos inteligentes EVM. Por lo tanto, una comprensión profunda de EVM es crucial para respaldar los contratos inteligentes en todo el ecosistema de blockchain.
EVM es una máquina virtual para la ejecución descentralizada de contratos inteligentes en la red Ethereum. Muchas cadenas de bloques compatibles con EVM aprovechan las implementaciones estándar de los populares clientes de implementación de Ethereum en diferentes idiomas, como go-ethereum (Golang) y besu (Java) directamente en su software de protocolo.
Dicho esto, bifurcar y modificar el EVM es bastante común en el ecosistema de la cadena de bloques, incluso dentro de los principales protocolos. Por ejemplo, Optimism Bedrock Stack que "alimenta" la cadena de bloques Base L2 de Coinbase utiliza una bifurcación del cliente de ejecución go-ethereum llamada op-geth, que ejecuta el mismo EVM que el popular cliente de ejecución ethereum compatible. Sin embargo, esto no significa que el EVM en Ethereum se comporte exactamente igual que el EVM en Optimism: el EVM op-geth se comporta de manera ligeramente diferente en algunos casos (es decir, la DIFICULTAD que devuelve valores aleatorios está determinada por el secuenciador).
Si bien esto suena aterrador, generalmente es beneficioso para la adopción de EVM. Si bien la implementación estándar de EVM está altamente optimizada para el protocolo base de Ethereum, las EVM bifurcadas a menudo la amplían para nuevos protocolos propios. Como resultado, los contratos pueden ejecutarse de manera diferente en algunas cadenas compatibles con EVM que en Ethereum, y las suposiciones de seguridad del comportamiento de los contratos inteligentes de EVM también pueden variar ampliamente entre diferentes protocolos.
Bifurcar el marco de seguridad de EVM
Con este fin, Coinbase ha desarrollado un marco de seguridad Web3 para evaluar el impacto en la seguridad de algunas implementaciones de EVM bifurcadas. Lo llamamos marco EVM bifurcado de Coinbase, que se explicará en detalle a continuación.
Con este marco de seguridad EVM bifurcado, Coinbase puede efectivamente:
Estándar de seguridad para cadenas de bloques compatibles con EVM
Para entender cómo existen los riesgos de seguridad en la máquina virtual de Ethereum, primero debemos saber qué garantías nos brinda la implementación estándar de EVM. Definimos el EVM estándar como el EVM utilizado de manera constante por los clientes de ejecución del validador de Ethereum, tal como se describe en la Especificación de implementación de Ethereum. Con mucho, el cliente más utilizado es go ethereum (es decir, geth).
Resumimos la seguridad en dos criterios de seguridad que representan los requisitos mínimos para que cualquier implementación de EVM bifurcada sea elegible para el soporte de Coinbase.
¿Cómo auditamos los riesgos de seguridad de una implementación de EVM?
Nuestro marco EVM bifurcado se centra en los siguientes requisitos de auditoría al evaluar el cumplimiento de los criterios generales de seguridad (es decir, inmutabilidad del contrato y un entorno de ejecución seguro). Cabe señalar que los siguientes componentes de riesgo no son el alcance completo de la auditoría EVM de la bifurcación.
La modificación de la definición y la codificación de los códigos de operación EVM puede generar diferencias significativas en la forma en que se ejecutan los contratos. Por ejemplo, supongamos que alguna implementación EVM bifurcada (EVM') cambia el código de operación ADD aritmético para definir la lógica (x1 + x2) para restar dos valores (x1 - x2).
Como resultado, la EVM' desviada es desigual e incompatible en su ejecución con la EVM estándar. Las consecuencias de modificar los códigos de operación pueden ser un comportamiento beneficioso, como evitar el desbordamiento y el subdesbordamiento de enteros en los códigos de operación aritméticos, o un comportamiento más peligroso, como el comportamiento de autodestrucción que provoca la acuñación infinita de activos locales.
EVM usa contratos precompilados para definir funciones complejas (como funciones de encriptación), usando un lenguaje más conveniente y eficaz como Golang, en lugar de usar el código de bytes de EVM menos accesible.
Fundamentalmente, estas son funciones programadas a las que se accede a través de direcciones de cadena predeterminadas representadas en el software del nodo. Hay 9 precompiladores definidos en el Libro amarillo de Ethereum (a partir de mayo de 2023), y cualquier cambio en estos 9 precompiladores o la introducción de nuevos precompiladores debe auditarse.
Tomemos otro ejemplo concreto: la vulnerabilidad de BNB Smart Chain. BNB Smart Chain utiliza una implementación desviada de go-ethereum para ejecutar nodos. Con este fin, se presentan dos nuevos contratos precompilados (tmHeaderValidate, iavlMerkleProofValidate) para utilizar software de terceros (es decir, SDK de Cosmos) para realizar la validación de bloques de clientes ligeros y la validación de pruebas de Merkle. El problema es que el software Cosmos SDK tiene un error de implementación en su representación de árbol IAWL que permite que las pruebas criptográficamente inválidas pasen la verificación. En otras palabras, cualquiera puede generar dinero de la nada. Los atacantes pudieron explotar esta falla de implementación anidada en el precompilador iavlMerkleProofValidate para desviar cientos de millones de dólares del puente de cadena cruzada de Binance.
Este ejemplo de explotación pretende demostrar la necesidad de seguridad del precompilador y los riesgos potenciales de introducir nuevos contratos precompilados para desviarse de las implementaciones de EVM.
Los riesgos potencialmente fatales de introducir precompiladores adicionales incluyen:
A pesar de tratar el compilador y el EVM como entidades completamente separadas, vale la pena señalar que el compilador de Solidity hace suposiciones estrictas sobre el comportamiento de los tres primeros contratos precompilados (ecrecover, sha256 y &ripemd) que se pasan a través de Solidity La función de palabra clave del idioma nativo representación en el lenguaje. Detrás de escena, el compilador de Solidity en realidad procesa estas palabras clave en código de bytes, que ejecuta llamadas estáticas entre contratos. El siguiente diagrama ilustra aún más esta forma de comunicación entre contratos.
Los riesgos de seguridad introducidos al modificar el precompilador estándar incluyen:
Los principales riesgos que plantea la modificación de los componentes fundamentales de la EVM incluyen:
¿Por qué debemos prestar atención a la seguridad de EVM?
Nuestro objetivo es construir un sistema financiero abierto basado en la tecnología blockchain y, con este fin, fomentamos el desarrollo de varias implementaciones de EVM. Sin embargo, para que Coinbase admita completamente una cadena de bloques compatible con EVM, debe cumplir con los requisitos básicos de una implementación estándar de EVM. Este documento espera generar conciencia sobre los riesgos asociados con la desviación de EVM y alentar a los emisores de activos a priorizar el desarrollo de componentes seguros cuando se desvían de EVM, aumentando la conciencia de seguridad en todo el ecosistema Web3.