*Forward the Original Title：坎昆升级前，项目开发者必看的几项安全检查

TL;DR: Con la próxima actualización de Cancún, se incluyen seis cambios propuestos por EIP, principalmente EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 y EIP-7516. EIP-4844 se centra en mejorar la escalabilidad de Ethereum, reducir los costos de transacción y acelerar las transacciones para las soluciones de Capa 2. La actualización ha sido probada en testnets de Ethereum y está programada para su activación en la mainnet el 13 de marzo. Salus ha recopilado importantes consideraciones de seguridad para que los desarrolladores las revisen antes de la actualización.

Revisión de Propuestas de EIP

Consideraciones de seguridad oficiales

Riesgos relacionados con contratos inteligentes

Más lecturas

Revisión de Propuestas EIP

EIP-1153

EIP-1153 introduce opcodes de almacenamiento temporal, que se utilizan para manipular el estado de una manera similar al almacenamiento, pero con el almacenamiento temporal descartado después de cada transacción. Esto significa que el almacenamiento temporal no deserializa valores del almacenamiento, ni serializa valores en el almacenamiento, lo que resulta en costos más bajos debido a la evitación del acceso al disco. Con la introducción de dos nuevas opcodes, TLOAD y TSTORE (donde "T" significa "temporal"), los contratos inteligentes pueden acceder al almacenamiento temporal. Esta propuesta tiene como objetivo proporcionar una solución dedicada y eficiente para la comunicación entre múltiples marcos de ejecución anidados durante la ejecución de transacciones en Ethereum.

EIP-4788

EIP-4788 tiene como objetivo exponer las raíces del árbol hash de los bloques de la cadena de balizas al EVM, permitiendo que estas raíces se accedan dentro de contratos inteligentes. Esto permite acceder al estado de la capa de consenso sin confianza, apoyando varios casos de uso como pools de participación, estructuras de reinversión, puentes de contratos inteligentes y mitigación de MEV. La propuesta logra esto almacenando estas raíces en un contrato inteligente y utilizando un búfer circular para limitar el consumo de almacenamiento, asegurando que cada bloque de ejecución requiere solo espacio constante para representar esta información.

EIP-4844

EIP-4844 introduce un nuevo formato de transacción llamado "Transacciones de Bloque de Fragmento" diseñado para ampliar la disponibilidad de datos de Ethereum de manera simple y compatible con versiones anteriores. Esta propuesta logra su objetivo al introducir "transacciones de transporte de bloques" que contienen grandes cantidades de datos a los que no se puede acceder mediante el EVM, pero sí a través de sus compromisos. Este formato es totalmente compatible con el formato utilizado por futuros fragmentos completos, proporcionando un alivio temporal pero significativo para la escalabilidad de rollup.

EIP-5656

EIP-5656 introduce una nueva instrucción EVM, MCOPY, para copiar eficientemente regiones de memoria. Esta propuesta tiene como objetivo reducir la sobrecarga de las operaciones de copia de memoria en el EVM mediante la copia directa de datos entre memorias utilizando la instrucción MCOPY. MCOPY permite la superposición de direcciones de origen y destino, está diseñado con la compatibilidad hacia atrás en mente y tiene como objetivo mejorar la eficiencia de ejecución en varios escenarios, incluida la construcción de estructuras de datos, el acceso eficiente y la copia de objetos de memoria.

EIP-6780

EIP-6780 modifica la funcionalidad del opcode SELFDESTRUCT. En esta propuesta, SELFDESTRUCT solo elimina cuentas y transfiere todo el ether en la misma transacción que la creación del contrato. Además, al ejecutar SELFDESTRUCT, el contrato no se eliminará, pero transferirá todo el ether a un destino especificado. Este cambio se adapta al uso futuro de los árboles Verkle, con el objetivo de simplificar la implementación de EVM, reducir la complejidad de los cambios de estado, y al mismo tiempo retener algunos casos de uso comunes de SELFDESTRUCT.

EIP-7516

EIP-7516 introduce una nueva instrucción EVM, BLOBBASEFEE, para devolver el valor de la tarifa base para los bloques en la ejecución del bloque actual. Esta instrucción es similar a la operación BASEFEE introducida en EIP-3198, con la diferencia de que devuelve la tarifa base de blob definida de acuerdo con EIP-4844. Esta funcionalidad permite a los contratos considerar programáticamente el precio del gas de los datos de blob, lo que permite a los contratos de rollup calcular los costos de uso de los datos de blob sin confianza o implementar futuros de gas de blob para suavizar los costos de los datos de blob.

Consideraciones de seguridad oficiales

EIP-1153

