@Dusk J’ai longtemps pensé que le redimensionnement de la confidentialité de Dusk était principalement une question de capacité réseau. En regardant plus en détail l’architecture du Prover, je vois plutôt une autre contrainte : le coût de production de la preuve elle-même.

Dusk s’appuie sur une infrastructure Prover pour gérer la génération de preuves à connaissance nulle, très coûteuse en calcul, nécessaire aux transactions préservant la confidentialité. Sa documentation indique que la génération des preuves est mono-threadée, ce qui rend une forte performance mono-cœur importante pour compléter les preuves efficacement et réduire le temps de finalisation. 

Cela change ma façon de penser le passage à l’échelle de l’activité confidentielle.

Plus de transactions privées n’augmentent pas seulement la charge de la blockchain. Elles peuvent aussi accroître la demande de calcul de preuve en temps opportun. Si la génération des preuves devient le composant le plus lent, la seule capacité de consensus ne garantit pas une expérience utilisateur fluide.

Il existe ici un compromis opérationnel. Dusk recommande de séparer le Prover de la Provisioner dans certains déploiements, afin de permettre une allocation différente des ressources d’infrastructure entre la production des preuves et le consensus. 

Le risque, c’est que des exigences croissantes en matière de preuves avantagent les opérateurs disposant de meilleurs matériels et qu’elles augmentent progressivement la concentration de l’infrastructure.

Donc, je surveillerais la latence de génération des preuves, la capacité du prover et les performances des transactions confidentielles à mesure que l’usage de la confidentialité augmente.

Pour les réseaux ZK, le passage à l’échelle ne consiste pas seulement à traiter les transactions. Il s’agit aussi de produire les preuves dont ces transactions ont besoin.

#dusk $DUSK $STAR $GPS