Actualités du développement Safe 🇫🇷 9 septembre 2021

Dimitar · Octobre 8, 2021, 9:56

Ceci est une traduction automatique. L’original en anglais est ici: Update 09 September, 2021

Cette semaine, nous abordons un peu plus en détail la dissociation de DBC et les implications et les compromis pour l’expérience utilisateur et l’efficacité du réseau.

Progrès général

Un Aîné est un type particulier de nœud avec des droits de vote et des fonctions de gestion, tandis qu’un Adulte stocke des données et les fournit sur demande, mais pour le client, elles se ressemblent exactement. @chris.connelly a résolu certains bogues qui voient un client essayer de s’amorcer vers un adulte, qui l’ignore ensuite, créant une boucle désagréable.

Chris a également travaillé sur l’amélioration de l’outil sn_launch (comme certains d’entre vous l’ont remarqué !) et sur le débogage de la mise à niveau de qp2p.

@JimCollinson s’est penché sur la question des informations d’identification, en utilisant multisig pour pouvoir ajouter plus d’options d’authentification au mot de passe/mnémonique de base, y compris des clés matérielles, des mnémoniques supplémentaires ou des phrases de départ, etc. Par exemple, l’utilisateur peut stipuler que trois de cinq informations d’identification doivent être présentées pour déverrouiller un coffre-fort. Multisig ouvre également la porte à l’utilisation de n tiers de confiance pour récupérer un compte, si vous le souhaitez. Les utilisateurs de Safe Network perdront inévitablement leurs informations d’identification, et multisig offre une voie de récupération de compte sécurisée permettant à l’utilisateur de contrôler la balance des risques comme bon lui semble.

@bochaco examine comment le client valide que la section à laquelle il parle est à jour via AE.

@Qi_Ma examine ce qui se passe lorsque les adultes deviennent rassasiés. Il existe actuellement un comportement aberrant dans la façon dont le prochain adulte alternatif non complet est choisi pour stocker un morceau par les anciens et comment les Aînés savent où se trouve le morceau, étant donné qu’il n’est plus le XOR le plus proche du nom du morceau.

Pendant ce temps, @chriso a travaillé sur la modernisation de l’API pour prendre en compte les nouveaux changements de messagerie, une tâche qui est presque terminée maintenant.

Le travail de @oetyng avec l’intégration de l’« auto-chiffrement » renforcé avec le refactor de gestion des morceaux a été fusionné. La dualité de portée (public/privé) a été déplacée du niveau des morceaux au niveau des blob - simplifiant considérablement les tâches du code et des nœuds. Une gestion appropriée de la clé secrète de facto, que l’auto-cryptage sort avec les morceaux cryptés, a également été ajoutée. Avec cela en place, le travail sur le traitement par lots peut maintenant se poursuivre.

Nous avons également fusionné notre branche de fonctionnalité de travail en cours avec master (ou plutôt, nous avons déplacé le HEAD de main vers celui-ci si vous voulez entrer dans les détails de git…). Cela signifie que la branche était plus stable que la principale. Nous voyons plus de pass CI et un code beaucoup plus propre en général. Il y a beaucoup de choses qui ont été ajoutées dans cette branche, et nous testons et déboguons toujours divers flux. Mais avec AE partout et un flux de code plus simple dans le nœud, tout devient plus facile au fur et à mesure. Ainsi, même s’il n’y a pas encore de testnet avec lequel les gens peuvent jouer, nous allons dans la bonne direction.

Plus sur les DBC

Poursuivant notre série sur les DBC, cette semaine, nous approfondissons la propriété de la unlinkability. Nous expliquons pourquoi c’est important et examinons les différentes manières dont les crypto-monnaies axées sur la confidentialité tentent d’y parvenir.

Espérons que cet aperçu puisse servir à fournir aux lecteurs plus de contexte et d’arrière-plan pour les technologies que nous avons explorées, telles que les preuves de connaissance zéro, les signatures aveugles, les engagements, les dénominations fixes, etc.

Dissociabilité

Alors pourquoi est-il important qu’un jeton monétaire soit unlinkable ? En bref, parce que c’est le moyen technique pour obtenir la propriété monétaire plus générale et hautement souhaitable de fongibilité. La fongibilité signifie qu’un jeton est interchangeable avec un autre.

