出典:ビットコインマガジン; コンピレーション:ファイブバーツ、ゴールデンファイナンス
Rollupsは最近、BTCのスケーリングの焦点となり、ライトニングネットワークから本当に風を奪った最初のものになり、より広い注目を集めています。Rollupsは、ライトニングネットワークのコア流動性制約や制限に影響を受けず、制約を受けずにオフチェーンの第2層として機能することを目的としています。つまり、最終ユーザーは事前に資金を割り当てる(または「借りる」)必要があり、または中間ルーティングノードは支払い額を送信者から受信者まで全体的に流動させるためにチャネル残高が必要です。
これらのシステムはもともとイーサリアムや他のチューリング完全システムで実行されていましたが、最近では重点がUTXOベースのブロックチェーン(例:BTC)への移植に移りました。この記事ではBTC上での現在の実装については議論するつもりはありませんが、長年にわたり追求されてきた理想的なRollupの機能について議論します。これはBTCが現在サポートしていない、つまりBTC上で直接ゼロ知識証明(ZKP)を検証する能力に依存しています。
Rollの基本的な構造は次のようになっています:個々のアカウント(BTCではUTXOと呼ばれます)は、Rollup内のすべてのユーザーの残高を保持します。このUTXOには、Merkleツリーのルートとして存在する、Rollup内の既存のアカウントのすべての現在の残高をコミットするコミットメントが含まれています。これらのアカウントはすべて、公開鍵/秘密鍵ペアを使用して承認されているため、オフチェーン支出を行うためには、ユーザーは依然として秘密鍵である内容に署名する必要があります。この構造のこの部分により、ユーザーはいつでも許可なしに抜けることができます。単に彼らのアカウントがMerkleツリーの一部であることをトランザクションで証明すれば、ユーザーは運営者の許可なしにRollupから一方的に退出することができます。
Rollupオペレーターは、トランザクションにZKPを含める必要があります。これにより、オフチェーン取引のプロセス中にオンチェーンアカウント残高のMerkleルートが更新されます。このZKPがない場合、トランザクションは無効になり、ブロックチェーンに含めることはできません。この証明により、オフチェーンアカウントのすべての変更が正当な権限を持つアカウント所有者によって承認されたこと、およびオペレーターがユーザーの資金を盗むために意図的に残高を更新したり、不正に他のユーザーに再割り当てしたりしていないことを人々が検証できます。
問題は、もしMerkleツリーのルートだけがオンチェーンに公開され、ユーザーがそれを表示してアクセスできる場合、彼らはいかにして自分たちの枝をツリーに配置し、希望するときに許可なしで退出できるようにするのかということですか?
適切なRollup内で、新しいオフチェーン取引が確認されるたびに、Rollupアカウントの状態が変化すると、その情報は直接ブロックチェーンに格納されます。全体のツリーではなく、ツリーを再構築するために必要な情報です。単純な実装では、Rollup内のすべての既存のアカウントの要約には残高が含まれ、アカウントはRollupの取引が更新される際にのみ追加されます。
より高度な実装では、残高差分を使用します。これは、更新プロセス中にどのアカウントが資金を増やしたり減らしたりしたかの要約です。これにより、各Rollupの更新には発生したアカウント残高の変更のみが含まれます。その後、ユーザーは単純にロールアップの先頭からスキャンして「計算」し、アカウント残高の現在の状態を復元できます。これにより、現在の残高のMerkle Treeを再構築できます。
こうすることで、多額の費用とブロックスペース(つまり資金)を節約しつつ、ユーザーが片方向の退出に必要な情報を保証できるようになります。rollup ルールでは、これらのデータを公式のrollupに含める必要があり、つまりアカウントの要約またはアカウントの差異を含まない取引は無効と見なされます。
ユーザーのデータの利用可能性の問題を処理する別の方法は、データをブロックチェーン以外の他の場所に配置することです。これにより、微妙な問題が生じます。ロールアップは依然として他の場所でデータが利用可能であることを強制的に保証する必要があります。伝統的に、他のブロックチェーンがこの目的のために使用され、ロールアップなどのシステムのデータの利用可能性層として特別に設計されています。
これにより、同じくらい強力なセキュリティ保護のジレンマが生じます。データが直接BTCブロックチェーンに公開される場合、コンセンサスルールによって絶対に正確であることが保証されます。しかし、外部システムに公開される場合、最善の場合はSPVプルーフを検証することで、データが別のシステムに公開されたことを確認できます。
これは、他のオンチェーンの証明に存在するデータを検証する必要があり、最終的にはオラクルマシンの問題です。BTCのブロックチェーンは、自分のブロックチェーンで起こること以外のことを完全に検証することはできませんが、ZKPを検証することができます。しかし、ZKPは、rollupデータを含むブロックが生成された後に実際に公開されたかどうかを検証することはできません。外部情報が本当にすべての人に公開されているかどうかを検証することはできません。
このデータの留保攻撃は、公開データに対する約束を作成し、それをrollupを推進するために使用することを可能にする一方で、実際にはデータが利用できない状態を作り出しました。これにより、ユーザーは資金を引き出すことができません。唯一の真の解決策は、BTC以外のシステムの価値とインセンティブ構造に完全に依存することです。
これは、ロールアップに困難をもたらします。データの可用性の問題に関わる場合、データをBTCブロックチェーンに公開するか、他の場所に公開するかという二者択一が基本的に存在します。この選択は、ロールアップのセキュリティ、主権、および拡張性に重大な影響を及ぼします。
一方、BTCブロックチェーンをデータの可用性層として使用することは、ロールアップのスケーラビリティに厳格な上限を設定します。ブロックスペースは限られており、これにより一度に存在できるロールアップの数や、オフチェーンで処理できるトランザクションの合計数に上限が設定されます。ロールアップの更新ごとに、前回の更新以降に残高が変化したアカウントの数に比例してブロックスペースが必要です。情報理論ではデータを一定の程度まで圧縮することしか許されていないため、これ以上の拡張の可能性はありません。
一方、データ可用性を実現するために異なる層を使用することにより、拡張性の利点の硬い上限が除去されますが、新しいセキュリティおよび主権の問題も生じます。BTCを使用したデータ可用性を実現するRollupの場合、ユーザーが抽出する必要のあるデータが自動的にブロックチェーンに公開されていない場合、Rollupの状態は変化しません。Validiumsを使用する場合、この保証は外部システムが詐欺とデータの隠蔽に対して抵抗する能力に完全に依存します。
現在、外部データの可用性システム上の任意のブロックプロデューサーは、そのブロックを実際にブロードキャストすることなく、BTCRollupユーザーの資金を奪うためにブロックを生成することができます。これにより、データが利用可能になります。
それでは、本当にBTCで理想的なRollup実装を実現した場合、本当に片側のユーザー引き出しを実現した場合、どうなるでしょうか?
50.08K 人気度
8.35K 人気度
5.89K 人気度
2.18K 人気度
2.09K 人気度
Bitcoin Magazine:Rollupはどんな困難に直面しているのでしょうか?
出典:ビットコインマガジン; コンピレーション:ファイブバーツ、ゴールデンファイナンス
Rollupsは最近、BTCのスケーリングの焦点となり、ライトニングネットワークから本当に風を奪った最初のものになり、より広い注目を集めています。Rollupsは、ライトニングネットワークのコア流動性制約や制限に影響を受けず、制約を受けずにオフチェーンの第2層として機能することを目的としています。つまり、最終ユーザーは事前に資金を割り当てる(または「借りる」)必要があり、または中間ルーティングノードは支払い額を送信者から受信者まで全体的に流動させるためにチャネル残高が必要です。
これらのシステムはもともとイーサリアムや他のチューリング完全システムで実行されていましたが、最近では重点がUTXOベースのブロックチェーン(例:BTC)への移植に移りました。この記事ではBTC上での現在の実装については議論するつもりはありませんが、長年にわたり追求されてきた理想的なRollupの機能について議論します。これはBTCが現在サポートしていない、つまりBTC上で直接ゼロ知識証明(ZKP)を検証する能力に依存しています。
Rollの基本的な構造は次のようになっています:個々のアカウント(BTCではUTXOと呼ばれます)は、Rollup内のすべてのユーザーの残高を保持します。このUTXOには、Merkleツリーのルートとして存在する、Rollup内の既存のアカウントのすべての現在の残高をコミットするコミットメントが含まれています。これらのアカウントはすべて、公開鍵/秘密鍵ペアを使用して承認されているため、オフチェーン支出を行うためには、ユーザーは依然として秘密鍵である内容に署名する必要があります。この構造のこの部分により、ユーザーはいつでも許可なしに抜けることができます。単に彼らのアカウントがMerkleツリーの一部であることをトランザクションで証明すれば、ユーザーは運営者の許可なしにRollupから一方的に退出することができます。
Rollupオペレーターは、トランザクションにZKPを含める必要があります。これにより、オフチェーン取引のプロセス中にオンチェーンアカウント残高のMerkleルートが更新されます。このZKPがない場合、トランザクションは無効になり、ブロックチェーンに含めることはできません。この証明により、オフチェーンアカウントのすべての変更が正当な権限を持つアカウント所有者によって承認されたこと、およびオペレーターがユーザーの資金を盗むために意図的に残高を更新したり、不正に他のユーザーに再割り当てしたりしていないことを人々が検証できます。
問題は、もしMerkleツリーのルートだけがオンチェーンに公開され、ユーザーがそれを表示してアクセスできる場合、彼らはいかにして自分たちの枝をツリーに配置し、希望するときに許可なしで退出できるようにするのかということですか?
適切なロールアップ
適切なRollup内で、新しいオフチェーン取引が確認されるたびに、Rollupアカウントの状態が変化すると、その情報は直接ブロックチェーンに格納されます。全体のツリーではなく、ツリーを再構築するために必要な情報です。単純な実装では、Rollup内のすべての既存のアカウントの要約には残高が含まれ、アカウントはRollupの取引が更新される際にのみ追加されます。
より高度な実装では、残高差分を使用します。これは、更新プロセス中にどのアカウントが資金を増やしたり減らしたりしたかの要約です。これにより、各Rollupの更新には発生したアカウント残高の変更のみが含まれます。その後、ユーザーは単純にロールアップの先頭からスキャンして「計算」し、アカウント残高の現在の状態を復元できます。これにより、現在の残高のMerkle Treeを再構築できます。
こうすることで、多額の費用とブロックスペース(つまり資金)を節約しつつ、ユーザーが片方向の退出に必要な情報を保証できるようになります。rollup ルールでは、これらのデータを公式のrollupに含める必要があり、つまりアカウントの要約またはアカウントの差異を含まない取引は無効と見なされます。
有効期限
ユーザーのデータの利用可能性の問題を処理する別の方法は、データをブロックチェーン以外の他の場所に配置することです。これにより、微妙な問題が生じます。ロールアップは依然として他の場所でデータが利用可能であることを強制的に保証する必要があります。伝統的に、他のブロックチェーンがこの目的のために使用され、ロールアップなどのシステムのデータの利用可能性層として特別に設計されています。
これにより、同じくらい強力なセキュリティ保護のジレンマが生じます。データが直接BTCブロックチェーンに公開される場合、コンセンサスルールによって絶対に正確であることが保証されます。しかし、外部システムに公開される場合、最善の場合はSPVプルーフを検証することで、データが別のシステムに公開されたことを確認できます。
これは、他のオンチェーンの証明に存在するデータを検証する必要があり、最終的にはオラクルマシンの問題です。BTCのブロックチェーンは、自分のブロックチェーンで起こること以外のことを完全に検証することはできませんが、ZKPを検証することができます。しかし、ZKPは、rollupデータを含むブロックが生成された後に実際に公開されたかどうかを検証することはできません。外部情報が本当にすべての人に公開されているかどうかを検証することはできません。
このデータの留保攻撃は、公開データに対する約束を作成し、それをrollupを推進するために使用することを可能にする一方で、実際にはデータが利用できない状態を作り出しました。これにより、ユーザーは資金を引き出すことができません。唯一の真の解決策は、BTC以外のシステムの価値とインセンティブ構造に完全に依存することです。
ジレンマ
これは、ロールアップに困難をもたらします。データの可用性の問題に関わる場合、データをBTCブロックチェーンに公開するか、他の場所に公開するかという二者択一が基本的に存在します。この選択は、ロールアップのセキュリティ、主権、および拡張性に重大な影響を及ぼします。
一方、BTCブロックチェーンをデータの可用性層として使用することは、ロールアップのスケーラビリティに厳格な上限を設定します。ブロックスペースは限られており、これにより一度に存在できるロールアップの数や、オフチェーンで処理できるトランザクションの合計数に上限が設定されます。ロールアップの更新ごとに、前回の更新以降に残高が変化したアカウントの数に比例してブロックスペースが必要です。情報理論ではデータを一定の程度まで圧縮することしか許されていないため、これ以上の拡張の可能性はありません。
一方、データ可用性を実現するために異なる層を使用することにより、拡張性の利点の硬い上限が除去されますが、新しいセキュリティおよび主権の問題も生じます。BTCを使用したデータ可用性を実現するRollupの場合、ユーザーが抽出する必要のあるデータが自動的にブロックチェーンに公開されていない場合、Rollupの状態は変化しません。Validiumsを使用する場合、この保証は外部システムが詐欺とデータの隠蔽に対して抵抗する能力に完全に依存します。
現在、外部データの可用性システム上の任意のブロックプロデューサーは、そのブロックを実際にブロードキャストすることなく、BTCRollupユーザーの資金を奪うためにブロックを生成することができます。これにより、データが利用可能になります。
それでは、本当にBTCで理想的なRollup実装を実現した場合、本当に片側のユーザー引き出しを実現した場合、どうなるでしょうか?