ロールアップ: ビットコインのスケーリングの難所

ロールアップは最近、ビットコインのスケーリングにおける物語の焦点となっており、ライトニング ネットワークから真に「脚光を盗む」最初のものとなっています。

Rollups have become a hot topic in the Bitcoin scaling discussion lately, being the first thing to truly “steal the limelight” from the Lightning Network in terms of wider mindshare. Rollups aim to be an off-chain layer two that is not bound or constrained by the liquidity limitations that are central to the Lightning Network, i.e. end users required someone allocate (or “lend”) them funds ahead of time in order to be able to receive money, or intermediary routing nodes requiring channel balances that can facilitate the movement of the payment amount all the way from sender to receiver.

ロールアップは最近、ビットコインのスケーリングに関する議論でホットな話題となっており、より幅広いマインドシェアの観点からライトニングネットワークから本当に「脚光を盗む」最初のものです。ロールアップは、ライトニング ネットワークの中心となる流動性制限に拘束されないオフチェーンのレイヤー 2 になることを目指しています。つまり、エンドユーザーは、事前に誰かが資金を割り当てる (または「貸す」) 必要があります。お金を受け取るため、または送金者から受取人までの支払い金額の移動を容易にするチャネル残高を必要とする中間ルーティングノード。

These systems were originally developed to function on Ethereum and other Turing complete systems, but as of late the focus has shifted to porting them to UTXO based blockchains such as Bitcoin. This article is not going to discuss the current state of things being implemented on Bitcoin currently, but going to discuss the function of an idealized rollup that people are aiming for in the long term depending on features Bitcoin currently does not support, namely the ability to verify Zero Knowledge Proofs (ZKPs) on Bitcoin directly.

これらのシステムはもともとイーサリアムやその他のチューリング完全システムで機能するように開発されましたが、最近ではビットコインなどの UTXO ベースのブロックチェーンに移植することに焦点が移っています。この記事では、現在ビットコインで実装されているものの現状について議論するつもりはありませんが、ビットコインが現在サポートしていない機能に応じて、人々が長期的に目指している理想的なロールアップの機能について議論するつもりです。ビットコインのゼロ知識証明 (ZKP) を直接検証します。

The basic architecture of a roll is as follows: a single account (or in Bitcoin’s case UTXO), holds the balances of all users in the rollup. This UTXO contains a commitment in the form of a merkle root of a merkle tree that commits to all the current balances of existing accounts in the rollup. All of these accounts are authorized using public/private key pairs, so in order to propose an off-chain spend a user must still sign something with a key. This part of the structure allows users to leave without permission whenever they want, simply by crafting a transaction proving their account is part of the merkle tree, they can unilaterally exit the rollup without the operator's permission.

ロールの基本的なアーキテクチャは次のとおりです。単一のアカウント (ビットコインの場合は UTXO) が、ロールアップ内のすべてのユーザーの残高を保持します。この UTXO には、ロールアップ内の既存のアカウントのすべての現在の残高をコミットするマークル ツリーのマークル ルートの形式でコミットメントが含まれています。これらのアカウントはすべて、公開キーと秘密キーのペアを使用して認証されるため、オフチェーンでの支出を提案するには、ユーザーはキーを使用して何かに署名する必要があります。構造のこの部分により、ユーザーはいつでも好きなときに許可なく退出でき、自分のアカウントがマークル ツリーの一部であることを証明するトランザクションを作成するだけで、オペレーターの許可なしに一方的にロールアップを終了できます。

The operator of the rollup must include a ZKP in transactions that update the merkle root of account balances on-chain in the process of finalizing off-chain transactions, without this ZKP the transaction will be invalid and therefore not includable in the blockchain. This proof allows people to verify that all changes to off-chain accounts were properly authorized by the account holder(s), and that the operator has not conducted a malicious update of balances to steal money from users or reallocate it to other users dishonestly.

ロールアップのオペレーターは、オフチェーントランザクションを終了するプロセスでオンチェーンのアカウント残高のマークルルートを更新するトランザクションに ZKP を含める必要があります。この ZKP がないとトランザクションは無効になり、したがってブロックチェーンに含めることはできません。この証明により、オフチェーン アカウントへのすべての変更がアカウント所有者によって適切に承認されたこと、およびオペレーターがユーザーからお金を盗んだり他のユーザーに不正に再割り当てしたりするために残高の悪意のある更新を行っていないことを検証できます。

The problem is, if only the root of the merkle tree is posted on-chain where users can view and access it, how do they get their branch in the tree in order to be capable of exiting without permission when they want to?

