Salus Insights: Algunas comprobaciones de seguridad imprescindibles para los desarrolladores de proyectos antes de la actualización a Cancún

En pocas palabras: la actualización de Cancún se acerca, y esta actualización incluye principalmente los cambios en la capa ejecutiva propuestos por los seis EIP, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 y EIP-7516. EIP-4844 es el protagonista de esta actualización, que tiene como objetivo mejorar la escalabilidad de Ethereum, reducir el costo de transacción L2 y aumentar la velocidad de transacción. La actualización de Cancún se completó el 17 de enero, el 30 de enero y el 7 de febrero en Ethereum Goerli, Sepolia y Holesky Testnet, y está programada para activarse el 13 de marzo en Ethereum Mainnet. Antes de la actualización, Salus ha recopilado importantes consideraciones de seguridad para esta actualización para que los desarrolladores las comprueben por su cuenta.

Revisión de la propuesta de EIP

Consideraciones de seguridad divulgadas oficialmente

Riesgos asociados a los contratos inteligentes

Leer más

Revisión de la propuesta de EIP

EIP-1153

EIP-1153 introduce el código de operación de almacenamiento efímero, que es un código de operación utilizado para el estado operativo y se comporta de manera casi idéntica al almacenamiento, pero se descarta después de que se completa cada transacción. Esto significa que el almacenamiento temporal no deserializa los valores del almacenamiento y no serializa los valores en el almacenamiento, por lo que el almacenamiento temporal es menos costoso porque no requiere acceso al disco. Con dos nuevos códigos de operación, TLOAD y TSTORE (donde “T” significa “temporal”), Smart Contract puede acceder al almacenamiento temporal. Esta propuesta tiene como objetivo proporcionar una solución dedicada y eficiente para la comunicación entre los marcos de ejecución anidados largos en la ejecución de transacciones de Ethereum.

EIP-4788

EIP-4788 tiene como objetivo exponer las raíces del árbol hash de los bloques de la cadena de balizas a la EVM para permitir el acceso a estas raíces dentro del contrato inteligente. De este modo, se proporciona un acceso sin confianza al estado de la capa de consenso, lo que admite casos de uso prolongado, como grupos de participación, estructuras de replanteo, puentes de contratos inteligentes, mitigación de MEV y más. La propuesta almacena estas raíces a través de un contrato inteligente y utiliza un búfer de anillo para limitar el consumo de almacenamiento, lo que garantiza que cada bloque de ejecución solo necesite un corto constante para representar esta información.

EIP-4844

EIP-4844 presenta un nuevo formato de transacción llamado “Sharding Blob Transactions” diseñado para escalar la disponibilidad de datos de Ethereum de una manera simple y compatible con el futuro. Esta propuesta lo hace mediante la introducción de “transacciones portadoras de blobs” que contienen una gran cantidad de datos a los que no se puede acceder mediante la ejecución de EVM, pero que pueden acceder a sus promesas. Este formato es totalmente compatible con el formato utilizado por el particionamiento completo en el futuro, lo que proporciona un alivio temporal pero significativo para el escalado continuo.

EIP-5656

EIP-5656 presenta una nueva instrucción EVM, MCOPY, para la replicación eficiente de regiones de memoria. Esta propuesta tiene como objetivo eliminar la sobrecarga de realizar operaciones de copia de memoria en la EVM al permitir directamente la replicación de datos entre la memoria a través de la instrucción MCOPY. MCOPY PERMITE QUE LA DIRECCIÓN DE ORIGEN Y DE DESTINO SE SUPERPONGA, ESTÁ DISEÑADO TENIENDO EN CUENTA LA COMPATIBILIDAD CON VERSIONES ANTERIORES Y ESTÁ DISEÑADO PARA MEJORAR LA EFICIENCIA DE LA EJECUCIÓN EN ESCENARIOS LARGOS, INCLUIDA LA CONSTRUCCIÓN DE ESTRUCTURAS DE DATOS, EL ACCESO EFICAZ A OBJETOS EN MEMORIA Y LA REPLICACIÓN.

EIP-6780

EIP-6780 modifica la funcionalidad del código de operación SELFDESTRUCT. En esta propuesta, SELFDESTRUCT solo eliminaría la cuenta y transferiría todo el Ether en la misma transacción en la que se creó el contrato, excepto que cuando se ejecutara SELFDESTRUCT, el contrato no se eliminaría, sino que simplemente transferiría todo el Ether al destino especificado. Este cambio está destinado a acomodar el uso de árboles Verkle en el futuro, y está destinado a simplificar las implementaciones de EVM y reducir la complejidad de los cambios de estado, al tiempo que conserva algunos de los escenarios comunes utilizados por SELFDESTRUCT.

EIP-7516

EIP-7516 presenta una nueva instrucción EVM, BLOBBASEFEE, que devuelve el valor de la tarifa base del blob en la ejecución del bloque actual. Esta directiva es similar al código de operación BASEFEE de EIP-3198, excepto que devuelve la tarifa base de blob definida por EIP-4844. Esta característica permite que el contrato considere mediante programación el precio del gas de los datos de blobs, por ejemplo, permitiendo que los contratos acumulativos calculen de forma confiable el costo de usar datos de blobs, o que implementen futuros de gas de blob basados en esto para suavizar los costos de los datos de blobs.

