@Dusk de consensus s’appelle Succinct Attestation, PoS avec un système de comité. Une fois qu’un bloc est approuvé, c’est une finalité finale déterministe ; en fonctionnement normal, il n’y a pas de réorganisation perceptible par les utilisateurs. Le livre blanc contient des spécifications complètes au chapitre 3.
En voyant « système de comité », ma réaction initiale est généralement : chaque bloc n’est décidé que par un petit ensemble, et donc ce n’est pas plus concentré que la solution de Nakamoto ?
Plus tard, j’ai compris : pour cette chaîne, ce n’est pas un compromis, c’est une hypothèse.
La première raison est liée au droit. L’UE a une directive spécifique sur la finalité des règlements : « réglé » est un statut juridique, pas une description probabiliste. Dans une livraison DvP une fois terminée, le compte ne peut pas être remboursé. Mettre une finalité probabiliste ici n’est pas une question d’expérience : c’est annuler un règlement déjà accompli juridiquement—ce n’est pas « ajouter un bloc », c’est un contentieux.
La deuxième raison est plus intéressante, et surtout directement liée à la confidentialité.
Sur une chaîne transparente, en cas de réorganisation, le relecture (replay) et la réconciliation sont possibles : l’état reste exposé, et on peut voir qui envoie quoi à qui. Ce n’est pas pareil pour l’état masqué. Phoenix repose sur le modèle note + nullifier. Après une réorganisation, il faut rééclaircir à nouveau quelles notes ont déjà été dépensées et quels nullifiers doivent être invalidés : la difficulté n’est absolument pas du même ordre de grandeur que celle d’un grand livre transparent.
Donc, une chaîne de confidentialité tolère moins la finalité probabiliste qu’une chaîne transparente—pas plus. Plus le niveau de chiffrement est élevé, plus vous dépendez de la garantie « ce bloc est le bloc final ».
Ainsi, le système de comité n’est pas une façon d’échanger la décentralisation contre la performance : c’est une condition nécessaire pour faire les deux choses en même temps—la confidentialité et le règlement. En choisissant Phoenix, il faut presque nécessairement choisir une finalité déterministe.
Le prix à payer est réel aussi. L’autre face de la finalité déterministe est que lorsque les conditions ne sont pas bonnes, la chaîne a tendance à s’arrêter plutôt qu’à se scinder (fork). L’arrêt est lui-même un autre risque, et la disponibilité du comité devient une variable clé de la vivacité de la chaîne. Cela, il faut le surveiller.
Ce qui précède est basé sur la documentation officielle et les supports publics du livre blanc ; des détails peuvent avoir été mis à jour. Veuillez vérifier par vous-même et cela ne constitue pas un conseil.
Donc, pour finir par une question : si la chaîne exécute un état chiffré, préféreriez-vous qu’elle s’arrête parfois plutôt que de revenir en arrière (rollback) parfois ?
#dusk $DUSK @Dusk
En voyant « système de comité », ma réaction initiale est généralement : chaque bloc n’est décidé que par un petit ensemble, et donc ce n’est pas plus concentré que la solution de Nakamoto ?
Plus tard, j’ai compris : pour cette chaîne, ce n’est pas un compromis, c’est une hypothèse.
La première raison est liée au droit. L’UE a une directive spécifique sur la finalité des règlements : « réglé » est un statut juridique, pas une description probabiliste. Dans une livraison DvP une fois terminée, le compte ne peut pas être remboursé. Mettre une finalité probabiliste ici n’est pas une question d’expérience : c’est annuler un règlement déjà accompli juridiquement—ce n’est pas « ajouter un bloc », c’est un contentieux.
La deuxième raison est plus intéressante, et surtout directement liée à la confidentialité.
Sur une chaîne transparente, en cas de réorganisation, le relecture (replay) et la réconciliation sont possibles : l’état reste exposé, et on peut voir qui envoie quoi à qui. Ce n’est pas pareil pour l’état masqué. Phoenix repose sur le modèle note + nullifier. Après une réorganisation, il faut rééclaircir à nouveau quelles notes ont déjà été dépensées et quels nullifiers doivent être invalidés : la difficulté n’est absolument pas du même ordre de grandeur que celle d’un grand livre transparent.
Donc, une chaîne de confidentialité tolère moins la finalité probabiliste qu’une chaîne transparente—pas plus. Plus le niveau de chiffrement est élevé, plus vous dépendez de la garantie « ce bloc est le bloc final ».
Ainsi, le système de comité n’est pas une façon d’échanger la décentralisation contre la performance : c’est une condition nécessaire pour faire les deux choses en même temps—la confidentialité et le règlement. En choisissant Phoenix, il faut presque nécessairement choisir une finalité déterministe.
Le prix à payer est réel aussi. L’autre face de la finalité déterministe est que lorsque les conditions ne sont pas bonnes, la chaîne a tendance à s’arrêter plutôt qu’à se scinder (fork). L’arrêt est lui-même un autre risque, et la disponibilité du comité devient une variable clé de la vivacité de la chaîne. Cela, il faut le surveiller.
Ce qui précède est basé sur la documentation officielle et les supports publics du livre blanc ; des détails peuvent avoir été mis à jour. Veuillez vérifier par vous-même et cela ne constitue pas un conseil.
Donc, pour finir par une question : si la chaîne exécute un état chiffré, préféreriez-vous qu’elle s’arrête parfois plutôt que de revenir en arrière (rollback) parfois ?
#dusk $DUSK @Dusk