Estaba mirando el modelo de transacciones transparente de Dusk y, al principio, pasé por alto algo que sonaba casi demasiado básico: el nonce.
Moonlight es el modelo de transacciones basado en cuentas de Dusk. Cada cuenta tiene una clave pública, un saldo y un nonce, y el nonce actúa como un contador para las transacciones enviadas desde esa cuenta.
Ese minúsculo contador tiene un trabajo más grande de lo que parece.
El whitepaper conecta explícitamente el nonce con la protección contra replays. Una transacción no queda autorizada simplemente porque la firma sea válida; la secuencia de transacciones de la cuenta también tiene que tener sentido.
Esta es una de esas piezas de infraestructura de blockchain que los usuarios casi nunca notan cuando funciona correctamente.
Firmas una transacción, la red la procesa, tu saldo cambia y sigues adelante.
Pero si no existieran mecanismos que eviten que una transacción válida antigua sea aceptada de nuevo, la misma autorización podría potencialmente convertirse en un problema de seguridad completamente distinto.
Lo que me resulta interesante de Dusk es que Moonlight y Phoenix resuelven los mismos requisitos fundamentales de transacciones a través de modelos muy diferentes.
Moonlight expone públicamente el estado de la cuenta, los saldos y la metadata de la transacción. Phoenix traslada la verificación del saldo y la protección contra doble gasto a pruebas ZK y nulificadores. Aun así, ambos tienen que establecer la propiedad, prevenir la maleabilidad y detener el doble gasto.
Así que la decisión de diseño real no es simplemente pública vs. privada.
Es cuánto de la transición del estado puede verificar la red directamente frente a cuánto debe demostrarse criptográficamente.
Eso hace que el humilde nonce sea más interesante de lo que suena.
La transacción visible es solo la superficie. Debajo hay un conjunto de reglas que se aseguran de que la misma autorización no pueda simplemente repetirse.
¿Cuántas “características” de blockchain son en realidad suposiciones de seguridad invisibles que los usuarios solo notan cuando fallan?
@Dusk $DUSK #dusk
Moonlight es el modelo de transacciones basado en cuentas de Dusk. Cada cuenta tiene una clave pública, un saldo y un nonce, y el nonce actúa como un contador para las transacciones enviadas desde esa cuenta.
Ese minúsculo contador tiene un trabajo más grande de lo que parece.
El whitepaper conecta explícitamente el nonce con la protección contra replays. Una transacción no queda autorizada simplemente porque la firma sea válida; la secuencia de transacciones de la cuenta también tiene que tener sentido.
Esta es una de esas piezas de infraestructura de blockchain que los usuarios casi nunca notan cuando funciona correctamente.
Firmas una transacción, la red la procesa, tu saldo cambia y sigues adelante.
Pero si no existieran mecanismos que eviten que una transacción válida antigua sea aceptada de nuevo, la misma autorización podría potencialmente convertirse en un problema de seguridad completamente distinto.
Lo que me resulta interesante de Dusk es que Moonlight y Phoenix resuelven los mismos requisitos fundamentales de transacciones a través de modelos muy diferentes.
Moonlight expone públicamente el estado de la cuenta, los saldos y la metadata de la transacción. Phoenix traslada la verificación del saldo y la protección contra doble gasto a pruebas ZK y nulificadores. Aun así, ambos tienen que establecer la propiedad, prevenir la maleabilidad y detener el doble gasto.
Así que la decisión de diseño real no es simplemente pública vs. privada.
Es cuánto de la transición del estado puede verificar la red directamente frente a cuánto debe demostrarse criptográficamente.
Eso hace que el humilde nonce sea más interesante de lo que suena.
La transacción visible es solo la superficie. Debajo hay un conjunto de reglas que se aseguran de que la misma autorización no pueda simplemente repetirse.
¿Cuántas “características” de blockchain son en realidad suposiciones de seguridad invisibles que los usuarios solo notan cuando fallan?
@Dusk $DUSK #dusk