Consideraciones de seguridad divulgadas oficialmente

EIP-1153

Los desarrolladores de contratos inteligentes deben comprender el ciclo de vida de las variables de almacenamiento transitorias antes de usarlas. Dado que el almacenamiento temporal se borra automáticamente al final de una transacción, los desarrolladores de contratos inteligentes pueden intentar evitar despejar las ranuras durante las llamadas para ahorrar gas. Sin embargo, esto puede impedir una mayor interacción con el contrato en la misma transacción (por ejemplo, en el caso de un bloqueo de reentrada) o causar otros errores, por lo que los desarrolladores de contratos inteligentes deben tener cuidado de conservar valores distintos de cero solo cuando se reserva la ranura temporal. Destinado a ser utilizado por futuras llamadas en la misma transacción. SSTORE De lo contrario, estos códigos de operación se comportan exactamente igual que SLOAD, por lo que se aplican todas las consideraciones de seguridad comunes, especialmente cuando se trata de riesgos de reentrada.

Los desarrolladores de contratos inteligentes también pueden intentar utilizar el almacenamiento transitorio como alternativa a la asignación de memoria. Deben tener en cuenta que el almacenamiento efímero no se descarta como la memoria cuando la llamada se devuelve o se reanuda, y la memoria debe priorizarse en estos casos de uso para evitar un comportamiento inesperado al volver a entrar en la misma transacción. El almacenamiento transitorio en la memoria es necesariamente costoso, lo que debería haber evitado este patrón de uso. El uso prolongado de la asignación en memoria se puede lograr mejor con listas de entrada ordenadas por claves, y la asignación en memoria rara vez se requiere en Smart Contract (es decir, el autor sabe que no hay casos de uso conocidos en producción).

EIP-4844

Este EIP aumenta el requisito de ancho de banda en aproximadamente 0,75 MB a un máximo de longitud por bloque de baliza. Esto es un 40% más grande que el tamaño de bloque máximo teórico actual (30 M Gas / 16 Gas por byte de datos de llamada = 1,875 M bytes), por lo que no aumenta significativamente el ancho de banda en el peor de los casos. Después de la fusión, el tiempo del bloque es estático en lugar de una distribución de Poisson impredecible, lo que proporciona un período de tiempo garantizado para la propagación del bloque grande.

Incluso con datos de llamadas limitados, la carga sostenida de este EIP es mucho menor que las alternativas que pueden reducir el costo de los datos de llamadas, ya que no es necesario almacenar blobs durante el tiempo que dure la carga de ejecución. Esto permite implementar una directiva en la que estos blobs deben conservarse durante al menos un período de tiempo determinado. El valor específico seleccionado es la época MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, que es de aproximadamente 18 días, con una latencia de Long en comparación con la rotación de un año recomendada (pero aún no implementada) del historial de carga útil de ejecución.

EIP-5656

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

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

EIP-6780

LAS SIGUIENTES APLICACIONES DE SELFDESTRUCT SE VERÁN COMPROMETIDAS Y LAS APLICACIONES QUE LO USEN DE ESTA MANERA YA NO SERÁN SEGURAS:

WhereCREATE 2 se utiliza para volver a implementar el contrato en la misma ubicación para que el contrato se pueda actualizar. Esta función ya no es compatible y, en su lugar, se debe utilizar ERC-2535 u otro tipo de contrato proxy.

Si el contrato se basa en la quema de Ether tomando el contrato SELFDESTRUCT como beneficiario, el contrato no se crea en la misma transacción.

Riesgos asociados a los contratos inteligentes

EIP 1153

Considere dos escenarios con el código de operación TLOAD y TSTORE:

1. El contrato convocado utiliza el Código de Operación
2. El código de operación se utiliza para iniciar el contrato de compra

Riesgo 1 :

En comparación con el SSTORE y SLOAD tradicionales, el nuevo almacenamiento transitorio cambia principalmente el período de almacenamiento de los datos, los datos almacenados por el tstore se leen a través del tload y los datos se liberarán después de la ejecución de una transacción, en lugar de escribirse en el contrato a medida que el almacén se registra permanentemente. Los desarrolladores deben reconocer las características del Código de Operación al usar el Código de Operación, a fin de evitar pérdidas causadas por el uso incorrecto de datos que no se pueden escribir correctamente en el contrato. Además, los datos de la tienda son una variable privada y solo pueden ser accedidos por el propio contrato. Si desea utilizar los datos externamente, solo puede pasarlos como parámetro o prepararlos en una variable de almacenamiento público.

Riesgo 2 :

