#eip
eip
14,120 visualizaciones
64 participa(n) en el debate
Populares
Novedades
·
--
En la comunidad de Ethereum ha surgido un borrador de EIP con una idea de diseño muy ingeniosa: usar «códigos de operación versionados» para volver a fijar los precios del gas sin afectar a ningún contrato ya desplegado.
El mecanismo central tiene tres niveles:
1｜Separar lo nuevo de lo antiguo. Los contratos recién desplegados deben usar códigos de operación V2 y ejecutar la nueva tabla de precios del gas establecida por EIP-8037/8038; los contratos existentes siguen usando la tabla antigua, de modo que el comportamiento histórico en la cadena permanece inalterado.
2｜Eliminar la introspección del gas. El conjunto de códigos de operación V2 no incluye códigos de consulta como GAS y GASLIMIT. Si el bytecode contiene alguno de ellos, el despliegue se revierte de inmediato. Esto equivale a prohibir que los contratos dependan del «gas restante» para tomar decisiones lógicas, allanando el camino para ajustar libremente los precios en el futuro.
3｜Las llamadas también tienen versión. Se añade DELEGATECALL_V2, cuyo comportamiento es similar al de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada falla de inmediato. Así se evita que los contratos nuevos invoquen por error lógica de versiones anteriores.
En esencia, esta propuesta convierte el «ajuste de los costes del gas» de una actualización de toda la red que afecta profundamente a todo, en una operación rutinaria que se implementa gradualmente según la versión de cada contrato. La compatibilidad con versiones anteriores queda garantizada por el protocolo. Los usuarios comunes como $ETH apenas lo notarán, mientras que los desarrolladores de contratos deberán estar atentos al ritmo de adaptación de las futuras herramientas V2.
Texto original del borrador: https://github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #TarifasDeGas
En la comunidad de Ethereum ha surgido un borrador de EIP con una idea de diseño muy ingeniosa: usar «códigos de operación versionados» para volver a fijar los precios del gas sin afectar a ningún contrato ya desplegado.
El mecanismo central tiene tres niveles:
1｜Separar lo nuevo de lo antiguo. Los contratos recién desplegados deben usar códigos de operación V2 y ejecutar la nueva tabla de precios del gas establecida por EIP-8037/8038; los contratos existentes siguen usando la tabla antigua, de modo que el comportamiento histórico en la cadena permanece inalterado.
2｜Eliminar la introspección del gas. El conjunto de códigos de operación V2 no incluye códigos de consulta como GAS y GASLIMIT. Si el bytecode contiene alguno de ellos, el despliegue se revierte de inmediato. Esto equivale a prohibir que los contratos dependan del «gas restante» para tomar decisiones lógicas, allanando el camino para ajustar libremente los precios en el futuro.
3｜Las llamadas también tienen versión. Se añade DELEGATECALL_V2, cuyo comportamiento es similar al de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada falla de inmediato. Así se evita que los contratos nuevos invoquen por error lógica de versiones anteriores.
En esencia, esta propuesta convierte el «ajuste de los costes del gas» de una actualización de toda la red que afecta profundamente a todo, en una operación rutinaria que se implementa gradualmente según la versión de cada contrato. La compatibilidad con versiones anteriores queda garantizada por el protocolo. Los usuarios comunes como $ETH apenas lo notarán, mientras que los desarrolladores de contratos deberán estar atentos al ritmo de adaptación de las futuras herramientas V2.
Texto original del borrador: https://github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #TarifasDeGas
El mecanismo central tiene tres niveles:
1｜Separar lo nuevo de lo antiguo. Los contratos recién desplegados deben usar códigos de operación V2 y ejecutar la nueva tabla de precios del gas establecida por EIP-8037/8038; los contratos existentes siguen usando la tabla antigua, de modo que el comportamiento histórico en la cadena permanece inalterado.
2｜Eliminar la introspección del gas. El conjunto de códigos de operación V2 no incluye códigos de consulta como GAS y GASLIMIT. Si el bytecode contiene alguno de ellos, el despliegue se revierte de inmediato. Esto equivale a prohibir que los contratos dependan del «gas restante» para tomar decisiones lógicas, allanando el camino para ajustar libremente los precios en el futuro.
3｜Las llamadas también tienen versión. Se añade DELEGATECALL_V2, cuyo comportamiento es similar al de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada falla de inmediato. Así se evita que los contratos nuevos invoquen por error lógica de versiones anteriores.
En esencia, esta propuesta convierte el «ajuste de los costes del gas» de una actualización de toda la red que afecta profundamente a todo, en una operación rutinaria que se implementa gradualmente según la versión de cada contrato. La compatibilidad con versiones anteriores queda garantizada por el protocolo. Los usuarios comunes como $ETH apenas lo notarán, mientras que los desarrolladores de contratos deberán estar atentos al ritmo de adaptación de las futuras herramientas V2.
Texto original del borrador: https://github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #TarifasDeGas
58
·
--
Ethereum quiere añadir «números de versión» a la EVM.
Un nuevo borrador de EIP propone «opcodes versionados para reprecificar el gas». La idea central, en una frase: los opcodes se dividen en versiones y funcionan en paralelo; los contratos antiguos siguen usando la tabla de tarifas de gas anterior, mientras que los nuevos contratos desplegados deben usar los opcodes V2 y seguir las nuevas tablas de tarifas de EIP-8037/8038. Ambos conjuntos de reglas no interfieren entre sí y son compatibles con versiones anteriores.
Algunos detalles que los desarrolladores deberían tener en cuenta:
1. El conjunto de opcodes V2 elimina directamente opcodes de introspección del gas como GAS y GASLIMIT. Si un nuevo contrato incluye alguno de ellos, el despliegue se revierte. La lógica detrás de esto es que, si un contrato depende de «cuánto gas queda» para tomar decisiones, cualquier cambio futuro en las tarifas podría romperlo.
2. Se añade DELEGATECALL_V2, cuyo comportamiento es similar al de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada falla de inmediato. Es como añadir un control de versión a las llamadas entre contratos.
3. El objetivo de todo este diseño es que, cuando Ethereum ajuste los costes del gas en el futuro, ya no tenga que andar con pies de plomo: el aislamiento por versiones separa el margen para las actualizaciones de la seguridad de los contratos existentes, en lugar de hacer que cada cambio de tarifas afecte a todo el ecosistema.
En esencia, se trata de poner al día la EVM para que funcione como un «sistema de software evolutivo». La propuesta todavía está en fase de borrador y falta mucho para que se incluya en una actualización de la red principal, pero vale la pena seguir de cerca esta dirección.
#以太坊 #EIP #EVM
Ethereum quiere añadir «números de versión» a la EVM.
Un nuevo borrador de EIP propone «opcodes versionados para reprecificar el gas». La idea central, en una frase: los opcodes se dividen en versiones y funcionan en paralelo; los contratos antiguos siguen usando la tabla de tarifas de gas anterior, mientras que los nuevos contratos desplegados deben usar los opcodes V2 y seguir las nuevas tablas de tarifas de EIP-8037/8038. Ambos conjuntos de reglas no interfieren entre sí y son compatibles con versiones anteriores.
Algunos detalles que los desarrolladores deberían tener en cuenta:
1. El conjunto de opcodes V2 elimina directamente opcodes de introspección del gas como GAS y GASLIMIT. Si un nuevo contrato incluye alguno de ellos, el despliegue se revierte. La lógica detrás de esto es que, si un contrato depende de «cuánto gas queda» para tomar decisiones, cualquier cambio futuro en las tarifas podría romperlo.
2. Se añade DELEGATECALL_V2, cuyo comportamiento es similar al de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada falla de inmediato. Es como añadir un control de versión a las llamadas entre contratos.
3. El objetivo de todo este diseño es que, cuando Ethereum ajuste los costes del gas en el futuro, ya no tenga que andar con pies de plomo: el aislamiento por versiones separa el margen para las actualizaciones de la seguridad de los contratos existentes, en lugar de hacer que cada cambio de tarifas afecte a todo el ecosistema.
En esencia, se trata de poner al día la EVM para que funcione como un «sistema de software evolutivo». La propuesta todavía está en fase de borrador y falta mucho para que se incluya en una actualización de la red principal, pero vale la pena seguir de cerca esta dirección.
#以太坊 #EIP #EVM
Un nuevo borrador de EIP propone «opcodes versionados para reprecificar el gas». La idea central, en una frase: los opcodes se dividen en versiones y funcionan en paralelo; los contratos antiguos siguen usando la tabla de tarifas de gas anterior, mientras que los nuevos contratos desplegados deben usar los opcodes V2 y seguir las nuevas tablas de tarifas de EIP-8037/8038. Ambos conjuntos de reglas no interfieren entre sí y son compatibles con versiones anteriores.
Algunos detalles que los desarrolladores deberían tener en cuenta:
1. El conjunto de opcodes V2 elimina directamente opcodes de introspección del gas como GAS y GASLIMIT. Si un nuevo contrato incluye alguno de ellos, el despliegue se revierte. La lógica detrás de esto es que, si un contrato depende de «cuánto gas queda» para tomar decisiones, cualquier cambio futuro en las tarifas podría romperlo.
2. Se añade DELEGATECALL_V2, cuyo comportamiento es similar al de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada falla de inmediato. Es como añadir un control de versión a las llamadas entre contratos.
3. El objetivo de todo este diseño es que, cuando Ethereum ajuste los costes del gas en el futuro, ya no tenga que andar con pies de plomo: el aislamiento por versiones separa el margen para las actualizaciones de la seguridad de los contratos existentes, en lugar de hacer que cada cambio de tarifas afecte a todo el ecosistema.
En esencia, se trata de poner al día la EVM para que funcione como un «sistema de software evolutivo». La propuesta todavía está en fase de borrador y falta mucho para que se incluya en una actualización de la red principal, pero vale la pena seguir de cerca esta dirección.
#以太坊 #EIP #EVM
65
·
--
Ethereum ha publicado discretamente un borrador de EIP que podría afectar al ciclo de vida de los contratos durante la próxima década: abrir el camino para volver a fijar el precio del Gas mediante «códigos de operación versionados».
La lógica central tiene tres partes:
1. Los contratos recién desplegados deben usar los códigos de operación V2 y ejecutar la nueva tabla de tarifas de Gas de EIP-8037/8038; los contratos ya desplegados seguirán usando la tabla antigua, sin alterar su comportamiento.
2. El conjunto de códigos de operación V2 elimina directamente instrucciones de introspección del Gas como GAS y GASLIMIT. Si el bytecode contiene estos códigos de operación, el despliegue se revertirá.
3. Se añade DELEGATECALL_V2, cuya semántica es similar a la de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada fallará de inmediato.
¿Por qué debería interesarles a los desarrolladores? Hasta ahora, la mayor preocupación al ajustar los costes de Gas en Ethereum era que «cambiar los precios equivale a cambiar el comportamiento de los contratos existentes». Los protocolos que dependían de suposiciones de Gas codificadas de forma rígida ya han sufrido las consecuencias en varias ocasiones. Con el versionado, los contratos antiguos se mantienen bajo las reglas antiguas y la nueva lógica entra en vigor con las nuevas: por primera vez, la actualización y la compatibilidad tienen límites claros.
El coste también es evidente: se elimina deliberadamente la capacidad de introspección del Gas, por lo que los diseños que dependen de leer en tiempo real el Gas restante en la cadena deberán adaptarse con antelación. Además, el requisito de versión de DELEGATECALL_V2 obligará a los contratos proxy, las firmas múltiples y los monederos inteligentes a revisar toda la cadena de llamadas.
Por ahora sigue siendo un borrador en fase de PR. Aún debe superar varias etapas de revisión, pruebas y bifurcaciones duras antes de llegar a la red principal, pero la dirección ya está clara: Ethereum está convirtiendo la «EVM actualizable» de un eslogan en un diseño de mecanismos. Los titulares de $ETH no necesitan hacer nada a corto plazo; se recomienda a los desarrolladores leer cuanto antes el texto original y evaluar el coste de la migración.
#以太坊 #EIP #Gas
Ethereum ha publicado discretamente un borrador de EIP que podría afectar al ciclo de vida de los contratos durante la próxima década: abrir el camino para volver a fijar el precio del Gas mediante «códigos de operación versionados».
La lógica central tiene tres partes:
1. Los contratos recién desplegados deben usar los códigos de operación V2 y ejecutar la nueva tabla de tarifas de Gas de EIP-8037/8038; los contratos ya desplegados seguirán usando la tabla antigua, sin alterar su comportamiento.
2. El conjunto de códigos de operación V2 elimina directamente instrucciones de introspección del Gas como GAS y GASLIMIT. Si el bytecode contiene estos códigos de operación, el despliegue se revertirá.
3. Se añade DELEGATECALL_V2, cuya semántica es similar a la de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada fallará de inmediato.
¿Por qué debería interesarles a los desarrolladores? Hasta ahora, la mayor preocupación al ajustar los costes de Gas en Ethereum era que «cambiar los precios equivale a cambiar el comportamiento de los contratos existentes». Los protocolos que dependían de suposiciones de Gas codificadas de forma rígida ya han sufrido las consecuencias en varias ocasiones. Con el versionado, los contratos antiguos se mantienen bajo las reglas antiguas y la nueva lógica entra en vigor con las nuevas: por primera vez, la actualización y la compatibilidad tienen límites claros.
El coste también es evidente: se elimina deliberadamente la capacidad de introspección del Gas, por lo que los diseños que dependen de leer en tiempo real el Gas restante en la cadena deberán adaptarse con antelación. Además, el requisito de versión de DELEGATECALL_V2 obligará a los contratos proxy, las firmas múltiples y los monederos inteligentes a revisar toda la cadena de llamadas.
Por ahora sigue siendo un borrador en fase de PR. Aún debe superar varias etapas de revisión, pruebas y bifurcaciones duras antes de llegar a la red principal, pero la dirección ya está clara: Ethereum está convirtiendo la «EVM actualizable» de un eslogan en un diseño de mecanismos. Los titulares de $ETH no necesitan hacer nada a corto plazo; se recomienda a los desarrolladores leer cuanto antes el texto original y evaluar el coste de la migración.
#以太坊 #EIP #Gas
La lógica central tiene tres partes:
1. Los contratos recién desplegados deben usar los códigos de operación V2 y ejecutar la nueva tabla de tarifas de Gas de EIP-8037/8038; los contratos ya desplegados seguirán usando la tabla antigua, sin alterar su comportamiento.
2. El conjunto de códigos de operación V2 elimina directamente instrucciones de introspección del Gas como GAS y GASLIMIT. Si el bytecode contiene estos códigos de operación, el despliegue se revertirá.
3. Se añade DELEGATECALL_V2, cuya semántica es similar a la de DELEGATECALL, pero exige que code_version del contrato de destino sea ≥ 2; de lo contrario, la llamada fallará de inmediato.
¿Por qué debería interesarles a los desarrolladores? Hasta ahora, la mayor preocupación al ajustar los costes de Gas en Ethereum era que «cambiar los precios equivale a cambiar el comportamiento de los contratos existentes». Los protocolos que dependían de suposiciones de Gas codificadas de forma rígida ya han sufrido las consecuencias en varias ocasiones. Con el versionado, los contratos antiguos se mantienen bajo las reglas antiguas y la nueva lógica entra en vigor con las nuevas: por primera vez, la actualización y la compatibilidad tienen límites claros.
El coste también es evidente: se elimina deliberadamente la capacidad de introspección del Gas, por lo que los diseños que dependen de leer en tiempo real el Gas restante en la cadena deberán adaptarse con antelación. Además, el requisito de versión de DELEGATECALL_V2 obligará a los contratos proxy, las firmas múltiples y los monederos inteligentes a revisar toda la cadena de llamadas.
Por ahora sigue siendo un borrador en fase de PR. Aún debe superar varias etapas de revisión, pruebas y bifurcaciones duras antes de llegar a la red principal, pero la dirección ya está clara: Ethereum está convirtiendo la «EVM actualizable» de un eslogan en un diseño de mecanismos. Los titulares de $ETH no necesitan hacer nada a corto plazo; se recomienda a los desarrolladores leer cuanto antes el texto original y evaluar el coste de la migración.
#以太坊 #EIP #Gas
66
La comunidad de desarrolladores principales de Ethereum vuelve a moverse: un borrador de EIP titulado «Códigos de operación versionados para volver a fijar los precios del Gas» se ha publicado oficialmente en el foro para recabar comentarios. La idea central es añadir números de versión a los códigos de operación, de modo que los futuros ajustes del coste del Gas no requieran una bifurcación dura que rompa los contratos ya desplegados.
En concreto, el borrador tiene varios puntos clave:
Primero, coexistencia de versiones nuevas y antiguas, con compatibilidad hacia atrás. Los contratos recién desplegados deben usar códigos de operación V2 y seguir la nueva tabla de Gas definida por EIP-8037/8038; los contratos existentes que ya están en producción seguirán usando la tabla antigua y su comportamiento no cambiará. En la práctica, el impacto de las «subidas de precio» queda aislado en los contratos nuevos.
Segundo, el conjunto de códigos de operación V2 elimina deliberadamente GAS, GASLIMIT y otros códigos de operación que permiten inspeccionar el Gas. Si el bytecode de un contrato nuevo incluye alguno de ellos, el despliegue se revertirá directamente. La lógica de la comunidad de desarrolladores es que, si un contrato depende demasiado de calcular con precisión el Gas restante, cualquier cambio de precios futuro podría desencadenar fallos en cadena. Es mejor cortar esa dependencia desde el origen.
Tercero, se añade DELEGATECALL_V2. Su semántica es similar a la del DELEGATECALL clásico, pero exige que el code_version del contrato de destino sea al menos 2; de lo contrario, la llamada falla de inmediato. Así se evita que los contratos nuevos invoquen por error lógica antigua y queden sujetos a supuestos obsoletos sobre el Gas.
En conjunto, se trata de un diseño de bajo nivel que prepara el terreno para que Ethereum pueda evolucionar a largo plazo: el precio del Gas nunca ha sido un parámetro estático, y los códigos de operación versionados ofrecen al protocolo una vía de ajuste gradual que «solo afecta a los contratos nuevos, sin repercutir en los antiguos». Para los desarrolladores, lo que habrá que seguir de cerca es cuándo se actualizarán las herramientas de migración y las reglas de auditoría; para los usuarios comunes, la experiencia en la cadena no cambiará a corto plazo, aunque esto podría influir profundamente en la forma de escribir contratos inteligentes en los próximos años.
#以太坊 #EIP
La comunidad de desarrolladores principales de Ethereum vuelve a moverse: un borrador de EIP titulado «Códigos de operación versionados para volver a fijar los precios del Gas» se ha publicado oficialmente en el foro para recabar comentarios. La idea central es añadir números de versión a los códigos de operación, de modo que los futuros ajustes del coste del Gas no requieran una bifurcación dura que rompa los contratos ya desplegados.
En concreto, el borrador tiene varios puntos clave:
Primero, coexistencia de versiones nuevas y antiguas, con compatibilidad hacia atrás. Los contratos recién desplegados deben usar códigos de operación V2 y seguir la nueva tabla de Gas definida por EIP-8037/8038; los contratos existentes que ya están en producción seguirán usando la tabla antigua y su comportamiento no cambiará. En la práctica, el impacto de las «subidas de precio» queda aislado en los contratos nuevos.
Segundo, el conjunto de códigos de operación V2 elimina deliberadamente GAS, GASLIMIT y otros códigos de operación que permiten inspeccionar el Gas. Si el bytecode de un contrato nuevo incluye alguno de ellos, el despliegue se revertirá directamente. La lógica de la comunidad de desarrolladores es que, si un contrato depende demasiado de calcular con precisión el Gas restante, cualquier cambio de precios futuro podría desencadenar fallos en cadena. Es mejor cortar esa dependencia desde el origen.
Tercero, se añade DELEGATECALL_V2. Su semántica es similar a la del DELEGATECALL clásico, pero exige que el code_version del contrato de destino sea al menos 2; de lo contrario, la llamada falla de inmediato. Así se evita que los contratos nuevos invoquen por error lógica antigua y queden sujetos a supuestos obsoletos sobre el Gas.
En conjunto, se trata de un diseño de bajo nivel que prepara el terreno para que Ethereum pueda evolucionar a largo plazo: el precio del Gas nunca ha sido un parámetro estático, y los códigos de operación versionados ofrecen al protocolo una vía de ajuste gradual que «solo afecta a los contratos nuevos, sin repercutir en los antiguos». Para los desarrolladores, lo que habrá que seguir de cerca es cuándo se actualizarán las herramientas de migración y las reglas de auditoría; para los usuarios comunes, la experiencia en la cadena no cambiará a corto plazo, aunque esto podría influir profundamente en la forma de escribir contratos inteligentes en los próximos años.
#以太坊 #EIP
En concreto, el borrador tiene varios puntos clave:
Primero, coexistencia de versiones nuevas y antiguas, con compatibilidad hacia atrás. Los contratos recién desplegados deben usar códigos de operación V2 y seguir la nueva tabla de Gas definida por EIP-8037/8038; los contratos existentes que ya están en producción seguirán usando la tabla antigua y su comportamiento no cambiará. En la práctica, el impacto de las «subidas de precio» queda aislado en los contratos nuevos.
Segundo, el conjunto de códigos de operación V2 elimina deliberadamente GAS, GASLIMIT y otros códigos de operación que permiten inspeccionar el Gas. Si el bytecode de un contrato nuevo incluye alguno de ellos, el despliegue se revertirá directamente. La lógica de la comunidad de desarrolladores es que, si un contrato depende demasiado de calcular con precisión el Gas restante, cualquier cambio de precios futuro podría desencadenar fallos en cadena. Es mejor cortar esa dependencia desde el origen.
Tercero, se añade DELEGATECALL_V2. Su semántica es similar a la del DELEGATECALL clásico, pero exige que el code_version del contrato de destino sea al menos 2; de lo contrario, la llamada falla de inmediato. Así se evita que los contratos nuevos invoquen por error lógica antigua y queden sujetos a supuestos obsoletos sobre el Gas.
En conjunto, se trata de un diseño de bajo nivel que prepara el terreno para que Ethereum pueda evolucionar a largo plazo: el precio del Gas nunca ha sido un parámetro estático, y los códigos de operación versionados ofrecen al protocolo una vía de ajuste gradual que «solo afecta a los contratos nuevos, sin repercutir en los antiguos». Para los desarrolladores, lo que habrá que seguir de cerca es cuándo se actualizarán las herramientas de migración y las reglas de auditoría; para los usuarios comunes, la experiencia en la cadena no cambiará a corto plazo, aunque esto podría influir profundamente en la forma de escribir contratos inteligentes en los próximos años.
#以太坊 #EIP
56
Ethereum va a ponerle «números de versión» a la EVM.
Un nuevo borrador de EIP propone «opcodes versionados para reajustar el precio del Gas». La idea central es que los contratos desplegados a partir de ahora utilicen los opcodes V2 y una nueva tabla de costes de Gas (EIP-8037/8038), mientras que los contratos antiguos ya desplegados sigan utilizando las reglas anteriores. Ambos sistemas funcionarían de forma independiente, lo que permitiría mantener la compatibilidad con versiones anteriores al ajustar los costes de Gas.
Vale la pena prestar atención a varios detalles del diseño:
1. El conjunto de opcodes V2 elimina directamente GAS, GASLIMIT y otros opcodes de introspección del Gas. Si un contrato nuevo incluye estas instrucciones, el despliegue se revertirá; precisamente este tipo de instrucciones ha hecho que los cambios históricos en el precio del Gas puedan afectar fácilmente a los contratos ya existentes.
2. Se añade DELEGATECALL_V2, que se comporta de forma similar a DELEGATECALL, pero exige que code_version ≥ 2 en el contrato de destino; de lo contrario, la llamada falla de inmediato. Así se evitan ambigüedades semánticas en las llamadas delegadas entre versiones.
3. El objetivo general es uno solo: que los futuros ajustes de los costes de Gas ya no sean un «cambio radical de una sola vez mediante un hard fork», sino una transición gradual según la versión del contrato, sin romper las suposiciones de los contratos ya desplegados.
En otras palabras, Ethereum está intentando dotar a la EVM de un mecanismo de evolución similar al control de versiones de software. Si el borrador sale adelante y se implementa, mejorará notablemente la capacidad de actualización a largo plazo de la EVM. Para $ETH , también supondría una mejora sustancial en la infraestructura subyacente.
Texto original del borrador: github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #EVM
Ethereum va a ponerle «números de versión» a la EVM.
Un nuevo borrador de EIP propone «opcodes versionados para reajustar el precio del Gas». La idea central es que los contratos desplegados a partir de ahora utilicen los opcodes V2 y una nueva tabla de costes de Gas (EIP-8037/8038), mientras que los contratos antiguos ya desplegados sigan utilizando las reglas anteriores. Ambos sistemas funcionarían de forma independiente, lo que permitiría mantener la compatibilidad con versiones anteriores al ajustar los costes de Gas.
Vale la pena prestar atención a varios detalles del diseño:
1. El conjunto de opcodes V2 elimina directamente GAS, GASLIMIT y otros opcodes de introspección del Gas. Si un contrato nuevo incluye estas instrucciones, el despliegue se revertirá; precisamente este tipo de instrucciones ha hecho que los cambios históricos en el precio del Gas puedan afectar fácilmente a los contratos ya existentes.
2. Se añade DELEGATECALL_V2, que se comporta de forma similar a DELEGATECALL, pero exige que code_version ≥ 2 en el contrato de destino; de lo contrario, la llamada falla de inmediato. Así se evitan ambigüedades semánticas en las llamadas delegadas entre versiones.
3. El objetivo general es uno solo: que los futuros ajustes de los costes de Gas ya no sean un «cambio radical de una sola vez mediante un hard fork», sino una transición gradual según la versión del contrato, sin romper las suposiciones de los contratos ya desplegados.
En otras palabras, Ethereum está intentando dotar a la EVM de un mecanismo de evolución similar al control de versiones de software. Si el borrador sale adelante y se implementa, mejorará notablemente la capacidad de actualización a largo plazo de la EVM. Para $ETH , también supondría una mejora sustancial en la infraestructura subyacente.
Texto original del borrador: github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #EVM
Un nuevo borrador de EIP propone «opcodes versionados para reajustar el precio del Gas». La idea central es que los contratos desplegados a partir de ahora utilicen los opcodes V2 y una nueva tabla de costes de Gas (EIP-8037/8038), mientras que los contratos antiguos ya desplegados sigan utilizando las reglas anteriores. Ambos sistemas funcionarían de forma independiente, lo que permitiría mantener la compatibilidad con versiones anteriores al ajustar los costes de Gas.
Vale la pena prestar atención a varios detalles del diseño:
1. El conjunto de opcodes V2 elimina directamente GAS, GASLIMIT y otros opcodes de introspección del Gas. Si un contrato nuevo incluye estas instrucciones, el despliegue se revertirá; precisamente este tipo de instrucciones ha hecho que los cambios históricos en el precio del Gas puedan afectar fácilmente a los contratos ya existentes.
2. Se añade DELEGATECALL_V2, que se comporta de forma similar a DELEGATECALL, pero exige que code_version ≥ 2 en el contrato de destino; de lo contrario, la llamada falla de inmediato. Así se evitan ambigüedades semánticas en las llamadas delegadas entre versiones.
3. El objetivo general es uno solo: que los futuros ajustes de los costes de Gas ya no sean un «cambio radical de una sola vez mediante un hard fork», sino una transición gradual según la versión del contrato, sin romper las suposiciones de los contratos ya desplegados.
En otras palabras, Ethereum está intentando dotar a la EVM de un mecanismo de evolución similar al control de versiones de software. Si el borrador sale adelante y se implementa, mejorará notablemente la capacidad de actualización a largo plazo de la EVM. Para $ETH , también supondría una mejora sustancial en la infraestructura subyacente.
Texto original del borrador: github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #EVM
56
El investigador de la Fundación Ethereum frisitano presentó un borrador de EIP cuyo objetivo es actualizar PeerDAS con una configuración «sin confianza» y resistencia cuántica.
Cambio principal: sustituir los compromisos y las pruebas KZG de los Blob por compromisos de Merkle Keccak-256 y rutas de autenticación. Después, una prueba LeanDA STARK recalculará la raíz de Merkle, verificará la relación de codificación Reed-Solomon y confirmará que los compromisos coinciden con los datos. Esto eliminará la dependencia de una configuración de confianza de KZG y, al mismo tiempo, reforzará la seguridad frente a la computación cuántica futura.
El borrador también introduce Blob de tamaño variable: la longitud en bytes debe estar entre 2048 y 524288, ser una potencia de 2 y divisible por 128 columnas. Las transacciones de la capa de ejecución pasarán a incluir (merkle_root, byte_length) en lugar de un hash versionado; también se ajustarán la capa de red y el cálculo de Gas.
Si finalmente se implementa, los datos enviados por los Rollups se ajustarán mejor a las necesidades reales y el uso de los recursos de Blob será más preciso. Sin embargo, por ahora sigue siendo un borrador y aún deben debatirse más a fondo el diseño de los parámetros, la compatibilidad y la seguridad.$ETH #以太坊 #EIP #PeerDAS
El investigador de la Fundación Ethereum frisitano presentó un borrador de EIP cuyo objetivo es actualizar PeerDAS con una configuración «sin confianza» y resistencia cuántica.
Cambio principal: sustituir los compromisos y las pruebas KZG de los Blob por compromisos de Merkle Keccak-256 y rutas de autenticación. Después, una prueba LeanDA STARK recalculará la raíz de Merkle, verificará la relación de codificación Reed-Solomon y confirmará que los compromisos coinciden con los datos. Esto eliminará la dependencia de una configuración de confianza de KZG y, al mismo tiempo, reforzará la seguridad frente a la computación cuántica futura.
El borrador también introduce Blob de tamaño variable: la longitud en bytes debe estar entre 2048 y 524288, ser una potencia de 2 y divisible por 128 columnas. Las transacciones de la capa de ejecución pasarán a incluir (merkle_root, byte_length) en lugar de un hash versionado; también se ajustarán la capa de red y el cálculo de Gas.
Si finalmente se implementa, los datos enviados por los Rollups se ajustarán mejor a las necesidades reales y el uso de los recursos de Blob será más preciso. Sin embargo, por ahora sigue siendo un borrador y aún deben debatirse más a fondo el diseño de los parámetros, la compatibilidad y la seguridad.$ETH #以太坊 #EIP #PeerDAS
Cambio principal: sustituir los compromisos y las pruebas KZG de los Blob por compromisos de Merkle Keccak-256 y rutas de autenticación. Después, una prueba LeanDA STARK recalculará la raíz de Merkle, verificará la relación de codificación Reed-Solomon y confirmará que los compromisos coinciden con los datos. Esto eliminará la dependencia de una configuración de confianza de KZG y, al mismo tiempo, reforzará la seguridad frente a la computación cuántica futura.
El borrador también introduce Blob de tamaño variable: la longitud en bytes debe estar entre 2048 y 524288, ser una potencia de 2 y divisible por 128 columnas. Las transacciones de la capa de ejecución pasarán a incluir (merkle_root, byte_length) en lugar de un hash versionado; también se ajustarán la capa de red y el cálculo de Gas.
Si finalmente se implementa, los datos enviados por los Rollups se ajustarán mejor a las necesidades reales y el uso de los recursos de Blob será más preciso. Sin embargo, por ahora sigue siendo un borrador y aún deben debatirse más a fondo el diseño de los parámetros, la compatibilidad y la seguridad.$ETH #以太坊 #EIP #PeerDAS
15
·
--
EIP-7702 es una actualización de seguridad para la red Ethereum que ha sido citada como una de las causas de la reciente hackeo a Binance. La actualización tiene como objetivo mejorar la seguridad de las transacciones en la red Ethereum, pero su implementación ha generado algunas preocupaciones entre los desarrolladores.
Para los traders, esta noticia importa porque puede afectar la estabilidad y seguridad de las transacciones en la red Ethereum, lo que podría tener un impacto en el valor de las criptomonedas que utilizan la red. Los desarrolladores de Ethereum están trabajando para implementar la actualización de manera que minimice las interrupciones en el servicio.
Pero, ¿qué medidas creen que deberían tomar los exchanges para protegerse contra futuros hackeos?
#EIP-7702 #BinanceHack #Ethereum #SeguridadCripto
EIP-7702 es una actualización de seguridad para la red Ethereum que ha sido citada como una de las causas de la reciente hackeo a Binance. La actualización tiene como objetivo mejorar la seguridad de las transacciones en la red Ethereum, pero su implementación ha generado algunas preocupaciones entre los desarrolladores.
Para los traders, esta noticia importa porque puede afectar la estabilidad y seguridad de las transacciones en la red Ethereum, lo que podría tener un impacto en el valor de las criptomonedas que utilizan la red. Los desarrolladores de Ethereum están trabajando para implementar la actualización de manera que minimice las interrupciones en el servicio.
Pero, ¿qué medidas creen que deberían tomar los exchanges para protegerse contra futuros hackeos?
#EIP-7702 #BinanceHack #Ethereum #SeguridadCripto
Para los traders, esta noticia importa porque puede afectar la estabilidad y seguridad de las transacciones en la red Ethereum, lo que podría tener un impacto en el valor de las criptomonedas que utilizan la red. Los desarrolladores de Ethereum están trabajando para implementar la actualización de manera que minimice las interrupciones en el servicio.
Pero, ¿qué medidas creen que deberían tomar los exchanges para protegerse contra futuros hackeos?
#EIP-7702 #BinanceHack #Ethereum #SeguridadCripto
224
·
--
El equipo de DevOps del Protocolo de la Fundación Ethereum lanza oficialmente la red de pruebas anticipada de la actualización Glamsterdam: Platåberget, con una bifurcación programada para completarse en esa red el 20 de agosto. A diferencia de los devnets de corta duración anteriores, se espera que Platåberget funcione de manera estable durante varios meses y, además, ofrezca una configuración de red con un solo clic y un faucet de ETH de pruebas, para facilitar que los desarrolladores y la comunidad participen de forma continua en la verificación.
La hoja de ruta de pruebas también es bastante clara: dentro de un mes se implementará un devnet no definitivo para probar escenarios de consenso anómalos; después, las redes de pruebas a largo plazo como Sepolia, Hoodi, etc., completarán la bifurcación de Glamsterdam de forma sucesiva, con el objetivo final apuntando directamente a la actualización de la red principal de Ethereum.
Los cambios que merecen una atención especial en esta actualización incluyen:
Propuesta y construcción separadas integradas (ePBS), que escribe la relación entre proposer y builder en la capa del protocolo; listas de acceso a nivel de bloque (Block-Level Access Lists), que optimizan la eficiencia del acceso a datos on-chain; nueva fijación de precios de las tarifas de gas, con un objetivo de un límite inferior de alrededor de 200 millones de Gas; y límites máximos de tamaño para contratos e initcode que se elevan de 24KiB y 48KiB a 64KiB y 128KiB, respectivamente.
Es especialmente importante tener en cuenta que: cualquier herramienta que dependa de un límite máximo de Gas codificado de forma fija, como billeteras, indexadores, estimadores de Gas, etc., se verá afectada y necesitará actualizarse en consecuencia. Se recomienda que los equipos de desarrollo pertinentes evalúen la adaptación lo antes posible.
#以太坊 #Glamsterdam #EIP
El equipo de DevOps del Protocolo de la Fundación Ethereum lanza oficialmente la red de pruebas anticipada de la actualización Glamsterdam: Platåberget, con una bifurcación programada para completarse en esa red el 20 de agosto. A diferencia de los devnets de corta duración anteriores, se espera que Platåberget funcione de manera estable durante varios meses y, además, ofrezca una configuración de red con un solo clic y un faucet de ETH de pruebas, para facilitar que los desarrolladores y la comunidad participen de forma continua en la verificación.
La hoja de ruta de pruebas también es bastante clara: dentro de un mes se implementará un devnet no definitivo para probar escenarios de consenso anómalos; después, las redes de pruebas a largo plazo como Sepolia, Hoodi, etc., completarán la bifurcación de Glamsterdam de forma sucesiva, con el objetivo final apuntando directamente a la actualización de la red principal de Ethereum.
Los cambios que merecen una atención especial en esta actualización incluyen:
Propuesta y construcción separadas integradas (ePBS), que escribe la relación entre proposer y builder en la capa del protocolo; listas de acceso a nivel de bloque (Block-Level Access Lists), que optimizan la eficiencia del acceso a datos on-chain; nueva fijación de precios de las tarifas de gas, con un objetivo de un límite inferior de alrededor de 200 millones de Gas; y límites máximos de tamaño para contratos e initcode que se elevan de 24KiB y 48KiB a 64KiB y 128KiB, respectivamente.
Es especialmente importante tener en cuenta que: cualquier herramienta que dependa de un límite máximo de Gas codificado de forma fija, como billeteras, indexadores, estimadores de Gas, etc., se verá afectada y necesitará actualizarse en consecuencia. Se recomienda que los equipos de desarrollo pertinentes evalúen la adaptación lo antes posible.
#以太坊 #Glamsterdam #EIP
La hoja de ruta de pruebas también es bastante clara: dentro de un mes se implementará un devnet no definitivo para probar escenarios de consenso anómalos; después, las redes de pruebas a largo plazo como Sepolia, Hoodi, etc., completarán la bifurcación de Glamsterdam de forma sucesiva, con el objetivo final apuntando directamente a la actualización de la red principal de Ethereum.
Los cambios que merecen una atención especial en esta actualización incluyen:
Propuesta y construcción separadas integradas (ePBS), que escribe la relación entre proposer y builder en la capa del protocolo; listas de acceso a nivel de bloque (Block-Level Access Lists), que optimizan la eficiencia del acceso a datos on-chain; nueva fijación de precios de las tarifas de gas, con un objetivo de un límite inferior de alrededor de 200 millones de Gas; y límites máximos de tamaño para contratos e initcode que se elevan de 24KiB y 48KiB a 64KiB y 128KiB, respectivamente.
Es especialmente importante tener en cuenta que: cualquier herramienta que dependa de un límite máximo de Gas codificado de forma fija, como billeteras, indexadores, estimadores de Gas, etc., se verá afectada y necesitará actualizarse en consecuencia. Se recomienda que los equipos de desarrollo pertinentes evalúen la adaptación lo antes posible.
#以太坊 #Glamsterdam #EIP
25
·
--
La comunidad de Ethereum acaba de lanzar una nueva propuesta de EIP sobre contratos de depósito seguros frente a la computación cuántica posterior (post-cuántica). Esto marca un paso importante más para Ethereum en su arquitectura de seguridad a largo plazo.
El contenido central de esta propuesta, numerada como EIP-12235, incluye:
✅ Introducir un nuevo contrato que soporte claves y metadatos de credenciales de longitud variable, junto con un identificador de scheme claramente definido; el depósito BLS actual conserva el scheme 0
✅ Abandonar la estructura del árbol de Merkle del contrato de depósitos antiguo y, mediante la ejecución por derivación de logs de EIP-7685 (log-derived execution request), transmitir la información del depósito a la capa de consenso
✅ Establecer una línea de tiempo irreversible controlada por el sistema de protocolos: el depósito se deshabilita inicialmente, luego se habilita el depósito BLS y, finalmente, se deshabilita permanentemente el depósito BLS
✅ Durante la fase de migración, el cliente debe fusionar las solicitudes de depósitos de los dos contratos, el nuevo y el antiguo
La seguridad post-cuántica siempre ha sido un área clave de atención en la industria blockchain. El desarrollo de la computación cuántica supone una amenaza potencial a largo plazo para los algoritmos criptográficos existentes. Al anticipar la actualización de la arquitectura, Ethereum se prepara para las necesidades de seguridad futuras y vale la pena seguir de cerca este avance.
$ETH
#以太坊 #EIP #Seguridad post-cuántica
La comunidad de Ethereum acaba de lanzar una nueva propuesta de EIP sobre contratos de depósito seguros frente a la computación cuántica posterior (post-cuántica). Esto marca un paso importante más para Ethereum en su arquitectura de seguridad a largo plazo.
El contenido central de esta propuesta, numerada como EIP-12235, incluye:
✅ Introducir un nuevo contrato que soporte claves y metadatos de credenciales de longitud variable, junto con un identificador de scheme claramente definido; el depósito BLS actual conserva el scheme 0
✅ Abandonar la estructura del árbol de Merkle del contrato de depósitos antiguo y, mediante la ejecución por derivación de logs de EIP-7685 (log-derived execution request), transmitir la información del depósito a la capa de consenso
✅ Establecer una línea de tiempo irreversible controlada por el sistema de protocolos: el depósito se deshabilita inicialmente, luego se habilita el depósito BLS y, finalmente, se deshabilita permanentemente el depósito BLS
✅ Durante la fase de migración, el cliente debe fusionar las solicitudes de depósitos de los dos contratos, el nuevo y el antiguo
La seguridad post-cuántica siempre ha sido un área clave de atención en la industria blockchain. El desarrollo de la computación cuántica supone una amenaza potencial a largo plazo para los algoritmos criptográficos existentes. Al anticipar la actualización de la arquitectura, Ethereum se prepara para las necesidades de seguridad futuras y vale la pena seguir de cerca este avance.
$ETH
#以太坊 #EIP #Seguridad post-cuántica
El contenido central de esta propuesta, numerada como EIP-12235, incluye:
✅ Introducir un nuevo contrato que soporte claves y metadatos de credenciales de longitud variable, junto con un identificador de scheme claramente definido; el depósito BLS actual conserva el scheme 0
✅ Abandonar la estructura del árbol de Merkle del contrato de depósitos antiguo y, mediante la ejecución por derivación de logs de EIP-7685 (log-derived execution request), transmitir la información del depósito a la capa de consenso
✅ Establecer una línea de tiempo irreversible controlada por el sistema de protocolos: el depósito se deshabilita inicialmente, luego se habilita el depósito BLS y, finalmente, se deshabilita permanentemente el depósito BLS
✅ Durante la fase de migración, el cliente debe fusionar las solicitudes de depósitos de los dos contratos, el nuevo y el antiguo
La seguridad post-cuántica siempre ha sido un área clave de atención en la industria blockchain. El desarrollo de la computación cuántica supone una amenaza potencial a largo plazo para los algoritmos criptográficos existentes. Al anticipar la actualización de la arquitectura, Ethereum se prepara para las necesidades de seguridad futuras y vale la pena seguir de cerca este avance.
$ETH
#以太坊 #EIP #Seguridad post-cuántica
60
La comunidad de Ethereum ha presentado recientemente una propuesta EIP para “contratos de depósito que soporten la computación poscuántica”. ¿Qué te parece este avance que se adelanta a las amenazas a la seguridad que la computación cuántica futura supondrá para los criptoactivos?
El núcleo de la propuesta incluye:
1️⃣ Introducir un nuevo contrato que admita claves públicas y metadatos de credenciales de longitud variable, además de añadir un identificador de esquema claro (el scheme 0 se reserva para los depósitos BLS actuales)
2️⃣ El nuevo contrato de depósitos ya no depende de la estructura del árbol de Merkle del contrato de depósitos antiguo; en su lugar, transmite la información de los depósitos a la capa de consenso mediante la ejecución derivada de registros de EIP-7685, con una estructura más clara
3️⃣ Se establece un modo de conmutación irreversible controlado por el sistema del protocolo: los depósitos se deshabilitan inicialmente, y se habilitarán los depósitos BLS en una marca de tiempo especificada; después, en una marca de tiempo posterior, se deshabilitan permanentemente los depósitos BLS y ya no se podrán reactivar, completando la migración de la actualización de forma gradual
4️⃣ Durante el periodo de migración, el cliente de ejecución debe combinar las solicitudes de depósitos de los dos contratos (el nuevo y el antiguo) para garantizar una transición fluida
En un contexto en el que la tecnología de computación cuántica sigue evolucionando, solo actualizando con antelación los estándares de seguridad de la infraestructura criptográfica se puede proteger a largo plazo la seguridad de los activos de los usuarios. Esta actualización “a prueba de futuro” como la del ecosistema $ETH , ¿crees que es necesaria?
#以太坊 #EIP #seguridad poscuántica
La comunidad de Ethereum ha presentado recientemente una propuesta EIP para “contratos de depósito que soporten la computación poscuántica”. ¿Qué te parece este avance que se adelanta a las amenazas a la seguridad que la computación cuántica futura supondrá para los criptoactivos?
El núcleo de la propuesta incluye:
1️⃣ Introducir un nuevo contrato que admita claves públicas y metadatos de credenciales de longitud variable, además de añadir un identificador de esquema claro (el scheme 0 se reserva para los depósitos BLS actuales)
2️⃣ El nuevo contrato de depósitos ya no depende de la estructura del árbol de Merkle del contrato de depósitos antiguo; en su lugar, transmite la información de los depósitos a la capa de consenso mediante la ejecución derivada de registros de EIP-7685, con una estructura más clara
3️⃣ Se establece un modo de conmutación irreversible controlado por el sistema del protocolo: los depósitos se deshabilitan inicialmente, y se habilitarán los depósitos BLS en una marca de tiempo especificada; después, en una marca de tiempo posterior, se deshabilitan permanentemente los depósitos BLS y ya no se podrán reactivar, completando la migración de la actualización de forma gradual
4️⃣ Durante el periodo de migración, el cliente de ejecución debe combinar las solicitudes de depósitos de los dos contratos (el nuevo y el antiguo) para garantizar una transición fluida
En un contexto en el que la tecnología de computación cuántica sigue evolucionando, solo actualizando con antelación los estándares de seguridad de la infraestructura criptográfica se puede proteger a largo plazo la seguridad de los activos de los usuarios. Esta actualización “a prueba de futuro” como la del ecosistema $ETH , ¿crees que es necesaria?
#以太坊 #EIP #seguridad poscuántica
El núcleo de la propuesta incluye:
1️⃣ Introducir un nuevo contrato que admita claves públicas y metadatos de credenciales de longitud variable, además de añadir un identificador de esquema claro (el scheme 0 se reserva para los depósitos BLS actuales)
2️⃣ El nuevo contrato de depósitos ya no depende de la estructura del árbol de Merkle del contrato de depósitos antiguo; en su lugar, transmite la información de los depósitos a la capa de consenso mediante la ejecución derivada de registros de EIP-7685, con una estructura más clara
3️⃣ Se establece un modo de conmutación irreversible controlado por el sistema del protocolo: los depósitos se deshabilitan inicialmente, y se habilitarán los depósitos BLS en una marca de tiempo especificada; después, en una marca de tiempo posterior, se deshabilitan permanentemente los depósitos BLS y ya no se podrán reactivar, completando la migración de la actualización de forma gradual
4️⃣ Durante el periodo de migración, el cliente de ejecución debe combinar las solicitudes de depósitos de los dos contratos (el nuevo y el antiguo) para garantizar una transición fluida
En un contexto en el que la tecnología de computación cuántica sigue evolucionando, solo actualizando con antelación los estándares de seguridad de la infraestructura criptográfica se puede proteger a largo plazo la seguridad de los activos de los usuarios. Esta actualización “a prueba de futuro” como la del ecosistema $ETH , ¿crees que es necesaria?
#以太坊 #EIP #seguridad poscuántica
83
·
--
📰 El equipo del Consorcio de la Fundación Ethereum ya ha enumerado las prioridades del upgrade de Hegotá dentro de EIP, con un objetivo muy claro: para el 12 de diciembre de 2029, completar la preparación de seguridad post-cuántica en las tres capas de Ethereum de la capa de ejecución, la capa de consenso y la capa de datos.
🔥 En esta ocasión, hay dos propuestas clave listadas como “imprescindibles” en la categoría S. La del nivel de consenso, FOCIL (es decir, EIP-7805), planea mejorar la resistencia a la censura de la red mediante la inclusión obligatoria de transacciones en el mempool público.
💡 En la capa de ejecución, Frame Transactions, también es un proyecto “imprescindible” (EIP-8141). Dividirá las transacciones en varios “marcos” programables para validación, pago de Gas y ejecución. En el futuro, la abstracción nativa de cuentas, las firmas personalizadas y el pago de Gas por terceros tendrán una base técnica más definida.
La verdad es que la seguridad post-cuántica suena lejana para el usuario común, pero esto no es un parche temporal: es una hoja de ruta de mejoras a largo plazo que el equipo de protocolo ya tiene planeada. El equipo estima que, a partir del hard fork Glamsterdam en el cuarto trimestre de 2026, cada hard fork posterior requerirá en promedio unos 7,2 meses, con la intención de llegar antes del “Q-day”, que se espera alrededor de 2030.
🤔 ¿Cuántos años crees que le tomará a Ethereum hacer esto? ¿Te parece una mejora anticipada una opción segura o crees que hará que la iteración del protocolo vaya demasiado lenta?
#以太坊 #Hegotá #量子安全 #EIP
📰 El equipo del Consorcio de la Fundación Ethereum ya ha enumerado las prioridades del upgrade de Hegotá dentro de EIP, con un objetivo muy claro: para el 12 de diciembre de 2029, completar la preparación de seguridad post-cuántica en las tres capas de Ethereum de la capa de ejecución, la capa de consenso y la capa de datos.
🔥 En esta ocasión, hay dos propuestas clave listadas como “imprescindibles” en la categoría S. La del nivel de consenso, FOCIL (es decir, EIP-7805), planea mejorar la resistencia a la censura de la red mediante la inclusión obligatoria de transacciones en el mempool público.
💡 En la capa de ejecución, Frame Transactions, también es un proyecto “imprescindible” (EIP-8141). Dividirá las transacciones en varios “marcos” programables para validación, pago de Gas y ejecución. En el futuro, la abstracción nativa de cuentas, las firmas personalizadas y el pago de Gas por terceros tendrán una base técnica más definida.
La verdad es que la seguridad post-cuántica suena lejana para el usuario común, pero esto no es un parche temporal: es una hoja de ruta de mejoras a largo plazo que el equipo de protocolo ya tiene planeada. El equipo estima que, a partir del hard fork Glamsterdam en el cuarto trimestre de 2026, cada hard fork posterior requerirá en promedio unos 7,2 meses, con la intención de llegar antes del “Q-day”, que se espera alrededor de 2030.
🤔 ¿Cuántos años crees que le tomará a Ethereum hacer esto? ¿Te parece una mejora anticipada una opción segura o crees que hará que la iteración del protocolo vaya demasiado lenta?
#以太坊 #Hegotá #量子安全 #EIP
🔥 En esta ocasión, hay dos propuestas clave listadas como “imprescindibles” en la categoría S. La del nivel de consenso, FOCIL (es decir, EIP-7805), planea mejorar la resistencia a la censura de la red mediante la inclusión obligatoria de transacciones en el mempool público.
💡 En la capa de ejecución, Frame Transactions, también es un proyecto “imprescindible” (EIP-8141). Dividirá las transacciones en varios “marcos” programables para validación, pago de Gas y ejecución. En el futuro, la abstracción nativa de cuentas, las firmas personalizadas y el pago de Gas por terceros tendrán una base técnica más definida.
La verdad es que la seguridad post-cuántica suena lejana para el usuario común, pero esto no es un parche temporal: es una hoja de ruta de mejoras a largo plazo que el equipo de protocolo ya tiene planeada. El equipo estima que, a partir del hard fork Glamsterdam en el cuarto trimestre de 2026, cada hard fork posterior requerirá en promedio unos 7,2 meses, con la intención de llegar antes del “Q-day”, que se espera alrededor de 2030.
🤔 ¿Cuántos años crees que le tomará a Ethereum hacer esto? ¿Te parece una mejora anticipada una opción segura o crees que hará que la iteración del protocolo vaya demasiado lenta?
#以太坊 #Hegotá #量子安全 #EIP
24
·
--
Se publica oficialmente la propuesta EIP-8361. La idea central es ponerle “una válvula de regulación” a la inflación de Ethereum:
· En cada epoch, se descuenta y destruye una parte de las recompensas de bloques del validador
· Cuando la tasa total de staking de toda la red alcance el 50%, la tasa de destrucción se incrementa directamente hasta el 100%
· La proporción exacta de cese de las recompensas al final la determina el tira y afloja del mercado, pero estrictamente es menor que 50%
En pocas palabras: cuanto más gente haga staking, más duramente se destruyen las recompensas. Este es un experimento de diseño que usa mecanismos on-chain para suprimir la inflación de ETH de forma inversa. El 50% es un umbral psicológico clave y también la línea de alerta para “sobre-staking” según el autor de la propuesta.
Si se implementa, significa que el modelo económico de Ethereum se acercará aún más a un enfoque de “deflación primero”: los tenedores a largo plazo se benefician, pero el rendimiento de los validadores se verá comprimido de manera significativa. ¿Te gusta esta dirección?
#Ethereum#EIP#Inflación
Se publica oficialmente la propuesta EIP-8361. La idea central es ponerle “una válvula de regulación” a la inflación de Ethereum:
· En cada epoch, se descuenta y destruye una parte de las recompensas de bloques del validador
· Cuando la tasa total de staking de toda la red alcance el 50%, la tasa de destrucción se incrementa directamente hasta el 100%
· La proporción exacta de cese de las recompensas al final la determina el tira y afloja del mercado, pero estrictamente es menor que 50%
En pocas palabras: cuanto más gente haga staking, más duramente se destruyen las recompensas. Este es un experimento de diseño que usa mecanismos on-chain para suprimir la inflación de ETH de forma inversa. El 50% es un umbral psicológico clave y también la línea de alerta para “sobre-staking” según el autor de la propuesta.
Si se implementa, significa que el modelo económico de Ethereum se acercará aún más a un enfoque de “deflación primero”: los tenedores a largo plazo se benefician, pero el rendimiento de los validadores se verá comprimido de manera significativa. ¿Te gusta esta dirección?
#Ethereum#EIP#Inflación
· En cada epoch, se descuenta y destruye una parte de las recompensas de bloques del validador
· Cuando la tasa total de staking de toda la red alcance el 50%, la tasa de destrucción se incrementa directamente hasta el 100%
· La proporción exacta de cese de las recompensas al final la determina el tira y afloja del mercado, pero estrictamente es menor que 50%
En pocas palabras: cuanto más gente haga staking, más duramente se destruyen las recompensas. Este es un experimento de diseño que usa mecanismos on-chain para suprimir la inflación de ETH de forma inversa. El 50% es un umbral psicológico clave y también la línea de alerta para “sobre-staking” según el autor de la propuesta.
Si se implementa, significa que el modelo económico de Ethereum se acercará aún más a un enfoque de “deflación primero”: los tenedores a largo plazo se benefician, pero el rendimiento de los validadores se verá comprimido de manera significativa. ¿Te gusta esta dirección?
#Ethereum#EIP#Inflación
125
¡La comunidad de Ethereum acaba de lanzar una nueva propuesta de EIP de contratos de depósito para la era de la computación poscuántica! Se adelantan a las actualizaciones de seguridad criptográfica: esta visión de futuro merece la máxima puntuación👏
Resumen de los puntos clave de la propuesta:
▫️ Introduce un nuevo contrato que admite claves y metadatos de credenciales de longitud variable, además de agregar un identificador de scheme definido (el scheme 0 se reserva para los depósitos actuales de BLS)
▫️ Ya no depende de la estructura del árbol de Merkle del contrato de depósito anterior. Con la ejecución derivada de logs de EIP-7685, las solicitudes de depósito se transmiten a la capa de consenso; la arquitectura es más sencilla y eficiente
▫️ Establece un mecanismo de transición irreversible: los depósitos se deshabilitan inicialmente. Primero se activan los depósitos de BLS por ventanas de tiempo; al vencer, los depósitos de BLS se desactivan de forma permanente. El proceso de cambio es claro y controlable
▫️ Durante la fase de migración, el cliente debe combinar y gestionar solicitudes de depósito de los contratos nuevos y antiguos para asegurar una transición fluida
Con la amenaza de la computación cuántica acercándose gradualmente, la comunidad de Ethereum inicia con antelación una actualización de seguridad a nivel de base, sentando una base sólida para la seguridad a largo plazo del ecosistema. Este es el tipo de actitud de largo plazo que debería tener un proyecto de primer nivel.
¿Qué opinas de esta planificación anticipada de Ethereum para la era poscuántica? ¡Comparte tu punto de vista en los comentarios!👇
#以太坊 #EIP #computaciónposcuántica
¡La comunidad de Ethereum acaba de lanzar una nueva propuesta de EIP de contratos de depósito para la era de la computación poscuántica! Se adelantan a las actualizaciones de seguridad criptográfica: esta visión de futuro merece la máxima puntuación👏
Resumen de los puntos clave de la propuesta:
▫️ Introduce un nuevo contrato que admite claves y metadatos de credenciales de longitud variable, además de agregar un identificador de scheme definido (el scheme 0 se reserva para los depósitos actuales de BLS)
▫️ Ya no depende de la estructura del árbol de Merkle del contrato de depósito anterior. Con la ejecución derivada de logs de EIP-7685, las solicitudes de depósito se transmiten a la capa de consenso; la arquitectura es más sencilla y eficiente
▫️ Establece un mecanismo de transición irreversible: los depósitos se deshabilitan inicialmente. Primero se activan los depósitos de BLS por ventanas de tiempo; al vencer, los depósitos de BLS se desactivan de forma permanente. El proceso de cambio es claro y controlable
▫️ Durante la fase de migración, el cliente debe combinar y gestionar solicitudes de depósito de los contratos nuevos y antiguos para asegurar una transición fluida
Con la amenaza de la computación cuántica acercándose gradualmente, la comunidad de Ethereum inicia con antelación una actualización de seguridad a nivel de base, sentando una base sólida para la seguridad a largo plazo del ecosistema. Este es el tipo de actitud de largo plazo que debería tener un proyecto de primer nivel.
¿Qué opinas de esta planificación anticipada de Ethereum para la era poscuántica? ¡Comparte tu punto de vista en los comentarios!👇
#以太坊 #EIP #computaciónposcuántica
Resumen de los puntos clave de la propuesta:
▫️ Introduce un nuevo contrato que admite claves y metadatos de credenciales de longitud variable, además de agregar un identificador de scheme definido (el scheme 0 se reserva para los depósitos actuales de BLS)
▫️ Ya no depende de la estructura del árbol de Merkle del contrato de depósito anterior. Con la ejecución derivada de logs de EIP-7685, las solicitudes de depósito se transmiten a la capa de consenso; la arquitectura es más sencilla y eficiente
▫️ Establece un mecanismo de transición irreversible: los depósitos se deshabilitan inicialmente. Primero se activan los depósitos de BLS por ventanas de tiempo; al vencer, los depósitos de BLS se desactivan de forma permanente. El proceso de cambio es claro y controlable
▫️ Durante la fase de migración, el cliente debe combinar y gestionar solicitudes de depósito de los contratos nuevos y antiguos para asegurar una transición fluida
Con la amenaza de la computación cuántica acercándose gradualmente, la comunidad de Ethereum inicia con antelación una actualización de seguridad a nivel de base, sentando una base sólida para la seguridad a largo plazo del ecosistema. Este es el tipo de actitud de largo plazo que debería tener un proyecto de primer nivel.
¿Qué opinas de esta planificación anticipada de Ethereum para la era poscuántica? ¡Comparte tu punto de vista en los comentarios!👇
#以太坊 #EIP #computaciónposcuántica
69
·
--
Vitalik última explicación detallada de su discurso sobre EIP-8288: la “solución definitiva” para la escalabilidad de Ethereum; ¡las futuras transacciones serán más rápidas y más baratas!
Problema central: Ethereum lleva mucho tiempo enfrentando una difícil encrucijada: no se pueden lograr de forma simultánea la seguridad frente a la computación cuántica, la protección de la privacidad y la escalabilidad. Las transacciones convencionales consumen aproximadamente 21.000 de gas; la verificación de firmas ECDSA consume cerca de 4.000 de gas. En cambio, las firmas con seguridad cuántica tienen un costo que llega a 100.000–300.000 de gas, y las pruebas de privacidad ZK mínimas exigen al menos 350.000 de gas (a veces más de un millón). Si se suman ambas (pruebas STARK de seguridad cuántica + privacidad), una sola transacción tendría que quemar unos 8 millones de gas. Esto reduciría el TPS de Ethereum de 25 a 0,25, dejándolo prácticamente inutilizable.
La idea de solución propuesta por Vitalik: el núcleo de EIP-8288 es mover los costosos cálculos criptográficos fuera de la cadena:
Antes de que la transacción se publique en la cadena, los nodos agregan en el mempool las firmas/pruebas de múltiples usuarios en una sola prueba STARK usando un diseño de “estructura de trama microscópica”. En la cadena solo se dejan 65–96 bytes de información de dependencias; los grandes datos criptográficos no se publican on-chain. La transacción se divide en dos partes: “lógica de negocio” y “trabajo de verificación”. La verificación se procesa en paralelo fuera de la cadena (con particionamiento especializado).
Algunos puntos destacados: podría ser la primera vez que Ethereum introduce de manera real un escenario de uso del conjunto de instrucciones RISC-V; la propuesta se apoya en el próximo EIP-8141 (abstracción nativa de cuentas); tras la compresión, los datos del bloque pueden mantenerse en el rango de 100–300 KB; la experiencia de desarrollo no cambia mucho: no requiere que los desarrolladores de Ethereum hagan demasiadas adaptaciones.
Conclusión: si la propuesta se concreta, el costo de las transacciones con seguridad cuántica disminuirá de forma significativa. Las aplicaciones de privacidad ya no se verán rechazadas por las altas tarifas de gas, y la velocidad de confirmación de los ZK-Rollup de L2 también podrá mejorar claramente. Actualmente, la comunidad ya ha abierto varios canales de participación como modelos de simulación de red, redes de prueba, concursos de algoritmos y repositorios de código prototipo; estamos en una etapa temprana de construcción colaborativa.
#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元
Vitalik última explicación detallada de su discurso sobre EIP-8288: la “solución definitiva” para la escalabilidad de Ethereum; ¡las futuras transacciones serán más rápidas y más baratas!
Problema central: Ethereum lleva mucho tiempo enfrentando una difícil encrucijada: no se pueden lograr de forma simultánea la seguridad frente a la computación cuántica, la protección de la privacidad y la escalabilidad. Las transacciones convencionales consumen aproximadamente 21.000 de gas; la verificación de firmas ECDSA consume cerca de 4.000 de gas. En cambio, las firmas con seguridad cuántica tienen un costo que llega a 100.000–300.000 de gas, y las pruebas de privacidad ZK mínimas exigen al menos 350.000 de gas (a veces más de un millón). Si se suman ambas (pruebas STARK de seguridad cuántica + privacidad), una sola transacción tendría que quemar unos 8 millones de gas. Esto reduciría el TPS de Ethereum de 25 a 0,25, dejándolo prácticamente inutilizable.
La idea de solución propuesta por Vitalik: el núcleo de EIP-8288 es mover los costosos cálculos criptográficos fuera de la cadena:
Antes de que la transacción se publique en la cadena, los nodos agregan en el mempool las firmas/pruebas de múltiples usuarios en una sola prueba STARK usando un diseño de “estructura de trama microscópica”. En la cadena solo se dejan 65–96 bytes de información de dependencias; los grandes datos criptográficos no se publican on-chain. La transacción se divide en dos partes: “lógica de negocio” y “trabajo de verificación”. La verificación se procesa en paralelo fuera de la cadena (con particionamiento especializado).
Algunos puntos destacados: podría ser la primera vez que Ethereum introduce de manera real un escenario de uso del conjunto de instrucciones RISC-V; la propuesta se apoya en el próximo EIP-8141 (abstracción nativa de cuentas); tras la compresión, los datos del bloque pueden mantenerse en el rango de 100–300 KB; la experiencia de desarrollo no cambia mucho: no requiere que los desarrolladores de Ethereum hagan demasiadas adaptaciones.
Conclusión: si la propuesta se concreta, el costo de las transacciones con seguridad cuántica disminuirá de forma significativa. Las aplicaciones de privacidad ya no se verán rechazadas por las altas tarifas de gas, y la velocidad de confirmación de los ZK-Rollup de L2 también podrá mejorar claramente. Actualmente, la comunidad ya ha abierto varios canales de participación como modelos de simulación de red, redes de prueba, concursos de algoritmos y repositorios de código prototipo; estamos en una etapa temprana de construcción colaborativa.
#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元
Problema central: Ethereum lleva mucho tiempo enfrentando una difícil encrucijada: no se pueden lograr de forma simultánea la seguridad frente a la computación cuántica, la protección de la privacidad y la escalabilidad. Las transacciones convencionales consumen aproximadamente 21.000 de gas; la verificación de firmas ECDSA consume cerca de 4.000 de gas. En cambio, las firmas con seguridad cuántica tienen un costo que llega a 100.000–300.000 de gas, y las pruebas de privacidad ZK mínimas exigen al menos 350.000 de gas (a veces más de un millón). Si se suman ambas (pruebas STARK de seguridad cuántica + privacidad), una sola transacción tendría que quemar unos 8 millones de gas. Esto reduciría el TPS de Ethereum de 25 a 0,25, dejándolo prácticamente inutilizable.
La idea de solución propuesta por Vitalik: el núcleo de EIP-8288 es mover los costosos cálculos criptográficos fuera de la cadena:
Antes de que la transacción se publique en la cadena, los nodos agregan en el mempool las firmas/pruebas de múltiples usuarios en una sola prueba STARK usando un diseño de “estructura de trama microscópica”. En la cadena solo se dejan 65–96 bytes de información de dependencias; los grandes datos criptográficos no se publican on-chain. La transacción se divide en dos partes: “lógica de negocio” y “trabajo de verificación”. La verificación se procesa en paralelo fuera de la cadena (con particionamiento especializado).
Algunos puntos destacados: podría ser la primera vez que Ethereum introduce de manera real un escenario de uso del conjunto de instrucciones RISC-V; la propuesta se apoya en el próximo EIP-8141 (abstracción nativa de cuentas); tras la compresión, los datos del bloque pueden mantenerse en el rango de 100–300 KB; la experiencia de desarrollo no cambia mucho: no requiere que los desarrolladores de Ethereum hagan demasiadas adaptaciones.
Conclusión: si la propuesta se concreta, el costo de las transacciones con seguridad cuántica disminuirá de forma significativa. Las aplicaciones de privacidad ya no se verán rechazadas por las altas tarifas de gas, y la velocidad de confirmación de los ZK-Rollup de L2 también podrá mejorar claramente. Actualmente, la comunidad ya ha abierto varios canales de participación como modelos de simulación de red, redes de prueba, concursos de algoritmos y repositorios de código prototipo; estamos en una etapa temprana de construcción colaborativa.
#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元
120
·
--
【Recopilación de noticias】 Investigadores de Ethereum proponen el EIP-8361: usar «combustión por emisión decreciente» para limitar el ratio de staking
Recientemente, un grupo de investigadores de Ethereum (incluido Justin Drake, etc.) publicó un borrador del EIP-8361 (Tapered Issuance Burn).
En pocas palabras, el mecanismo:
1. Las recompensas a los validadores se calculan según el ratio total de staking de la red, descontando y destruyendo de forma permanente una parte
2. Cuanto más staking, mayor será el porcentaje que se quema
3. Cuando el staking activo alcance 60,25 millones de ETH (aprox. la mitad de la oferta), la quema puede llegar al 100%; la emisión neta en la capa de consenso tiende a cero
4. Para mitigar el impacto sobre los stakers existentes, se diseña un período de transición de ~18 meses (durante el período de transición también se ajusta el factor de recompensas)
La motivación de la propuesta es más bien de capa de protocolo: evitar los riesgos de centralización y captura que implica acumular staking sin límite, y mantener en la medida de lo posible el papel neutral del ETH no apostado como moneda. A día de hoy sigue siendo Draft; la comunidad lo debate en Eth Magicians / GitHub, y no está claro aún si pasará a futuras actualizaciones de la red.
Fuente:
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Borrador https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md
#Ethereum #EIP
Recopilación de información, no constituye asesoramiento de inversión
【Recopilación de noticias】 Investigadores de Ethereum proponen el EIP-8361: usar «combustión por emisión decreciente» para limitar el ratio de staking
Recientemente, un grupo de investigadores de Ethereum (incluido Justin Drake, etc.) publicó un borrador del EIP-8361 (Tapered Issuance Burn).
En pocas palabras, el mecanismo:
1. Las recompensas a los validadores se calculan según el ratio total de staking de la red, descontando y destruyendo de forma permanente una parte
2. Cuanto más staking, mayor será el porcentaje que se quema
3. Cuando el staking activo alcance 60,25 millones de ETH (aprox. la mitad de la oferta), la quema puede llegar al 100%; la emisión neta en la capa de consenso tiende a cero
4. Para mitigar el impacto sobre los stakers existentes, se diseña un período de transición de ~18 meses (durante el período de transición también se ajusta el factor de recompensas)
La motivación de la propuesta es más bien de capa de protocolo: evitar los riesgos de centralización y captura que implica acumular staking sin límite, y mantener en la medida de lo posible el papel neutral del ETH no apostado como moneda. A día de hoy sigue siendo Draft; la comunidad lo debate en Eth Magicians / GitHub, y no está claro aún si pasará a futuras actualizaciones de la red.
Fuente:
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Borrador https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md
#Ethereum #EIP
Recopilación de información, no constituye asesoramiento de inversión
Recientemente, un grupo de investigadores de Ethereum (incluido Justin Drake, etc.) publicó un borrador del EIP-8361 (Tapered Issuance Burn).
En pocas palabras, el mecanismo:
1. Las recompensas a los validadores se calculan según el ratio total de staking de la red, descontando y destruyendo de forma permanente una parte
2. Cuanto más staking, mayor será el porcentaje que se quema
3. Cuando el staking activo alcance 60,25 millones de ETH (aprox. la mitad de la oferta), la quema puede llegar al 100%; la emisión neta en la capa de consenso tiende a cero
4. Para mitigar el impacto sobre los stakers existentes, se diseña un período de transición de ~18 meses (durante el período de transición también se ajusta el factor de recompensas)
La motivación de la propuesta es más bien de capa de protocolo: evitar los riesgos de centralización y captura que implica acumular staking sin límite, y mantener en la medida de lo posible el papel neutral del ETH no apostado como moneda. A día de hoy sigue siendo Draft; la comunidad lo debate en Eth Magicians / GitHub, y no está claro aún si pasará a futuras actualizaciones de la red.
Fuente:
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Borrador https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md
#Ethereum #EIP
Recopilación de información, no constituye asesoramiento de inversión
115
·
--
La comunidad de Ethereum ha presentado recientemente la propuesta EIP-12235, con el plan de introducir un nuevo contrato de depósito compatible con la seguridad de la computación poscuántica, como una planificación anticipada para garantizar la seguridad a largo plazo de Ethereum. Este paso se está dando con mucha solidez.
Los puntos clave de la propuesta incluyen:
1️⃣ El nuevo contrato admite claves y metadatos de credenciales de longitud variable, incorpora un identificador de scheme explícito; el scheme 0 queda reservado para el mecanismo actual de depósitos BLS
2️⃣ Ya no depende de la estructura del árbol de Merkle del contrato de depósitos anterior; en su lugar, transmite la información del depósito a la capa de consenso mediante la ejecución derivada de registros según EIP-7685
3️⃣ Se establece un modo de transición irreversible controlado por llamadas del sistema del protocolo: en el estado inicial la función de depósitos está deshabilitada; primero se habilitan los depósitos BLS en una marca de tiempo específica y, posteriormente, en una marca de tiempo más tardía, se deshabilitan permanentemente los depósitos BLS, sin posibilidad de reactivarlos
4️⃣ Durante la migración, el cliente ejecutor debe combinar las solicitudes de depósitos de los dos contratos, el nuevo y el anterior
En el contexto más amplio del avance de la tecnología de computación cuántica, actualizar con antelación la infraestructura base de seguridad criptográfica es muy necesario, porque al final la seguridad es la línea de vida de la blockchain.
$ETH
#以太坊 #后量子安全 #EIP
La comunidad de Ethereum ha presentado recientemente la propuesta EIP-12235, con el plan de introducir un nuevo contrato de depósito compatible con la seguridad de la computación poscuántica, como una planificación anticipada para garantizar la seguridad a largo plazo de Ethereum. Este paso se está dando con mucha solidez.
Los puntos clave de la propuesta incluyen:
1️⃣ El nuevo contrato admite claves y metadatos de credenciales de longitud variable, incorpora un identificador de scheme explícito; el scheme 0 queda reservado para el mecanismo actual de depósitos BLS
2️⃣ Ya no depende de la estructura del árbol de Merkle del contrato de depósitos anterior; en su lugar, transmite la información del depósito a la capa de consenso mediante la ejecución derivada de registros según EIP-7685
3️⃣ Se establece un modo de transición irreversible controlado por llamadas del sistema del protocolo: en el estado inicial la función de depósitos está deshabilitada; primero se habilitan los depósitos BLS en una marca de tiempo específica y, posteriormente, en una marca de tiempo más tardía, se deshabilitan permanentemente los depósitos BLS, sin posibilidad de reactivarlos
4️⃣ Durante la migración, el cliente ejecutor debe combinar las solicitudes de depósitos de los dos contratos, el nuevo y el anterior
En el contexto más amplio del avance de la tecnología de computación cuántica, actualizar con antelación la infraestructura base de seguridad criptográfica es muy necesario, porque al final la seguridad es la línea de vida de la blockchain.
$ETH
#以太坊 #后量子安全 #EIP
Los puntos clave de la propuesta incluyen:
1️⃣ El nuevo contrato admite claves y metadatos de credenciales de longitud variable, incorpora un identificador de scheme explícito; el scheme 0 queda reservado para el mecanismo actual de depósitos BLS
2️⃣ Ya no depende de la estructura del árbol de Merkle del contrato de depósitos anterior; en su lugar, transmite la información del depósito a la capa de consenso mediante la ejecución derivada de registros según EIP-7685
3️⃣ Se establece un modo de transición irreversible controlado por llamadas del sistema del protocolo: en el estado inicial la función de depósitos está deshabilitada; primero se habilitan los depósitos BLS en una marca de tiempo específica y, posteriormente, en una marca de tiempo más tardía, se deshabilitan permanentemente los depósitos BLS, sin posibilidad de reactivarlos
4️⃣ Durante la migración, el cliente ejecutor debe combinar las solicitudes de depósitos de los dos contratos, el nuevo y el anterior
En el contexto más amplio del avance de la tecnología de computación cuántica, actualizar con antelación la infraestructura base de seguridad criptográfica es muy necesario, porque al final la seguridad es la línea de vida de la blockchain.
$ETH
#以太坊 #后量子安全 #EIP
56
·
--
📰 Exploit de Binance vinculado a una delegación EIP-7702; aumentan las pérdidas preliminares
Fireblocks afirma que una delegación EIP-7702 firmada permitió retirar fondos de las billeteras calientes de Binance; la actualización preliminar de Binance apunta a una laptop de DevOps comprometida. (Leer más)
Fuente : Blockchain News
Hora : 2026-10-30 19:59:28
Crédito : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Comparte tu opinión en la sección de comentarios de abajo
📰 Exploit de Binance vinculado a una delegación EIP-7702; aumentan las pérdidas preliminares
Fireblocks afirma que una delegación EIP-7702 firmada permitió retirar fondos de las billeteras calientes de Binance; la actualización preliminar de Binance apunta a una laptop de DevOps comprometida. (Leer más)
Fuente : Blockchain News
Hora : 2026-10-30 19:59:28
Crédito : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Comparte tu opinión en la sección de comentarios de abajo
Fireblocks afirma que una delegación EIP-7702 firmada permitió retirar fondos de las billeteras calientes de Binance; la actualización preliminar de Binance apunta a una laptop de DevOps comprometida. (Leer más)
Fuente : Blockchain News
Hora : 2026-10-30 19:59:28
Crédito : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Comparte tu opinión en la sección de comentarios de abajo
76
·
--
Ethereum quiere reducir el tiempo hasta la finalización de unos 16 minutos a unos 4. Ben Edgington, coordinador de investigación sobre finalización rápida de Ethereum, presentó un borrador de EIP junto con Francesco D'Amato, Roberto Saltini, Yann Vonlanthen y Mikhail Kalinin (n.º 12566, ya en el proceso formal). El objetivo es reducir el tiempo hasta la confirmación final aproximadamente cuatro veces.
¿Por qué tanta prisa? Los servicios de remesas entre cadenas tienen que adelantar fondos mientras esperan la confirmación: si adelantan de forma constante 1 millón de dólares por hora, con una demora de 16 minutos quedan inmovilizados unos 267.000 dólares; con 4 minutos, la cifra bajaría a unos 67.000 dólares.
La causa técnica de fondo es que los validadores usan un mismo voto para dos cosas: elegir bloques y confirmar bloques anteriores. Por eso, las confirmaciones solo pueden avanzar al ritmo de la rotación de validadores. El borrador separa los dos votos, lo que permite acelerar las confirmaciones de forma independiente y seguir reduciendo los tiempos más adelante. Separar las votaciones también facilitaría adoptar firmas resistentes a la computación cuántica en el futuro. Los propios autores dicen que «many aspects remain TBD»; por ahora, el modesto objetivo es obtener un número de propuesta y entrar en el proceso formal de actualizaciones de Ethereum. El diseño no está terminado y no hay fecha de activación: no lo des por hecho.
La comparación lo hace aún más interesante: Circle (CRCL) ya cobra por la rapidez de las transferencias rápidas de USDC entre cadenas: la ruta rápida de Ethereum cuesta un 0,01 % (1 dólar por cada 10.000 dólares) y, además, tiene un límite para el importe total de las transferencias rápidas. Por su parte, Solana Alpenglow apunta a una finalización de unos 150 milisegundos (se lanzó ayer). Incluso con un objetivo de 4 minutos, Ethereum seguiría siendo lento; su ventaja está en la seguridad y la escala de la red principal.
Fuentes: CoinDesk y el borrador de EIP (github.com/ethereum/EIPs/pull/12566).
#ETH #以太坊 #EIP #跨链 #Circle
Ethereum quiere reducir el tiempo hasta la finalización de unos 16 minutos a unos 4. Ben Edgington, coordinador de investigación sobre finalización rápida de Ethereum, presentó un borrador de EIP junto con Francesco D'Amato, Roberto Saltini, Yann Vonlanthen y Mikhail Kalinin (n.º 12566, ya en el proceso formal). El objetivo es reducir el tiempo hasta la confirmación final aproximadamente cuatro veces.
¿Por qué tanta prisa? Los servicios de remesas entre cadenas tienen que adelantar fondos mientras esperan la confirmación: si adelantan de forma constante 1 millón de dólares por hora, con una demora de 16 minutos quedan inmovilizados unos 267.000 dólares; con 4 minutos, la cifra bajaría a unos 67.000 dólares.
La causa técnica de fondo es que los validadores usan un mismo voto para dos cosas: elegir bloques y confirmar bloques anteriores. Por eso, las confirmaciones solo pueden avanzar al ritmo de la rotación de validadores. El borrador separa los dos votos, lo que permite acelerar las confirmaciones de forma independiente y seguir reduciendo los tiempos más adelante. Separar las votaciones también facilitaría adoptar firmas resistentes a la computación cuántica en el futuro. Los propios autores dicen que «many aspects remain TBD»; por ahora, el modesto objetivo es obtener un número de propuesta y entrar en el proceso formal de actualizaciones de Ethereum. El diseño no está terminado y no hay fecha de activación: no lo des por hecho.
La comparación lo hace aún más interesante: Circle (CRCL) ya cobra por la rapidez de las transferencias rápidas de USDC entre cadenas: la ruta rápida de Ethereum cuesta un 0,01 % (1 dólar por cada 10.000 dólares) y, además, tiene un límite para el importe total de las transferencias rápidas. Por su parte, Solana Alpenglow apunta a una finalización de unos 150 milisegundos (se lanzó ayer). Incluso con un objetivo de 4 minutos, Ethereum seguiría siendo lento; su ventaja está en la seguridad y la escala de la red principal.
Fuentes: CoinDesk y el borrador de EIP (github.com/ethereum/EIPs/pull/12566).
#ETH #以太坊 #EIP #跨链 #Circle
¿Por qué tanta prisa? Los servicios de remesas entre cadenas tienen que adelantar fondos mientras esperan la confirmación: si adelantan de forma constante 1 millón de dólares por hora, con una demora de 16 minutos quedan inmovilizados unos 267.000 dólares; con 4 minutos, la cifra bajaría a unos 67.000 dólares.
La causa técnica de fondo es que los validadores usan un mismo voto para dos cosas: elegir bloques y confirmar bloques anteriores. Por eso, las confirmaciones solo pueden avanzar al ritmo de la rotación de validadores. El borrador separa los dos votos, lo que permite acelerar las confirmaciones de forma independiente y seguir reduciendo los tiempos más adelante. Separar las votaciones también facilitaría adoptar firmas resistentes a la computación cuántica en el futuro. Los propios autores dicen que «many aspects remain TBD»; por ahora, el modesto objetivo es obtener un número de propuesta y entrar en el proceso formal de actualizaciones de Ethereum. El diseño no está terminado y no hay fecha de activación: no lo des por hecho.
La comparación lo hace aún más interesante: Circle (CRCL) ya cobra por la rapidez de las transferencias rápidas de USDC entre cadenas: la ruta rápida de Ethereum cuesta un 0,01 % (1 dólar por cada 10.000 dólares) y, además, tiene un límite para el importe total de las transferencias rápidas. Por su parte, Solana Alpenglow apunta a una finalización de unos 150 milisegundos (se lanzó ayer). Incluso con un objetivo de 4 minutos, Ethereum seguiría siendo lento; su ventaja está en la seguridad y la escala de la red principal.
Fuentes: CoinDesk y el borrador de EIP (github.com/ethereum/EIPs/pull/12566).
#ETH #以太坊 #EIP #跨链 #Circle
10
Artículo
Vitalik Dice Que Ethereum Se Convertirá En Una Cadena Híbrida Con FOCIL, EIP-8288 & Privacidad$El fundador de Ethereum, Vitalik Buterin, acaba de revelar la actualización más importante para Ethereum después del hard fork Hegota.Dijo que Ethereum ya no es solo una blockchain. Se convertirá en una arquitectura híbrida que combina blockchain + criptografía moderna como SNARKs, STARKs, FHE y Ofuscación.¿Qué es FOCIL?🚀
FOCIL llegará en la actualización de H-STARK. Actualmente, un solo constructor puede censurar tu transacción. Con FOCIL, 16 constructores crearán bloques en conjunto. Así que si envías una transacción, DEBE incluirse en el siguiente turno. Ninguna entidad única puede retrasarla. Esto es enorme para la descentralización.¿Qué es EIP-8288?
Vitalik Dice Que Ethereum Se Convertirá En Una Cadena Híbrida Con FOCIL, EIP-8288 & Privacidad
$El fundador de Ethereum, Vitalik Buterin, acaba de revelar la actualización más importante para Ethereum después del hard fork Hegota.Dijo que Ethereum ya no es solo una blockchain. Se convertirá en una arquitectura híbrida que combina blockchain + criptografía moderna como SNARKs, STARKs, FHE y Ofuscación.¿Qué es FOCIL?🚀
FOCIL llegará en la actualización de H-STARK. Actualmente, un solo constructor puede censurar tu transacción. Con FOCIL, 16 constructores crearán bloques en conjunto. Así que si envías una transacción, DEBE incluirse en el siguiente turno. Ninguna entidad única puede retrasarla. Esto es enorme para la descentralización.¿Qué es EIP-8288?
FOCIL llegará en la actualización de H-STARK. Actualmente, un solo constructor puede censurar tu transacción. Con FOCIL, 16 constructores crearán bloques en conjunto. Así que si envías una transacción, DEBE incluirse en el siguiente turno. Ninguna entidad única puede retrasarla. Esto es enorme para la descentralización.¿Qué es EIP-8288?
1
70
·
--
Alcista
$BTC $ASTER
¿Te has sentido "herido" por el repentino aumento de las tarifas de Gas de Ethereum? ¿Alguna vez has visto cómo una tarifa de transacción es más alta que el monto de la transferencia, sin poder hacer nada al respecto? 🤯 No te preocupes, ¡V ha propuesto una audaz solución que podría cambiar las reglas del juego por completo: establecer un mercado de futuros de Gas para Ethereum! Esto no es para que los comerciantes especulen, sino para que tú y yo podamos fijar el precio del combustible por adelantado, ¡diciendo adiós a la era de la volatilidad aterradora! 🚀
En pocas palabras, esta idea permite a los usuarios y desarrolladores fijar el precio del Gas futuro por adelantado, como si compraras un seguro. ¡Ya no tendrás que "jugar a la suerte" cada vez que la red esté ocupada! 📉
¿Por qué es esto importante?
Actualmente, la intensa volatilidad de las tarifas de Gas es uno de los puntos más dolorosos para Ethereum. Es difícil de predecir, imposible de presupuestar y se convierte en una pesadilla durante la ejecución de aplicaciones a gran escala. Un mercado de futuros tiene como objetivo transformar el Gas de una variable caótica en un costo estable y planificable.
¿Y si tiene éxito, qué traerá?
✅ Los desarrolladores pueden presupuestar con confianza, sin preocuparse por que los costos se descontrolen.
✅ Las DApps funcionarán de manera más estable y confiable, mejorando la experiencia del usuario.
✅ $ETH se asemejará más a una verdadera infraestructura, y no solo a una red experimental.
💡 La clave está en que: esto no es para especular con criptomonedas, sino para que Ethereum siga siendo utilizable y asequible en los momentos en que más necesita estabilidad: es decir, cuando las transacciones realmente explotan y la red está más congestionada. Actualmente, esto es solo una propuesta temprana, pero envía una señal fuerte: ¡Ethereum sigue enfocado en abordar esos problemas fundamentales difíciles y poco atractivos que realmente afectan la adopción a largo plazo!
¿Crees que esta idea de "futuros de Gas" podrá implementarse con éxito? ¿Podría convertirse en la pieza clave para la adopción masiva de Ethereum? 🤔 ¡Ven a comentar tu opinión! ⬇️
#区块链 #Web3 #EIP #加密货币
$BTC $ASTER
¿Te has sentido "herido" por el repentino aumento de las tarifas de Gas de Ethereum? ¿Alguna vez has visto cómo una tarifa de transacción es más alta que el monto de la transferencia, sin poder hacer nada al respecto? 🤯 No te preocupes, ¡V ha propuesto una audaz solución que podría cambiar las reglas del juego por completo: establecer un mercado de futuros de Gas para Ethereum! Esto no es para que los comerciantes especulen, sino para que tú y yo podamos fijar el precio del combustible por adelantado, ¡diciendo adiós a la era de la volatilidad aterradora! 🚀
En pocas palabras, esta idea permite a los usuarios y desarrolladores fijar el precio del Gas futuro por adelantado, como si compraras un seguro. ¡Ya no tendrás que "jugar a la suerte" cada vez que la red esté ocupada! 📉
¿Por qué es esto importante?
Actualmente, la intensa volatilidad de las tarifas de Gas es uno de los puntos más dolorosos para Ethereum. Es difícil de predecir, imposible de presupuestar y se convierte en una pesadilla durante la ejecución de aplicaciones a gran escala. Un mercado de futuros tiene como objetivo transformar el Gas de una variable caótica en un costo estable y planificable.
¿Y si tiene éxito, qué traerá?
✅ Los desarrolladores pueden presupuestar con confianza, sin preocuparse por que los costos se descontrolen.
✅ Las DApps funcionarán de manera más estable y confiable, mejorando la experiencia del usuario.
✅ $ETH se asemejará más a una verdadera infraestructura, y no solo a una red experimental.
💡 La clave está en que: esto no es para especular con criptomonedas, sino para que Ethereum siga siendo utilizable y asequible en los momentos en que más necesita estabilidad: es decir, cuando las transacciones realmente explotan y la red está más congestionada. Actualmente, esto es solo una propuesta temprana, pero envía una señal fuerte: ¡Ethereum sigue enfocado en abordar esos problemas fundamentales difíciles y poco atractivos que realmente afectan la adopción a largo plazo!
¿Crees que esta idea de "futuros de Gas" podrá implementarse con éxito? ¿Podría convertirse en la pieza clave para la adopción masiva de Ethereum? 🤔 ¡Ven a comentar tu opinión! ⬇️
#区块链 #Web3 #EIP #加密货币
¿Te has sentido "herido" por el repentino aumento de las tarifas de Gas de Ethereum? ¿Alguna vez has visto cómo una tarifa de transacción es más alta que el monto de la transferencia, sin poder hacer nada al respecto? 🤯 No te preocupes, ¡V ha propuesto una audaz solución que podría cambiar las reglas del juego por completo: establecer un mercado de futuros de Gas para Ethereum! Esto no es para que los comerciantes especulen, sino para que tú y yo podamos fijar el precio del combustible por adelantado, ¡diciendo adiós a la era de la volatilidad aterradora! 🚀
En pocas palabras, esta idea permite a los usuarios y desarrolladores fijar el precio del Gas futuro por adelantado, como si compraras un seguro. ¡Ya no tendrás que "jugar a la suerte" cada vez que la red esté ocupada! 📉
¿Por qué es esto importante?
Actualmente, la intensa volatilidad de las tarifas de Gas es uno de los puntos más dolorosos para Ethereum. Es difícil de predecir, imposible de presupuestar y se convierte en una pesadilla durante la ejecución de aplicaciones a gran escala. Un mercado de futuros tiene como objetivo transformar el Gas de una variable caótica en un costo estable y planificable.
¿Y si tiene éxito, qué traerá?
✅ Los desarrolladores pueden presupuestar con confianza, sin preocuparse por que los costos se descontrolen.
✅ Las DApps funcionarán de manera más estable y confiable, mejorando la experiencia del usuario.
✅ $ETH se asemejará más a una verdadera infraestructura, y no solo a una red experimental.
💡 La clave está en que: esto no es para especular con criptomonedas, sino para que Ethereum siga siendo utilizable y asequible en los momentos en que más necesita estabilidad: es decir, cuando las transacciones realmente explotan y la red está más congestionada. Actualmente, esto es solo una propuesta temprana, pero envía una señal fuerte: ¡Ethereum sigue enfocado en abordar esos problemas fundamentales difíciles y poco atractivos que realmente afectan la adopción a largo plazo!
¿Crees que esta idea de "futuros de Gas" podrá implementarse con éxito? ¿Podría convertirse en la pieza clave para la adopción masiva de Ethereum? 🤔 ¡Ven a comentar tu opinión! ⬇️
#区块链 #Web3 #EIP #加密货币
5
375
Inicia sesión para explorar más contenidos
Únete a usuarios de criptomonedas de todo el mundo en Binance Square
⚡️ Obtén la información más reciente y útil sobre criptomonedas.
💬 Confía en el mayor exchange de criptomonedas del mundo.
👍 Descubre opiniones reales de creadores verificados.
Correo electrónico/número de teléfono
Temas en tendencia
1
#WhoWillSucceedJensenHuangatNvidia?
121,639 visualizaciones
1,416 participa(n) en el debate
2
#WhatWillDriveCryptoandStocks’NextRebound?
506,875 visualizaciones
3,297 participa(n) en el debate
3
#BitcoinActiveSupplyInProfitDropsBelow45%
49,611 visualizaciones
569 participa(n) en el debate
4
#KavaSaysAbnormalActivityLimitedToKavaLend
24,653 visualizaciones
309 participa(n) en el debate
5
#USSpotXRPETFsSeeLargestWeeklyOutflowIn8Months
19,130 visualizaciones
265 participa(n) en el debate
6
#USPPIMissMayEaseBTCPressure
252,587 visualizaciones
2,172 participa(n) en el debate
7
#WORPTLetsTouristsConvertCryptoToThaiBaht
6,556 visualizaciones
78 participa(n) en el debate
8
#TONStrategyReports$23.97MQ3NetLoss
7,363 visualizaciones
41 participa(n) en el debate
9
#PolkadotCommunityApprovesNewStrategyWith97%Vote
23,632 visualizaciones
275 participa(n) en el debate
10
#dYdXPlansV9.9UpgradeToShiftUSDCToInjective
18,275 visualizaciones
227 participa(n) en el debate