Después de que la cartera muestra que todo “se completó”, el dinero aún no necesariamente es tuyo.
Ayer estuve mirando el flujo de transacciones de DuskEVM y me tropecé con un detalle poco intuitivo:
que una transacción entre en un bloque no significa que ya cuente.
La mayoría de la gente en la cadena confunde estas dos cosas.
Cuando la cartera salta a “éxito”, asumen que el dinero ya es suyo.
Pero en realidad, las transacciones en DuskEVM tienen dos etapas de vida.
La primera se llama “inclusión”. La transacción se envía al sequencer, se empaqueta en el bloque de la L2 y, aunque es rápido—cuestión de segundos—,
esta fase solo significa que “ya entró en la cola”.
La segunda se llama “finalización”. El batcher envía los datos de la transacción a DuskDS;
las garantías de estado y las pruebas de fallos quedan ancladas en la capa de consenso.
Esto es lo que realmente constituye el caso cerrado.
La frase exacta de la documentación oficial la tengo muy presente: la inclusión es rápida, pero la inclusión y la finalización son dos etapas distintas.
Rápido por un lado, firme por el otro, con un tramo de tiempo entre medio: “parece que ya llegó, pero todavía no es definitivo”.
Lo más contraintuitivo de este diseño es que le quita al usuario la capacidad de decidir “cuánto hay que esperar para que cuente”.
El método “artesanal” que circula en el mundo de Bitcoin es: 1 confirmación para comprar un café, 6 confirmaciones para cobrar el pago,
una experiencia que los comerciantes descubren mediante probabilidades; la cadena por sí misma no hace promesas.
Dusk incorpora ese asunto al protocolo: inclusión por un lado y finalización por el otro, con las etapas perfectamente claras.
El precio es sacrificar un poco de “sensación de fluidez”, a cambio de obtener certidumbre.
En aplicaciones financieras, el verdadero miedo no es la lentitud, sino “creer que ya llegó”.
Si una aplicación maneja una transferencia grande de nivel institucional y usa “cuántos segundos pasó” para inferir la inmutabilidad final,
un incidente no es solo un tema de comisiones: es un problema de responsabilidad en la liquidación.
Por eso la documentación oficial advierte especialmente a los desarrolladores:
si implica transferir activos entre capas,
hay que mirar el estado del protocolo o el estado de la cartera, y no intentar adivinar la finalización usando el tiempo.
Este diseño no tiene nada de sexy; incluso puede parecer un poco farragoso.
Pero el dinero sujeto a regulación no necesita sensaciones: necesita que cada operación pueda cerrarse de forma “definitiva”.
En una cadena institucional, ¿de qué se tiene más miedo: de que la finalización sea lenta, o de que parezca que “ya se completó” pero en realidad no? #dusk $DUSK @Dusk
Ayer estuve mirando el flujo de transacciones de DuskEVM y me tropecé con un detalle poco intuitivo:
que una transacción entre en un bloque no significa que ya cuente.
La mayoría de la gente en la cadena confunde estas dos cosas.
Cuando la cartera salta a “éxito”, asumen que el dinero ya es suyo.
Pero en realidad, las transacciones en DuskEVM tienen dos etapas de vida.
La primera se llama “inclusión”. La transacción se envía al sequencer, se empaqueta en el bloque de la L2 y, aunque es rápido—cuestión de segundos—,
esta fase solo significa que “ya entró en la cola”.
La segunda se llama “finalización”. El batcher envía los datos de la transacción a DuskDS;
las garantías de estado y las pruebas de fallos quedan ancladas en la capa de consenso.
Esto es lo que realmente constituye el caso cerrado.
La frase exacta de la documentación oficial la tengo muy presente: la inclusión es rápida, pero la inclusión y la finalización son dos etapas distintas.
Rápido por un lado, firme por el otro, con un tramo de tiempo entre medio: “parece que ya llegó, pero todavía no es definitivo”.
Lo más contraintuitivo de este diseño es que le quita al usuario la capacidad de decidir “cuánto hay que esperar para que cuente”.
El método “artesanal” que circula en el mundo de Bitcoin es: 1 confirmación para comprar un café, 6 confirmaciones para cobrar el pago,
una experiencia que los comerciantes descubren mediante probabilidades; la cadena por sí misma no hace promesas.
Dusk incorpora ese asunto al protocolo: inclusión por un lado y finalización por el otro, con las etapas perfectamente claras.
El precio es sacrificar un poco de “sensación de fluidez”, a cambio de obtener certidumbre.
En aplicaciones financieras, el verdadero miedo no es la lentitud, sino “creer que ya llegó”.
Si una aplicación maneja una transferencia grande de nivel institucional y usa “cuántos segundos pasó” para inferir la inmutabilidad final,
un incidente no es solo un tema de comisiones: es un problema de responsabilidad en la liquidación.
Por eso la documentación oficial advierte especialmente a los desarrolladores:
si implica transferir activos entre capas,
hay que mirar el estado del protocolo o el estado de la cartera, y no intentar adivinar la finalización usando el tiempo.
Este diseño no tiene nada de sexy; incluso puede parecer un poco farragoso.
Pero el dinero sujeto a regulación no necesita sensaciones: necesita que cada operación pueda cerrarse de forma “definitiva”.
En una cadena institucional, ¿de qué se tiene más miedo: de que la finalización sea lenta, o de que parezca que “ya se completó” pero en realidad no? #dusk $DUSK @Dusk
怕慢,效率就是一切
100%
怕假到账,责任说不清
0%
都怕,所以干脆不上链
0%
1 Votos • Votación cerrada