Un détail auquel je revenais sans cesse : le nonce de 32 octets ajouté à chaque payload.
C’est comme si l’on enfermait un court message dans une boîte en y plaçant une longue chaîne aléatoire, afin que personne ne puisse deviner le message simplement en regardant le verrou.
Dans Covenants, le protocole ne hache pas simplement l’instruction. Il y ajoute un nonce de 32 octets, puis crée l’engagement keccak256(payload || nonce). Comme de nombreuses instructions de marché sont courtes et prévisibles, cette part de hasard supplémentaire rend les tentatives de devinette par force brute impraticables.
Vous bénéficiez d’une meilleure protection contre quelqu’un qui chercherait à faire correspondre l’engagement sur la chaîne à un ordre courant. En contrepartie, vous devez disposer de 32 octets d’entropie qui n’apparaissent jamais sur la chaîne et que l’auteur doit conserver en sécurité jusqu’à la révélation.
Est-ce un prix raisonnable que d’ajouter 32 octets de hasard caché pour empêcher que des instructions prévisibles soient devinées ?
#nil $NIL @Nillion
C’est comme si l’on enfermait un court message dans une boîte en y plaçant une longue chaîne aléatoire, afin que personne ne puisse deviner le message simplement en regardant le verrou.
Dans Covenants, le protocole ne hache pas simplement l’instruction. Il y ajoute un nonce de 32 octets, puis crée l’engagement keccak256(payload || nonce). Comme de nombreuses instructions de marché sont courtes et prévisibles, cette part de hasard supplémentaire rend les tentatives de devinette par force brute impraticables.
Vous bénéficiez d’une meilleure protection contre quelqu’un qui chercherait à faire correspondre l’engagement sur la chaîne à un ordre courant. En contrepartie, vous devez disposer de 32 octets d’entropie qui n’apparaissent jamais sur la chaîne et que l’auteur doit conserver en sécurité jusqu’à la révélation.
Est-ce un prix raisonnable que d’ajouter 32 octets de hasard caché pour empêcher que des instructions prévisibles soient devinées ?
#nil $NIL @Nillion