作者: ピーター
序文
2009 年の BTC の出現以来、ビットコインは 3 回の技術的反復を経て、単純なデジタル ネイティブ資産の概念から、複雑な機能とアプリケーションを備えた分散型金融システムへと発展しました。
この記事は BEVM の創設者によって書かれ、BTC テクノロジーの進化に関する洞察を共有し、BTC Layer2 テクノロジー開発における重要なマイルストーンである BEVM がどのようにして BTC の将来を技術レベルで実現するのかについても詳しく説明しています。分散型の生態学的繁栄。
この記事を通じて、以下について詳しく学びます。
- BTC Layer2の必要性
- BTC レイヤー 2 を実装するにはどうすればよいですか?
- 完全に分散化された BEVM ソリューション
BTC の誕生以来、BTC が繰り返してきた 3 つの偉大な革新的なテクノロジーに敬意を表します。
- 2009: 分散型通貨アプリケーションを可能にするために初めてブロックチェーン構造を使用した BTC が誕生しました。
- 2017: BTC Segregated Witness は最大 4MB のストレージをサポートするようにアップグレードされ、BTC のオンチェーン ストレージの問題を解決しました。これは、現在人気のある Ordinals プロトコル (資産の発行) の基礎も提供します。
- 2021: BTC Taproot は、BTC しきい値署名アルゴリズムをサポートするようにアップグレードされ、完全に分散化された BTC Layer2 テクノロジーの基礎となるサポートを提供します。
1. なぜ BTC Layer2 を構築したいのですか?
1. 需要はあります: ビットコインネットワークは資産登録の需要を満たしていますが、オンチェーン決済 (レイヤー 2) を必要とする資産が依然として多数あります。
現在の ETH の Layer2 は、ETH Layer1 の単なるコピーであり、Layer1 では解決できず、Layer2 で解決する必要がある実際的なビジネス上の問題を解決するものではありません。
ETH Layer2 は ETH Layer1 の問題を解決すると言わなければなりません。Layer2 は Layer1 の高いガスコストの問題を解決します。 GMX など、ETH 最大のレイヤー 2 アービトラム上のデリバティブ アプリケーションが作成されたのは、まさにこの需要のためです。
BTC のレイヤー 2 は、ETH のレイヤー 2 ほど無関係ではありません。
BTC の非チューリング完全オンチェーン仮想マシンは資産の登録のみが可能で決済はできないため、BTC レイヤー 1 は、BTC レイヤー 1 が発行した資産を決済するためにチューリング完全 BTC レイヤー 2 を要求する必要があります。
2. 可能性: BTC は完全に分散化されたレイヤー 2 になることができます
2021 年の BTC Taproot アップグレードまでは、完全に分散化された BTC Layer2 を実現することは不可能です。ただし、このアップグレード後は、BTC しきい値署名アルゴリズムにより、BTC は完全に分散化されたレイヤー 2 コンピューティング レイヤーをサポートできるようになります。
第二に、分散型 BTC L2 をどのように実現するか?
ビットコイン改善提案 (BIP) は、ビットコインに新しい機能と情報を導入する設計文書です。一方、タップルート アップグレードは、Schnorr Signature (BIP 340)、Taproot (BIP 341)、Tapscript (BIP 342) という 3 つの BIP をまとめたものです。 3 つのアップグレードは総称して BIP Taproot と呼ばれます。
これは、より効率的で柔軟かつプライベートな送信方法をビットコインにもたらし、その核心はシュノア署名とメルケル抽象構文ツリーの使用にあります。
これは、より効率的で柔軟かつプライベートな送信方法をビットコインにもたらし、その核心はシュノア署名とメルケル抽象構文ツリーの使用にあります。
Schnorr 署名は、そのシンプルさとセキュリティで知られるデジタル署名スキームです。 Schnoor 署名には、計算効率、ストレージ、プライバシーの点でいくつかの利点があります。
利用者は公開鍵で署名者の身元を確認し、データで契約内容を確認することでデジタル契約の正当性を検証する。
Schnorr 集約署名は、複数の署名データを 1 つの集約署名に圧縮してマージできます。
検証者は、すべての署名関連データと公開鍵のリストを通じて単一の集合署名を検証します。検証に合格した場合、その効果は、関連するすべての署名を独立して検証し、すべて合格したことと同等になります。
現在のほとんどのブロックチェーンは ECDSA マルチ署名アルゴリズムを使用しており、ブロック データの場合、各ノードは独自の秘密キーを使用して独立したデジタル署名を生成し、それを他のノードにブロードキャストします。他のノードは署名を検証し、それをデータの次のブロックに書き込みます。
この方法を使用すると、コンセンサス ノードの数が多い場合、コンセンサス ブロックの各ラウンドに格納される署名データが増加し続け、ストレージ スペースを占有します。
新しいノードがネットワークに参加し、履歴ブロックを同期する必要があるときは常に、大量の署名データがネットワーク帯域幅に大きな課題をもたらします。
集約署名テクノロジーを使用した後、図 2 に示すように、各ノードは他のノードによってブロードキャストされた集約署名名刺を収集し、署名をフラグメントに集約して保存します。
このようにして、新しいノードが参加すると、履歴ブロックの同期には集約された署名データをダウンロードするだけで済むため、ネットワーク帯域幅の占有が大幅に削減され、トランザクション手数料が削減されます。
さらに、キー集約により、すべての Taproot 出力が類似したものになります。マルチ署名出力、単一署名出力、またはその他の複雑なスマート コントラクトがブロックチェーン上ではすべて同じに見えるため、多くのブロックチェーン分析が利用できなくなり、すべての Taproot ユーザーのプライバシーが保護されます。
MAST (マークル抽象構文ツリー) は、マークル ツリーを使用して複雑なロック スクリプトを暗号化します。そのリーフはシラー非重複スクリプト (マルチシグネチャやタイム ロックなど) です。
MAST (マークル抽象構文ツリー) は、マークル ツリーを使用して複雑なロック スクリプトを暗号化します。そのリーフはシラー非重複スクリプト (マルチシグネチャやタイム ロックなど) です。
支払いの際には、関連するスクリプトとそのスクリプトから Merck ツリーのルートまでのパスのみが開示されます。図 3 に示すように、script1 を使用するには、script1、script2、および hash3 を公開するだけで済みます。
MAST の主な利点は次のとおりです。
- 複雑な出金条件にも対応
- 未実行のスクリプトやトリガーされていない支払い条件を開示する必要がないため、プライバシー保護が強化されます。
- 圧縮されたトランザクション サイズ: スクリプトの数が増加すると、非 MAST トランザクション サイズは直線的に増加しますが、MAST トランザクション サイズは対数的に増加します。
ただし、Taproot のアップグレードには問題があります。つまり、P2SH は一般的な公開鍵ハッシュへの支払い (P2PKH) とは異なる動作をし、プライバシー保護の問題がまだ残っています。
P2SH と P2PKH をチェーン上で同じように見せることは可能ですか?
この目的を達成するために、Taproot は解決策を提案しました。これは、署名者の数が限られているスクリプトに対して 2 つの部分に分けることができます。
最初の部分はマルチ署名で、すべての署名者が特定の支出結果に同意します。これは「共同支出」と呼ばれます。
2 番目の部分は「非協力的支出」と呼ばれ、非常に複雑なスクリプト構造を持つ可能性があります。
これら 2 つの部分は「または」の関係にあります。
図 3 に示すように、Script3 は 2-of-2 マルチ署名であり、有効であるためにはアリスとボブの両方が署名する必要があります。これは「共同支出」ですが、Script1 と 2 は「非共同支出」です。
「共同支出」と「非共同支出」の両方がこの産出物に費やすことができます。その中には次のようなものがあります。
- 「非協力支出」スクリプトの場合は、上記の MAST メソッドを採用し、MerkleRoot を使用してマークル ツリー ルートを表します。
- 「共同支出」スクリプトには、シュノア署名に基づくマルチ署名アルゴリズムが採用されています。 Pa と Pb がそれぞれアリスとボブの公開鍵を表し、Da と Db がそれぞれアリスとボブの秘密鍵を表すものとします。したがって、集約公開キーは P=Pa+Pb であり、対応する秘密キーは Da+Db です。
- 「協力支出」と「非協力支出」は P2PKH の形式に結合されます。公開鍵は PP+H(P||MerkleRoot)G、対応する秘密鍵は Da+Db+H(P| |MerkleRoot) です。 )。
- アリスとボブが「共同支出」に同意する場合、どちらかが秘密鍵に H(P||MerkleRoot) を追加する限り、Da+Db+H(P||MerkleRoot) を使用します。
オンチェーンでは、これは公開鍵と対応する秘密鍵を使用した P2PKH トランザクションのように動作し、基礎となる MAST を開示する必要はありません。
3. 当社の完全分散型 BTC レイヤー 2 ソリューション:
3.1 BTCライトノード+分散閾値署名契約
このソリューションでは、BTC チェーン上の分散しきい値署名集約保管契約を完了するために、n 個 (n は BEVM 上のすべてのバリデーターにすることができます) の固定バリデーターが選択されます。
このソリューションでは、BTC チェーン上の分散しきい値署名集約保管契約を完了するために、n 個 (n は BEVM 上のすべてのバリデーターにすることができます) の固定バリデーターが選択されます。
BEVM レイヤー 2 の各バリデーターのブロック生成秘密鍵も、BTC のしきい値署名の集合秘密鍵の一部を導出し、n 個のバリデーターのしきい値秘密鍵が結合されて、BTC の集合署名写真アドレスが作成されます。 n の最大値の範囲は 1000 以上です。
- ユーザー A が BTC を BEVM にクロスチェーンしたい場合、ユーザーは BTC をビットコイン アグリゲーション カストディ コントラクトに送信するだけでよく、ユーザーは BEVM レイヤー 2 で BTC を受け取ることができます。
- 同様に、ユーザー A が出金操作を実行すると、集約された署名を構成する n 個の検証ノードのうち m 個だけが分散閾値署名契約の相互運用を自動的に完了し、保管契約からユーザー A への転送をビットコイン上で完了できます。 , BTCはBEVM上で破棄されます。
3.2 BTC をネイティブ ガス料金および EVM 互換のレイヤー 2 として実装
1) EVM 原理
イーサリアム仮想マシンは、イーサリアム スマート コントラクトの実行環境です。サンドボックス化されているだけでなく、実際には完全に分離されています。
これは、EVM で実行されているコードがネットワーク、ファイル システム、およびその他のプロセスにアクセスできないことを意味します。スマートコントラクト間のアクセスも制限されています。
Ethereum の最下層は EVM モジュールを通じてコントラクトの実行と呼び出しをサポートしており、呼び出し時にはコントラクト アドレスに従ってコントラクト コードが取得され、EVM にロードされて実行されます。通常、スマート コントラクトの開発プロセスは、Solidity を使用してロジック コードを記述し、それをコンパイラーを通じてバイトコードにコンパイルし、最終的にイーサリアムに公開します。
2) EVMの主要部
3) EVM コード
EVM コードはイーサリアム仮想マシン コードであり、イーサリアムに含めることができるプログラミング言語のコードを指します。アカウントに関連付けられた EVM コードは、メッセージがアカウントに送信されるたびに実行され、ストレージの読み取り/書き込みとメッセージ自体の送信を行う機能を備えています。
4)マシンの状態
マシン状態は、プログラム カウンター、スタック、メモリなどの evm コードが実行される場所です。
5)保管
ストレージは、読み取り可能、書き込み可能、および変更可能な永続ストレージ スペースであり、各コントラクトがデータを永続的に保存する場所でもあります。ストレージは合計 2256 個のスロットを持つ巨大なマップで、各スロットは 32 バイトです。
6) BTCをガス料金として使用する
ストレージは、読み取り可能、書き込み可能、および変更可能な永続ストレージ スペースであり、各コントラクトがデータを永続的に保存する場所でもあります。ストレージは合計 2256 個のスロットを持つ巨大なマップで、各スロットは 32 バイトです。
6) BTCをガス料金として使用する
ビットコインネットワークから転送されたBTCを、EVM上でトランザクションを実行するためのガス料金計算通貨として使用します。
全てのコメント