Ethereum Constantinople Hard Fork - La tercera fue la vencida

Luego de dos intentos fallidos para aplicar el hard fork de Ethereum Constantinople, los desarrolladores lo intentan nuevamente. La tercera es la vencida, seguramente dirán. Y es precisamente lo que ha pasado.

El día de hoy se ha llevado a cabo con total éxito un doble hard fork en la red Ethereum. Por un lado, han aplicado la tan esperada actualización Constantinople. Por el otro, han modificado la testnet con el hard fork St Petersburg. Todo ello sin que la red sufriera de una parada total y continuarán sus operaciones sin mayores dificultades.

El hard fork se ha llevado a cabo, tal como estaba planificado en el bloque número 7,280,000. Y se pudo monitorear toda la actividad desde un monitor de tráfico diseñado para tal fin.

La razón por la que Constantinople y St Petersburg han tenido que ser aplicadas al mismo tiempo, es debido al retraso sufrido por Constantinople. Recordemos que Constantinople fue suspendida debido a una vulnerabilidad descubierta en el ultimo minuto en una de sus nuevas características. Es por ello, que el lanzamiento fue aplazado hasta que la vulnerabilidad fuera corregida. Pese a que la actualización se llevo sin problemas, los desarrolladores han encontrado que muchos nodos aún ejecutan una versión vieja del software. Una situación espera se subsane en los días por venir.

También te puede interesar: El nuevo Galaxy con criptomonedero estará en el MWC de Barcelona y en Davos se dijo que los consejos de administración necesitan expertos en blockchain.

Sin embargo, esta situación no es atípica en Ethereum. En 2016, tras una controvertida actualización, Ethereum sufrió una gran división que es ahora conocida como Ethereum Classic.

Adicional a esto, la aplicación de St Petersburg ha desactivado una parte del código vulnerable de Constantinople, por el cual los atacantes podían robar fondos.

Ethereum Chain State Constantinople
Ethereum Chain State Constantinople

Que traen de nuevo Constantinople y St Petersburg

Los cambios que se implementan en Ethereum se definen usando los EIP (Ethereum Improvement Proposals) o Propuestas de Mejora de Ethereum. Estas describen los estándares para la plataforma Ethereum, incluyendo las especificaciones del protocolo central, las APIs de los clientes y los estándares de los contratos.

Los siguientes EIPs serán implementados en Constantinople:

EIP 145: Instrucciones de cambio de bits en EVM

Con esta mejora se busca proporcionar un desplazamiento nativo por bits con un coste a la par con otras operaciones aritméticas.

La EVM (Ethereum Virtual Machine), carece de operadores de cambio de bits, pero soporta otros operadores lógicos y aritméticos. Las operaciones de turnos se pueden implementar mediante operadores aritméticos, pero esto tiene un coste más elevado y requiere más tiempo de tratamiento. La implementación de SHL y SHR usando aritmética cuesta cada 35 gas, mientras que estas instrucciones propuestas toman 3 gas.

Con ello se busca reducir el coste total de ciertas operaciones, al tiempo que se facilita su programación y ejecución dentro del sistema.

EIP 1014: Skinny CREATE2

Esta mejora añade un nuevo opcode que permite la realización de interacciones con direcciones que aún no existen en la cadena. A pesar de que no existen dichas direcciones, se puede confiar en ellas para que sólo contengan código, porque eventualmente, serán creadas.

Este cambio es importante para los casos de uso de canales estatales que involucran interacciones contrafácticas con contratos.

EIP 1052: opcode EXTCODEHASH

Este cambio especifica un nuevo opcode, que devuelve el hash keccak256 del código de un contrato.

Muchos contratos necesitan realizar comprobaciones en el bytecode de un contrato, pero no necesariamente necesitan el bytecode en sí. Por ejemplo, un contrato puede querer comprobar si el bytecode de otro contrato es uno de un conjunto de implementaciones permitidas. También puede realizar análisis de código y hacer una lista blanca de cualquier contrato con bytecode coincidente.

Actualmente, los contratos pueden hacerlo utilizando el opcode de EXTCODECOPY, pero esto es costoso. Una situación que afecta especialmente para contratos grandes, en los casos en que solo se requiere el hash. Como resultado, se está implementando un nuevo opcode llamado EXTCODEHASH que devuelve el hash keccak256 del bytecode de un contrato.

Con este cambio se busca abaratar y agilizar el proceso de manejo de verificación del bytecode de un contrato.

EIP 1234: Retraso de la Bomba de dificultad y Ajuste de Recompensa de Bloque

Los tiempos medios de los bloques aumentan debido a que la bomba de dificultad se acelera lentamente. Este EIP propone retrasar la bomba de dificultad durante aproximadamente 12 meses. Además de reducir las recompensas de los bloques para ajustarse al retraso de la edad de hielo. De esta forma se asegura el funcionamiento de la blockchain hasta la llegada de la Prueba de la Participación (PoS).

¿Qué cambios produjo St Petersburg?

Por su parte St Peterburg ha eliminado una característica que originalmente se activaría con la llegada de Constantinople. Sin embargo, el descubrimiento de una vulnerabilidad que permitía a los atacantes robar fondos. Es por ello que para lograr una actualización segura, St Peterburg ha eliminado dicha característica bajo el EIP 1283.

Por José Maldonado

Activista y bloguero de tecnología, software libre y blockchain. Liberal y pro-anarquista.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

  • bitcoinBitcoin (BTC) $ 40,309.00
  • ethereumEthereum (ETH) $ 2,315.73
  • tetherTether (USDT) $ 0.998364
  • cardanoCardano (ADA) $ 1.29
  • bitcoin-cashBitcoin Cash (BCH) $ 502.37
  • litecoinLitecoin (LTC) $ 136.69
  • chainlinkChainlink (LINK) $ 19.88
  • stellarStellar (XLM) $ 0.263804
  • moneroMonero (XMR) $ 227.89
  • eosEOS (EOS) $ 3.80
  • tezosTezos (XTZ) $ 2.85
Esta web utiliza cookies. Puedes ver aquí la Política de Cookies. Si continuas navegando estás aceptándola    Ver
Privacidad