Ethereum: la EIP-8246 llega al plazo de consulta sobre las quemas de SELFDESTRUCT

Un plazo de revisión, no una activación

La EIP-8246, titulada «Remove SELFDESTRUCT Burn», alcanza el 4 de noviembre de 2026 la fecha de cierre de última consulta indicada en el registro oficial de propuestas de Ethereum. Creado el 1 de mayo por Paweł Bylica, el documento seguía mostrando el estado Last Call durante nuestra lectura. Su objetivo es eliminar los últimos casos en que la instrucción SELFDESTRUCT hace desaparecer ethers del saldo de un contrato. Esta etapa documental no constituye una decisión de despliegue: el texto señala que su aplicación exigiría modificar las reglas de consenso y, por tanto, actualizar la red.

El alcance es limitado. Desde la EIP-6780, los casos afectados corresponden a un contrato creado y sometido a SELFDESTRUCT dentro de la misma transacción. Todavía puede destruirse un saldo cuando el contrato se designa a sí mismo como beneficiario o recibe más ethers después de la instrucción, pero antes de finalizar la transacción. El autor pretende retirar estas excepciones poco utilizadas para simplificar las implementaciones, especificaciones y pruebas de la máquina virtual de Ethereum.

El saldo permanecería tras eliminar el contrato

El cambio propuesto conservaría el saldo cuando el beneficiario sea la propia dirección del contrato. Al finalizar, se borrarían el código y el almacenamiento y el nonce se restablecería a cero, mientras se preservarían los fondos restantes. Una cuenta sin saldo seguiría eliminándose conforme a las reglas existentes. Una cuenta con fondos podría permanecer como cuenta de solo saldo, sin código ejecutable. Los demás comportamientos de SELFDESTRUCT continuarían siendo los descritos por la EIP-6780.

Esta distinción entre el programa y su valor evita confundir la eliminación del código con la desaparición de fondos. Sin embargo, no garantiza que el usuario anterior pueda recuperar libremente el saldo. La propuesta permite recrear un contrato en la misma dirección mediante CREATE2 en una transacción posterior. Los desarrolladores deben examinar las condiciones de redespliegue, en lugar de suponer que una dirección que perdió su código queda inutilizable para siempre o bajo el control de una sola persona.

Algunas redes secundarias necesitarían adaptaciones propias

El documento destaca una diferencia entre Ethereum y determinadas redes secundarias. En el OP Stack, el contrato que transmite mensajes hacia la capa principal utiliza este mecanismo de destrucción para tratar saldos vinculados a las retiradas. Las cadenas que dependen de esa lógica necesitarían un plan de migración separado si adoptaran la modificación. Por tanto, no sería un cambio aplicable mecánicamente a todas las implementaciones compatibles con Ethereum sin revisar sus contratos de sistema y su contabilidad.

La sección de seguridad exige un esfuerzo importante de pruebas, especialmente sobre interacciones entre llamadas, creación de contratos y reversiones de transacciones. También advierte de que una fábrica abierta a todos podría permitir que un tercero recreara una dirección y tomara el saldo conservado si se cumplen las condiciones de CREATE2. La información del 4 de noviembre sigue siendo un plazo de consulta: deberán comprobarse por separado el estado posterior, las pruebas, las posibles adaptaciones y un calendario de activación. La llegada de esta fecha, por sí sola, no demuestra cambios en los saldos de los usuarios.