J’ai relu la documentation hier soir sur les modèles de transactions @Dusk et j’ai passé quelques heures à essayer de cartographier précisément comment Moonlight et Phoenix s’articulent.
Au début, la distinction semblait nette. Moonlight est la partie transparente, basée sur les comptes : chaque compte conserve un état public qui enregistre son solde et son nonce. Phoenix est la partie protégée (basée sur des notes) : une note est structurée autour d’une clé publique de destinataire, d’une valeur v, et de scalaires aléatoires supplémentaires, avec des notes indexées dans un arbre de Merkle afin qu’un dépensier puisse prouver l’inclusion sans révéler la note elle-même. Dépenser nécessite une preuve à divulgation nulle (zéro-connaissance) et la publication d’un nullifier pour que le réseau puisse rejeter les doubles dépenses. La documentation indique aussi que les valeurs des notes sont bornées par 2^{64}-1.
Les chemins de conversion entre les deux modèles (dépôt dans des notes Phoenix, retrait vers des comptes Moonlight) sont décrits, mais je me suis constamment heurté à des blocages sur les hypothèses de sécurité exactes qui s’appliquent pendant ces transferts. Les circuits sont présentés comme garantissant la validité, mais je n’ai pas trouvé de formulation claire indiquant si une conversion incorrectement formée pourrait, à elle seule, affecter l’ensemble global des nullifiers ou les soldes transparents sur lesquels s’appuient les contrats intelligents.
Cela m’a amené à une question plus large concernant la décentralisation : si la majeure partie de la valeur finit par vivre dans des notes Phoenix, quelle puissance de gouvernance pratique reste aux mains de la couche de comptes transparente que les contrats et les oracles voient réellement ?
Le design actuel des circuits et la borne de valeur 2^{64}-1 sont-ils considérés comme définitifs, ou y a-t-il encore des paramètres ouverts concernant la génération des notes, la profondeur de l’arbre de Merkle, et l’unicité des nullifiers que la communauté continue d’itérer ?
J’apprécierais des indications de la part de personnes qui sont allées plus loin dans les preuves.
#dusk $DUSK
Au début, la distinction semblait nette. Moonlight est la partie transparente, basée sur les comptes : chaque compte conserve un état public qui enregistre son solde et son nonce. Phoenix est la partie protégée (basée sur des notes) : une note est structurée autour d’une clé publique de destinataire, d’une valeur v, et de scalaires aléatoires supplémentaires, avec des notes indexées dans un arbre de Merkle afin qu’un dépensier puisse prouver l’inclusion sans révéler la note elle-même. Dépenser nécessite une preuve à divulgation nulle (zéro-connaissance) et la publication d’un nullifier pour que le réseau puisse rejeter les doubles dépenses. La documentation indique aussi que les valeurs des notes sont bornées par 2^{64}-1.
Les chemins de conversion entre les deux modèles (dépôt dans des notes Phoenix, retrait vers des comptes Moonlight) sont décrits, mais je me suis constamment heurté à des blocages sur les hypothèses de sécurité exactes qui s’appliquent pendant ces transferts. Les circuits sont présentés comme garantissant la validité, mais je n’ai pas trouvé de formulation claire indiquant si une conversion incorrectement formée pourrait, à elle seule, affecter l’ensemble global des nullifiers ou les soldes transparents sur lesquels s’appuient les contrats intelligents.
Cela m’a amené à une question plus large concernant la décentralisation : si la majeure partie de la valeur finit par vivre dans des notes Phoenix, quelle puissance de gouvernance pratique reste aux mains de la couche de comptes transparente que les contrats et les oracles voient réellement ?
Le design actuel des circuits et la borne de valeur 2^{64}-1 sont-ils considérés comme définitifs, ou y a-t-il encore des paramètres ouverts concernant la génération des notes, la profondeur de l’arbre de Merkle, et l’unicité des nullifiers que la communauté continue d’itérer ?
J’apprécierais des indications de la part de personnes qui sont allées plus loin dans les preuves.
#dusk $DUSK