Según los informes, Istanbul, el próximo Hard Fork de Ethereum [ETH], que se lanzará en los próximos meses, ha encontrado problemas en la Testnet Ropsten. Inicialmente, Istanbul estaba programada para lanzarse en dicha red el día de hoy, 2 de octubre, a la altura del bloque #6,485,846.
Sin embargo, dado que los tiempos de bloque aumentaron, el cambio se produjo antes del tiempo especulado, a su vez, esto resultó en una cadena dividida, ya que varios mineros no actualizaron, y continuaron minando en la versión anterior.
El problema se destacó por primera vez en el canal AllCoreDev Gitter, con Aman Pruthi, un ingeniero de software que señaló:
“Ropsten está atascada en el bloque de Fork de Istanbul número 6,485,846 (parece que los mineros todavía tienen una versión Geth más antigua). Cambié a la nueva versión de Geth 1.9.5, y estoy atorado en el mismo número de bloque, por favor, aconséjenme cómo proceder mientras tanto, los Geths en la versión anterior continúan».
En particular, este problema no sólo se vio con Geth, sino con otros clientes de Ethereum. Peter Szilagyi, un desarrollador de la comunidad ETH, declaró en una página de GitHub que el único medio posible de resolver este problema era que la gente actualizara a la nueva versión y que «la cadena de Istanbul venciera a la anterior». Szilagyi expresó:
«El Fork Ropsten Istanbul fue ‘hacia el sur’ como lo esperábamos. La mayoría de las personas no se actualizaron, los grandes mineros están en la cadena no mejorada, causando todo tipo de problemas de sincronización (difícil encontrar y elegir buenos pares, la cadena es más pesada, es mala, etc.) Nuestro protocolo de red actual no puede dividir a los pares en conjuntos de Forks y no-Forks».
Protocolos e inutilidad
Szilagyi también destacó que el equipo había propuesto un «forkid» del Protocolo de Mejora de Ethereum (EIP) para manejar exactamente este tipo de escenario. Dicho EIP se habría asegurado de que «un nodo no sólo publicite su hash Génesis (ahora inútil) sino, más bien, una combinación de Génesis + todos los Forks siguientes». Añadió:
«Tal mecanismo permitiría que dos nodos se validen entre sí y se desconecten limpiamente si están en Forks diferentes, sin que pierdan el tiempo el uno del otro».
Dejando esto de lado, Afri Schoedon, Desarrollador de Relaciones de Parity Tech, señaló que el tiempo que se les dio a los usuarios para actualizar fue demasiado pequeño:
«Dos semanas no son suficientes para que los clientes lo lancen y los usuarios se actualicen».