Los desarrolladores de contratos inteligentes deben comprender el ciclo de vida de las variables de almacenamiento transitorio antes de usarlas. Dado que el almacenamiento temporal se borra automáticamente al final de una transacción, los desarrolladores de contratos inteligentes podrían intentar evitar borrar los espacios durante una llamada para ahorrar gas. Sin embargo, esto podría evitar una interacción adicional con el contrato en la misma transacción (por ejemplo, en el caso de bloqueos recursivos) o llevar a otros errores. Por lo tanto, los desarrolladores de contratos inteligentes deben ser cautelosos y retener solo valores no nulos cuando el espacio de almacenamiento temporal esté reservado para llamadas futuras dentro de la misma transacción. De lo contrario, el comportamiento de estos opcodes es idéntico a SLOAD y SSTORE, por lo que se aplican todas las consideraciones de seguridad comunes, especialmente en lo que respecta a los riesgos de reentrancia.

Los desarrolladores de contratos inteligentes también pueden intentar usar almacenamiento transitorio como alternativa al mapeo de memoria. Deben ser conscientes de que el almacenamiento transitorio no se descarta como la memoria cuando se devuelve una llamada o se revierte, y deben priorizar la memoria en dichos casos de uso para evitar comportamientos inesperados durante la reentrada en la misma transacción. El alto costo del almacenamiento transitorio en memoria debería desalentar este patrón de uso. La mayoría de los casos de uso para mapeos en memoria se pueden implementar de manera más efectiva a través de una lista ordenada de entradas por clave, y el almacenamiento transitorio en mapeos de memoria rara vez es necesario en contratos inteligentes (es decir, no hay casos de uso conocidos en producción).

EIP-4844

Esta EIP aumenta los requisitos de ancho de banda para cada bloque de baliza en hasta aproximadamente 0.75 MB. Esto es un aumento del 40% sobre el tamaño máximo teórico de los bloques de hoy (30M Gas / 16 Gas por byte de calldata = 1.875M bytes), por lo que no aumenta significativamente el ancho de banda en escenarios de peor caso. Después de la fusión, los tiempos de bloque son estáticos en lugar de distribuidos de manera impredecible de Poisson, lo que proporciona un marco de tiempo garantizado para la propagación de bloques grandes.

Incluso con datos de llamadas limitados, la carga sostenida de esta EIP es significativamente menor que las soluciones alternativas que podrían reducir el costo de los datos de llamadas porque el almacenamiento de blobs no necesita ser retenido durante la misma duración que la carga de ejecución. Esto hace posible implementar estrategias que requieran que estos blobs se retengan al menos durante un período de tiempo. El valor específico elegido es el MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, que es aproximadamente 18 días, mucho más corto que el tiempo de rotación propuesto (pero aún no implementado) de un año para ejecutar historias de carga válidas.

EIP-5656

Los clientes deben tener en cuenta que sus implementaciones no utilizan búferes intermedios (por ejemplo, la función memmove de la biblioteca estándar de C no utiliza búferes intermedios), ya que esto es un vector potencial de denegación de servicio (DoS). La mayoría de las funciones integradas del lenguaje/funciones de biblioteca estándar utilizadas para mover bytes tienen las características de rendimiento correctas aquí.

Además, el análisis de los ataques de denegación de servicio (DoS) y de agotamiento de memoria es el mismo que para otros códigos de operación que tocan la memoria, ya que la expansión de la memoria sigue las mismas reglas de precios.

EIP-6780

Las siguientes aplicaciones de SELFDESTRUCT se romperán, y las aplicaciones que lo utilizan de esta manera ya no son seguras:

Donde se utiliza CREATE2 para volver a implementar un contrato en la misma ubicación y hacer contratos actualizables. Esta funcionalidad ya no es compatible y debe ser reemplazada por ERC-2535 u otros tipos de contratos proxy.

Si un contrato depende de quemar ether a un contrato a través de SELFDESTRUCT como beneficiario, el contrato no se crea en la misma transacción.

Riesgos relacionados con contratos inteligentes

EIP1153

Considere dos escenarios usando los opcodes TLOAD y TSTORE:

1. Los contratos llamados utilizan estos opcodes.
2. Llamar a contratos utiliza estos opcodes.

Riesgo 1:

En comparación con SSTORE y SLOAD tradicionales, la introducción de almacenamiento transitorio cambia principalmente la duración de almacenamiento de los datos. Los datos almacenados por TSTORE se leen a través de TLOAD y se liberarán después de la ejecución de una transacción, en lugar de ser registrados permanentemente en el contrato como SSTORE. Los desarrolladores deben comprender las características de estos opcodes al usarlos para evitar usarlos incorrectamente, lo que puede resultar en que los datos no se escriban correctamente en el contrato, causando pérdidas. Además, los datos almacenados por TSTORE son privados y solo pueden ser accedidos por el contrato mismo. Si se requiere un acceso externo a estos datos, deben ser pasados a través de parámetros o almacenados temporalmente en una variable de almacenamiento pública.

Riesgo 2:

