Saltar al contenido

Ethereum Constantinople / St. Anuncio de actualización de Petersburg

La red Ethereum se someterá a una actualización programada en bloque numero 7,280,000, que se prevé que ocurra en Jueves 28 de febrero de 2019.. La fecha exacta está sujeta a cambios dependiendo de los tiempos de bloqueo entre ahora y entonces y puede activarse 1-2 días antes o después. Un temporizador de cuenta regresiva se puede ver en https://amberdata.io/blocks/7280000. Puede monitorear la actualización de la red en tiempo real en http://forkmon.ethdevops.io/.

Constantinopla y San Petersburgo son los nombres dados a esta actualización de la red. Las actualizaciones de red anteriores han recibido otros nombres, como Dragón espurio y Bizancio. La razón por la que esta actualización de red tiene dos nombres es porque La actualización original de la red de Constantinopla fue pospuesta y deberán realizarse dos actualizaciones de protocolo en el mismo número de bloque para solucionar problemas en varias redes de prueba de Ethereum, como Ropsten.

Si utiliza un intercambio (como Coinbase, Kraken o Binance), un servicio de billetera web (como Metamask, MyCrypto o MyEtherWallet), un servicio de billetera móvil (como Coinbase Wallet, Status.im o Trust Wallet), o una billetera de hardware (como Ledger, Trezor o KeepKey) que no necesita hacer nada a menos que se le indique que tome medidas adicionales por parte de su servicio de cambio o billetera.

Descargue la última versión de su cliente Ethereum:

Si está utilizando un cliente de Ethereum que no está actualizado a la versión más reciente (mencionada anteriormente), su cliente se sincronizará con la cadena de bloques de actualización previa a la red una vez que se realice la actualización. Estará atrapado en una cadena incompatible siguiendo las reglas anteriores y no podrá enviar ether u operar en la red Ethereum posterior a la actualización.

Una actualización de la red es un cambio en el protocolo subyacente de Ethereum, que crea nuevas reglas para mejorar el sistema. La naturaleza descentralizada de los sistemas blockchain hace que la actualización de la red sea más difícil. Las actualizaciones de red en una cadena de bloques requieren cooperación y comunicación con la comunidad, así como con los desarrolladores de los diversos clientes de Ethereum para que la transición se realice sin problemas.

Una vez que la comunidad llega a un acuerdo sobre qué cambios deberían incluirse en la actualización, los cambios al protocolo se escriben en los diversos clientes de Ethereum, como geth, Parity y Harmony. Los cambios de protocolo se activan en un número de bloque específico. Todos los nodos que no se hayan actualizado al nuevo conjunto de reglas se abandonarán en la cadena antigua donde siguen existiendo las reglas anteriores.

Los cambios que se implementan en Constantinopla se definen mediante EIP. Las propuestas de mejora de Ethereum (EIP) describen los estándares para la plataforma de Ethereum, incluidas las especificaciones de los protocolos centrales, las API de los clientes y los estándares de los contratos. Los siguientes EIP se implementarán en Constantinopla.

EIP 145: Instrucciones de cambio de bit a bit en EVM

  • Proporciona cambios de bit a bit nativos con costo a la par con otras operaciones aritméticas.

  • EVM carece de operadores de cambio a nivel de bits, pero admite otros operadores lógicos y aritméticos. Las operaciones de cambio se pueden implementar a través de operadores aritméticos, pero eso tiene un costo mayor y requiere más tiempo de procesamiento. Implementar SHL y SHR usando aritméticos cuesta cada 35 gas, mientras que estas instrucciones propuestas toman 3 gas.

  • En resumen: este EIP agrega funcionalidad nativa al protocolo para que sea más barato y más fácil hacer ciertas cosas en la cadena.

