シールドされた CSV: ビットコインのプライバシーとスケーラビリティの新時代

現在のビットコイン開発は、(1) スケーリングと (2) プライバシーという 2 つの主要な問題に焦点を当てています。ビットコインへの通常の提案には、新しいオペコードとスクリプト ツールの追加が含まれます。

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.

現在のビットコイン開発は、(1) スケーリングと (2) プライバシーという 2 つの主要な問題に焦点を当てています。ビットコインへの通常の提案には、新しいオペコードとスクリプト ツールの追加が含まれます。しかし、トランザクションをよりプライベートでピアツーピアにするという古いアイデアが戻ってきています。

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.

現在、すべてのビットコイントランザクションは検証のためにネットワーク全体にブロードキャストされています。これは二重支出を防ぐ効果的な方法ですが、必要以上に多くの情報が公開されることも意味します。これにより、計算量が増加し、コストが増加し、システムの拡張が難しくなります。

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?

しかし、トランザクション プロセスの一部をクライアント側に移動することで、効率が向上するだけでなく、ビットコインのプライバシーのまったく新しい時代が開かれるとしたらどうなるでしょうか?

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.

Alpen Labs および ZeroSync と共同で最近発表した論文 Blockstream では、真にプライベートなトランザクションを提供するクライアント側検証 (CSV) の改良版である Shielded CSV プロトコルを紹介しています。この新しいプロトコルは、ビットコイン取引のプライバシー強化に向けた重要な一歩であり、このブログ投稿で説明するいくつかの追加措置を通じて、トランザクション容量を 1 秒あたり 11 件から 100 件以上に増加させる可能性があります。

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.

この投稿では、ビットコインとの完全な互換性を維持しながら、レイヤー 1 ブロックチェーンのパフォーマンスを向上させることを目的とした Shielded CSV プロトコルの概要を説明します。ジョナス・ニック、リアム・イーゲン、ロビン・ライナスの結集により開発されました。ここでは、Shielded CSV の背景と、それがすべてを変える可能性がある理由を説明します。

Bitcoin Then and Now

ビットコインの昔と今

The Double-Spend Problem: How Bitcoin Solved It

二重支払い問題: ビットコインはどのように解決したか

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.

ビットコイン以前は、信頼できる仲介者なしでは信頼できるデジタル通貨を作成することは不可能であると広く信じられていました。二重支払いの問題は、「デジタル コイン」を複数回使用できないようにする方法がないことを意味しました。それはデジタル通貨の実現を妨げる根本的な欠陥でした。

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.

そして 2009 年に、サトシはブロックチェーンと呼ばれる共有公開台帳を導入することでこの問題に対処しました。ビットコインは、単一の信頼できる機関に依存するのではなく、共有公開台帳上のノードのネットワークを使用し、そこですべてのトランザクションが記録され検証されます。このシステムにより、各コインが一意であることが保証され、同じコインを二度使うことが不可能になります。

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

ビットコイン トランザクションがチェーンに追加されると、次のプロセスに従います。

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.

検証中に、ノードはコインが存在することを確認し、署名の有効性をチェックし、各コインが 1 回だけ使用されるようにする重要な二重支払いルールを適用します。

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

この台帳の目的は、秩序を維持し、誰がどのコインを所有し、いつ移動したかを明確に示すことです。

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

台帳の目的は、取引を整理整頓し、誰がどのコインを所有し、いつ送信されたかを明確にすることです。

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?

ビットコインの開発者たちは、その誕生以来、同じ疑問に立ち返り続けてきました。これは本当にトランザクションを処理する最良かつ最もプライベートな方法なのでしょうか?このシステムをより効率的で、よりプライベートなものにするにはどうすればよいでしょうか?

A Privacy Problem: Public Transactions

プライバシーの問題: 公開取引

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.

ビットコインのプライバシーに関する最大の課題は、ビットコイン取引がブロックチェーン上で公開されていることです。サトシは最初からこの脆弱性に気づいていました。オリジナルのホワイトペーパーで、彼は単純な解決策を提案しました。ユーザーはトランザクションごとに新しいキーを作成し、アドレスの再利用を避ける必要があります。

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.

その目的は、トランザクションを単一の所有者に結び付けることを困難にすることでした。しかし実際には、現在利用可能な高度なチェーン分析手法がすべてあるため、プライバシーを維持することは、思っているよりもはるかに困難です。新しいアドレスを使用しても、ユーザーのアクティビティを追跡したい人にとって、トランザクションのリンクとパターンの特定が容易になりました。

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.

これに応じて、Zcash のようなプライバシーを重視したプロトコルは、より高度な暗号化や zk-SNARK などを使用してトランザクションの詳細を隠す新しい方法を導入しました。ただし、これらの方法には重大なトレードオフが伴います。トランザクションが大きくなり、ノードの検証プロセスがより多くのリソースを消費し、検証コストが高くなります。

A Communication Problem: Communication is Inefficient

コミュニケーションの問題: コミュニケーションが非効率的である

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.

ビットコインの設計では、マイニングは 2 つの基本的な目的を果たします。(1) トランザクションの公開証明、および (2) トランザクションの順序に関する合意の提供です。ただし、ビットコインのシステムは、これらのコア機能と、トランザクションの検証やコインの発行など、それほど重要ではないタスクも絡み合わせています。

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?

ビットコイン、イーサリアム、Zcash、ドージコインなど、すべてのブロックチェーンでトランザクション プロセスは常に同じです。ウォレットがトランザクションに署名し、ネットワークにブロードキャストし、フル ノードがトランザクションを検証します。しかし、ブロックチェーン上ですべてのトランザクションを直接検証することは本当に必要なのでしょうか?

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!’

もっと良い方法があると思います。このアイデアは、Peter Todd が初めてクライアント側検証について言及した 2013 年の洞察に遡ります。このメーリングリストへの投稿で彼は、「出版証明と取引順序に関する合意だけがあれば、暗号コインシステムを成功させることができるだろうか？」と尋ねている。驚いたことに、答えはイエスです！」

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

すべての完全なノードにすべてのトランザクションを検証させる代わりに、CSV を使用すると、有効性の証明を含むコインを受信者に直接送信できます。