Esa actualización de Aegis, la de $DUSK : yo estuve pendiente del panel de nodos hasta quedarme despierto esa misma jornada. Según lo dicho por la oficina, es muy directo: "una actualización obligatoria para todos los operadores de nodos". Si no te actualizas, el nodo sale directamente de la red cuando se active el hard fork, sin periodo de transición opcional.
Revisé el registro de cambios de Rusk v1.7.0 y encontré que en esta actualización se esconde una corrección discreta pero bastante clave: en dusk-wallet-core, "evitar que la agregación de saldos de Phoenix ocurra con un overflow en u64". En otras palabras: el código anterior del monedero, al sumar los saldos de Phoenix (el modelo de cuentas cifradas UTXO de Dusk), en teoría podía sufrir un desbordamiento numérico y "volver" a un número muy pequeño o incluso incorrecto. Esta actualización elimina ese riesgo. Dentro del mismo lote de cambios también se incluye el cambio de la verificación de pruebas PLONK a la versión V3, se añadió un límite de tamaño al cuerpo de las solicitudes HTTP para prevenir un DoS por falta de memoria, y en el flujo de recuperación se cerró una vulnerabilidad de escritura por cruce de rutas ZIP inseguras. Todo eso son acciones típicas de "refuerzo de seguridad para un sistema de nivel producción": no son mejoras funcionales, sino labores de despeje.
Como operador de nodos, lo que más me preocupa en realidad es el riesgo que supone la propia ventana de actualización: la altura de activación de Aegis en la red principal es 3.590.904, y en la red de pruebas es 2.773.727; está fijada por altura de bloque, no es una ventana blanda tipo "cuando termines de actualizar, entonces entra en vigor". Si una parte de los nodos no alcanza a completar la actualización antes de esa altura de bloque, ¿podría la red mostrar por un momento una inconsistencia de consenso por la bifurcación? La versión oficial dice que "es una actualización de infraestructura para allanar el camino de DuskEVM y no involucra economía de tokens"; suena a que el impacto es controlable, pero una hard fork obligatoria, por sí misma, siempre es una prueba real de riesgo de coordinación para una red que no es muy descentralizada y en la que aún no hay demasiados nodos. #dusk
Esta actualización se desplegó sin problemas; en cierto sentido, antes de que @Dusk empiece a correr oficialmente DuskEVM, ya hicimos una prueba de carga para someter a prueba el consenso subyacente y la capa de almacenamiento. La actualización en sí no tuvo fallos, pero esas cuatro palabras: "hard fork forzado", merecen que cada persona que vaya a operar un nodo o que dependa de la determinación del procesamiento de Dusk en la liquidación le eche un vistazo extra.
Revisé el registro de cambios de Rusk v1.7.0 y encontré que en esta actualización se esconde una corrección discreta pero bastante clave: en dusk-wallet-core, "evitar que la agregación de saldos de Phoenix ocurra con un overflow en u64". En otras palabras: el código anterior del monedero, al sumar los saldos de Phoenix (el modelo de cuentas cifradas UTXO de Dusk), en teoría podía sufrir un desbordamiento numérico y "volver" a un número muy pequeño o incluso incorrecto. Esta actualización elimina ese riesgo. Dentro del mismo lote de cambios también se incluye el cambio de la verificación de pruebas PLONK a la versión V3, se añadió un límite de tamaño al cuerpo de las solicitudes HTTP para prevenir un DoS por falta de memoria, y en el flujo de recuperación se cerró una vulnerabilidad de escritura por cruce de rutas ZIP inseguras. Todo eso son acciones típicas de "refuerzo de seguridad para un sistema de nivel producción": no son mejoras funcionales, sino labores de despeje.
Como operador de nodos, lo que más me preocupa en realidad es el riesgo que supone la propia ventana de actualización: la altura de activación de Aegis en la red principal es 3.590.904, y en la red de pruebas es 2.773.727; está fijada por altura de bloque, no es una ventana blanda tipo "cuando termines de actualizar, entonces entra en vigor". Si una parte de los nodos no alcanza a completar la actualización antes de esa altura de bloque, ¿podría la red mostrar por un momento una inconsistencia de consenso por la bifurcación? La versión oficial dice que "es una actualización de infraestructura para allanar el camino de DuskEVM y no involucra economía de tokens"; suena a que el impacto es controlable, pero una hard fork obligatoria, por sí misma, siempre es una prueba real de riesgo de coordinación para una red que no es muy descentralizada y en la que aún no hay demasiados nodos. #dusk
Esta actualización se desplegó sin problemas; en cierto sentido, antes de que @Dusk empiece a correr oficialmente DuskEVM, ya hicimos una prueba de carga para someter a prueba el consenso subyacente y la capa de almacenamiento. La actualización en sí no tuvo fallos, pero esas cuatro palabras: "hard fork forzado", merecen que cada persona que vaya a operar un nodo o que dependa de la determinación del procesamiento de Dusk en la liquidación le eche un vistazo extra.