La semana pasada ayudé a un cliente a coordinar una transferencia transfronteriza; debido a que la red se trabó, se confirmó dos veces. El sistema lo detectó directamente como "transacción duplicada" y lo bloqueó. Pasaron horas y nadie daba una explicación. En la cadena, este caso en realidad es el mismo problema, pero la solución es totalmente diferente.
El modelo de cuentas de Moonlight de Dusk (o sea, ese sistema de cuentas transparentes) se basa en el nonce para evitar la repetición: cada cuenta está vinculada a un contador, y el nonce de cada transacción debe ser exactamente 1 mayor que el valor actual. Si es uno de más o uno de menos, la red la rechaza directamente. No es que el sistema intente “adivinar si lo tocaste dos veces”; es que los números por sí mismos fijan el orden y nadie puede echarle la culpa, además de que no necesitas esperar a que el soporte lo determine.
Esto no tiene nada que ver con la lógica antedoble gasto (anti-double-spend) de Phoenix: Phoenix se apoya en el nullifier; marca de forma única que cierto UTXO ya fue gastado una vez, y si se gastó, queda invalidado. Moonlight, en cambio, usa nonce: al incrementar por orden, bloquea la repetición. Dos modelos de cuentas, dos lógicas distintas de prevención de duplicados. En el whitepaper está bastante claro: no es la misma serie de código con otro nombre reutilizada en ambos lados.
Este diseño resuelve qué hacer si “la misma transacción es recibida dos veces por la red”, pero no resuelve qué hacer si “el usuario se equivoca y transfiere a la cuenta incorrecta”. El nonce controla el orden y la unicidad, no si el contenido de la transacción es correcto o no; esa parte todavía depende de las confirmaciones e interacciones en el lado de la billetera como respaldo.
$DUSK
#dusk @Dusk
El modelo de cuentas de Moonlight de Dusk (o sea, ese sistema de cuentas transparentes) se basa en el nonce para evitar la repetición: cada cuenta está vinculada a un contador, y el nonce de cada transacción debe ser exactamente 1 mayor que el valor actual. Si es uno de más o uno de menos, la red la rechaza directamente. No es que el sistema intente “adivinar si lo tocaste dos veces”; es que los números por sí mismos fijan el orden y nadie puede echarle la culpa, además de que no necesitas esperar a que el soporte lo determine.
Esto no tiene nada que ver con la lógica antedoble gasto (anti-double-spend) de Phoenix: Phoenix se apoya en el nullifier; marca de forma única que cierto UTXO ya fue gastado una vez, y si se gastó, queda invalidado. Moonlight, en cambio, usa nonce: al incrementar por orden, bloquea la repetición. Dos modelos de cuentas, dos lógicas distintas de prevención de duplicados. En el whitepaper está bastante claro: no es la misma serie de código con otro nombre reutilizada en ambos lados.
Este diseño resuelve qué hacer si “la misma transacción es recibida dos veces por la red”, pero no resuelve qué hacer si “el usuario se equivoca y transfiere a la cuenta incorrecta”. El nonce controla el orden y la unicidad, no si el contenido de la transacción es correcto o no; esa parte todavía depende de las confirmaciones e interacciones en el lado de la billetera como respaldo.
$DUSK
#dusk @Dusk