#dusk $DUSK @Dusk
La documentación de las transacciones de Moonlight tiene una sección que la mayoría de la gente trata como simple “boilerplate”: la lista completa de las propiedades de seguridad que el whitepaper nombra formalmente. Son cuatro, y la última es más interesante de lo que suena.
Propiedades de seguridad de Moonlight: intraducibilidad (asegurada mediante firmas digitales), prevención de doble gasto (la red comprueba los saldos antes de aceptar), no maleabilidad (la firma cubre el hash de todos los campos de la transacción, así que cualquier modificación la invalida) y prevención de ataques de repetición (asegurada mediante el nonce).
Vale la pena pensar qué hace realmente el nonce aquí.
Un ataque de repetición ocurre cuando alguien toma una transacción válida y firmada y la reenvía. La firma es genuina: fuiste tú quien la firmó, pero no autorizaste este envío en particular. Sin un mecanismo de prevención de repetición, una transacción válida enviada una vez podría retransmitirse indefinidamente por cualquiera que la haya capturado.
El nonce lo soluciona. Cada cuenta de Moonlight tiene un nonce actual: un contador que se incrementa con cada transacción aceptada. Cuando envías una transacción, el campo nonce debe ser exactamente current_nonce + 1. La red rechaza cualquier cosa en la que falle esa comprobación. Una vez aceptada, el nonce de la cuenta incrementa, por lo que la misma transacción no puede reenviarse.
No digo que esto sea inusual. Cualquier cadena seria basada en cuentas usa nonces para este propósito exacto. Ethereum lo hace igual.
Tampoco digo que sea trivial. El nonce está haciendo un trabajo separado de la firma: la firma prueba la autorización, el nonce prueba que esta instancia específica de la transacción es nueva. Necesitas ambos, y cubren vectores de ataque distintos.
Lo que no he calculado es si los nonces de Moonlight son globales para la cuenta o por contrato: si al llamar a un contrato y enviar una transferencia directa desde la misma cuenta se comparte un único contador de nonce, o si cada tipo de interacción tiene su propia secuencia. @Dusk
$DUSK #dusk
La documentación de las transacciones de Moonlight tiene una sección que la mayoría de la gente trata como simple “boilerplate”: la lista completa de las propiedades de seguridad que el whitepaper nombra formalmente. Son cuatro, y la última es más interesante de lo que suena.
Propiedades de seguridad de Moonlight: intraducibilidad (asegurada mediante firmas digitales), prevención de doble gasto (la red comprueba los saldos antes de aceptar), no maleabilidad (la firma cubre el hash de todos los campos de la transacción, así que cualquier modificación la invalida) y prevención de ataques de repetición (asegurada mediante el nonce).
Vale la pena pensar qué hace realmente el nonce aquí.
Un ataque de repetición ocurre cuando alguien toma una transacción válida y firmada y la reenvía. La firma es genuina: fuiste tú quien la firmó, pero no autorizaste este envío en particular. Sin un mecanismo de prevención de repetición, una transacción válida enviada una vez podría retransmitirse indefinidamente por cualquiera que la haya capturado.
El nonce lo soluciona. Cada cuenta de Moonlight tiene un nonce actual: un contador que se incrementa con cada transacción aceptada. Cuando envías una transacción, el campo nonce debe ser exactamente current_nonce + 1. La red rechaza cualquier cosa en la que falle esa comprobación. Una vez aceptada, el nonce de la cuenta incrementa, por lo que la misma transacción no puede reenviarse.
No digo que esto sea inusual. Cualquier cadena seria basada en cuentas usa nonces para este propósito exacto. Ethereum lo hace igual.
Tampoco digo que sea trivial. El nonce está haciendo un trabajo separado de la firma: la firma prueba la autorización, el nonce prueba que esta instancia específica de la transacción es nueva. Necesitas ambos, y cubren vectores de ataque distintos.
Lo que no he calculado es si los nonces de Moonlight son globales para la cuenta o por contrato: si al llamar a un contrato y enviar una transferencia directa desde la misma cuenta se comparte un único contador de nonce, o si cada tipo de interacción tiene su propia secuencia. @Dusk
$DUSK #dusk
