Se activó PLONK V3 en la red principal (mainnet) al bloque 3,590,904, pero los bloques anteriores aún dependen de las reglas de PLONK V1 o V2 que se aplicaban cuando fueron producidos.
Al principio, eso puede sonar como una simple actualización del verificador. Pero una nueva regla para la actividad actual no se convierte automáticamente en la regla para todo el historial de Dusk.
Activar PLONK V3 me dice qué reglas de prueba usa Dusk a partir de esa frontera del fork. No me indica que los bloques anteriores se reevalúen con el verificador más nuevo.
Lo que todavía no sé es qué tan fiablemente la red de Dusk mantiene separadas esas eras de verificación mientras los nodos sincronizan, reproducen el historial y validan nuevas actividades con conjuntos de reglas diferentes.
Esto importa más a medida que Dusk construye infraestructura para flujos de emisión nativa, donde más del ciclo de vida de un valor de seguridad regulado puede depender de que el ledger preserve un historial consistente a través de actualizaciones de protocolo.
Rusk ofrece un mecanismo útil para observar. Selecciona el verificador apropiado en función de la altura del bloque, de modo que los bloques históricos se revisan bajo sus reglas originales mientras la actividad más reciente usa PLONK V3.
Una activación exitosa demuestra que Dusk puede introducir un nuevo verificador. La reproducción consistente entre V1, V2 y V3 es una evidencia más sólida porque los nodos tienen que acordar no solo las reglas actuales, sino exactamente qué reglas pertenecen a cada parte anterior de la cadena.
Eso cambia la forma en que evaluaría las actualizaciones criptográficas en Dusk.
La pregunta es si Dusk puede seguir evolucionando su pila criptográfica preservando exactamente las reglas que hicieron que cada bloque anterior fuera válido.
Estoy observando la reproducción histórica, la sincronización de nodos a través de fronteras de verificador y si los componentes de Dusk continúan seleccionando el mismo conjunto de reglas en la misma altura de bloque.
#dusk $DUSK @Dusk
Al principio, eso puede sonar como una simple actualización del verificador. Pero una nueva regla para la actividad actual no se convierte automáticamente en la regla para todo el historial de Dusk.
Activar PLONK V3 me dice qué reglas de prueba usa Dusk a partir de esa frontera del fork. No me indica que los bloques anteriores se reevalúen con el verificador más nuevo.
Lo que todavía no sé es qué tan fiablemente la red de Dusk mantiene separadas esas eras de verificación mientras los nodos sincronizan, reproducen el historial y validan nuevas actividades con conjuntos de reglas diferentes.
Esto importa más a medida que Dusk construye infraestructura para flujos de emisión nativa, donde más del ciclo de vida de un valor de seguridad regulado puede depender de que el ledger preserve un historial consistente a través de actualizaciones de protocolo.
Rusk ofrece un mecanismo útil para observar. Selecciona el verificador apropiado en función de la altura del bloque, de modo que los bloques históricos se revisan bajo sus reglas originales mientras la actividad más reciente usa PLONK V3.
Una activación exitosa demuestra que Dusk puede introducir un nuevo verificador. La reproducción consistente entre V1, V2 y V3 es una evidencia más sólida porque los nodos tienen que acordar no solo las reglas actuales, sino exactamente qué reglas pertenecen a cada parte anterior de la cadena.
Eso cambia la forma en que evaluaría las actualizaciones criptográficas en Dusk.
La pregunta es si Dusk puede seguir evolucionando su pila criptográfica preservando exactamente las reglas que hicieron que cada bloque anterior fuera válido.
Estoy observando la reproducción histórica, la sincronización de nodos a través de fronteras de verificador y si los componentes de Dusk continúan seleccionando el mismo conjunto de reglas en la misma altura de bloque.
#dusk $DUSK @Dusk
