Una cadena pública fue hackeada; la solución es retrotraer el libro mayor hasta antes del ataque
Vi un anuncio de MultiversX y mi primera reacción fue: la red principal se detuvo.
El motivo es que los atacantes se fijaron en una vulnerabilidad “atómica” dentro de la máquina virtual, e introdujeron en la cadena un conjunto de estados que no deberían existir. La respuesta del equipo no fue solo parchear y reiniciar, sino preparar una “bifurcación dura coordinada”: volver a iniciar la cadena desde un punto de control que ya se confirmó como correcto, lo que equivale a retroceder el libro mayor por un tramo.🧐
El progreso ahora es este: las pruebas internas ya se completaron y el punto de control para la red principal también está listo. A continuación, falta coordinar pruebas en una red de pruebas con validadores y exchanges. El anuncio repite una y otra vez la advertencia a los usuarios: la red principal sigue detenida; no transmitan transacciones, y tampoco utilicen exchanges ni puentes entre cadenas para depósitos o retiros.
Modificar el código y registrar el rollback son dos cosas distintas. El parche arregla cómo se ejecutará el sistema a partir de ahora; el rollback refleja ese tramo que ya quedó asentado. El primero es un problema de ingeniería; el segundo se parece más a establecer reglas para una cadena.
Así que quisiera preguntar: cuando se hace este “rebobinado” para recuperar las pérdidas, ¿prefieres verlo como una solución de emergencia, o como un precedente que no debería abrirse?
👉 关注我，点击进入聊天室，学习更多策略
#multiversx计划协调硬分叉恢复
Vi un anuncio de MultiversX y mi primera reacción fue: la red principal se detuvo.
El motivo es que los atacantes se fijaron en una vulnerabilidad “atómica” dentro de la máquina virtual, e introdujeron en la cadena un conjunto de estados que no deberían existir. La respuesta del equipo no fue solo parchear y reiniciar, sino preparar una “bifurcación dura coordinada”: volver a iniciar la cadena desde un punto de control que ya se confirmó como correcto, lo que equivale a retroceder el libro mayor por un tramo.🧐
El progreso ahora es este: las pruebas internas ya se completaron y el punto de control para la red principal también está listo. A continuación, falta coordinar pruebas en una red de pruebas con validadores y exchanges. El anuncio repite una y otra vez la advertencia a los usuarios: la red principal sigue detenida; no transmitan transacciones, y tampoco utilicen exchanges ni puentes entre cadenas para depósitos o retiros.
Modificar el código y registrar el rollback son dos cosas distintas. El parche arregla cómo se ejecutará el sistema a partir de ahora; el rollback refleja ese tramo que ya quedó asentado. El primero es un problema de ingeniería; el segundo se parece más a establecer reglas para una cadena.
Así que quisiera preguntar: cuando se hace este “rebobinado” para recuperar las pérdidas, ¿prefieres verlo como una solución de emergencia, o como un precedente que no debería abrirse?
👉 关注我，点击进入聊天室，学习更多策略
#multiversx计划协调硬分叉恢复
