#dusk $DUSK @Dusk
Estos últimos días leí sobre Dusk y me di cuenta de algo bastante extraño.
Crypto habla mucho de TPS. Pero si lo que se está transfiriendo en la blockchain es una acción o un bono de alto valor, entonces la pregunta más importante quizá sea:
¿Cuándo terminará realmente esta operación?
Volví a leer la parte de DuskDS de @DuskFoundation y me pareció especialmente notable la Succinct Attestation.
Pasa un ciclo de consenso: proposal → validation → ratification. Después de que un bloque sea ratificado, DuskDS proporciona finalización determinista.
Suena algo seco 😅, pero si lo pones en contexto financiero se entiende mucho mejor.
Si A acaba de transferir un activo a B, B no solo necesita ver que la transacción aparece en el explorador. Necesitan saber que ese estado ya quedó confirmado para poder pasar al siguiente paso de la operación.
Y creo que aquí Dusk está escogiendo un problema bastante distinto al de muchas L1.
No solo “cuántas transacciones puede procesar”, sino también construir un settlement lo bastante claro para workflows financieros donde el hecho de que “ya quedó confirmado” o no realmente importa.
DuskDS también se encarga del consenso, settlement y data availability, mientras que DuskVM/DuskEVM sirven para distintos tipos de ejecución.
Cuanto más profundizo, más veo que la parte más interesante de $DUSK l está en cosas con poca “hype” como esta.
Si quieres llevar activos financieros reales a la cadena, a veces “final” es más importante que “rápido”.
$ACE
Estos últimos días leí sobre Dusk y me di cuenta de algo bastante extraño.
Crypto habla mucho de TPS. Pero si lo que se está transfiriendo en la blockchain es una acción o un bono de alto valor, entonces la pregunta más importante quizá sea:
¿Cuándo terminará realmente esta operación?
Volví a leer la parte de DuskDS de @DuskFoundation y me pareció especialmente notable la Succinct Attestation.
Pasa un ciclo de consenso: proposal → validation → ratification. Después de que un bloque sea ratificado, DuskDS proporciona finalización determinista.
Suena algo seco 😅, pero si lo pones en contexto financiero se entiende mucho mejor.
Si A acaba de transferir un activo a B, B no solo necesita ver que la transacción aparece en el explorador. Necesitan saber que ese estado ya quedó confirmado para poder pasar al siguiente paso de la operación.
Y creo que aquí Dusk está escogiendo un problema bastante distinto al de muchas L1.
No solo “cuántas transacciones puede procesar”, sino también construir un settlement lo bastante claro para workflows financieros donde el hecho de que “ya quedó confirmado” o no realmente importa.
DuskDS también se encarga del consenso, settlement y data availability, mientras que DuskVM/DuskEVM sirven para distintos tipos de ejecución.
Cuanto más profundizo, más veo que la parte más interesante de $DUSK l está en cosas con poca “hype” como esta.
Si quieres llevar activos financieros reales a la cadena, a veces “final” es más importante que “rápido”.
$ACE