Otro riesgo potencial es que si los desarrolladores de contratos inteligentes no gestionan adecuadamente el ciclo de vida de las variables de almacenamiento transitorias, podría dar lugar a que los datos se purguen o se conserven incorrectamente en momentos indebidos. Si un contrato espera usar datos almacenados en almacenamiento transitorio en llamadas posteriores a una transacción, pero no administra correctamente el ciclo de vida de esos datos, los datos pueden compartirse por error o perderse entre diferentes llamadas, lo que resulta en errores lógicos o violaciones de seguridad. Teniendo en cuenta que los datos de saldo o asignación de un proyecto de Token similar no se almacenan correctamente, dará lugar a errores en la lógica del contrato y causará pérdidas. O el uso de este Código de Operación al establecer la Dirección del propietario provocará que la Dirección privilegiada no se registre correctamente, perdiendo así la modificación de parámetros importantes del contrato.

Considere un contrato inteligente que utiliza almacenamiento transitorio para registrar temporalmente los precios de las transacciones en una plataforma de negociación de criptoactivos. El contrato actualiza el precio a medida que se completa cada transacción y permite a los usuarios consultar el último precio durante un corto período de tiempo. Sin embargo, si el diseño del contrato no tiene en cuenta el hecho de que el almacenamiento transitorio se autoriza automáticamente al final de la operación, el usuario puede obtener un precio erróneo u obsoleto en el período comprendido entre el final de una operación y el comienzo de la siguiente. Esto no solo puede llevar a los usuarios a tomar decisiones basadas en información errónea, sino que también puede ser explotada maliciosamente, afectando la reputación de la plataforma y la seguridad de los activos de los usuarios.

EIP-6780

La propuesta cambia el comportamiento anterior del código de operación de autodestrucción, no destruyendo el contrato, solo transfiriendo el token, y solo se destruirá el contrato creado en la misma transacción que la autodestrucción. El impacto de esta EIP es relativamente grande.

Vuelva a implementar el contrato en la misma dirección con create 2 para actualizar el contrato. Esta función ya no es compatible y, en su lugar, se debe utilizar ERC-2535 u otro tipo de contrato proxy. (Esto puede afectar a la seguridad de los contratos on-chain que utilizan create 2 para implementar contratos escalables)

La operación SELFDESTRUCT en el contrato inteligente permite que el contrato se destruya y el saldo del contrato se envíe a la dirección de destino especificada. En este caso, el contrato utiliza SELFDESTRUCT para quemar Ether y envía el Ether quemado al contrato. Sin embargo, el contrato solo puede ser un contrato creado en la misma transacción (un contrato creado por este contrato u otro contrato en la misma transacción). De lo contrario, solo se transferirá el Ether sin destruir el contrato (por ejemplo, se autodestruye y el beneficiario es un contrato que se autodestruye, lo que no cambiará nada). Esto afectará a cualquier contrato que dependa de la autodestrucción para retiros u otras operaciones.

Un token de gas similar al token CHI de 1inch funciona: mantenga un desplazamiento, ejecute siempre CREATE 2 o SELFDESTRUCT en ese desplazamiento. Después de esta actualización, si el contrato con el desplazamiento actual aún no se ha autodestruido correctamente, el CREATE 2 posterior no podrá implementar correctamente el contrato.

La implementación de esta propuesta no conducirá a un ataque directo al contrato, pero dañará la lógica normal del contrato desplegado original que se basa en la operación de autodestrucción (el contrato que solo se basa en la autodestrucción para la transferencia de fondos no se verá afectado, y si la operación posterior debe requerir que se elimine el contrato de autodestrucción, se verá afectado), lo que dará como resultado que el contrato no funcione según lo previsto, y solo para el contrato y los usuarios, puede provocar la huelga del contrato, la pérdida de fondos y otros daños (como el uso original de create 2). Implemente un nuevo contrato en la dirección original y el contrato que autodestruye el contrato original para la actualización ya no se puede implementar correctamente). A largo plazo, la capacidad de modificar un código de operación puede dar lugar a problemas de centralización.

Por ejemplo, hay una bóveda de contrato de almacén existente para actualizar:

• Crear 2 El contrato de almacenamiento temporal se utiliza para reservar temporalmente fondos para la bóveda
• Contrato de bóveda de autodestrucción, transferencia de fondos a contrato temporal (solo se transfieren fondos, no se quema ningún contrato)
• Nuevo contrato de bóveda en la creación de la dirección original 2 (error porque el contrato de bóveda original no se destruyó)
• Contrato temporal de autodestrucción para devolver fondos a la bóveda (pérdida de fondos, no se creó el contrato de bóveda)

Leer más

La actualización de Cancún mejorará aún más la ventaja competitiva de Ethereum. Sin embargo, esta actualización supone un riesgo para los cambios en la capa central del contrato inteligente, lo que afectará al funcionamiento seguro de las DApps existentes. En el proceso de desarrollo de contratos inteligentes, también hay que prestar mucha atención a estos cambios y a los riesgos que puedan surgir. Puede ponerse en contacto con Salus para realizar comprobaciones de riesgos o asistencia en auditorías, o puede seguir leyendo para comprender los cambios.

Especificación de actualización de la red de Cancún

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Contrato Metapod

Contrato de GasToken 2