Desarrolladores retrasan bifurcación en Ethereum por vulnerabilidad encontrada

La firma de seguridad ChainSecurity reportó hoy martes, quince de enero, que descubrió una vulnerabilidad (bug) en los contratos inteligentes, la cual podría ser aprovechada por agentes maliciosos tras la próxima bifurcación de Ethereum llamada Constantinople.

Según el reporte hecho por ChainSecurity, el bug descubierto permitiría llevar a cabo ataques de reentrada (reentrancy attack). Estos consisten en permitir que un atacante pueda ejecutar una determinada función indefinidamente por medio de un contrato inteligente; por lo tanto, el perpetrador del ataque podría simplemente “retirar fondos de una cartera para siempre”.

Tras haberse hecho pública la información sobre la vulnerabilidad, accionistas de Ethereum, representantes de firmas de ciberseguridad, desarrolladores tanto de Ethereum como de clientes diseñados para esta red, operadores de nodos, proveedores de carteras, así como desarrolladores de DApps y contratos inteligentes, entre otros, se reunieron para decidir qué hacer al respecto.

La decisión final fue la de postergar la bifurcación Constantinople hasta nuevo aviso, en vista de la proximidad del evento, que estaba estipulado que ocurriera entre el 16 y 17 de enero, a la altura del bloque 7.080.000. Al respecto, Evan Van Ness, quien pertenece al equipo de ConsenSys, comentó en Twitter que el próximo viernes decidirían cuándo se haría la esperada bifurcación.

A pesar de que el fork de Ethereum se ha retrasado nuevamente, los operadores de los clientes Geth y Parity, mineros en solitario, administradores de pools de minería de ether y casas de cambio tendrán que actualizar de emergencia el software, según lo que explica el comunicado oficial publicado en el blog de Ethereum.

Esta es la segunda postergación que sufre Constantinople en los últimos meses. En un principio se esperaba que esta bifurcación se diera a finales del 2018, pero en octubre, se supo que la comunidad de Ethereum tendría que esperar al 2019 para probar lo nuevo de esta red. En aquella oportunidad fueron fallas en el código, descubiertas al ser ejecutado en la red de pruebas, lo que provocó el primer retraso.

Imagen destacada por: ake1150 / stock.adobe.com