Après avoir passé un peu de temps à étudier la conception de Phoenix, un détail a vraiment retenu mon attention :
la confidentialité ne signifie pas nécessairement qu’il faut effectuer soi-même tous les calculs.
Le livre blanc de Dusk décrit un modèle de délégation dans lequel une partie des tâches les plus lourdes peut être confiée à un tiers de confiance sans lui donner tout ce dont il aurait besoin pour dépenser vos notes.
Pour l’analyse du réseau, Phoenix utilise des clés de visualisation. Un utilisateur peut déléguer la tâche consistant à rechercher sur le réseau les transactions qui lui sont destinées, tandis que la partie à qui cette tâche est déléguée ne peut toujours pas dépenser ces notes, car elle ne possède pas les clés secrètes complètes de l’utilisateur.
La deuxième partie est encore plus intéressante.
Phoenix permet également de déléguer, au moyen de signatures, la génération de preuves ZK pour les transactions, tout en préservant l’intégrité de la transaction.
La conception distingue donc deux choses qu’il est facile de confondre :
en savoir suffisamment pour accomplir une tâche ≠ disposer d’une autorité suffisante pour dépenser les fonds.
Cette distinction est importante dans un système axé sur la confidentialité.
Au lieu de faire dépendre la confidentialité du contrôle total exercé par une seule partie, le modèle répartit les responsabilités en fonction de ce qu’il est réellement nécessaire de savoir ou d’accomplir.
C’est probablement l’aspect de Phoenix que je trouve le plus intéressant : déléguer les calculs sans pour autant déléguer la propriété.
@Dusk $DUSK
#dusk
#dusk $DUSK @Dusk
la confidentialité ne signifie pas nécessairement qu’il faut effectuer soi-même tous les calculs.
Le livre blanc de Dusk décrit un modèle de délégation dans lequel une partie des tâches les plus lourdes peut être confiée à un tiers de confiance sans lui donner tout ce dont il aurait besoin pour dépenser vos notes.
Pour l’analyse du réseau, Phoenix utilise des clés de visualisation. Un utilisateur peut déléguer la tâche consistant à rechercher sur le réseau les transactions qui lui sont destinées, tandis que la partie à qui cette tâche est déléguée ne peut toujours pas dépenser ces notes, car elle ne possède pas les clés secrètes complètes de l’utilisateur.
La deuxième partie est encore plus intéressante.
Phoenix permet également de déléguer, au moyen de signatures, la génération de preuves ZK pour les transactions, tout en préservant l’intégrité de la transaction.
La conception distingue donc deux choses qu’il est facile de confondre :
en savoir suffisamment pour accomplir une tâche ≠ disposer d’une autorité suffisante pour dépenser les fonds.
Cette distinction est importante dans un système axé sur la confidentialité.
Au lieu de faire dépendre la confidentialité du contrôle total exercé par une seule partie, le modèle répartit les responsabilités en fonction de ce qu’il est réellement nécessaire de savoir ou d’accomplir.
C’est probablement l’aspect de Phoenix que je trouve le plus intéressant : déléguer les calculs sans pour autant déléguer la propriété.
@Dusk $DUSK
#dusk
#dusk $DUSK @Dusk