Les bibliothèques Common de Zakura réduisent la génération de preuves des paiements privés Zcash sous les 200 millisecondes
Points clés
- •Les bibliothèques open source Common de Zakura réduisent la génération de preuves protégées de plus de trois secondes à moins de 200 millisecondes lors de certains tests internes de l'entreprise.
- •La génération de preuves sur mobile était plus de 14 fois plus rapide et la génération sur ordinateur plus de cinq fois plus rapide sur le matériel de référence de Zakura.
- •Le résultat sous les 200 millisecondes s'applique uniquement à la construction locale de la transaction ; la diffusion, la confirmation de bloc et le règlement dépendent toujours des conditions du réseau.
- •Common a également accéléré le hachage Sinsemilla de plus de 21 fois, le déchiffrement d'essai de plus de 1,5 fois et la vérification zk-SNARK de quatre à huit fois dans les tests de Zakura.
- •Les bibliothèques fonctionnent sans hard fork, donc l'adoption dépend de l'intégration et des tests du code par chaque développeur de portefeuille.

Points clés
La génération de preuves sur mobile a été plus de 14× plus rapide.
Certains tests de transaction se sont terminés en moins de 200 millisecondes.
La confirmation sur le réseau reste un processus distinct.
Les intégrations dans les portefeuilles déterminent qui bénéficiera des améliorations.
Le délai se produit avant que Zcash ne voie le paiement
Avant qu'un paiement Zcash privé n'atteigne le réseau, le portefeuille de l'expéditeur doit sélectionner les notes dépensables, préparer la transaction, générer une preuve à divulgation nulle et signer le résultat. La génération de preuve représente une grande partie de l'attente locale, car elle doit démontrer que le paiement est valide sans révéler l'expéditeur, le destinataire ni le montant transféré. Cette étape de calcul local a historiquement constitué l'un des compromis pratiques des paiements protégés par rapport aux paiements transparents, où le portefeuille effectue bien moins de travail cryptographique avant la diffusion.
Zakura indique que ses bibliothèques Common open source ont réduit ce processus de plus de trois secondes à moins de 200 millisecondes lors de certains tests. Sur le matériel de référence de l'équipe, la génération de preuves sur mobile était plus de 14 fois plus rapide, tandis que la génération sur ordinateur s'est améliorée de plus de cinq fois.
Ces résultats proviennent des tests internes de Zakura et non de références indépendantes de portefeuilles. Les performances réelles dépendront de l'appareil, du système d'exploitation, de la composition de la transaction et de l'implémentation du portefeuille ; un téléphone plus ancien pourrait donc ne pas reproduire les chiffres annoncés.
Où s'arrêtent les 200 millisecondes
Un paiement Zcash passe toujours par trois étapes distinctes :
Construction : Le portefeuille construit la transaction et génère sa preuve de confidentialité sur l'appareil de l'utilisateur. Zakura Common accélère cette étape.
Diffusion et confirmation : Le portefeuille soumet la transaction complète aux nœuds Zcash. Elle reste non confirmée jusqu'à ce qu'un mineur l'inclue dans un bloc.
Confiance de règlement : Chaque bloc ultérieur ajoute une confirmation supplémentaire et réduit la possibilité d'une annulation causée par une réorganisation de la chaîne.
La documentation Zcash définit la première confirmation comme le moment où une transaction entre dans un bloc. Le résultat sous les 200 millisecondes s'arrête avant la diffusion ; la production de blocs, les conditions du mempool et la politique de confirmation du destinataire déterminent toujours quand le paiement est considéré comme réglé.
Les gains vont au-delà du bouton d'envoi
Zakura a également mesuré des améliorations dans trois opérations qui affectent le traitement des transactions, la synchronisation des portefeuilles et les performances des nœuds :
Hachage Sinsemilla : plus de 21 fois plus rapide dans les tests de Zakura. Zcash utilise cette fonction de hachage dans son protocole protégé, donc une exécution plus rapide réduit une partie de la charge cryptographique.
Déchiffrement d'essai : plus de 1,5 fois plus rapide. Les portefeuilles utilisent ce processus pour analyser la blockchain et identifier les sorties protégées qui leur appartiennent.
Vérification zk-SNARK : entre quatre et huit fois plus rapide. Les nœuds utilisent la vérification pour contrôler une preuve protégée sans apprendre les informations qu'elle protège.
Un déchiffrement d'essai plus rapide pourrait raccourcir la synchronisation des portefeuilles et la récupération de compte, tandis qu'une vérification moins coûteuse réduit le travail demandé aux nœuds. Zakura s'attend également à ce que les améliorations des nœuds complets favorisent une propagation plus rapide des transactions et moins de blocs orphelins.
Le calendrier importe, car davantage de ZEC migrent vers une infrastructure protégée plus récente. Comme rapporté précédemment, Ironwood était devenu le plus grand pool protégé de Zcash, dépassant Orchard peu après son activation. À mesure que l'activité protégée augmente, une construction de transaction et une synchronisation lentes deviennent des problèmes que davantage d'utilisateurs peuvent rencontrer.
Pas de hard fork signifie aussi pas de déploiement automatique
Zakura Common modifie la manière dont le logiciel effectue le travail cryptographique existant sans changer les règles de consensus de Zcash. Les bibliothèques produisent des preuves que le réseau actuel comprend déjà, permettant aux développeurs de portefeuilles de les utiliser sans attendre que les mineurs et les nœuds activent un hard fork. Cette voie de mise à niveau purement logicielle est caractéristique des travaux récents du protocole Zcash, où les optimisations au niveau des portefeuilles et des bibliothèques peuvent atteindre les utilisateurs par des mises à jour d'application ordinaires plutôt que par des mises à niveau coordonnées du réseau.
Le dépôt Common est disponible sous les licences MIT et Apache 2.0. Un dépôt wallet-libraries distinct relie les composants destinés aux portefeuilles à la pile optimisée.
Cette compatibilité supprime une barrière de déploiement à l'échelle du réseau, mais chaque développeur de portefeuille doit encore examiner, intégrer et tester le code avant de le publier pour ses utilisateurs. Les portefeuilles qui conservent leur pile de preuve actuelle garderont leurs performances existantes.
Zakura indique que sa version 1.3.0 à venir utilisera Common. Ensuite, l'attention se tournera vers les portefeuilles mobiles indépendants. Leurs notes de version et leurs tests sur appareils réels montreront si l'amélioration dépasse le logiciel de Zakura lui-même.
L'adoption par les portefeuilles est désormais le goulot d'étranglement
Les benchmarks de Zakura montrent que la génération de preuves protégées peut s'exécuter bien plus vite sans modifier le réseau Zcash. Le résultat pratique dépend désormais de la publication des bibliothèques par les portefeuilles établis et de la capacité des tests indépendants à reproduire ces gains sur des téléphones courants.
Les temps de synchronisation et de récupération comptent également. Si ces attentes diminuent sans hausse des taux d'erreur, Common aura amélioré plus que l'instant où l'utilisateur appuie sur « envoyer ».
Zakura a montré que le délai côté portefeuille peut être réduit sans changer Zcash lui-même. La question restante est de savoir combien de développeurs de portefeuilles mettront cette vitesse entre les mains des utilisateurs.
L'article Zcash Wallet Upgrade Makes Private Payments Faster est paru en premier sur Coindoo.