Pensez à deux lingots d’or non marqués de poids égal. L’un est aussi bon que l’autre. Ils sont indiscernables. Cependant, si ces barres sont marquées de numéros de série et qu’une entité centrale conserve une liste de tous les échanges d’or suivis par le numéro de série, alors nous pouvons avoir une situation où une barre devient moins chère qu’une autre dans l’esprit des destinataires potentiels parce qu’elle était associée à une « mauvaise » activité dans le passé. Ou un autre pourrait être encore plus précieux parce qu’il est passé entre les mains d’une personne célèbre. Avec un tel système, les participants peuvent commencer à perdre confiance dans les lingots d’or. Ils peuvent avoir à vérifier par rapport à une « liste bonne/mauvaise » centralisée pour chaque transaction afin d’éviter de recevoir une « mauvaise barre », et le système global devient moins efficace. En raison du suivi, nous avons perdu la fongibilité. Pour en savoir plus à ce sujet, consultez l’article lié ci-dessus.

Il existe également de nombreuses implications en matière de perte de confidentialité lors de la réception ou de l’exécution d’un paiement avec un jeton auquel il est attaché depuis longtemps. Le Safe Network aspire à permettre des transactions privées et sûres pour tous les participants du réseau.

Comment pouvons-nous déterminer si une pièce est linkable ou unlinkable? C’est en fait assez simple, nous regardons simplement les entrées et les sorties d’une paire de transactions.

Remarque: Dans le cas des DBC, nous utilisons souvent les mots transaction et reissue dansinterchangeable

Voici un exemple simplifié de deux rééditions utilisant notre système DBC actuel. On peut dire que Bob a payé 50 à Alice (1ère réédition) puis Alice a payé les mêmes 50 à Jim (2ème réédition). Ainsi, chaque réédition n’a qu’un seul DBC d’entrée et un seul DBC de sortie. Chaque DBC a un amount associé, la clé publique du propriétaire pubkey et une signature mint mintsig. Dans cet exemple, pubkey, mintsig et hash sont raccourcis à 3 chiffres par souci de concision. En réalité, ce sont de très grands nombres uniques.

réédition 1 (r1) :
→ input = a {amount=50, pubkey = 567, mintsig=233}, hash(a) = 223
→ sortie = b {montant = 50, pubkey = 725, mintsig=112}, hash(b) = 787

réédition 2 (r2) :
→ input = b {amount = 50, pubkey = 725, mintsig=112 }, hash(b) = 787
→ sortie = c {amount = 50, pubkey = 212, mintsig=455}, hash(c) = 993

Remarque : a, b et c sont des étiquettes pour cet exemple. Ils n’apparaissent pas dans une réédition. Les montants sont désormais masqués par les engagements, mais ne sont pas pertinents pour cette analyse.

Nous pouvons facilement voir que l’entrée b pour r2 correspond à la sortie b pour r1. Nous pouvons les lier ensemble par l’un des éléments suivants : pubkey == 725 ou mintsig == 112, ou hash == 787.

Cela établit que les rééditions r1 et r2 sont liées ensemble car elles partagent un DBC commun. Au fil d’une série de rééditions, cela crée une chaîne qui peut être suivie.

C’est ce que l’on entend par linkability.

De plus, si le montant est une valeur très unique (ou un engagement de valeur), il peut être utilisé pour lier des transactions.

Un point important à noter est que même si nous supprimons les champs pubkey et mintsig et utilisons simplement un champ id aléatoire (pour éviter les doubles dépenses), les DBC sont toujours identifiables par leur valeur de hachage. En d’autres termes, si les mêmes données sont utilisées comme sortie d’une réédition et comme entrée d’une autre, alors les rééditions peuvent être liées. Ceci est généralisable à n’importe quelle crypto-monnaie, en remplaçant le mot transaction par réémission.

Vous pouvez vous demander: et si nous utilisions plusieurs entrées et sorties et des quantités variables pour diviser et fusionner les jetons ? Eh bien, de telles techniques peuvent rendre plus difficile la certitude de la trace d’un jeton individuel. C’est la base de CoinJoin, CoinShuffle et des algorithmes de mixage similaires. Ils font plus de liens possibles à suivre/évaluer. Mais ils ne rompent en réalité aucun lien… qui sont conservés indéfiniment pour que chacun puisse les analyser à loisir à l’aide d’analyses statistiques, de données de tiers (échanges par exemple), etc. De telles techniques sont généralement considérées comme «faible-sauce» par les cryptographes.

Vous pouvez également demander: pourquoi avoir un identifiant unique dans le DBC ? La réponse est qu’un identifiant est nécessaire pour éviter les doubles dépenses. La monnaie doit être en mesure d’enregistrer une « pièce » comme dépensée, afin d’attraper toute tentative future de la dépenser à nouveau.

Une fois que nous comprenons la liabilité, nous pouvons commencer à réfléchir aux moyens de l’empêcher.

Un système avec la propriété de unlinkability n’aurait pas de tels liens. La grande question est, comment atteindre cette propriété ?

