Je regardais le modèle de transaction transparent de Dusk et j’ai d’abord négligé quelque chose qui sonnait presque trop évident : le nonce.
Moonlight est le modèle de transaction basé sur les comptes de Dusk. Chaque compte possède une clé publique, un solde et un nonce, le nonce servant de compteur pour les transactions envoyées depuis ce compte.
Ce tout petit compteur a un rôle plus important qu’il n’y paraît.
Le livre blanc relie explicitement le nonce à la protection contre la ré-exécution. Une transaction n’est pas simplement autorisée parce que la signature est valide ; la séquence de transactions du compte doit aussi avoir du sens.
C’est l’un de ces éléments de l’infrastructure blockchain que les utilisateurs ne remarquent presque jamais lorsqu’il fonctionne correctement.
Vous signez une transaction, le réseau la traite, votre solde change et vous passez à autre chose.
Mais sans mécanismes empêchant qu’une ancienne transaction valide soit acceptée à nouveau, la même autorisation pourrait potentiellement devenir un problème de sécurité complètement différent.
Ce qui m’intéresse avec Dusk, c’est que Moonlight et Phoenix répondent aux mêmes exigences fondamentales de transaction avec des modèles très différents.
Moonlight expose publiquement l’état du compte, les soldes et les métadonnées de transaction. Phoenix déplace la vérification des soldes et la protection contre la double dépense dans des preuves ZK et des nullifiers. Pourtant, dans les deux cas, il faut encore établir la propriété, empêcher la malléabilité et empêcher la double dépense.
Donc la vraie décision de conception ne se résume pas simplement à public vs privé.
Il s’agit de la quantité de la transition d’état que le réseau peut vérifier directement par rapport à la quantité qui doit être prouvée cryptographiquement.
Cela rend le humble nonce plus intéressant que ce qu’il n’en a l’air.
La transaction visible n’est que la surface. En dessous, il y a un ensemble de règles qui garantissent que la même autorisation ne peut pas simplement être rejouée.
Combien de « fonctionnalités » d’une blockchain reposent en réalité sur des hypothèses de sécurité invisibles, que les utilisateurs ne remarquent que quand elles échouent ?
@Dusk $DUSK #dusk
Moonlight est le modèle de transaction basé sur les comptes de Dusk. Chaque compte possède une clé publique, un solde et un nonce, le nonce servant de compteur pour les transactions envoyées depuis ce compte.
Ce tout petit compteur a un rôle plus important qu’il n’y paraît.
Le livre blanc relie explicitement le nonce à la protection contre la ré-exécution. Une transaction n’est pas simplement autorisée parce que la signature est valide ; la séquence de transactions du compte doit aussi avoir du sens.
C’est l’un de ces éléments de l’infrastructure blockchain que les utilisateurs ne remarquent presque jamais lorsqu’il fonctionne correctement.
Vous signez une transaction, le réseau la traite, votre solde change et vous passez à autre chose.
Mais sans mécanismes empêchant qu’une ancienne transaction valide soit acceptée à nouveau, la même autorisation pourrait potentiellement devenir un problème de sécurité complètement différent.
Ce qui m’intéresse avec Dusk, c’est que Moonlight et Phoenix répondent aux mêmes exigences fondamentales de transaction avec des modèles très différents.
Moonlight expose publiquement l’état du compte, les soldes et les métadonnées de transaction. Phoenix déplace la vérification des soldes et la protection contre la double dépense dans des preuves ZK et des nullifiers. Pourtant, dans les deux cas, il faut encore établir la propriété, empêcher la malléabilité et empêcher la double dépense.
Donc la vraie décision de conception ne se résume pas simplement à public vs privé.
Il s’agit de la quantité de la transition d’état que le réseau peut vérifier directement par rapport à la quantité qui doit être prouvée cryptographiquement.
Cela rend le humble nonce plus intéressant que ce qu’il n’en a l’air.
La transaction visible n’est que la surface. En dessous, il y a un ensemble de règles qui garantissent que la même autorisation ne peut pas simplement être rejouée.
Combien de « fonctionnalités » d’une blockchain reposent en réalité sur des hypothèses de sécurité invisibles, que les utilisateurs ne remarquent que quand elles échouent ?
@Dusk $DUSK #dusk