CSV protégé : une nouvelle ère de confidentialité et d'évolutivité pour Bitcoin

Le développement du Bitcoin se concentre aujourd’hui sur deux problèmes majeurs : (1) la mise à l’échelle et (2) la confidentialité. Les propositions habituelles concernant Bitcoin impliquent l’ajout de nouveaux opcodes et outils de script.

Bitcoin development today focuses on two major issues: (1) scaling and (2) privacy. The usual proposals to Bitcoin involve adding new opcodes and scripting tools. But an old idea is coming back, one that could make transactions more private and peer-to-peer.

Le développement du Bitcoin se concentre aujourd’hui sur deux problèmes majeurs : (1) la mise à l’échelle et (2) la confidentialité. Les propositions habituelles concernant Bitcoin impliquent l’ajout de nouveaux opcodes et outils de script. Mais une vieille idée revient, celle qui pourrait rendre les transactions plus privées et peer-to-peer.

Right now, every Bitcoin transaction is broadcast to the entire network for verification. It’s an effective way to prevent double-spending, but it also means more information is exposed than is strictly necessary. This leads to heavier computational demands, higher costs, and a system that struggles to scale.

À l’heure actuelle, chaque transaction Bitcoin est diffusée sur l’ensemble du réseau pour vérification. C'est un moyen efficace d'éviter les doubles dépenses, mais cela signifie également que plus d'informations sont exposées que ce qui est strictement nécessaire. Cela entraîne des demandes de calcul plus lourdes, des coûts plus élevés et un système qui a du mal à évoluer.

But what if moving part of the transaction process client-side didn't just improve efficiency, but also unlocks a whole new era of privacy on Bitcoin?

Mais et si le déplacement d’une partie du processus de transaction côté client n’améliorait pas seulement l’efficacité, mais ouvrait également une toute nouvelle ère de confidentialité sur Bitcoin ?

In our recently published paper, Blockstream, in collaboration with Alpen Labs and ZeroSync, we introduce the Shielded CSV Protocol, an improvement on Client-Side Validation (CSV) that offers truly private transactions. This new protocol is a significant step towards enhancing the privacy of Bitcoin transactions and has the potential to increase transaction capacity from 11 per second to over 100 per second, through some additional measures we’ll cover in this blog post.

Dans notre article récemment publié, Blockstream, en collaboration avec Alpen Labs et ZeroSync, nous introduisons le protocole Shielded CSV, une amélioration de la validation côté client (CSV) qui offre des transactions véritablement privées. Ce nouveau protocole constitue une étape importante vers l'amélioration de la confidentialité des transactions Bitcoin et a le potentiel d'augmenter la capacité de transaction de 11 par seconde à plus de 100 par seconde, grâce à certaines mesures supplémentaires que nous aborderons dans cet article de blog.

This post offers a high-level overview of the Shielded CSV Protocol, which aims to advance layer one blockchain performance while remaining fully compatible with Bitcoin. Developed by the combined minds of Jonas Nick, Liam Eagen, and Robin Linus. Here’s the backstory on Shielded CSV, and why it has the potential to change everything.

Cet article offre un aperçu de haut niveau du protocole Shielded CSV, qui vise à améliorer les performances de la première couche de blockchain tout en restant entièrement compatible avec Bitcoin. Développé par les esprits combinés de Jonas Nick, Liam Eagen et Robin Linus. Voici l'histoire de Shielded CSV et pourquoi il a le potentiel de tout changer.

Bitcoin Then and Now

Bitcoin hier et aujourd'hui

The Double-Spend Problem: How Bitcoin Solved It

Le problème de la double dépense : comment Bitcoin l'a résolu

Before Bitcoin, it was widely believed that creating a reliable digital currency was impossible without a trusted middleman. The double-spend problem meant there was no way to ensure a “digital coin” couldn’t be spent more than once. It was a fundamental flaw that kept digital currency from becoming a reality.

Avant Bitcoin, il était largement admis que la création d’une monnaie numérique fiable était impossible sans un intermédiaire de confiance. Le problème de la double dépense signifiait qu'il n'y avait aucun moyen de garantir qu'une « pièce numérique » ne puisse pas être dépensée plus d'une fois. C’était un défaut fondamental qui empêchait la monnaie numérique de devenir une réalité.

Then, in 2009, Satoshi addressed this problem by introducing the shared public ledger called the blockchain. Instead of relying on a single trusted authority, Bitcoin uses a network of nodes on a shared public ledger, where every transaction is recorded and verified. This system ensures that each coin is unique, making it impossible to spend the same coin twice.

Puis, en 2009, Satoshi a résolu ce problème en introduisant le grand livre public partagé appelé blockchain. Au lieu de s’appuyer sur une seule autorité de confiance, Bitcoin utilise un réseau de nœuds sur un registre public partagé, où chaque transaction est enregistrée et vérifiée. Ce système garantit que chaque pièce est unique, ce qui rend impossible de dépenser deux fois la même pièce.

When a Bitcoin transaction is added to the chain, it follows this process:

Lorsqu’une transaction Bitcoin est ajoutée à la chaîne, elle suit ce processus :

During validation, nodes verify that the coins exist, check the validity of the signature, and enforce the critical double-spend rule—making sure each coin is spent only once.