Signatures aveugles

La plus ancienne technique connue a été inventée par David Chaum et est connue sous le nom de signatures aveugles. Il a l’avantage d’être le schéma le plus simple à mettre en œuvre, et pour l’instant du moins, le plus efficace, ce qui le rend très bien adapté aux opérations de monnayage.

Passons en revue le concept de base d’une signature aveugle. Le papier de Chaum prend l’exemple d’une élection menée à distance. Nous présentons ici une version condensée, bien que celle de Chaum mérite également d’être lue.

Une signature à l’aveugle, c’est comme mettre un « bout de papier » avec un message (par exemple un vote) à l’intérieur d’une « enveloppe » doublée de carbone. Mary envoie l’« enveloppe » avec le « bordereau » à l’intérieur et une adresse de retour au fonctionnaire électoral Charles. Charles signe l’« enveloppe » (qui signe aussi le « bordereau » à l’intérieur) et la renvoie. Plus tard, Mary retire le « bulletin » de vote et le renvoie à Charles dans une nouvelle « enveloppe », mais sans adresse de retour. Charles ouvre « l’enveloppe », retire le « bordereau », vérifie qu’il a une signature valide de Charles et compte le vote – sans savoir qui a émis ce vote particulier ou quand il a été signé (parmi l’ensemble des enveloppes signées).

Le point clé est qu’il n’y a aucun lien entre ce qui est sur l’un des feuillets et ce qui a été écrit sur l’une des enveloppes. Ainsi, le vote exprimé par chacun des électeurs est inconnu du fonctionnaire électoral Charles. (à l’exclusion de l’écriture médico-légale, etc., qui ne sont pas pertinentes pour les discussions cryptographiques).

Ok, alors refait nos deux rééditions, cette fois en utilisant des signatures aveugles. C’est désormais la DBC Mint qui signe aveuglément la ou les enveloppes. Pour cet exemple, nous supposons que tous les DBC ont la même valeur.

réédition 1 (r1) :
→ input = a.slip {pubkey = 567, mintsig=233}, hash(a.slip) = 223
→ sortie = b.envelope {blind(b.slip)}, hash(b.envelope) = 565

réédition 2 (r2) :
→ input = b.slip {pubkey = 445, mintsig=112 }, hash(b.slip) = 787
→ sortie = c.envelope {blind(c.slip)}, hash(c.envelope) = 993

Dans les mots:

Bob présente l’entrée A (slip) à la menthe (wavec un sig d’atelier valide sur A) et obtient la signature de l’atelier sur la sortie B (enveloppe) avec un sig d’atelier indiquant que B vaut la même chose que A (slip).
L’état neuf marque également A (slip) comme dépensé.
Bob retire B (feuillet) de B (enveloppe) et le donne à Alice, qui présente B (feuillet) à la monnaie et obtient le sig de la monnaie sur C (enveloppe) d’une valeur égale à B (feuillet).
L’état neuf marque également B (slip) comme dépensé.

Maintenant, la chose intéressante ici est que B (enveloppe) a un hachage différent de B (feuillet) à l’intérieur. 565 != 787

Par conséquent, les hachages ne correspondent pas entre tx1 et tx2 et ni les champs. Rien ne relie ces deux transactions pour autant que la Monnaie puisse le voir. Nous avons l’indissociabilité!

Circuits Zéro Connaissance

Une approche plus moderne des transactions non liées consiste à utiliser des circuits de preuve Zero-Knowledge (ZK) comme ZCash.

Avec les preuves ZK, nous essayons de convaincre la Monnaie de quelque chose sans révéler certaines informations sensibles. Les systèmes d’épreuves de circuits ZK comme PLONK sont apparus au cours des dernières années en tant que systèmes généraux pour l’ingénierie des épreuves ZK.

Par exemple, supposons que nous implémentions un circuit ZK qui simule sha3_256. Ce circuit nous permettrait de prouver à un tiers que nous connaissons les données qui hachent un certain hachage sans révéler les données elles-mêmes. Nous pouvons même prouver des propriétés sur ces données !

Disons par exemple que les données que nous hachons sont en fait une transaction de réémission entière.

