#dusk $DUSK
Je suis passé par la structure de clé de Phoenix cette semaine parce que je voulais comprendre ce qu’une clé de vue donne réellement à quelqu’un — et en quoi elle diffère du simple fait de lui confier un accès.
Clés de vue Phoenix : le livre blanc définit la clé de vue comme (a, B) — un secret partiel qui permet à un tiers de scanner le réseau pour identifier quelles transactions vous sont adressées. Il peut voir ce qui arrive. Il ne peut pas calculer la clé secrète de note, donc il ne peut rien dépenser. Scanner sans dépenser.
La génération des preuves ZK est déléguable séparément. Une transaction nécessite une preuve à connaissance nulle. La génération de cette preuve est coûteuse sur le plan computationnel et peut être externalisée à une partie de confiance via des signatures, sans lui donner accès à votre clé privée complète. L’intégrité de la transaction n’est pas compromise, car la signature la relie à votre clé même si la preuve a été générée ailleurs.
Cette partie est solide. Deux niveaux de délégation, clairement séparés : l’un pour un accès de type audit, l’autre pour le déchargement de calcul.
Ce qui est plus difficile à évaluer, c’est le coût en confidentialité de chacun. Le délégué de clé de vue sait quelles transactions sont les vôtres. « Ne peut pas dépenser » ne signifie pas « ne sait rien » — cela signifie qu’il peut reconstituer un tableau complet de votre historique de réception. Pour un cas d’usage conformité, c’est peut-être exactement ce dont on a besoin. Pour un utilisateur individuel, confier une clé de vue à un service constitue une divulgation significative, même s’il n’y a pas de mouvements de fonds.
Je pense en fait que la délégation de preuve est plus propre du point de vue de la confidentialité — le générateur de preuve n’apprend rien sur le contenu de la transaction si le protocole est correctement structuré. La clé de vue est celle qui porte la vraie information.
Ce que je n’ai pas encore déterminé, c’est si, dans les cas d’usage d’audit pour Phoenix, la clé de vue est utilisée directement, ou s’il existe des mécanismes de divulgation sélective permettant de ne révéler que certaines transactions, plutôt que l’historique complet des réceptions. @Dusk
$DUSK #dusk
Je suis passé par la structure de clé de Phoenix cette semaine parce que je voulais comprendre ce qu’une clé de vue donne réellement à quelqu’un — et en quoi elle diffère du simple fait de lui confier un accès.
Clés de vue Phoenix : le livre blanc définit la clé de vue comme (a, B) — un secret partiel qui permet à un tiers de scanner le réseau pour identifier quelles transactions vous sont adressées. Il peut voir ce qui arrive. Il ne peut pas calculer la clé secrète de note, donc il ne peut rien dépenser. Scanner sans dépenser.
La génération des preuves ZK est déléguable séparément. Une transaction nécessite une preuve à connaissance nulle. La génération de cette preuve est coûteuse sur le plan computationnel et peut être externalisée à une partie de confiance via des signatures, sans lui donner accès à votre clé privée complète. L’intégrité de la transaction n’est pas compromise, car la signature la relie à votre clé même si la preuve a été générée ailleurs.
Cette partie est solide. Deux niveaux de délégation, clairement séparés : l’un pour un accès de type audit, l’autre pour le déchargement de calcul.
Ce qui est plus difficile à évaluer, c’est le coût en confidentialité de chacun. Le délégué de clé de vue sait quelles transactions sont les vôtres. « Ne peut pas dépenser » ne signifie pas « ne sait rien » — cela signifie qu’il peut reconstituer un tableau complet de votre historique de réception. Pour un cas d’usage conformité, c’est peut-être exactement ce dont on a besoin. Pour un utilisateur individuel, confier une clé de vue à un service constitue une divulgation significative, même s’il n’y a pas de mouvements de fonds.
Je pense en fait que la délégation de preuve est plus propre du point de vue de la confidentialité — le générateur de preuve n’apprend rien sur le contenu de la transaction si le protocole est correctement structuré. La clé de vue est celle qui porte la vraie information.
Ce que je n’ai pas encore déterminé, c’est si, dans les cas d’usage d’audit pour Phoenix, la clé de vue est utilisée directement, ou s’il existe des mécanismes de divulgation sélective permettant de ne révéler que certaines transactions, plutôt que l’historique complet des réceptions. @Dusk
$DUSK #dusk