問題は、マークル ツリーのルートのみがオンチェーンに投稿され、ユーザーが表示およびアクセスできる場合、必要なときに許可なく終了できるようにするには、ツリー内のブランチをどのように取得するかということです。

In a proper rollup, the information is put directly into the blockchain everytime that new off-chain transactions are confirmed and the state of the rollup accounts change. Not the entire tree, that would be absurd, but the information necessary to reconstruct the tree. In a naive implementation, the summary of all existing accounts in the rollup would have balances and accounts simply added in the transaction updating the rollup.

適切なロールアップでは、新しいオフチェーン トランザクションが確認され、ロールアップ アカウントの状態が変化するたびに、情報がブロックチェーンに直接書き込まれます。ツリー全体ではなく、それはばかげていますが、ツリーを再構築するために必要な情報です。単純な実装では、ロールアップ内のすべての既存の口座の概要には、ロールアップを更新するトランザクションに単純に残高と口座が追加されます。

In more advanced implementations, a balance diff is used. This is essentially a summary of what accounts have had money added to or subtracted from them during the course of an update. This allows each rollup update to only include the changes to account balances that occur. Users can then simply scan the chain and “do the math” from the beginning of the rollup to arrive at the current state of account balances, which allows them to reconstruct the merkle tree of current balances.

より高度な実装では、バランス差分が使用されます。これは基本的に、更新中にどのアカウントにお金が追加または削除されたかの概要です。これにより、各ロールアップ更新には、発生した口座残高の変更のみが含まれるようになります。その後、ユーザーは単純にチェーンをスキャンし、ロールアップの先頭から「計算」して口座残高の現在の状態を把握し、現在の残高のマークル ツリーを再構築できます。

This saves a lot of overhead and blockspace (and therefore money) while still allowing users to guarantee access to the information needed for them to exit unilaterally. Including this data in a formal rollup that uses the blockchain to make it available to users is mandated by the rules of the rollup, i.e. a transaction that does not include the account summary or account diff is considered an invalid transaction.

これにより、ユーザーが一方的に終了するために必要な情報へのアクセスを保証しながら、多くのオーバーヘッドとブロックスペース (したがってコスト) が節約されます。このデータをブロックチェーンを使用してユーザーが利用できるようにする正式なロールアップに含めることは、ロールアップのルールによって義務付けられています。つまり、アカウントの概要またはアカウントの差分が含まれていないトランザクションは無効なトランザクションとみなされます。

The other way to handle the problem of data availability for users to withdraw is to put the data somewhere else besides the blockchain. This introduces subtle issues, the rollup still needs to enforce that the data was made available somewhere else. Traditionally other blockchains are used for this purpose, specifically designed to function as data availability layers for systems like rollups.

ユーザーが引き出し可能なデータの可用性の問題に対処するもう 1 つの方法は、データをブロックチェーン以外の場所に置くことです。これにより微妙な問題が発生し、ロールアップではデータが別の場所で利用可能になったことを強制する必要があります。従来、この目的には他のブロックチェーンが使用されており、特にロールアップなどのシステムのデータ可用性レイヤーとして機能するように設計されています。

This creates the dilemma of security guarantees being as strong. When the data is posted directly to the Bitcoin blockchain, consensus rules can guarantee it is correct with absolute certainty. However when it is posted to an external system, the best it can do is verify an SPV proof that the data was posted to another system.

これにより、セキュリティの保証が同じくらい強力であるというジレンマが生じます。データがビットコイン ブロックチェーンに直接投稿されると、コンセンサス ルールによってそのデータが絶対的に正しいことが保証されます。ただし、データが外部システムに投稿された場​​合、できることは、データが別のシステムに投稿されたことを示す SPV の証拠を検証することだけです。

This entails verifying an attestation that data exists on other chains, which is ultimately an oracle problem. Bitcoin’s blockchain cannot verify anything completely except what occurs on its own blockchain, the best it can do is verify a ZKP. A ZKP however cannot verify that a block containing rollup data was actually publicly broadcast after being produced. It cannot verify that external information is actually publicly available to everyone.

これには、データが他のチェーンに存在するという証明の検証が必要になりますが、これは最終的にはオラクルの問題になります。ビットコインのブロックチェーンは、独自のブロックチェーン上で発生すること以外は完全に検証することはできず、できるのは ZKP を検証することだけです。ただし、ZKP は、ロールアップ データを含むブロックが作成後に実際に公開ブロードキャストされたかどうかを検証できません。外部情報が実際に誰にでも公開されているかどうかを検証することはできません。

This opens the door to data withholding attacks, where a commitment

これにより、データ保留攻撃への扉が開かれます。