laisser rééditer = Rééditer {
   entrées : { Dbc {montant : 9, propriétaire : pk1,..}, Dbc {montant : 1, propriétaire : pk2,..},
   sorties : { Dbc {montant : 10, propriétaire : pk3,..}
   property_proofs : {pk1_sig, pk2_sig}
} ;

Je pourrais exécuter cette réédition via sha3_256 pour produire un hachage : tx_hash = sha3_256(reissue).
Pour convaincre la Monnaie qu’il s’agit d’un hachage d’une transaction valide, nous pouvons générer une preuve ZK en utilisant notre circuit sha3_256.

Un circuit ZK a des entrées privées et publiques, dans cet exemple, les informations de réédition seront des entrées privées et le tx_hash sera une entrée publique.

privé : [9, pk1, 1, pk2, 10, pk3, pk1_sig, pk2_sig]
public : [tx_hash]

Nous pouvons écrire des contraintes sur ces entrées privées/publiques, ces contraintes sont codées dans un circuit ZK qui peut ensuite être exécuté pour produire des preuves que ces contraintes sont satisfaites

/// Contraintes de réédition
privé[0] + privé[2] = privé[4] // 9 + 1 = 10
private[1].verify(private[0..6], public[6]) // pk1 a signé la transaction
private[3].verify(private[0..6], public[7]) // pk2 a signé la transaction
public[0] = sha3_256(private) // réémet les hachages de données vers tx_hash

Remarque : nous faisons référence aux entrées par leur index, les circuits ont une taille prédéterminée, cette taille limite le nombre de DBC d’entrée/sortie que nous pouvons réémettre au sein d’une seule transaction de réémission.

Maintenant, une fois que nous avons codé ces contraintes en tant que circuit ZK, nous pouvons insérer les détails de la réédition dans les emplacements d’entrée privés et le tx_hash dans l’emplacement d’entrée public du circuit. Nous tournons ensuite la manivelle pour produire une preuve que toutes les contraintes sont satisfaites.

Il est important de noter que cette preuve ne divulgue aucune information sur les entrées privées, nous pouvons envoyer cette preuve avec le tx_hash à un Mint et il serait convaincu que ce tx_hash est un hachage d’une transaction valide. La monnaie pourrait alors signer tx_hash pour certifier la réédition.

C’est très cool, mais la recherche dans ce domaine est encore jeune et l’outillage autour de ces systèmes de circuits ZK est encore assez immature. Les preuves ont tendance à être très lentes à produire et à vérifier, en particulier pour les circuits complexes comme sha3_256.

Si vous souhaitez approfondir cette série est assez bonne.

Signatures de bague

Les signatures en anneau, telles qu’elles sont utilisées dans Monero et d’autres crypto-monnaies, sont une méthode pour masquer l’historique des transactions en se cachant dans un groupe.

Dans une signature en anneau, Alice signe une transaction en utilisant (1) la clé privée d’Alice, (2) la clé publique d’Alice et (3) les clés publiques d’autres personnes. N’importe qui peut vérifier la signature d’Alice à l’aide de l’ensemble de clés publiques, mais il est (généralement) incapable de déterminer qui était le véritable signataire car il existe plusieurs clés publiques équivalentes.

En tant que telles, les signatures en anneau sont une forme de mixage automatique. Des liens existent toujours, mais il y en a tellement, qu’il est peut-être trop difficile à analyser. Dans Monero actuellement, il y a 11 signataires possibles : le vrai plus 10 autres. C’est donc comme se cacher dans une foule de 11 personnes… mieux que de rester seul, mais pas super réconfortant si un limier renifle.

Montant caché

Amount Hiding, également connu sous le nom de Confidential Transactions, contribue également à améliorer la confidentialité, mais n’affecte pas la [un]linkability.

Amount Hiding est compatible avec les circuits zk et les signatures en anneau, mais pas avec une approche de signature aveugle, qui nécessite généralement l’utilisation de dénominations fixes.

Nous avons discuté de Amount Hiding via les engagements de Pedersen dans une mise à jour précédente.

Dénominations fixes

Les dénominations fixes sont une autre forme de protection de la vie privée, similaire dans son objectif au quantité cachée. Seul un certain nombre de montants limités sont autorisés par le système. Pour représenter tout autre montant, il faut faire le changement en utilisant les montants connus.

Forcer toutes les transactions à utiliser ces montants fixes signifie que toutes les entrées et sorties d’une transaction apparaissent régulières. Bien que le montant total d’une transaction donnée soit visible, on ne peut pas suivre efficacement une entrée ou une sortie donnée par son montant car elle se fond dans un océan d’autres jetons d’une valeur du même montant. Ainsi, toutes les unités d’une dénomination donnée sont fongibles entre elles.

Il est donc important de limiter le nombre total de coupures. On pourrait par exemple définir chaque valeur entière à sa propre dénomination. Bien que cela fonctionne techniquement, c’est mauvais pour la vie privée, car les gens utiliseront souvent des montants très uniques. Au lieu de se fondre dans un océan, une seule goutte erre d’elle-même.

Liens utiles

N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.

En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!