原作者: Fu Shaoqing、SatoshiLab、All Things Island BTC Studio
1. ビットコイン独自技術の主な探求と紛争
ビットコインの独自のテクノロジーは、大規模なアプリケーションとビットコインが持つべき機能との間に常に矛盾を抱えてきました。大規模なアプリケーションとトランザクションの規模は、より複雑な取引指示とより大きな取引スペースを意味しますか?すべての機能を単一のビットコイン システムに実装する必要があるという意味ですか?ビットコインの生態技術が十分に開発されていなかった初期の頃、これらの現象はビットコイン自体の問題であるように見えました。テクノロジーが発展するにつれて、多くの疑問に対してより明確な答えが得られるようになるでしょう。
この記事では、いくつかの関連する問題と、これらの問題が発生して解決されるプロセスを示します。この記事を通じて、これらの問題とテクノロジーの相関関係、さらにはビットコインのメインチェーンとそれに関連する「テストチェーン」の変化プロセスを見ることができます。ビットコインテクノロジーは、さまざまなプロジェクトやチーム（ビットコインの不完全な探求であるイーサリアムを含む）によって探求されてきましたが、ビットコインメインネットの変化は、タップルートのようなテクノロジーの出現を促進した後まで、十分に明らかではありませんでした。 Ordinals プロトコルなどのプロトコルの開発が完了し、再び新たな開発のクライマックスに入っています。
これらの開発プロセスと関連テクノロジーを全体的に見ると、それらの間のつながりがわかり、より多くの開発の方向性と全体的なアーキテクチャを推測することができます。
1.1. ビットコインのスクリプト言語といくつかの削除命令
ビットコインのプログラミング言語は、ループ ステートメントや条件付き制御ステートメントを持たない、逆ポーランド パラダイム スクリプト言語です (この機能を拡張するには、後述の TaprootTaproot スクリプトを参照してください)。したがって、ビットコイン スクリプト言語はチューリングが完全ではないとよく言われ、そのためビットコイン スクリプト言語には特定の制限が生じます。
もちろん、これらの制限により、ハッカーはこのスクリプト言語を使用して無限ループ (ネットワーク麻痺を引き起こす) や、DOS 攻撃を引き起こす可能性のある悪意のあるコードを作成することはできず、ビットコイン ネットワークに対する DOS 攻撃を回避できます。ビットコイン開発者はまた、一部の攻撃やネットワークの輻輳を避けるために、コアのブロックチェーンはチューリング完全性を持つべきではないと考えています。
しかし、これらの制限があるからこそ、ビットコイン ネットワークは他の複雑なプログラムを実行したり、いくつかの「便利な」機能を実行したりすることができません。その後開発された一部のブロックチェーン システムは、特定の問題を解決し、ユーザーのニーズを満たすために、この点を直接変更しました。たとえば、イーサリアムで使用される言語はチューリング完全です。
一般的なタイプのビットコイン スクリプト命令:
キーワード:
1. 一定。例: OP_ 0、OP_FALSE
2. プロセス制御。例: OP_IF、OP_NOTIF、OP_ELSE、…
3. 積み重ねる。例: OP_TOALTSTACK (入力を補助スタックの項目にプッシュし、メイン スタックから削除します)、...
4. 文字列。例: OP_CAT (2 つの文字列を接続、無効)、OP_SIZE (スタックの最上位要素の文字列長をスタックにプッシュします (要素をポップする必要はありません))
5. ビットロジック。例: OP_AND、OP_OR、OP_XOR
6. 算術論理。例: OP_ 1 ADD (入力値プラス 1)、OP_ 1 SUB (入力値マイナス 1)
7. 暗号化。例: OP_SHA 1 (入力は SHA-1 アルゴリズム HASH を使用します。)、OP_CHECKSIG()
8. 疑似キーワード
9. 予約されたキーワード
一般的なタイプのビットコイン スクリプト命令:
脚本：
1. ビットコインアドレスに支払う標準トランザクション (pay-to-pubkey-hash)
2. 標準ビットコイントランザクション (公開キーへの支払い)
3. 明らかに使用できない/削除可能な出力
4. 誰でも支出できるアウトプット
5. 推測取引
5 つの標準タイプのトランザクション スクリプトには、Pay to Public Key Hash (P2P KH)、Pay to Public Key、Multisig (15 キーに制限)、Pay to Script Hash (P2SH)、および Data Out (OP_RETURN) が含まれます。
詳細な手順については、Web ページ https://en.bitcoin.it/wiki/Script に記載されています。
ビットコインサポートの説明を削除
ビットコインの歴史の中で、指示は何度も削除されてきました。下図の赤い部分が削除された命令です。
(1) 文字列操作
(2)
(3) 算術演算
なぜ指示を削除するのでしょうか？セキュリティは考慮事項の 1 つにすぎません。階層化された設計概念を使用して削除命令を検討すると、その合理性が理解され、基盤となるプロトコルがより基本的かつ安定になります。おそらくサトシ・ナカモトは最初からこの問題に気づいていただろうし、そうでなければ率先して指示を削除しなかっただろう。私たちの通常の考え方は、コラボレーションを必要とする大規模なプロトコルではなく、ユーザーのニーズに直接応え、完全な命令とシステム機能を備えた小さなシステムを構築することです。
これにより、レイヤー ネットワークとして適しているのはビットコインだけであるという事実も生まれます。この現象については、「ビットコインの過剰価格が新たな代替チェーンの生成を促進する」という記事で分析しましたが、経済的観点と技術的観点から、ビットコインの代替チェーンが生成される可能性があります。しかし、ビットコインの基本的な特性と階層設計の観点から、ネットワークインフラストラクチャの層として機能できるのは、ほぼビットコインだけです。代替チェーンがあったとしても、それは 1.5 層の製品です。第一層ネットワークのレベルでは、本物はビットコインだけであり、何らかの代替機能を持たせることができるチェーンはせいぜいA級品である。
1.2. ビットコインフォークの歴史、理由、重要性
ビットコインの開発の歴史では、削除指示の問題に加えて、ブロックサイズをめぐる論争もあり、ビットコインのハードフォークにつながることがよくあります。
BTCが作られた当初はブロックサイズに制限がなかったため、同時に処理できるトランザクション数には制限がありました。しかし、BTC の価格が初期に非常に低かったとき、悪意のある取引のコストも非常に低かったため、この問題を解決するために、サトシ ナカモトは 2010 年 9 月 12 日にソフトフォークを実施し、ブロックに制限を追加しました。サイズは 1 MB を超えてはなりません。サトシ・ナカモト氏は、この制限は一時的なものであり、拡張のニーズに合わせて将来的には制御された段階的な方法でブロック制限を増やすことができると指摘しました。
下の図は、ビットコインのフォークの歴史を示しています。
ビットコインの人気に伴い、ネットワークトランザクションの混雑と確認時間の増大がますます深刻な問題となっています。 2015 年、ギャビン アンドレセンとマイク ハーンは、ブロック制限を 8 MB に増やすことを期待して、BitcoinXT の新しいバージョンに BIP-101 提案を実装すると発表しました。 Greg Maxell、Luke Jr、Pieter Wuille などのコア開発者は、このアプローチはフルノードを実行するためのしきい値を引き上げ、制御不能な影響を与えると信じて反対しました。議論は最終的に、議題と参加範囲の点で拡大しました。
上記の内容から、サトシ・ナカモト氏も「ブロック・サイズ制限は一時的なものであり、拡張のニーズを満たすために、将来的には制御可能かつ段階的にブロック・サイズ制限を増やすことができる」とも述べていることがわかります。より大きなブロックをサポートし、より大きなブロックをサポートするためにチェーンを分離すると問題は解決しますか?絶え間ない論争の中で、多くの事件も発生しました。たとえば、BCH ブロック サイズは 8 M ですが、その後 32 M に増加しました。 BSVのブロックサイズは128Mです。 BitMEXResearch によると、BCH (およびその後の BSV) に加えて、他の多くの BTC フォークされたコインも登場しました。BitMEXResearch によると、BCH フォーク後わずか 1 年で少なくとも 50 の新しいフォークされたコインが登場しました。
ビットコインメインネット上の Segwit と Taproot もブロック容量を 1 MB から 4 MB にある程度まで増加させたことは後でわかります。
ビットコインのフォークは開発の探求であり、独自の変更を通じてより多くのニーズをサポートしようとしています。その中には、ユーザーのニーズ、マイナーのニーズ、投資家のニーズ、開発者のニーズなどがあります。
1.3. ビットコイン開発におけるいくつかの典型的な探査
サトシ・ナカモト氏が去った後、後継者のギャビン・アンドレセン氏がビットコイン・コアとビットコイン財団の設立を主導した。この期間中、特に資産発行の分野で、BTC のスケーラビリティの探求が続けられてきました。
(1)カラーコイン
eToro CEO の Yoni Assia は、2012 年 3 月 27 日に公開された記事で最初にカラー コインを提案しました。このアイデアは成長を続け、Bitcointalk などのフォーラムで、カラー コインの概念が具体化し、注目を集め始めました。最後に、Meni Rosenfeld は、2012 年 12 月 4 日にカラー通貨について詳しく説明した白書を発表しました。
染色コインのアイデアは、ビットコインの特定の部分に特別なラベル (つまり、染料) を追加して、より広範囲の資産と価値を表現することです。カラーコインの実装には一連のエンティティがあり、大まかに 2 つのカテゴリに分類されます。
1) OP_RETURN に基づく:たとえば、2013 年に Flavien Charlon によって提案された Open Assets は、OP_RETURN (ビットコイン v 0.9.0 で提案) を使用して、少量のデータをビットコインに保存するために使用できます。初期制限は 40 バイトです。後に 80 バイトに増加しました)。オペコードはスクリプトに保存され、外部によって読み取られて「カラーリング」とトランザクションが完了します。 (このパターンは、資産の合法性を判断するために外部インデックスに依存する序数に似ています)。
2) OP_RETURN に基づく:代表的なものは、2014 年に ChromaWay によって提案された EPOBC プロトコルです。EPOBC 資産に関する追加情報は、ビットコイン トランザクションの nSequence フィールドに保存されます。各 EPOBC 資産のカテゴリと合法性は、起源まで遡る必要があります。決定するトランザクション。
(2)マスターコイン(OMNI)
JR Willettは2012年1月6日にMasterCoinのアイデアを発表し、それを「ビットコインの第2の白書」と名付け、2013年7月にICOを通じてプロジェクトを正式に開始し、最終的に5,120BTC（当時50万ドル相当）を調達しました。 MasterCoin は、ビットコイン ブロックをスキャンしてブロックチェーンの外部のノードに存在する状態モデル データベースを維持する完全なノード層を構築するという点で Colored Coins とは異なります。この設計は、新しい資産の作成、分散型取引所、自動価格フィードバックなど、カラーコインよりも複雑な機能を提供できます。 2014 年、テザーはマスターコイン プロトコルを通じてビットコイン上のステーブルコインも開始しました。これはテザー USD (OMNI) として知られています。
(3)相手方
Counterparty は 2014 年に正式に発足しました。カウンターパーティは、OP_RETURN を使用してデータを BTC ネットワークに保存します。ただし、カラーコインとは異なり、カウンターパーティの資産はUTXOの形式で存在しませんが、資産の譲渡を示すためにOP_RETURNを通じて情報をロードし、資産所有者が保有アドレスを使用して特別なデータでトランザクションに署名すると、資産の譲渡が完了します。 。このようにして、カウンターパーティは資産の発行と取引、およびイーサリアムスマートコントラクトと互換性のあるプラットフォームを実現できます。
さらに、イーサリアム、リップル、ビットシェアズも広義の「ビットコイン2.0」に属するという意見もあります。
1.4. ビットコインの不完全性と多層プロトコル
ビットコイン システムの不完全性 (または制限) は主にいくつかの側面で現れます (この記事の不完全性はイーサリアム ホワイト ペーパーの要約に基づいており、実際の不完全性ではありません)。
1. ビットコインアカウントシステムUTXO
現在のブロックチェーン プロジェクトには、主に 2 つの記録保持方法があります。1 つはアカウント/残高モデル、もう 1 つは UTXO モデルです。ビットコインはUTXOモデルを使用しますが、イーサリアム、EOSなどはアカウント/残高モデルを使用します。
ビットコインウォレットでは通常、アカウント残高を確認できますが、サトシ・ナカモトが設計したビットコインシステムには残高という概念がありません。 「ビットコインバランス」は、ビットコインウォレットアプリから派生した商品です。 UTXO (Unspent Transaction Outputs) は、未使用のトランザクション出力であり、ビットコイン トランザクションの生成と検証における中心的な概念です。トランザクションは一連のチェーン構造を形成しており、すべての合法的なビットコイン トランザクションは 1 つ以上の以前のトランザクションの出力まで遡ることができ、これらのチェーンのソースはマイニング報酬であり、最終的には現在の未使用のトランザクション出力になります。
つまり、現実世界にはビットコインは存在せず、UTXO だけが存在します。ビットコイン トランザクションはトランザクション入力とトランザクション出力で構成され、各トランザクションは入力を消費して出力を生成し、生成される出力は「未使用のトランザクション出力」、つまり UTXO です。
スマート コントラクトを実装したい場合、UTXO アカウント モデルには非常に大きな問題があります。イーサリアム イエロー ペーパーのデザイナーであるギャビン ウッドは、UTXO について非常に深い理解を持っています。イーサリアムの最大の新機能はスマート コントラクトです。スマート コントラクトの考慮事項により、Gavin Wood が UTXO に基づいてチューリング完全なスマート コントラクトを実装することは困難です。アカウント モデルは当然オブジェクト指向であり、各トランザクションは対応するアカウント (nonce++) に記録されます。アカウントの管理を容易にするために、グローバル状態が導入され、トランザクションごとにこのグローバル状態が変更されます。これは現実世界に相当します。あらゆる小さな変化が世界を変えます。そのため、イーサリアムではアカウントシステムが採用されており、その後のパブリックチェーンも基本的に各種アカウントシステムに基づいて実装されています。
UTXO のもう 1 つの重大な欠陥は、アカウントの出金制限を細かく制御できないことです。これについてはイーサリアムのホワイトペーパーで説明されています。
2. ビットコインのスクリプト言語はチューリングが完全ではない
ビットコイン スクリプト言語はさまざまな計算をサポートできますが、すべての計算をサポートできるわけではありません。主に欠けているのは、ビットコインのスクリプト言語であり、ループ ステートメントや条件付き制御ステートメントがありません。したがって、私たちは、「ビットコインスクリプト言語はチューリングが完全ではない」と言います。その結果、ビットコイン スクリプト言語には特定の制限が課せられます。もちろん、これらの制限により、ハッカーはこのスクリプト言語を使用して無限ループ (ネットワーク麻痺を引き起こす) や、DOS 攻撃を引き起こす可能性のある悪意のあるコードを作成することはできず、ビットコイン ネットワークに対する DOS 攻撃を回避できます。ビットコイン開発者はまた、一部の攻撃やネットワークの輻輳を避けるために、コアのブロックチェーンはチューリング完全性を持つべきではないと考えています。しかし、これらの制限があるからこそ、ビットコイン ネットワークは複雑なプログラムを実行できません。ループ ステートメントをサポートしない目的は、トランザクション確認中の無限ループを回避することです。
セキュリティのためにチューリングの完全性をサポートしない理由はありません。そして非チューリング完全言語はできることが限られています。
3. ビットコインのその他の欠陥、セキュリティとスケーラビリティ
マイニングの集中化の問題 ビットコイン マイニング アルゴリズムでは、基本的に、マイナーは特定のノードの修正バージョンのハッシュが目標値より小さくなるまで、ブロック ヘッダーを何千万回もわずかに変更できます。ただし、このマイニング アルゴリズムは 2 つの形式の集中化攻撃の影響を受けやすくなります。 1 つ目では、マイニング エコシステムは、ASIC (特定用途向け集積回路) と、ビットコインのマイニングという特定のタスクで数千倍効率が向上するように特別に設計されたコンピューター チップによって制御されます。これは、ビットコインマイニングがもはや高度に分散化されて平等主義的ではなくなり、巨大資本の効果的な参加が必要になることを意味します。第二に、ほとんどのビットコインマイナーは実際にはブロック検証をローカルで完了するのではなく、代わりに集中化されたマイニングプールに依存してブロックヘッダーを提供しています。問題は深刻です。現在、上位 3 つのマイニング プールがビットコイン ネットワークの処理能力の約 50% を間接的に制御しています。
スケーラビリティの問題はビットコインにとって重要な問題です。ビットコインの場合、1 時間あたり約 1 MB 増加します。ビットコイン ネットワークが 1 秒あたり 2,000 件の Visa トランザクションを処理すると、3 秒ごとに 1 MB 増加します (1 時間あたり 1 GB、年間 8 TB)。トランザクション数が少ないこともビットコインコミュニティで議論を引き起こしていますが、大規模なブロックチェーンはパフォーマンスを向上させることができますが、問題は集中化のリスクです。
製品ライフサイクルの観点から見ると、ビットコインのいくつかの小さな欠陥は独自のシステムで改善できますが、現在のシステムでは改善方法が制限されています。しかし、これらの問題が新しいシステムで解決できるのであれば、古いシステムの限界を考慮する必要はありません。新しいブロックチェーンシステムを構築するので、新しいシステムを設計する際には、これらの小さな機能改善も設計し、アップグレードする必要があります。
レイヤードデザイン
階層化設計は、システムを複数の階層構造に分割し、各層間の関係と機能を定義することで、システムのモジュール性、保守性、および拡張性を実現し、それによって設計効率を向上させるための手段および方法論です。システムの信頼性。
広範囲かつ大規模なプロトコル システムの場合、階層化を使用することには明らかな利点があります。これにより、人にとって理解しやすく、分業で実装しやすく、モジュールごとに改善しやすくなります。たとえば、コンピュータ ネットワークでは ISO/OSI の 7 層モデルが設計されていますが、特定の実装では、いくつかの層を組み合わせることができます。たとえば、特定のネットワーク プロトコルである TCP/IP は 4 層のプロトコルです。具体的には、プロトコル階層化の利点は次のとおりです。各層は独立しており、柔軟性があり、構造的に分離可能で、実装と保守が容易で、標準化作業を促進できます。
階層型プロトコルの観点から見ると、ビットコインは最も基本的なレベルにあるため、UTXO、非チューリング完全性、長いブロック生成時間、小さなブロック容量、創設者の消失などは、むしろ欠点ではありません。層ネットワークが持つべき特性です。
注：プロトコルの階層化については、筆者が「ビットコインレイヤー2構築V1.5の基礎知識体系をまとめた記事」で詳しく説明しています。
2. ビットコイン開発における重要な新技術（ブロック拡張と容量拡張）
前のセクションでは、ビットコインのオリジナルテクノロジーの主な競合といくつかの探索ケースについて説明しましたが、その多くはハードフォークやまったく新しい異種チェーンの作成につながりました。ビットコインのブロックチェーン自体でも、この探査は多くの成果をもたらしましたが、それらは本質的にブロックと機能の拡張です。それらは主に次のような側面で現れます。
2.1.OP_RETURN
ビットコイン開発者は常にビットコインの機能を拡張したいと考えており、それはいくつかの側面に反映されています。
(1) OP_RETURNの使用
OP_RETURN は、スクリプトを終了し、スタックの一番上の値を返すスクリプト オペコードです。このオペコードは、プログラミング言語の戻り関数に似ています。 OP_RETURN オペコードの機能は、ビットコインの歴史の中で何度か変更されてきましたが、現在では主に台帳にデータを保存する方法として使用されています。 OP_RETURN オペコードの機能は過去に大幅に変更され、現在ではオンチェーンに任意のデータを保存できる重要なメカニズムとなっています。
OP_RETURN は本来、スクリプトの実行を早期に終了するために使用されるリターン操作であり、実行結果はスタックの最上位の項目として表示されます。このオペコードには元々簡単に悪用可能な脆弱性がありましたが、Satoshi Middlemoto によってすぐにパッチが適用されました。
OP_RETURN 機能へのさらなる変更
Bitcoin Core v 0.9.0 アップグレードでは、「OP_RETURN 出力」スクリプトが標準出力タイプになり、ユーザーが「使用できないトランザクション出力」にデータを追加できるようになりました。このようなスクリプトで使用できるデータ量の上限は、当初は 40 バイトに制限されていましたが、その後 80 バイトに引き上げられました。
データをブロックチェーンに保存します。
常に false を返すように OP_RETURN を変更すると、興味深い結果が得られました。 OP_RETURN の後はオペコードもデータも評価されないため、ネットワーク ユーザーはこのオペコードを使用して任意の形式のデータを保存し始めました。
Bitcoin Cash (BCH) の期間、つまり 2017 年 8 月 1 日から 2018 年 11 月 15 日まで、OP_RETURN 出力に追加できるデータの長さが 220 バイトに拡張され、より大きなデータによりデータの利用が容易になります。ブロックチェーン上の革新的なアプリケーション（ブロックチェーンソーシャルメディアでのコンテンツの公開など）
BSV では、220 バイトの制限が短期間維持されました。その後、2019 年 1 月に、ノードが後続のオペコードを検証しないように OP_RETURN オペコードがスクリプトを終了するため、ノードはスクリプトが最大スクリプト サイズ制限の 520 バイト内にあるかどうかもチェックしません。その結果、ネットワーク上のノードオペレーターは最大トランザクションサイズを100KBに増やすことを決定し、これにより開発者がより自由にアプリケーションを革新できるようになり、新しいアプリケーションがより大規模で複雑なデータをビットコイン台帳に入れることができるようになりました。当時、誰かが Web サイト全体を BSV 台帳に登録するアプリケーションの例がありました。
OP_RETURN には特定の機能拡張がありますが、全体的な機能は依然として制限されています。そこで、Segregated Witness のテクノロジーが誕生しました。
(2) Segwit隔離証人
Segregated Witness (略して SegWit) は、2015 年 12 月に Pieter Wuile (ビットコイン コア開発者およびブロックストリーム共同創設者) によって最初に提案され、その後ビットコイン BIP 141 が形成されました。 Segregated Witness は、次の問題を解決するために、ビットコイン ブロック内のトランザクションのデータ構造をわずかに変更します。
1) トランザクションの順応性の問題。
2) SPV プルーフで送信されるトランザクションの署名はオプションとなり、マークルプルーフによって送信されるデータ量を削減できます。
3) 偽装した形でブロック容量を増加します。
最初の 2 つの項目は主にセキュリティとパフォーマンスを向上させるためのもので、その中で 3 番目の項目の実現は、ブロックの容量を増加させ (以下のブロックの重みの概念を参照)、それによって基盤を築きます。ビットコインの機能が拡張された結果、その後の Taproot (Segregated Witness の 2 番目のバージョン) はさらに強化されました。
収益化によりブロック容量が拡張される一方で、SegWit はブロック サイズによっても制限されます。ビットコインのブロック サイズは 1 M バイトに制限されていますが、この制限には監視データは含まれていないため、監視データの悪用を防ぐために、合計ブロック サイズは依然として制限されています。ブロックウェイトと呼ばれる新しい概念を導入
ブロック重量 = 基本サイズ * 3 + 合計サイズ
基本サイズは、監視データを含まないブロック サイズです。
合計サイズは、BIP 144 に記載されているシリアル化されたトランザクションのブロック サイズ (バイト単位) であり、ベース データと監視データが含まれます。
隔離された証人の制限はブロック重量 <= 4M です。
Segregated Witness では、ライトニング ネットワークを使用してビットコインを拡張することも技術的に許可されています。この部分についてはここでは詳しく紹介しません。
(3) Taproot Segregated Witness V2 バージョン
Taproot という言葉を直接使うと、新しい概念だと思う人も多いでしょうが、これが Segregated Witness の第 2 バージョンであると言われれば、ほとんどの人がその関連性を理解するでしょう。 Taproot に関連する BIP は 340、341、および 342 です。それらの名前は、BIP 340 (secp 256 k 1 の Schnorr 署名)、BIP 341 (Taproot: SegWit バージョン 1 の支出ルール)、BIP 342 (Taproot スクリプトの検証) です。
2021 年 11 月、Taproot はソフト フォークの形で正式に発効しました。このアップグレードは、BIP 340、BIP 341、および BIP 342 で構成されます。その中で、BIP 340は、楕円曲線デジタル署名アルゴリズム(ECDSA)に代わって複数のトランザクションを同時に検証できるSchnorr署名を導入し、ネットワーク容量を再び拡張し、バッチトランザクションの処理を高速化し、複雑でスマートなトランザクションの展開を可能にしました。 BIP 341 は、ブロックチェーン上のトランザクション データ ストレージを最適化するためにメルケル化抽象構文ツリー (MAST) を実装します。BIP 342 (Tapscript) は、ビットコインのネイティブ スクリプト機能の不足を拡張します。
Segwit と Taproot の領域の拡大により、Schnorr、MAST ツリー、および Taproot スクリプトが作成されました。その使命は、ビットコイン メインネットの機能を拡張することです。
2.2. Schnorr、MAT、タップルート スクリプト
セクション 2.1 を通じて、ビットコインの拡張と拡大の継続的な探求を見てきましたが、ビットコインの機能が真に開かれたのは、Taproot テクノロジーと、Schnorr、MAST、Taproot Script などのいくつかの関連する重要なテクノロジーの出現でした。
(1)シュノア署名
Taproot の開発では、その機能を拡張する一方で、署名アルゴリズムに特定の要件があるため、Schnorr 署名が登場し始め、楕円曲線デジタル署名アルゴリズム (ECDSA) の置き換えに使用されました。 Schnorr 署名は、トランザクションとメッセージに効率的かつ安全に署名するデジタル署名スキームです。これは、1991 年の論文で Claus Schnorr によって初めて説明されました。 Schnorr は、そのシンプルさ、証明可能なセキュリティ、および直線性で高く評価されています。
Schnorr 署名の利点:
1) Schnorr 署名には、ECDSA のすべての機能とセキュリティの前提条件を保持しながら、効率性やプライバシーの強化など、複数の利点があります。 Schnorr 署名により、署名サイズが小さくなり、検証時間が短縮され、特定の種類の攻撃に対する耐性が向上します。
2) Schnorr 署名の最も重要な利点は、キーの集約です。これは、複数の署名を、キーの合計に対して有効な 1 つの署名に集約します。言い換えれば、Schnorr を使用すると、複数のパートナーが公開鍵の合計に対して有効な署名を生成できるようになります。署名の集約により、複数の署名者の署名を 1 つの署名に結合できます。
キーの集約により、マルチ署名セットアップからの電子署名は単一パーティのトランザクションからの署名と同じブロック内のスペースを占有するため、トランザクション手数料が削減され、根本的なスケーラビリティが向上します。 Schnorr のこの機能を使用すると、マルチシグネチャ支払いやその他のマルチシグネチャ関連トランザクション (ライトニング ネットワーク チャネル トランザクションなど) のサイズを削減できます。
3) Schnorr 署名のもう 1 つの重要な特徴は、改ざんできないことです。
4) Schnorr はプライバシーに関する多くの利点も提供します。 Schnorr は、マルチ署名スキームを従来の単一の公開鍵と外部から区別できないようにすることで、観察者がオンチェーン アクティビティにおけるマルチ署名の支出と単一署名の支出を区別することをより困難にします。さらに、n-of-m マルチシグ設定では、Schnorr により、外部の観察者がオンチェーン情報を見てどの参加者がトランザクションに署名し、どの参加者が署名しなかったのかを判断することがより困難になります。
Schnorr 署名は、Taproot ソフト フォーク アップグレードの一部として BIP-340 に実装され、2021 年 11 月 14 日にブロック高さ 709,632 でアクティブ化されました。 Schnorr は、BTC のデジタル署名をより速く、より安全に、より簡単に処理できるようにします。特に、Schnorr 署名は BTC の暗号化アルゴリズムと下位互換性があり、ソフト フォーク アップグレードを通じて導入できます。
(2) MAST抽象構文ツリー
中国語と英語の MAST の略語には少し曖昧な点があります。 BIP 公式 (BIP 114) および一部の記事では、MAST の略語が Merklized Abstract Syntax Tree として使用されます。他の一部の資料は、Merclized Alternative Script Tree (MAST) を使用して中国語に翻訳されています。この略語については、書籍「Mastering Bitcoin」および記事で説明されています: https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade。
マークル抽象構文ツリーとマークル化代替スクリプト ツリー (MAST) は機能的に同等であるように見えます。翻訳の観点から、私は個人的に、ビットコインの公式 BIP プロトコルでの使用は維持されるべきだと感じています。
MAST の背後にある概念は、抽象セマンティック ツリーとマークル ツリーという2 つの概念から来ています。
抽象セマンティック ツリー (AST) は、コンピュータ サイエンスにおける編集原理と形式言語学の知識分野に属します。抽象セマンティック ツリーは、コンパイル プロセスの中間表現であり、ソース コードのセマンティック構造を表すために使用されます。ソース コードをツリー構造に変換します。各ノードは意味単位を表し、エッジはノード間の関係を表します。抽象セマンティック ツリーは、コンパイラの字句解析および構文解析の段階で重要な役割を果たし、コンパイラがソース コードの意味を理解し、その後の最適化とターゲット コードの生成を実行するのに役立ちます。平たく言えば、抽象セマンティック ツリー (AST) は、プログラムを独立した小さな部分に分割することによってプログラムを記述する方法であり、これによりプログラムの分析と最適化が容易になります。 AST を生成するには、すべての前提が見つかるまで、すべての方程式とその前提を矢印で接続する必要があります。下の図はスクリプトの AST です。
一方、マークル ツリーは、セット全体を知らなくても、要素がセットに属しているかどうかを検証するために使用できます。たとえば、ビットコインの簡易決済検証ウォレット (SPV ウォレット) は、マークル ツリーを使用して特定のブロックにトランザクションが存在するかどうかを検証します。これにより、ブロック全体をダウンロードする必要がなくなり、帯域幅が節約されます。
マークル ツリーを生成するには、各要素を 1 回ハッシュして独自の一意の識別子を生成する必要があります。その後、これらの識別子をペアリングした後に再度ハッシュして、識別子が 1 つだけ残るまで繰り返します。これは「マークル ルート」と呼ばれ、コレクション全体にラベルを付ける短く簡潔な識別子です。
要素がセットに属していることを確認する場合、セット全体の所有者は、その要素からマークル ルートまでのパス上のすべての識別子を提供できます。これにより、この要素が実際にこのセットに含まれていることを証明できます。
つまり、AST の背後にあるテクノロジーを使用すると、プログラムを小さな部分に分割することができ、マークル ツリーを使用すると、プログラム全体を公開することなく、これらの小さな部分が実際に完全なプログラムの一部であることを検証できます。これは MAST の基本原理であり、消費者は単一の取引で使用されなかった条件をマークル証明を使用して置き換えることができ、取引量の削減、プライバシーの向上、大規模な契約のサポートが可能になります。
インターネット上には、特定の MAST ツリーの例が数多くあります。プログラムの開発方法を知っている人は、MAST プロセスを分類することで関連するロジックを明確にすることができます。
MAST 抽象構文ツリーができたので、ビットコインのネイティブ構文の機能を拡張する必要があるため、Taproot Scripts が生まれました。
(3) タップルートスクリプト
Tapscript スクリプトは BIP 342 プロトコルに含まれています。Taprootscript は、元のビットコイン スクリプトのアップグレードされたバージョンです。これは、実際にはコマンドを含むオペコードのコレクションです。これらのコマンドは、他の 2 つの BIP で使用されます。実装支援。また、Taprootscript は 10,000 バイトのスクリプト サイズ制限を削除し、ビットコイン ネットワーク上でスマート コントラクトを作成するためのより良い環境を提供します。 (Ordinals プロトコルは追加データを実装するために Taproot の script-path 消費スクリプト スクリプトを使用するため、このアップグレードはその後の Ordinals の誕生の基礎も築きました)。詳細情報は公式ウェブサイトでご覧いただけます。
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
現在、TaprootScript の機能は十分に活用されておらず、将来的にはより多くの構築がその能力を反映することになります。たとえば、ビットコインのレイヤー 1 ネットワークとレイヤー 2 ネットワークの間の接続テクノロジでは、Taproot、MAST、および TaprootScript をより頻繁に使用する必要があります。
2.3. 序数、碑文、BRC 20 およびその他の協定
ビットコイン エコシステムでは、Segwit、Taproot、Schnorr、MAST、Taproot Scripts などの基本ツールを使用して、新しいアプリケーションが登場し始めています。最初のアプリケーションは軽量でシンプルなものです。
(1) 序数序列プロトコル、碑文、BRC 20
序数プロトコルの誕生は、sat の概念と深く関連しています。このプロトコルは、序数と碑文の概念を提案しています。序数とは、ビットコイン ネットワーク上の各サトシにマイニングの順序で番号を割り当てる番号付けスキームを指します。このプロトコルでは、sat が異なるウォレット間でどのように転送されても、その順序識別子は変更されません。 Rodarmor オープンソース ソフトウェア ORD を実行するビットコイン フル ノードは、これらの番号付きサトシを追跡できます。これは、人々が各サトシを正確に追跡し、独立して検証するためのメカニズムを提供します。
碑文にはサトシに関する情報が焼き付けられている。 SegWit と Taproot を組み合わせることで、Ordinals プロトコルは、サトシごとに 4 MB 未満のファイル、つまり碑文をビットコイン ブロックに書き込むことができます。碑文には、テキスト、写真、ビデオなど、さまざまな形式の情報を含めることができます。下の写真はサンプル碑文のスクリーンショットです。
簡単に言えば、順序番号付けスキームは各サトシに一意の追跡可能な番号を提供し、サトシを非同質なものにします。碑文は、白紙の紙にアートを作成するのと同様に、分割できないデータ情報を序数に追加できます。この 2 つの組み合わせにより、ビットコインに新しい NFT 標準が与えられます。 Ordinals の本質は実際には非常に単純ですが、ほとんどが IPFS または集中サーバーに保存される ETH や他のパブリック チェーンの NFT メタデータ (MetaData) とは異なり、Ordinals のメタデータは次のように埋め込まれます。証人フィールド（証人データ）は、特定の人物に「刻印」されるようなもので、これが碑文の語源でもあります。
BRC-20: Ordinals プロトコルに触発されて、Twitter ユーザー @domodata は、2023 年 3 月 8 日にビットコインの実験的な代替トークン標準 BRC-20 を作成しました。 Ordinalsプロトコルは各サトシに異なる「属性」を与えることでBTCネットワークNFTを作成しますが、BRC-20は均一なトークンである統一された「フォーマット」と「属性」を与えることでBTC上にFTを作成します。
BRC-20 は、Ordinals プロトコルを介して JSON テキストを BTC 碑文に書き込み、トークン コントラクトをデプロイし、トークンを生成および転送します (Depoly、Mint、Transfer)。デプロイメントの鍵は、トークン名、総供給量、および単一の最大値にあります。鋳造量。転送または売買取引の場合、オフチェーン残高を追跡するために追加の NFT が刻印されます。 「先着順」の鋳造メカニズムは公平な発行と参加の機会をもたらしますが、同時に、BTC の生態学的インフラストラクチャーが比較的不完全であるため、一定の学習しきい値と低い流動性が存在し、そのため BRC-20 トークンの発行が可能になります。 、ordi、sats、rat、その他の BRC 20 トークンは容易に宣伝され、富創造神話の波を引き起こしました。
(2) その他のプロトコル - Atomics、ARC 20
Atomics プロトコルの誕生は非常に劇的でした。Ordinals プロトコルが最初にリリースされたとき、創設者の Arthur は、その上に DID プロジェクトを開発したいと考えていました。しかし、開発プロセス中に、Ordinals プロトコルには多くの制限があることに気づきました。彼が達成したいと思っていた機能をサポートするのに役立ちました。そこで、2023 年 5 月 29 日に、アーサーは Atomicals プロトコルのアイデアに関する最初のツイートを Twitter に投稿しました。数か月の開発を経て、2023 年 9 月 17 日に Atomicals プロトコルが開始されました。その後、Atomics プロトコルは Dmint、Bitwork、ARC-20、RNS という 4 つの主要な概念を導き出し、将来的には AVM やスプリット ソリューションが登場する予定です。
Ordinals や BRC 20 と同様に、Atomics に代替可能トークンをデプロイすると ARC 20 が形成されます。 ARC 20 に興味のある読者はさらに読んでください。
https://docs.atomicals.xyz/arc20-tokens
(3) その他のプロトコル - Rune
この開発に伴い、Ordinals の創設者 Casey Rodarmor は、BRC-20 トークンには「UTXO の普及による望ましくない結果」があると述べた記事を発表し、UTXO ベースの代替手段として Runes を提案しました。さまざまな既存のプロトコルは一般に、複雑なプロトコルの実装、質の悪いユーザー エクスペリエンス、ガベージ未使用トランザクション出力 (UTXO)、操作用のネイティブ トークンの必要性などの問題を抱えています。
ルーンは OP_RETURN を使用して転送され、プロトコル メッセージの最初のデータ出力は一連の整数にデコードされ、一連の (ID、OUTPUT、AMOUNT) タプルとして解釈されます。デコードされた整数が 3 の倍数でない場合、プロトコル メッセージは無効です。 ID は転送されるトークン ID、OUTPUT は割り当てられる出力インデックス (つまり、どの出力に割り当てられるか)、AMOUNT は割り当てられる実行量です。すべてのタプルの割り当てが処理された後、未割り当てのルーン トークンは最初の非 OP_RETURN 出力に割り当てられ、残りのルーン トークンは、プロトコル メッセージを含む OP_RETURN 出力にルーン プロトコルを割り当てることで焼き付けることができます。
ルーンの発行: UTXO ベースの同種トークン追跡。プロトコル メッセージに 2 番目のデータ プッシュがある場合、それは発行トランザクションです。 2 番目のデータ プッシュは 2 つの整数、SYMBOL、DECIMALS にデコードされます。他に整数が残っている場合、プロトコル メッセージは無効です。 SYMBOL は、序数名で使用されるものと同様の人間が判読できる基本的な 26 ビット記号で、現在有効な文字は A から Z のみです。 DECIMALS は、ルーンを表示するときに使用する小数点以下の桁数です。 SYMBOL が割り当てられていない場合、ルーン トークンには ID 値 (1 から始まる) が割り当てられます。 SYMBOL がすでに割り当てられている場合、または BITCOIN、BTC、または XBT である場合、新しいルーンは作成されません。これは Runes プロトコルの特別な機能です。残高レコードをウォレットのアドレスにリンクする代わりに、UTXO 自体にレコードを配置します。
新しいルーン トークンは発行トランザクションから始まり、供給、符号、スケールを指定し、その供給を特定の UTXO に割り当てます。サイズに関係なく、任意の数のルーン トークンを UTXO に含めることができます。 UTXO は残高を追跡するためにのみ使用されます。次に、転送関数はその UTXO を使用し、さまざまな数のルーンを含む任意のサイズの複数の新しい UTXO に分割して、レコードを他の人に送信します。 BRC-20と比較して、Runesはサーバーコンセンサス層を削減し、よりシンプルになります。同時に、オフチェーンデータに依存せず、ネイティブトークンを持たないため、ビットコインのネイティブUTXOモデルに非常に適しています。
(4) その他のプロトコル - BTC スタンプ、SRC 20、SRC 721
ビットコイン スタンプ システムは、2023 年 3 月に Mike In Space によってリリースされ、Counterparty (2014 年から存在するビットコイン L2) の概念実証プロジェクトとして始まりました。スタンプは、現在 SRC-20 として知られる基礎となるプロトコルのアップデートにより、昨年夏にビットコインに完全に移行しました。創設者のマイクは当初、恒久的なビットコインNFTを鋳造する方法としてスタンプを構想していました。ただし、このプロトコルは、Casey Rodarmor が 2023 年 1 月に Ordinals を立ち上げて以来、碑文ブームのおかげでビットコインで繁栄したバッチ代替可能なトークンである BRC-20 を複製するために拡張されました。
Stamps と Ordinals の主な違いはアーキテクチャです。これは、スタンプはメタデータをマルチシグネチャの未使用トランザクション出力 (UTXO) に保存するのに対し、オーディナルはメタデータをビットコイン トランザクションの「監視」部分に保存するためです。この設計の違いは、開発者の選択を示しています。そうは言っても、スタンプの UTXO メソッドではスタンプはトリム不可能なので、永続的であるように見えますが、オーディナルのキャストよりも作成コストが高くなります。代わりに、Ordinal が証人データを使用する方法により、最終的には枝刈りが可能になり、Stamp よりも作成コストが低くなります。
そのため、Ordinals は今日の暗号通貨における NFT の永続性とコストの比率で最高のパフォーマンスを提供する可能性がありますが (オンチェーン NFT はイーサリアムでも利用できますが、Ordinals よりも構築コストが相対的に高くなります)、Stamps は現在最高の Best Direct を提供しているようです。永久保証。
BTC スタンプの生成後、SRC 20 と SRC 721 が生成され始めました。原理は BRC 20 と同様です。 BRC-20 は Ordinals プロトコルに基づいて構築されており、SRC-20 は BTC STAMPS に基づいて構築されています。興味のある読者は、SRC 20 および SRC 721 に関連するドキュメントをさらに読むことができます。
https://docs.openstamp.io/introduction/src20-protocol
https://docs.openstamp.io/introduction/src721-protocol
この時点で、第 1 層ネットワーク上のビットコインの重要な新技術が導入されました。その後の拡張と容量拡張に関しては、ビットコインのレイヤー 2 などのビットコインの上位レイヤー機能や、ライトニング ネットワークの助けを借りて実装された RGB などの上位レイヤーに依存するようになりました。この分野の記事については、「ビットコインの第二層（レイヤー2）構築のための基礎知識体系を整理する一記事 V1.5」と「ビットコインの第二層をステートマシンの視点から観察する、将来の Web3.0 アプリケーションのアーキテクチャと構築パス」、またはビットコインの第 2 層構築またはアーキテクチャ設計に関するその他の記事をご覧ください。
3. 新技術の活用方法と今後必要となる開発
セクション 2 の内容を通じて、ビットコイン エコシステムの技術開発が大規模なアプリケーションの基礎を築いたことがわかります。しかし、開発にはプロセスが必要であり、一部の関連技術が未成熟であるため、現在普及しているアプリケーションと最終的に一般的なアプリケーションの間には依然として大きな差があります。
3.1. 新しいテクノロジーの使用方法
前の 2 つのセクションから、ビットコイン テクノロジーの開発は本質的にブロックと機能の拡張であることがわかります。
ブロック拡張に関しては、Segregated Witness が事実上のブロック拡張につながりましたが、証人部分を切り離すさまざまな提案がありますが、特に証人部分にさらなる意味が与えられた後では、これが起こる可能性は低いでしょう。
拡張機能の点では、Taproot、Schnorr、MAST、Taproot Scripts などのテクノロジーにより、ビットコインにさらなる機能が与えられています。特に、MAST+Taproot スクリプトはビットコインのネイティブ スクリプト言語の機能を拡張し、他のいくつかのテクノロジーは複雑なシナリオを処理するビットコイン言語の機能を拡張します。ただし、これらの機能の拡張により、結局のところ、これらのスクリプト開発は高級言語ではなく、ビットコインの開発と理解がさらに困難になります。そして、この部分の機能の拡張は、ユーザーのブロック容量拡張の理解と学習の速度よりも遅れることになります。
ブロックを使用して拡張するのは簡単ですが、機能を使用して拡張するのは複雑であるため、ユーザーは最初にこれらの小さな画像NFTをビットコインのメインネットワークに書き込み、BRC 20のようなアプリケーションが作成されました。現在ビットコインメインネット上のさまざまなアプリケーションは、ほぼすべてブロック拡張後のアプリケーションを検討しています。たとえば、BEVM の第 1 層と第 2 層の接続は、少数のアプリケーションが容量拡張を検討し始めていますが、そのほとんどは上記の基本要素で構築された機能を使用しています。ビットコイン ライト ノード ネットワークの Shnorr 署名 + MAST コントラクト + BTC L2 ソリューションは、第 1 層と第 2 層の接続を学習するのに適した例です。今後も容量を拡張するケースは増えるだろう。
容量拡張の境界はどこにあるべきでしょうか?レイヤードデザインの観点から判断すると、これらの機能拡張がビットコインの第 1 層と第 2 層の間の接続技術である場合、機能拡張はそれほど複雑になる必要はありません。しかし、私たちの豊かな創造性と資産発行と管理の強力な魅力に基づいて、一部のチームまたは個人は、容量拡張シナリオのより多くのケースを検討するでしょう。
3.2. 今後の開発ニーズ
ブロックチェーン技術の出現の最も直接的な理由はデジタル通貨であるため、ビットコインやブロックチェーンの分野では資産の発行や資産管理などのアプリケーションが最も直接的なニーズとなります。カラーコインの探求からBRC 20やARC 20などのアプリケーション、あるいはICO、IDO、その他イーサリアム上のアプリケーションに至るまで、それらはすべて資産発行を模索しています。 Uniswap、Lending、AMM はすべて、イーサリアムなどのネットワーク上で成熟して開発されており、これらの資産管理アプリケーションはビットコイン エコシステムに移行される必要があります。ビットコインの第二層。
資産の発行と資産管理のニーズが満たされて初めて、Web3.0 時代 (バリュー時代とも呼ばれます) に属する大規模なアプリケーションを開発するためのエネルギーと時間が生まれます。将来の Web3.0 時代の大規模アプリケーションのシステム アーキテクチャについては、「ステート マシンの視点からビットコイン レイヤ 2 を観察すると、将来の Web3.0 アプリケーションのアーキテクチャと構築パスが見えてきます。」に関連した記述があります。
建設の道はニーズに応え続けるプロセスであり、短期、中期、長期の3段階に分けられます。短期的には、ビットコインメインネット上の新技術によって生成されたアプリケーションと、チェーンに基づく第 2 層の構築を通じて、さまざまな金融アプリケーションに対応するための主要な容量拡張が完了する単純な段階です。中期的には、チェーンベースの第2層構築と分散システムベースの第2層構築により、さまざまな金融アプリケーションや信託アプリケーションに対応できるようになります。長期的には、本当の Web3.0 時代の構築を完了するためのビットコイン エコシステムの大規模な構築に基づいています。
参考説明
(1) ABCDE調査レポート「[ABCDELabs]: ビットコインの過去、現在、未来」
(2) https://en.bitcoin.it/wiki/Script
(3) https://en.bitcoin.it/wiki/Segregated_Witness
(4) https://en.bitcoin.it/wiki/Taproot_activation_proposals
(5)「分離立会人（分離立会人）の超徹底解説」、 https://blog.csdn.net/t46414704152abc/article/details/105638788
(6) 「疑問点の解説：ビットコインのメルケル化抽象構文木とは何ですか？」 》、 https://baijiahao.baidu.com/s?id =1709873918363821702
(7) https://github.com/bitcoin/bips
(8) https://bitcoinops.org/en/topics/tapscript/