Otro riesgo potencial es que si los desarrolladores de contratos inteligentes no gestionan correctamente el ciclo de vida de las variables de almacenamiento transitorio, puede dar lugar a que los datos se borren en momentos inapropiados o se retengan incorrectamente. Si un contrato espera usar datos almacenados en almacenamiento transitorio en llamadas posteriores de una transacción pero no logra gestionar correctamente el ciclo de vida de estos datos, puede compartir o perder datos erróneamente entre diferentes llamadas, lo que resulta en errores lógicos o vulnerabilidades de seguridad. La falla en almacenar datos correctamente, como el saldo o los datos de autorización en proyectos de tokens, puede causar errores de lógica en los contratos, provocando pérdidas. Del mismo modo, el uso de estos opcodes para establecer la dirección del propietario puede resultar en que la dirección privilegiada no se registre correctamente, lo que lleva a la pérdida de modificaciones a parámetros importantes del contrato.

Considere un contrato inteligente que utiliza almacenamiento transitorio para registrar temporalmente el precio de la transacción en una plataforma de negociación de criptomonedas. El contrato actualiza el precio después de cada transacción y permite a los usuarios consultar el precio más reciente en un corto período. Sin embargo, si el diseño del contrato no considera la eliminación automática del almacenamiento transitorio al final de una transacción, puede haber un período entre el final de una transacción y el inicio de la siguiente donde los usuarios pueden recibir un precio incorrecto o desactualizado. Esto no solo podría llevar a los usuarios a tomar decisiones basadas en información incorrecta, sino que también podría ser explotado maliciosamente, afectando la reputación de la plataforma y la seguridad de los activos de los usuarios.

EIP-6780

Esta propuesta cambia el comportamiento del opcode anterior de autodestrucción, donde el contrato no se quema, sino que solo ocurre la transferencia de tokens, y solo se quemarán los contratos creados en la misma transacción que el contrato de autodestrucción. El impacto de este EIP es relativamente significativo.

El uso de create2 para volver a implementar contratos en la misma dirección para actualizaciones de contratos ya no es compatible. Esta funcionalidad debería ser reemplazada por ERC-2535 u otros tipos de contratos proxy. (Esto puede afectar la seguridad de contratos on-chainimplementando contratos actualizables usando create2).

La operación SELFDESTRUCT en contratos inteligentes permite que los contratos sean quemados, y el saldo del contrato se envíe a una dirección de destino especificada. En este caso, el contrato usa SELFDESTRUCT para quemar Ether y envía el Ether quemado al contrato. Sin embargo, este contrato solo debe crearse en la misma transacción que otros contratos (contratos creados por este contrato u otros contratos en la misma transacción). De lo contrario, Ether solo se transferirá sin quemar el contrato (por ejemplo, selfdestruct con el beneficiario siendo el contrato selfdestruct, lo que no producirá cambios). Esto afectará a todos contratosque confían en la función de autodestrucción para retiros u otras operaciones.

Un token de gas similar al token CHI de 1 pulgada funciona de la siguiente manera: manteniendo un desplazamiento, siempre implementando CREATE2 o SELFDESTRUCT en este desplazamiento. Después de esta actualización, si el contrato en el desplazamiento actual no se ha autodestruido correctamente, los CREATE2 posteriores no podrán implementar contratos con éxito.

Esta implementación de propuesta no puede atacar directamente contratos, pero dañará la lógica normal de contratos existentes que dependen de operaciones de autodestrucción (los contratos que solo dependen de autodestrucción para transferencias de fondos no se ven afectados, pero los contratos que requieren operaciones posteriores para eliminar contratos de autodestrucción se ven afectados), causando que los contratos funcionen inesperadamente, y puede provocar conflictos de contratos, pérdida de fondos, etc. (por ejemplo, los contratos que originalmente usaban create2 para implementar nuevos contratos en la dirección original y autodestruían el contrato original para la actualización, ya no pueden implementarse con éxito). A largo plazo, modificar la funcionalidad de un opcode puede provocar problemas de centralización.

Por ejemplo, existe un contrato de bóveda existente para actualizaciones:

• Los contratos de almacenamiento temporales, create2, se utilizan para reservar temporalmente fondos para la bóveda.
• Autodestruir el contrato de la bóveda, transfiriendo fondos al contrato temporal (solo se transfieren fondos sin quemar el contrato).
• Crear un nuevo contrato de bóveda en la dirección original usando create2 (falla porque el contrato de bóveda original no ha sido quemado).
• Autodestruir el contrato temporal para devolver los fondos a la bóveda (fondos perdidos, el contrato de la bóveda no ha sido creado).

Lectura extendida:

La actualización de Cancún mejorará aún más la ventaja competitiva de Ethereum. Sin embargo, los cambios en la capa central del contrato inteligente en esta actualización conllevan riesgos que afectarán la operación segura de las DApps existentes. Durante el desarrollo del contrato inteligente, estos cambios y los posibles riesgos que puedan traer deben ser monitoreados de cerca. Puede contactar a Salus para verificar los riesgos o recibir apoyo en la auditoría, o para obtener más información y comprender los cambios.

Especificación de actualización de la red Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

contrato de Metapod

contrato GasToken2

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [GateAicoin], Forward the Original Title‘Salus Insights：坎昆升级前，项目开发者必看的几项安全检查’. All copyrights belong to the original author [*Odaily Planeta Diario]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Aprenderequipo y lo resolverán rápidamente.
2. Responsabilidad Descargo: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.