He estado mirando @Dusk últimamente y cuanto más lo miro, más interesante me parece.
Primero, hablemos del ciclo de vida de las transacciones que más me tiene enganchado. Al principio yo también me dejé llevar por la supuesta finalidad determinista; después de revisar documentación durante varios días, descubrí que confirmed y finalized no son lo mismo. El bloque todavía no llega al último paso: aún puede revertirse. El proceso es: primero el provisioner propone un bloque candidato, luego una comisión aleatoria hace la validación, después viene un segundo grupo de ratification, y solo tras la fase de ratify es cuando se asienta de verdad. No es que una vez propuesto ya estás condenado: lo que sí es cierto es que después de la finalización ya no necesitas acumular más confirmaciones.
Si fuera una simple transferencia, da igual; pero en depósitos de exchanges o en entregas de valores no puedes jugar así. Detectar executed solo indica que se ejecutó; aún tienes que comprobar que el error esté vacío y recién el evento finalized es lo que da estabilidad. Si te llega un reverted, toca volver a escucharlo. Un revert del contrato es un error de código; un revert del bloque es un cambio en el consenso. La lógica de recuperación es completamente en direcciones opuestas. Si un integrador toma confirmed como si fuera finalized, la “determinación” se le va a romper en la capa de aplicación. Lo que más me preocupa ahora es si el exchange y Dusk Trade usan finalized como el límite unificado y si existe un flujo de reprocesamiento auditable.
Hablemos también de trading justo; esto de verdad me enfureció. El mempool es como un invernadero con las cortinas quitadas: lo que quieres comprar lo ve todo el mundo, y los robots tipo pinza pueden entrar en cualquier momento. $DUSK hizo una subasta batch privada directamente a nivel de protocolo: la puja y la cantidad se envían y, al instante, ZK lo protege. Los nodos calculan un precio justo que hace que la diferencia entre la demanda total de órdenes de compra ocultas y la oferta total de órdenes de venta quede cerca de cero; luego todas las órdenes colgadas en el mismo bloque se liquidan a ese precio. Se destapa la asimetría de información: la piscina oscura es justa desde sus entrañas.
En cumplimiento tampoco se quedan cortos. Phoenix usa ZK para preservar la privacidad; Moonlight trabaja con un libro mayor transparente; Citadel soporta divulgación selectiva; XSC mete en la lógica del contrato la elegibilidad, las restricciones y los reportes completos. Las reglas no puedes depender de que existan solo fuera de la cadena.
Cuanto más complejo es el producto, más reglas hay. La pregunta clave para mí es si se puede ejecutar con estabilidad en distintos flujos de trabajo. La verdadera finalidad no es un término: es el recorrido de los eventos del nodo hasta el libro contable, sin que nadie se adelante por la carrera. #dusk $DUSK
Primero, hablemos del ciclo de vida de las transacciones que más me tiene enganchado. Al principio yo también me dejé llevar por la supuesta finalidad determinista; después de revisar documentación durante varios días, descubrí que confirmed y finalized no son lo mismo. El bloque todavía no llega al último paso: aún puede revertirse. El proceso es: primero el provisioner propone un bloque candidato, luego una comisión aleatoria hace la validación, después viene un segundo grupo de ratification, y solo tras la fase de ratify es cuando se asienta de verdad. No es que una vez propuesto ya estás condenado: lo que sí es cierto es que después de la finalización ya no necesitas acumular más confirmaciones.
Si fuera una simple transferencia, da igual; pero en depósitos de exchanges o en entregas de valores no puedes jugar así. Detectar executed solo indica que se ejecutó; aún tienes que comprobar que el error esté vacío y recién el evento finalized es lo que da estabilidad. Si te llega un reverted, toca volver a escucharlo. Un revert del contrato es un error de código; un revert del bloque es un cambio en el consenso. La lógica de recuperación es completamente en direcciones opuestas. Si un integrador toma confirmed como si fuera finalized, la “determinación” se le va a romper en la capa de aplicación. Lo que más me preocupa ahora es si el exchange y Dusk Trade usan finalized como el límite unificado y si existe un flujo de reprocesamiento auditable.
Hablemos también de trading justo; esto de verdad me enfureció. El mempool es como un invernadero con las cortinas quitadas: lo que quieres comprar lo ve todo el mundo, y los robots tipo pinza pueden entrar en cualquier momento. $DUSK hizo una subasta batch privada directamente a nivel de protocolo: la puja y la cantidad se envían y, al instante, ZK lo protege. Los nodos calculan un precio justo que hace que la diferencia entre la demanda total de órdenes de compra ocultas y la oferta total de órdenes de venta quede cerca de cero; luego todas las órdenes colgadas en el mismo bloque se liquidan a ese precio. Se destapa la asimetría de información: la piscina oscura es justa desde sus entrañas.
En cumplimiento tampoco se quedan cortos. Phoenix usa ZK para preservar la privacidad; Moonlight trabaja con un libro mayor transparente; Citadel soporta divulgación selectiva; XSC mete en la lógica del contrato la elegibilidad, las restricciones y los reportes completos. Las reglas no puedes depender de que existan solo fuera de la cadena.
Cuanto más complejo es el producto, más reglas hay. La pregunta clave para mí es si se puede ejecutar con estabilidad en distintos flujos de trabajo. La verdadera finalidad no es un término: es el recorrido de los eventos del nodo hasta el libro contable, sin que nadie se adelante por la carrera. #dusk $DUSK