EIP 1014: flaco CREATE2

  • Agrega un nuevo código de operación en 0xf5, que toma 4 argumentos de pila: dotación, memory_start, memory_length, salt. Se comporta de manera idéntica a CREAR, excepto que utiliza keccak256 (0xff ++ address ++ salt ++ keccak256 (init_code))) (12 🙂 en lugar de keccak256 (RLP (sender_address, nonce)) (12 🙂 como la dirección donde se encuentra el contrato inicializado en.

  • Esto permite que las interacciones se realicen con direcciones que aún no existen en la cadena, pero se puede confiar en que solo posiblemente contengan código eventualmente que haya sido creado por una pieza particular de código de inicio.

  • Importante para casos de uso de canal de estado que involucran interacciones contrafactuales con contratos.

  • En resumen: este EIP lo hace para que pueda interactuar con direcciones que aún no se han creado.

EIP 1052: código de operación EXTCODEHASH

  • Este EIP especifica un nuevo código de operación, que devuelve el hash keccak256 del código de un contrato.

  • Muchos contratos deben realizar comprobaciones en el código de bytes de un contrato, pero no necesariamente necesitan el código de bytes en sí. Por ejemplo, un contrato puede querer verificar si el bytecode de otro contrato es uno de un conjunto de implementaciones permitidas, o puede realizar análisis en el código y en la lista blanca de cualquier contrato con el bytecode correspondiente si el análisis pasa.

  • Actualmente, los contratos pueden hacer esto utilizando el código de operación EXTCODECOPY, pero esto es costoso, especialmente para contratos grandes, en los casos en que solo se requiere el hash. Como resultado, se está implementando un nuevo código de operación llamado EXTCODEHASH que devuelve el hash keccak256 del código de bytes de un contrato.

  • En resumen: este EIP hace que sea más barato (se necesita menos gas) para hacer ciertas cosas en la cadena.

EIP 1234: Retraso de bomba de dificultad de Constantinopla y ajuste de recompensa de bloque

  • Los tiempos promedio de bloqueo están aumentando debido a la bomba de dificultad (también conocida como la "edad de hielo") que se acelera lentamente. Este EIP propone retrasar la bomba de dificultad durante aproximadamente 12 meses y reducir las recompensas del bloque para ajustar el retraso de la edad de hielo.

  • En resumen: este EIP se asegura de que no congelamos la cadena de bloques antes de que esté listo e implementado el comprobante de participación.

Antes de que Ethereum realice actualizaciones de red en la red principal, las redes de prueba, como Ropsten, se actualizan para probar los cambios. Los cambios originales de Constantinopla, enumerados en esta publicación del blog, se aplicaron a las redes de prueba antes del aplazamiento y requieren una segunda actualización de la red para revertir los cambios originales de Constantinopla. Esto se llama San Petersburgo y ocurre en el mismo número de bloque que Constantinopla.

El siguiente EIP se eliminó de las redes de prueba utilizando la actualización de la red de San Petersburgo:

Eliminando EIP 1283: Medición de gas neta para SSTORE sin mapas sucios

Un gran agradecimiento a la comunidad de Ethereum, ya todos los desarrolladores de Ethereum en todos los clientes y plataformas que se unieron para proporcionar comentarios, opiniones y contribuciones. Un agradecimiento especial al usuario de Reddit cartercarlson que nos dejó usar su publicación de Reddit y el MyCrypto equipo que nos dejó usar su "Ethereum Constantinopla: Todo lo que necesitas saber”Mensaje medio.

RENUNCIA: Se trata de un espacio altamente técnico emergente y en evolución. Si elige implementar las recomendaciones en esta publicación y continúa participando, debe asegurarse de comprender cómo le afecta a usted. Debe comprender que existen riesgos involucrados que incluyen, entre otros, riesgos como errores inesperados. Al elegir implementar estas recomendaciones, solo usted asume los riesgos de las consecuencias. Esta publicación y las recomendaciones no son una venta de ningún tipo y no crean ninguna garantía de ningún tipo, incluidas, entre otras, las relacionadas con la red Ethereum o los clientes de Ethereum mencionados en este documento.

Fuente: https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/