Lors de la validation, les nœuds vérifient que les pièces existent, vérifient la validité de la signature et appliquent la règle critique de double dépense, en s'assurant que chaque pièce n'est dépensée qu'une seule fois.

The whole purpose of this ledger is to maintain order, showing clearly who owns which coins and when they moved.

Le but de ce registre est de maintenir l’ordre, en montrant clairement qui possède quelles pièces et quand elles ont été déplacées.

The purpose of the ledger is to keep transactions in order, making it clear who owns what coins and when they were sent.

Le but du grand livre est de maintenir les transactions en ordre, en indiquant clairement à qui appartient quelles pièces et quand elles ont été envoyées.

Since its inception, Bitcoin’s developers keep coming back to the same question: is this really the best and most private way to handle transactions? How can we make this system leaner, more efficient, and more private?

Depuis sa création, les développeurs de Bitcoin reviennent sans cesse à la même question : est-ce vraiment le moyen le meilleur et le plus privé de gérer les transactions ? Comment pouvons-nous rendre ce système plus simple, plus efficace et plus privé ?

A Privacy Problem: Public Transactions

Un problème de confidentialité : les transactions publiques

Bitcoin's biggest privacy challenge is that bitcoin transactions are out there in the open on the blockchain. Satoshi saw this vulnerability from the beginning. In the original whitepaper, he suggested a straightforward solution: users should create new keys for each transaction and avoid reusing addresses.

Le plus grand défi de Bitcoin en matière de confidentialité est que les transactions Bitcoin se déroulent librement sur la blockchain. Satoshi a vu cette vulnérabilité dès le début. Dans le livre blanc original, il suggérait une solution simple : les utilisateurs devaient créer de nouvelles clés pour chaque transaction et éviter de réutiliser les adresses.

The idea was to make it harder to link transactions back to a single owner. But in practice, with all the advanced chain analysis methods available today, maintaining privacy is much harder than it seems. Even with new addresses, linking transactions and identifying patterns has become easier for those intent on tracing user activity.

L’idée était de rendre plus difficile le lien entre les transactions et un seul propriétaire. Mais dans la pratique, avec toutes les méthodes avancées d’analyse de chaîne disponibles aujourd’hui, préserver la confidentialité est beaucoup plus difficile qu’il n’y paraît. Même avec de nouvelles adresses, relier les transactions et identifier les modèles est devenu plus facile pour ceux qui souhaitent suivre l'activité des utilisateurs.

In response, privacy-focused protocols like Zcash have introduced novel ways to conceal transaction details using more advanced cryptography and things like zk-SNARKs. But these methods come with significant trade-offs: transactions are larger, making the verification process for nodes more resource-intensive and expensive to verify.

En réponse, des protocoles axés sur la confidentialité comme Zcash ont introduit de nouveaux moyens de dissimuler les détails des transactions en utilisant une cryptographie plus avancée et des éléments tels que les zk-SNARK. Mais ces méthodes s'accompagnent de compromis importants : les transactions sont plus volumineuses, ce qui rend le processus de vérification des nœuds plus gourmand en ressources et plus coûteux à vérifier.

A Communication Problem: Communication is Inefficient

Un problème de communication : la communication est inefficace

In Bitcoin’s design, mining serves two fundamental purposes: (1) proof-of-publication for transactions and (2) providing a consensus on the order of transactions. However, Bitcoins’ system also intertwines these core functions with less essential tasks, like transaction validation and coin issuance.

Dans la conception de Bitcoin, le minage répond à deux objectifs fondamentaux : (1) une preuve de publication pour les transactions et (2) fournir un consensus sur l'ordre des transactions. Cependant, le système Bitcoin associe également ces fonctions essentielles à des tâches moins essentielles, telles que la validation des transactions et l'émission de pièces.

Across all blockchains, whether it’s Bitcoin, Ethereum, Zcash, or Dogecoin, the transaction process always looks the same: wallets sign transactions, broadcast them to the network, and full nodes validate them. But is validating every transaction directly on the blockchain really necessary?

Dans toutes les blockchains, qu'il s'agisse de Bitcoin, Ethereum, Zcash ou Dogecoin, le processus de transaction est toujours le même : les portefeuilles signent les transactions, les diffusent sur le réseau et les nœuds complets les valident. Mais est-il vraiment nécessaire de valider chaque transaction directement sur la blockchain ?

We think there’s a better way. The idea traces back to a 2013 insight, when Peter Todd first mentioned Client-Side Validation. In this mailing list post he asks, ‘Given only proof-of-publication, and a consensus on the order of transactions, can we make a successful crypto-coin system? Surprisingly, the answer is yes!’

Nous pensons qu'il existe une meilleure solution. L'idée remonte à une idée de 2013, lorsque Peter Todd a mentionné pour la première fois la validation côté client. Dans ce message sur la liste de diffusion, il demande : "Étant donné seulement une preuve de publication et un consensus sur l'ordre des transactions, pouvons-nous créer un système de crypto-monnaie réussi ? » Étonnamment, la réponse est oui ! »

Instead of requiring every full node to verify every transaction, CSV allows you to send coins with proof of their validity directly to the recipient

Au lieu d'exiger que chaque nœud complet vérifie chaque transaction, CSV vous permet d'envoyer des pièces avec une preuve de leur validité directement au destinataire.