Antes trabajé durante unos años en el área de liquidación y la parte que más me agobiaba no eran las fluctuaciones del mercado, sino la “ventana de inacción” de la conciliación que ocurría cada día después del cierre. El dinero ya estaba negociado, pero en el sistema seguía figurando como “pendiente de confirmación”; en ese periodo no podías hacer nada, solo esperar. Al final, todavía había que hacer la conciliación, y si no cuadraba, entonces tocaba la trazabilidad. Era algo habitual que una operación no se diera por realmente cerrada hasta la mañana siguiente.
Mira Dusk: en el primer problema siempre está la finalidad. El libro contable ya no cambia de opinión. Succinct Attestation sigue una ruta determinista; dicho simple, es un flujo de confirmación que garantiza que “si el bloque queda, queda”. El bloque pasa por tres etapas: Proposal, Validation y Ratification; después de Ratification ya cuenta como confirmación final. No hay retrocesos probabilísticos, ni “esperar unos cuantos confirmaciones más”. En contabilidad, llegar con tres minutos de diferencia y llegar con un día de diferencia son dos mundos distintos.
Confirmar rápido tiene un coste. El consenso determinista exige muchísimo a los validadores: si un nodo cae o hay partición de red, en otras cadenas sería solo “un poco más lento”, pero en este mecanismo quizá directamente no se genere bloque. Yo mismo ejecuté nodos y lo comprobé: con una red doméstica, si cambias el IP una vez, basta para que se te escape una ronda de votaciones. Para tener garantías de liquidación a nivel institucional, primero hay que asegurar calidad de nodos.
El equipo de OtterSec revisó la implementación de PLONK de Dusk y descubrió una vulnerabilidad: en el último paso, el validador usó datos no verificados proporcionados por el probador, y en teoría podría existir un problema de falsificación (forja). El equipo reaccionó relativamente rápido: lo corrigieron en un día. Este asunto me recuerda que en ingeniería aún hay que seguir puliendo: en criptografía la capa central no deja de plantear problemas; no es “se arregla y ya se acaba”.
El ecosistema también es delgado: hay pocas aplicaciones aprovechables y el pulido de productos no alcanza la ambición técnica. NPEX tiene escenarios de colaboración reales, pero habrá que ver si las necesidades on-chain pueden traducirse a un consumo real de DUSK; el gas es la comisión de transacción on-chain, y eso todavía hay que comprobarlo.
La dirección es correcta, pero si las “pruebas” pendientes se superan o no es otro tema. No todos los proyectos que van en la dirección correcta logran sobrevivir hasta ese día. ¿Qué métricas usarán ustedes para determinar si una cadena “ya se puede usar”? #dusk $DUSK @Dusk
Mira Dusk: en el primer problema siempre está la finalidad. El libro contable ya no cambia de opinión. Succinct Attestation sigue una ruta determinista; dicho simple, es un flujo de confirmación que garantiza que “si el bloque queda, queda”. El bloque pasa por tres etapas: Proposal, Validation y Ratification; después de Ratification ya cuenta como confirmación final. No hay retrocesos probabilísticos, ni “esperar unos cuantos confirmaciones más”. En contabilidad, llegar con tres minutos de diferencia y llegar con un día de diferencia son dos mundos distintos.
Confirmar rápido tiene un coste. El consenso determinista exige muchísimo a los validadores: si un nodo cae o hay partición de red, en otras cadenas sería solo “un poco más lento”, pero en este mecanismo quizá directamente no se genere bloque. Yo mismo ejecuté nodos y lo comprobé: con una red doméstica, si cambias el IP una vez, basta para que se te escape una ronda de votaciones. Para tener garantías de liquidación a nivel institucional, primero hay que asegurar calidad de nodos.
El equipo de OtterSec revisó la implementación de PLONK de Dusk y descubrió una vulnerabilidad: en el último paso, el validador usó datos no verificados proporcionados por el probador, y en teoría podría existir un problema de falsificación (forja). El equipo reaccionó relativamente rápido: lo corrigieron en un día. Este asunto me recuerda que en ingeniería aún hay que seguir puliendo: en criptografía la capa central no deja de plantear problemas; no es “se arregla y ya se acaba”.
El ecosistema también es delgado: hay pocas aplicaciones aprovechables y el pulido de productos no alcanza la ambición técnica. NPEX tiene escenarios de colaboración reales, pero habrá que ver si las necesidades on-chain pueden traducirse a un consumo real de DUSK; el gas es la comisión de transacción on-chain, y eso todavía hay que comprobarlo.
La dirección es correcta, pero si las “pruebas” pendientes se superan o no es otro tema. No todos los proyectos que van en la dirección correcta logran sobrevivir hasta ese día. ¿Qué métricas usarán ustedes para determinar si una cadena “ya se puede usar”? #dusk $DUSK @Dusk