Peter Todd met en garde contre la technologie de Zcash, jugée trop risquée pour améliorer la confidentialité de Bitcoin

bitcoinistPublié le 2026-06-05Dernière mise à jour le 2026-06-05

Résumé

Le développeur Bitcoin Peter Todd s'oppose à l'intégration de la confidentialité de style Zcash dans la couche de consensus de Bitcoin, estimant que le profil de risque cryptographique est trop élevé pour le protocole de base. Le débat a surgi après qu'un problème affectant le pool blindé Orchard de Zcash ait été révélé. Todd souligne que les bugs dans Bitcoin, comme l'incident de dépassement de valeur de 2010, étaient visibles et permettaient des retours en arrière faciles, car les comptes étaient transparents. En revanche, dans un système entièrement protégé comme Zcash, une faille pourrait compromettre les soldes des utilisateurs de manière invisible et irréversible, menaçant une part importante des fonds (30% de l'offre est actuellement blindée). Todd reconnaît que Bitcoin n'est pas exempt de problèmes techniques, mais il affirme que les risques diffèrent fondamentalement selon le type de cryptographie utilisé, celle de Zcash présentant un niveau de danger plus élevé pour l'intégrité du réseau.

Le développeur Bitcoin Peter Todd s'est opposé aux appels à intégrer une confidentialité de type Zcash dans la couche de consensus de Bitcoin, arguant que le profil de risque cryptographique est trop élevé pour le protocole de base du réseau. Le débat a éclaté après que les développeurs de ZODL ont révélé un problème affectant le pool protégé Orchard, transformant brièvement un incident technique en un argument plus large sur la confidentialité, l'auditabilité et l'ossification de Bitcoin.

Le message initial de Todd était direct : "Pourquoi ajouter une confidentialité de style Zcash à Bitcoin au niveau de la couche de consensus est une mauvaise idée." Il répondait à un message du Zcash Open Development Lab, qui annonçait qu'une "mise à niveau coordonnée du réseau Zcash" était en cours après qu'un problème affectant le pool Orchard de Zcash a été identifié lors des processus d'audit de routine et d'examen de sécurité.

Pourquoi Peter Todd tire la sonnette d'alarme sur la confidentialité de style Zcash

L'échange s'est rapidement élargi au-delà du ZEC lui-même. Un utilisateur a fait valoir que Bitcoin a sa propre histoire de bugs critiques, citant l'incident de débordement de valeur de 2010 et la scission de chaîne de 2013 comme preuves qu'"aucun protocole n'est à l'abri de problèmes techniques". Le même message accusait les maximalistes de Bitcoin de pousser à une "ossification totale" tout en faisant face à des menaces futures comme l'informatique quantique.

Todd a répondu en établissant une distinction entre les échecs visibles et cachés. "Exactement mon point. Avec Bitcoin, revenir en arrière sur la chaîne est faisable, car seule une petite sous-partie des pièces était affectée, et l'exploitation était triviale à remarquer," a-t-il écrit. Son argument n'était pas que Bitcoin est exempt de bugs, mais que son modèle comptable rend certaines classes de bugs catastrophiques plus faciles à détecter et à annuler.

Ce point est devenu le cœur du désaccord. Lorsqu'un autre utilisateur a soutenu que rejeter la confidentialité au niveau du consensus pour des raisons de risque de bug "arrêterait toute innovation/développement", Todd a répondu que toutes les cryptographies ne comportent pas le même risque opérationnel. "Différents types de cryptographie ont différents niveaux de risque. La cryptographie de style Zcash a un niveau de risque très élevé, beaucoup plus que celle de Bitcoin. Ce qui se reflète dans le fait que Zcash a eu des problèmes bien plus graves que Bitcoin."

Le contre-argument était que Bitcoin lui-même a subi de graves échecs précoces. Un participant a cité l'incident de débordement de valeur de 2010 et le bug de 2018, CVE-2018-17144, comme des exemples remettant en cause le cadre de Todd. Todd a rejeté la comparaison, affirmant qu'aucun de ces cas ne faisait courir au monnaie le même type de risque existentiel.

"Aucune de ces exploitations n'avait la moindre chance de détruire la monnaie," a écrit Todd. "Il était trivialement visible de savoir quelles pièces étaient contrefaites, permettant des retours en arrière faciles. Pas avec Zcash."

Le désaccord repose sur une propriété spécifique des systèmes protégés : la confidentialité peut réduire la visibilité qui rend les audits de l'offre simples. Selon Todd, cela modifie le calcul des risques pour Bitcoin. Un bug dans une comptabilité transparente peut être remarqué car les sorties invalides ou les pièces contrefaites sont visibles sur la chaîne. Dans un système profondément protégé, a-t-il soutenu, les dégâts peuvent être plus difficiles à observer, à attribuer et à inverser.

Les défenseurs de Zcash ont également contesté ce cadre. Un utilisateur a dit à Todd qu'il ne comprenait pas le "construct turnstile", affirmant qu'"aucun bug de ce type ne peut affecter l'offre totale de ZEC". Todd a déplacé l'attention de l'offre totale vers les soldes des utilisateurs protégés, notant qu'une grande part du ZEC se trouve déjà dans le pool protégé. "30 % de l'offre de Zcash est protégée. La destruction de cette offre serait un désastre et anéantirait complètement les avoirs d'un pourcentage élevé de tous les utilisateurs de Zcash. Personnellement, j'ai un peu de Zcash, et tout est protégé."

Au moment de la rédaction, le ZEC s'échangeait à 532 $.

Le ZEC s'échange à nouveau sous le niveau Fib 1.618, graphique 1 semaine | Source : ZECUSDT sur TradingView.com

Cryptos en tendance

Questions liées

QQuel est l'argument principal de Peter Todd contre l'intégration d'une confidentialité de type Zcash dans la couche de consensus du Bitcoin ?

APeter Todd soutient que le profil de risque cryptographique de la technologie Zcash est trop élevé pour être intégré au protocole de base du réseau Bitcoin. Il souligne qu'en raison de sa nature confidentielle, un bug dans un système blindé comme Zcash serait plus difficile à détecter, à attribuer et à inverser qu'un bug dans le système comptable transparent du Bitcoin.

QSelon l'article, quel incident technique a déclenché le débat sur la confidentialité et l'ossification du Bitcoin ?

ALe débat a été déclenché après que les développeurs de ZODL ont divulgué un problème affectant le pool blindé Orchard de Zcash, transformant brièvement cet incident technique en une discussion plus large sur la confidentialité, l'auditabilité et l'ossification du Bitcoin.

QComment Peter Todd distingue-t-il les échecs visibles des échecs cachés dans son argumentation ?

APeter Todd distingue les échecs visibles (comme ceux du Bitcoin) des échecs cachés. Il affirme que dans Bitcoin, les bugs comme l'incident de dépassement de valeur de 2010 étaient faciles à remarquer car les pièces contrefaites étaient visibles sur la chaîne, permettant un retour en arrière (rollback) réalisable. Dans un système blindé comme Zcash, les dommages pourraient être plus difficiles à observer et à inverser.

QQuel contre-argument les défenseurs de Zcash ont-ils avancé concernant la visibilité des bugs et l'offre totale de ZEC ?

ALes défenseurs de Zcash ont rétorqué qu'un bug ne pouvait pas affecter l'offre totale de ZEC grâce à leur 'construction tourniquet' (turnstile construct). Ils soutiennent que ce mécanisme garantit que la quantité totale de ZEC reste vérifiable et inchangée, même dans le pool blindé.

QSelon Peter Todd, pourquoi un bug affectant le pool blindé de Zcash représenterait-il un risque majeur, malgré la stabilité de l'offre totale ?

APeter Todd explique qu'un bug catastrophique dans le pool blindé, même sans altérer l'offre totale, pourrait détruire une grande partie des ZEC détenus par les utilisateurs. Il note que 30% de l'offre de Zcash est blindée, et la destruction de cette réserve serait un désastre qui anéantirait les avoirs d'un pourcentage élevé d'utilisateurs, créant un risque existentiel différent.

Lectures associées

15 modèles de raisonnement échouent collectivement : explication des risques cachés derrière les chaînes de pensée révélées

Lorsque les modèles de raisonnement à grande échelle (LRM) exposent leurs processus de raisonnement intermédiaires aux utilisateurs et aux systèmes en aval, une question négligée émerge : se fier uniquement à la sécurité de la réponse finale est-il suffisant ? Une étude conjointe de plusieurs universités, dont Harvard, USC et le MIT, démontre le contraire. Elle révèle que les chaînes de raisonnement (CoT) peuvent générer des contenus à haut risque (ex : instructions pour fabriquer une bombe), même lorsque la réponse finale semble sûre. L'étude propose une évaluation en deux étapes : analyser séparément la trajectoire de raisonnement (r) et la réponse finale (y) selon 20 principes de sécurité, chacun noté de 1 à 5. Trois modes d'échec sont identifiés : **Unsafe** (raisonnement et réponse non sûrs), **Leak** (raisonnement dangereux mais réponse sûre), et **Escape** (raisonnement sûr mais réponse dangereuse). Testé sur 15 modèles de raisonnement (dont GPT-4o, Gemini, Claude) avec un ensemble de 41K prompts potentiellement nuisibles, un constat majeur apparaît : **la dangerosité moyenne du raisonnement dépasse systématiquement celle de la réponse finale** pour tous les modèles. Les risques se concentrent sur des catégories comme la désinformation, les préjugés et les dommages physiques. Pour atténuer ces risques, les chercheurs proposent une méthode d'**orientation adaptative multi-principes**. Elle ajuste les activations internes du modèle pendant le raisonnement pour le guider vers des états « sûrs » définis par les principes. Testée sur des modèles open-source (comme DeepSeek-R1), cette méthode réduit le taux de contenus non sûrs jusqu'à 40.8% tout en conservant 97.7% des performances sur des benchmarks standard. En conclusion, cette recherche souligne l'importance cruciale d'évaluer et de contrôler la sécurité tout au long du processus de raisonnement, et pas seulement au résultat final, en fournissant un cadre unifié pour le diagnostic et l'atténuation de ces risques cachés.

marsbitIl y a 50 mins

15 modèles de raisonnement échouent collectivement : explication des risques cachés derrière les chaînes de pensée révélées

marsbitIl y a 50 mins

Trading

Spot

Articles tendance

Comment acheter PUSH

Bienvenue sur HTX.com ! Nous vous permettons d'acheter Push Protocol (PUSH) de manière simple et pratique. Suivez notre guide étape par étape pour commencer votre parcours crypto.Étape 1 : Création de votre compte HTXUtilisez votre adresse e-mail ou votre numéro de téléphone pour ouvrir un compte sur HTX gratuitement. L'inscription se fait en toute simplicité et débloque toutes les fonctionnalités.Créer mon compteÉtape 2 : Choix du mode de paiement (rubrique Acheter des cryptosCarte de crédit/débit : utilisez votre carte Visa ou Mastercard pour acheter instantanément Push Protocol (PUSH).Solde :utilisez les fonds du solde de votre compte HTX pour trader en toute simplicité.Prestataire tiers :pour accroître la commodité d'utilisation, nous avons ajouté des modes de paiement populaires tels que Google Pay et Apple Pay.P2P :tradez directement avec d'autres utilisateurs sur HTX.OTC (de gré à gré) : nous offrons des services personnalisés et des taux de change compétitifs aux traders.Étape 3 : stockage de vos Push Protocol (PUSH)Après avoir acheté vos Push Protocol (PUSH), stockez-les sur votre compte HTX. Vous pouvez également les envoyer ailleurs via un transfert sur la blockchain ou les utiliser pour trader d'autres cryptos.Étape 4 : tradez des Push Protocol (PUSH)Tradez facilement Push Protocol (PUSH) sur le marché Spot de HTX. Il vous suffit d'accéder à votre compte, de sélectionner la paire de trading, d'exécuter vos trades et de les suivre en temps réel. Nous offrons une expérience conviviale aux débutants comme aux traders chevronnés.

385 vues totalesPublié le 2024.12.13Mis à jour le 2026.06.02

Comment acheter PUSH

Discussions

Bienvenue dans la Communauté HTX. Ici, vous pouvez vous tenir informé(e) des derniers développements de la plateforme et accéder à des analyses de marché professionnelles. Les opinions des utilisateurs sur le prix de PUSH (PUSH) sont présentées ci-dessous.

活动图片