Bitcoinの急騰につながった新しい技術的な進展の概要

初級編4/29/2024, 1:25:25 AM
この記事は、ビットコイン技術の開発史について詳細に探求しており、特に大規模なアプリケーションや取引規模を扱う際の課題に焦点を当てています。記事では、ビットコインの元の技術の制約について分析し、UTXOモデル、チューリング完全でないスクリプト言語、ビットコインのフォークの歴史と理由などが挙げられています。その後、記事では、OP_RETURN、SegreGate.iod Witness(Segwit)、Taprootテクノロジー、Schnorr署名、MAST、Taproot Scriptsなど、ビットコインの開発におけるいくつかの重要な技術について詳細に紹介しています。また、記事ではOrdinals、Inscriptions、BRC-20などの新しいビットコインベースのプロトコルや、それらがビットコインエコシステムの発展を促進する方法についても議論しています。最後に、記事では新しい技術の潜在的な応用と将来の発展への可能性の影響についても取り上げています。

ビットコインの元の技術の主な探求と衝突

ビットコインのオリジナルの技術は、常に普及性と持っているべき機能との間での対立に直面してきました。スケーリングと取引量は、より複雑な取引コマンドや大きな取引スペースを意味するのでしょうか?すべての機能を単一のビットコインシステムで実装する必要があるということでしょうか?ビットコインのエコシステム技術の開発が未完了だった初期には、これらの問題はビットコインそのものに固有のもののように思えました。しかし、技術が進歩するにつれ、これらの問題の多くが明確になってきました。

この記事では、それらが発生し対処された過程とともに、関連する問題のいくつかを列挙しています。この記事を通じて、これらの問題と技術との関連性、およびBitcoinのメインチェーンと関連する「テストチェーン」の変化を見ることができます。Bitcoinの技術は、さまざまなプロジェクトやチーム(Bitcoinの欠陥の探求であるEthereumを含む)によって継続的に探求されてきました。しかし、Taprootなどの技術の出現まで、Bitcoinのメインネットでの変更はあまり顕著ではありませんでした。これにより、Ordinalsなどのプロトコルの開発を促進し、開発の急騰をもたらしました。

より広い観点から、これらの進展とそれらが生み出した技術を見ると、そのつながりを見て、さらなる展開や全体的なアーキテクチャの方向性を推測することができます。

1.1 ビットコインのスクリプト言語といくつかの命令削減

ビットコインのプログラミング言語は、逆ポーランド記法を使用したスタックベースのスクリプト言語であり、ループや条件付き制御文がないため(後の拡張機能であるTaproot&Taproot Scriptなどがこの機能を強化しています)、ビットコインのスクリプト言語はチューリング完全ではないとよく言われており、その能力が制限されています。

これらの制限のため、ハッカーはこのスクリプト言語を使用してネットワークを麻痺させる無限ループを書くことはできず、またDOS攻撃につながる可能性のあるコードを書くこともできません。したがって、BitcoinネットワークをDOS攻撃から守ることができます。Bitcoinの開発者はまた、特定の攻撃やネットワークの混雑を避けるために、コアブロックチェーンにチューリング完全性を持たせるべきでないと考えています。

ただし、これらの制限は、ビットコインネットワークが他の複雑なプログラムを実行したり、一部の「有用な」機能を実行したりすることができないことを意味します。特定の問題を解決し、ユーザーのニーズを満たすために開発された後続のブロックチェーンシステムがこの側面を変えました。たとえば、Ethereumが使用する言語はチューリング完全です。

Bitcoinスクリプト命令の一般的なタイプには、次のものがあります:

キーワード:

  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_1ADD(入力に1を追加)、OP_1SUB(入力から1を引く)

  7. 暗号化。例:OP_SHA1(SHA-1アルゴリズムで入力をハッシュ化)、OP_CHECKSIG

  8. 疑似キーワード

  9. 予約されたキーワード

Bitcoinスクリプトの一般的なタイプ:

  1. ビットコインアドレスに支払う標準トランザクション(支払い先公開鍵ハッシュへの支払い)

  2. 標準的なビットコイン鋳造トランザクション(公開鍵への支払い)

  3. 証明可能な未使用可能/削減可能な出力

  4. 誰でも使える出力

  5. パズル取引

5つの標準的なトランザクションスクリプトの種類には、公開鍵ハッシュへの支払い(P2PKH)、公開鍵への支払い、マルチシグ(最大15個のキーまで)、スクリプトハッシュへの支払い(P2SH)、およびデータ出力(OP_RETURN)が含まれています。

Bitcoinスクリプトに関する詳細情報については、以下をご覧ください: Bitcoin Wiki - スクリプト.

ビットコインのサポートされる命令の削減

歴史的に、Bitcoinはサポートされる命令を何度か削減してきました。次のチャートでは、赤い部分が削除された命令です。

  • 文字列操作

(2)

(3) 算術演算

指示を削減する理由は何ですか?セキュリティは考慮すべき要素の一つにすぎません。指示の削減を層状の設計の観点から見ると、基本プロトコルをより基本的で安定したものにする合理性が理解できます。おそらくサトシ・ナカモトはこの問題に初めから気づいていたため、積極的に指示を削減しました。一般的な考え方は、完全なコマンドとシステム機能を備えた小規模なシステムを構築することで、協力が必要な大規模なプロトコルではなく、ユーザーのニーズを直接満たすものです。

これはまた、事実につながります: 最初のレイヤーネットワークとして適しているのはビットコインだけです。私はこの現象を「高いビットコイン価格が新しい代替チェーンの出現を促す可能性について」の記事で分析し、経済的および技術的観点、およびビットコインの代替チェーンの出現の可能性を考慮しました。ただし、ビットコインの基本的な特性とレイヤー設計の観点から、ほとんどビットコインしか第1レイヤーネットワークインフラストラクチャとして機能できません。代替チェーンがあっても、それらは1.5レイヤープロダクトになります。第1層のレベルでは、本物のものはビットコインだけであり、最高で他のチェーンは質の劣る代替品として機能できます。

1.2. ビットコインフォークの歴史、理由、および重要性

ビットコインの開発史において、命令の削減の問題に加えて、もう一つの側面はブロックサイズの議論であり、これはしばしばビットコインのハードフォークを引き起こすことがあります。

BTCが確立された当初、同じ時間枠内で一定数の取引を処理するためのブロックサイズ制限はありませんでした。しかし、初期のBTC価格が非常に低かったため、悪意のある取引のコストも非常に低かったです。この問題に対処するために、Satoshi Nakamotoは2010年9月12日にソフトフォークを主導し、ブロックのサイズが1MBを超えることができない制限を導入しました。Satoshiはこの制限が一時的であり、将来的にはブロックの制限を管理された段階的な方法で拡大することができると述べています。

Bitcoinの人気が高まるにつれて、ネットワークトランザクションの混雑と確認時間の増加という問題が深刻化しています。2015年、Gavin AndresenとMike Hearnは、BitcoinXTの新バージョンでBIP-101提案を実装すると発表し、ブロックサイズの上限を8MBに引き上げることを期待していました。しかし、Greg Maxell、Luke Jr、Pieter Wuilleなどのコア開発者はこれに反対し、フルノードの運用の障壁が上がり、制御できない影響がある可能性があると主張しました。この議論は最終的に範囲と参加者が拡大しました。

上記の内容から、Satoshi Nakamotoも「ブロックサイズの制限は拡張の必要性を満たすために将来制御されたかつ徐々に増加させることができる一時的な制約である」と述べていることがわかります。しかし、いつフォークがより大きなブロックをサポートし、大きなブロックをサポートするために別のチェーンを分割することで問題を解決できるのでしょうか?継続的な論争の中で、多くの事例が浮上しています。たとえば、BCHのブロックサイズは8 MBで、後に32 MBに増加しました。BSVのブロックサイズは128 MBです。BCH(後にBSVも)以外にも、この期間には多くの他のBTCのフォークが見られました。BitMEXResearchによると、BCHのフォークの直後の1年間で少なくとも50種類の新しいフォークコインが登場しました。

後のコンテンツでは、ビットコインのメインネット上で、SegwitとTaprootがブロックサイズをある程度1MBから4MBに拡大させたことも示されます。

ビットコインのフォークは、ユーザー、マイナー、投資家、開発者などのニーズを含む、自らの変化を通じてより幅広いニーズに応えようとする開発探索の一形態です。

1.3. ビットコインの開発におけるいくつかの典型的な探求

サトシ·ナカモトが去った後、彼の後継者であるギャヴィン·アンドレセンがビットコインコアとビットコイン財団の設立を主導しました。この期間中、特に資産発行の分野でBTCのスケーラビリティに関する探究が続きました。

(1)カラードコイン(染色币)

eToroのCEOであるYoni Assiaは、2012年3月27日に発表された記事で、着色コインの概念を初めて提案しました。このアイデアは着実に進化し、Bitcointalkなどのフォーラムで注目を集め始めました。最終的に、Meni Rosenfeldが2012年12月4日に着色コインに関する詳細なホワイトペーパーを公開しました。

Colored coinsの背後にある考えは、ビットコインの特定の部分に特別なマーキング(つまり、着色)を追加することによって、より広範囲の資産や価値を表現することです。実装では、Colored coinsはいくつかのエンティティで登場しており、大まかに2つのカテゴリに分かれています。

1) OP_RETURNに基づいて: Flavien Charlonが2013年に提案したように、Open Assetsを使用して、OP_RETURN(Bitcoin v0.9.0で導入された、元々40バイトに制限されていたデータをBitcoinに格納するための80バイトに後で増やされた)を利用します。オペコードはスクリプトに格納され、外部読み取りによって「色付け」およびトランザクションが完了します(このモデルは外部インデックスに依存し、資産の合法性を決定するためにOrdinalsに類似しています)。

2) OP_RETURNに基づいて: 典型的な例は、2014年にChromaWayによって提案されたEPOBCプロトコルで、EPOBC資産の追加情報がBitcoin取引のnSequenceフィールドに格納され、各EPOBC資産のカテゴリと合法性を決定するためには、それらが起源取引にさかのぼって追跡される必要があります。

(2) MasterCoin (OMNI)

JRウィレットは2012年1月6日にMasterCoinのコンセプトを発表し、「2番目のBitcoinホワイトペーパー」と名付け、2013年7月にICOを通じてプロジェクトを正式に開始し、最終的に5120BTC(当時50万ドル相当)を調達しました。 MasterCoinとColored Coinsの違いは、Bitcoinブロックをスキャンして状態モデルデータベースを維持する完全なノードレイヤーを確立したことにあり、これはブロックチェーンの外部にあるノードに存在します。 この設計により、Colored Coinsよりも新しい資産の作成、分散型取引所、自動価格フィードバックメカニズムなど、より複雑な機能が提供されます。 2014年には、TetherもMastercoinプロトコルを介してTether USD(OMNI)として知られるステーブルコインをBitcoin上に発行しました。

(3) CounterParty

Counterpartyは2014年に正式に開始されました。Colored Coinsのように、CounterpartyもBTCネットワーク内にデータを格納するためにOP_RETURNを使用しています。しかし、Colored Coinsとは異なり、Counterpartyの資産はUTXOの形式で存在せず、代わりに情報がOP_RETURNを介して読み込まれ、資産の移転が示されます。資産保有者が保有アドレスを使用して特別なデータを含む取引に署名すると、資産が移転されます。この方法により、Counterpartyは資産の発行、取引、およびEthereumスマートコントラクトと互換性のあるプラットフォームを実装できます。

さらに、一部の見解では、イーサリアム、リップル、およびBitSharesも広い意味での「Bitcoin 2.0」の一部と見なされています。

1.4 ビットコインと階層プロトコルの不完全性

Bitcoinの不完全さ(または制限)は、主にいくつかの側面で表れています(この記事で言及されている不完全さは、イーサリアムのホワイトペーパーの要約に基づいており、必ずしも真の欠陥とは限りません)。

  1. ビットコインのUTXOアカウントシステム

現在のブロックチェーンプロジェクトでは、主に2種類の記録方法があります: アカウント/残高モデルとUTXOモデル。ビットコインはUTXOモデルを使用しており、一方、イーサリアム、EOS、その他はアカウント/残高モデルを使用しています。

ビットコインウォレットでは、通常、口座残高を確認できますが、ビットコインシステムの原設計者であるサトシ・ナカモトの元の設計では、「残高」という概念は存在しませんでした。 「ビットコイン残高」は、ビットコインウォレットアプリケーションの派生です。 UTXO(未使用取引出力)は未使用の取引出力を表し、ビットコイン取引の生成および検証における中核的概念です。 取引は鎖のような構造を形成し、すべての正当なビットコイン取引は、1つまたは複数の以前の取引からの出力にさかのぼることができます。 これらの鎖は採掘報酬で始まり、現在の未使用取引出力で終わります。

したがって、現実世界にはビットコインは存在せず、UTXOのみが存在します。ビットコイン取引は取引の入力と出力から成り立ちます。各取引は入力を消費して出力を生成し、それが「未使用取引出力」またはUTXOとなります。

スマートコントラクトの実装は、UTXOモデルにおいて重要な課題を抱えています。Ethereum Yellow PaperのデザイナーであるGavin Woodは、UTXOについて深い理解を持っています。Ethereumの最も重要な新機能はスマートコントラクトです。スマートコントラクトのため、Gavin WoodにとってUTXOに基づいたチューリング完全なスマートコントラクトを実装することは難しいです。それに対して、アカウントモデルは本質的にオブジェクト指向であり、それぞれのトランザクションを対応するアカウント(nonce++)に記録します。アカウント管理を容易にするために、各トランザクションがこのグローバルステートを変更するように導入されており、これは毎回の小さな変更が実世界に影響を与えるのに類似しています。したがって、Ethereumおよびその後の公共ブロックチェーンは、一般的にさまざまな種類のアカウントシステムに基づいています。

UTXOのもう一つの重大な欠陥は、口座の引き出し限度額に細かい制御を提供できないことであり、これはEthereumホワイトペーパーで議論されています。

  1. ビットコインのスクリプト言語、チューリング完全ではない

ビットコインのスクリプト言語はさまざまな計算をサポートできますが、すべての計算をサポートすることはできません。主な欠落点は、ビットコインのスクリプト言語にはループ文や条件付き制御文が欠けていることです。したがって、ビットコインのスクリプト言語はチューリング完全ではなく、その機能が制限されています。ただし、これらの制限により、ハッカーがこのスクリプト言語を使用して無限ループ(ネットワークを麻痺させる可能性がある)やDOS攻撃につながる悪意のあるコードを作成することが防がれ、これによりビットコインネットワークがDOS攻撃から保護されています。ビットコインの開発者たちはまた、コアブロックチェーンが攻撃やネットワーク混雑を防ぐためにチューリング完全であってはならないと考えています。ただし、非チューリング完全言語が安全である理由は十分ではなく、そのような言語は限られた機能しか実行できません。

  1. ビットコインの他の欠陥:セキュリティ、スケーラビリティ

マイニングの中央集権化は問題で、ビットコインのマイニングアルゴリズムは基本的にマイナーにブロックヘッダーを何百万回も微調整させて、ノードの変更されたバージョンのハッシュが目標値よりも小さくなるまで続けさせます。このマイニングアルゴリズムは中央集権攻撃の2つの形態に対して脆弱です。まず、マイニングエコシステムはASIC(Application-Specific Integrated Circuits)やビットコインマイニングのために特別に設計されたコンピュータチップによって制御されており、このタスクにおいて何千倍も効率的です。これは、ビットコインのマイニングが高度に分散化され、平等であるわけではなく、効果的な参加には相当な資本が必要とされることを意味します。次に、ほとんどのビットコインのマイナーはもはやブロックの検証をローカルで行わず、代わりに中央集権的なマイニングプールにブロックヘッダーを提供するようになっています。この問題は重要です。現在、トップ3のマイニングプールがビットコインネットワーク内の処理能力の約50%を間接的に制御しています。

ビットコインの拡張性は重要な問題です。ビットコインを使用すると、データは1時間あたり約1MB増えます。ビザのようにビットコインネットワークが1秒あたり2000取引を処理した場合、3秒ごとに1MB増えるため(1時間あたり1GB、1年あたり8TB増えます)。取引数が少ないことはビットコインコミュニティ内で論争を引き起こしており、大きなブロックチェーンはパフォーマンスを向上させる一方で、中央集権化のリスクがあります。

製品ライフサイクルの観点から、ビットコインの一部の軽微な欠陥は、現行のシステムによって制約されているが、そのシステム内で改善される可能性がある。ただし、これらの問題は、新しいシステムで対処される場合、古いシステムの制約を考慮しないで解決できる。新しいブロックチェーンシステムが開発されている場合、これらの軽微な機能的改善も設計およびアップグレードされるべきである。

Layered Design

レイヤー設計は、複雑なシステムを扱うために人間が使用する方法論および手法であり、システムを複数の階層構造に分割し、これらのレイヤー間の関係や機能を定義してシステムのモジュール性、保守性、拡張性を実現し、それによってシステムの設計効率と信頼性を向上させる。

広範囲かつ包括的なプロトコルシステムを使用する場合、層を使用することには明らかな利点があります。このアプローチにより、人々が理解しやすくなります。

,実装し、モジュールを改善します。たとえば、コンピューターネットワークでは、ISO/OSIモデルは7層の設計ですが、実際には、4層のTCP/IPプロトコルのように、いくつかの層を組み合わせることができます。プロトコル層の特定の利点には、各層の独立性と柔軟性、構造的な分割性、実装および保守の容易さ、標準化の取り組みの促進が含まれます。

レイヤードプロトコルの観点から見ると、Bitcoinの基盤レイヤーとしての位置付けは、UTXO、非チューリング完全性、長いブロック時間、小さなブロック容量、創設者の消失などの特性は、欠点ではなく、むしろ基本的なネットワークレイヤーが持つべき特性であるということを意味します。

注意: この著者は、「ビットコインレイヤー2(レイヤー2)構築基本知識システムV1.5の概要」でプロトコルの階層化について詳細な説明を提供しています。

2. ビットコイン開発の重要な新技術(ブロック拡張と機能強化)

前のセクションでは、元のビットコイン技術の主な葛藤といくつかの探索的ケースを探求しました。その多くはハードフォークやまったく新しい異種チェーンの作成につながりました。ただし、ビットコイン自体のブロックチェーン内では、これらの探求も多くの成果をもたらしました。主にブロックの拡張と機能の向上の形で基本的に表れています。これらは主に以下の側面で現れます:

2.1. OP_RETURN

ビットコインの開発者は常にビットコインの機能を拡張しようと努力しており、それはいくつかの方法で表れています。

(1) OP_RETURNの使用

OP_RETURNは、スクリプトを終了し、スタックのトップ値を返すために使用されるスクリプトオペコードです。このオペコードは、プログラミング言語のreturn関数に類似しています。 Bitcoinの歴史を通じて、OP_RETURNオペコードの機能は複数回変更されており、現在は主に台帳にデータを保存する方法として使用されています。 OP_RETURNオペコードの機能は過去に大きな変更を経ており、現在ではチェーン上に任意のデータを保存するための重要なメカニズムとなっています。

初めに、OP_RETURNはスクリプトの実行を早めに終了させるために使用されました。実行結果はトップスタックアイテムとして表示されます。このオペコードには初めは簡単に悪用できる脆弱性がありましたが、サトシ・ナカモトが迅速に修正しました。

OP_RETURN機能へのさらなる変更

Bitcoin Core v0.9.0へのアップグレードでは、「OP_RETURN出力」スクリプトが標準出力タイプに変更され、ユーザーが「使用できないトランザクション出力」にデータを追加できるようになりました。このようなスクリプトで利用可能なデータ容量は当初40バイトに制限されていましたが、後に80バイトに増加しました。

ブロックチェーン上でのデータの保管:

OP_RETURNを常にfalseに変更すると、興味深い結果がもたらされました。OP_RETURNの後に他のオペコードやデータが評価されないため、ネットワークユーザーはこのオペコードを使用して任意の形式でデータを格納するようになりました。

ビットコインキャッシュ(BCH)時代、2017年8月1日から2018年11月15日まで、OP_RETURN出力に添付できるデータ長が220バイトに拡張され、ブロックチェーン上でコンテンツを投稿するなど、より重要なデータを許容し、革新的なアプリケーションを育成することが可能となりました。

BSVでは、220バイトの制限が短期間で維持されました。その後、2019年1月に、OP_RETURNオペコードがスクリプトを終了させるため、ノードはその後のオペコードを検証しないため、ノードもスクリプトが最大スクリプトサイズ制限の520バイト以内であるかどうかをチェックしませんでした。その結果、ネットワークノードオペレーターは最大取引量を100KBに増やすことを決定し、開発者にアプリケーションイノベーションのためのより多くの自由を与え、新しいアプリケーションがビットコイン台帳により大きく、より複雑なデータを配置することが可能となりました。当時、BSV台帳にウェブサイト全体を収めた例もありました。

OP_RETURNにはいくつかの機能拡張がありますが、その全体的な機能はまだ限られています。これがセグリゲーテッドウィットネスの技術につながりました。

(2) SegWit(セグウィットネス)

Segregated Witness、またはSegWitは、Pieter Wuille(Bitcoinのコア開発者およびBlockstreamの共同創設者)によって2015年12月に初めて提案され、後にBitcoin BIP 141となりました。SegWitは、Bitcoinブロック内の取引データ構造をわずかに変更して、以下の問題に対処します。

1) トランザクション改竄問題。

2) SPVプルーフでは、送金トランザクションの署名の転送が任意となり、Merkleプルーフのデータ量が削減されます。

3) ブロック容量を間接的に増やす。

最初の2つのアイテムは主にセキュリティとパフォーマンスを向上させ、新技術に最も影響を与えるのは3番目のアイテムで、これは間接的にブロック容量を増やし(以下、ブロックウェイトの概念を参照)、Bitcoinの機能強化の基盤を築き、Taproot(Segregated Witnessの第2バージョン)のさらなる強化につながった。

実現がブロック容量を増加させましたが、SegWitはまだブロックサイズの制限の対象です。 Bitcoinのブロックサイズ制限は1 Mバイトであり、証人データがこの制限に含まれていないため、証人データの乱用を防ぐために、合計ブロックサイズに制限があります。 ブロックウェイトという新しい概念が導入されました:

ブロック重量=ベースサイズ*3+合計サイズ

ベースサイズとは、証人データを除いたブロックサイズのことです

総サイズは、ベースデータとウィットネスデータの両方を含む、BIP 144に従ってシリアル化された合計ブロックサイズです。

SegWitはブロックの重量を4 M以下に制限します。

SegWitは技術的にもビットコインの拡張を可能にし、ここでは詳細には触れませんが、ライトニングネットワークの利用も可能にしています。

(3) Taproot (セグリゲーテッドウィットネスV2)

直接Taprootという言葉を使うと、多くの人が新しい概念だと思うかもしれませんが、それがSegregated Witnessの第2版であることを理解すれば、多くの人がその関連性を把握するでしょう。 TaprootはBIP 340、341、342に関連しており、それぞれBIP 340(secp256k1用のSchnorr署名)、BIP 341(Taproot:SegWitバージョン1の支出ルール)と名付けられています。

BIP 342 (Taprootスクリプトの検証)。

2021年11月、Taprootはソフトフォークとして正式にアクティブ化されました。このアップグレードは、BIP 340、BIP 341、およびBIP 342を組み合わせています。その中で、BIP 340はSchnorr署名を導入し、複数のトランザクションを同時に検証できるようにしました。これにより、楕円曲線デジタル署名アルゴリズム(ECDSA)を置き換え、ネットワーク容量を再度拡大し、バッチトランザクションの処理を高速化し、複雑なスマートコントラクトの展開に可能性を提供します。BIP 341は、ブロックチェーン上のトランザクションデータの格納を最適化するためにMerklized Abstract Syntax Trees(MAST)を実装します。BIP 342(Tapscript)は、Bitcoinのスクリプトエンコーディング言語を使用してBitcoinのネイティブスクリプト機能を強化します。

SegwitとTaprootによるスペース拡張により、Schnorr署名、MASTツリー、Taprootスクリプトが生み出され、その使命はBitcoinメインネットの機能拡張です。

2.2 Schnorr Signatures、MAST、およびTaproot Scripts

セクション2.1から、我々はBitcoinのスケーリングと機能強化の進行を観察し、Schnorr、MAST、Taproot Scriptsなどの重要な技術とともにTaproot技術の開発によって、Bitcoinの機能が本当に拡大されました。

(1) Schnorr 署名

Taprootの進化は、機能を拡張する一方で、署名アルゴリズムから特定の要求を必要とし、それにより、楕円曲線デジタル署名アルゴリズム(ECDSA)を置き換えるためにSchnorr署名が導入されました。Schnorr署名は、効率的かつ安全に取引やメッセージに署名することができるデジタル署名スキームです。これは、1991年の論文で最初にClaus Schnorrによって述べられました。Schnorrは、その単純さ、証明可能なセキュリティ、直線性で称賛されています。

Schnorr署名の利点:

1) Schnorr署名は、ECDSAのすべての機能とセキュリティの前提を維持しながら、効率性と強化されたプライバシーを提供するいくつかの利点を提供します。これにより、より小さな署名サイズ、より高速な検証時間、および特定の種類の攻撃に対する改善された耐性が実現されます。

2) Schnorr署名の注目すべき利点の1つは、鍵の集約です。これにより、複数の署名が1つに集約され、それらの鍵の合計に有効なものとなります。言い換えると、Schnorrは複数の協力者が、公開鍵の合計に有効な1つの署名を生成することを許可します。署名の集約により、複数の署名者の署名を1つの署名に結合することが可能となります。

キーの集約は、マルチシグのセットアップからの電子署名が、単一当事者の取引からのものと同じスペースをブロック内に占めるため、取引手数料を削減し、基礎となるスケーラビリティを向上させることができます。Schnorrのこの機能は、マルチシグ支払いやマルチシグに関連するその他の取引(たとえば、ライトニングネットワークチャネル取引など)のサイズを削減するために使用することができます。

3) Schnorr署名のもう1つの重要な特徴は、それらの非改ざん性です。

4) 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が使用されています。他の情報源では、Merklized Alternative Script Trees(MAST)を中国語に翻訳する際には、Merklized Replacement Script Trees(MAST)とされています。書籍「Mastering Bitcoin」やある記事では、この略語が使用されています。https://cointelegraph.com/learn/a-beginners-guide-to-the-BIT-taproot-upgrade.

Merklized Abstract Syntax TreesとMerklized Alternative Script Trees(MAST)は、同じ機能を持っているように見えます。翻訳の観点からは、私個人としては、公式のBitcoin BIPプロトコルで見つかる使用法を維持するのが最善だと感じています。

MASTの背後にあるコンセプトは、抽象構文木とMerkle木という2つのアイデアから来ています。

抽象構文木(AST)は、コンピュータサイエンスのコンパイラ原理と形式言語学の領域に属しています。抽象構文木は、コンパイルプロセス中の中間表現であり、ソースコードの意味構造を表すのに使用されます。これは、ソースコードをツリー構造に変換し、各ノードが意味的単位を表し、エッジがそれらの関係を表すようにします。抽象構文木は、コンパイラの字句および構文解析段階で重要な役割を果たし、ソースコードの意味を理解し、その後の最適化およびターゲットコード生成プロセスを実行するのに役立ちます。要するに、抽象構文木(AST)は、プログラムを独立したブロックに分割して記述する方法であり、プログラムを分析および最適化しやすくします。ASTを生成するには、すべての等式と前提条件を同定するまで、矢印で接続する必要があります。以下は、スクリプトのASTです。

一方、マークルツリーを使用すると、セット全体を知らなくても、要素がセットに属しているかどうかを検証できます。たとえば、ビットコインの簡易支払い検証ウォレット(SPVウォレット)は、マークルツリーを使用してトランザクションがブロック内に存在するかどうかを検証し、ブロック全体をダウンロードしないことで帯域幅を節約します。

Merkleツリーを生成するには、各要素を個別にハッシュして一意の識別子を作成します。これらの識別子は次にペアになり、再びハッシュされてそのペアの識別子が作成されます。このプロセスは、1つの識別子だけが残るまで繰り返され、これは「Merkleルート」として知られ、全体を表す簡潔な識別子です。

要素がセットに属しているかどうかを確認する場合、セットの所有者は、その要素からマークルルートまでのすべての識別子を提供できます。これは、要素が実際にセットの一部であることを証明します。

ASTの背後にある技術により、プログラムを複数の小さなブロックに分割することができます。一方、Merkleツリーによって、これらのブロックが実際にプログラム全体の一部であることを検証できますが、プログラム全体を公開することなく行うことができます。これがMASTの基本原則であり、支出者は、1つの取引で未使用の条件をMerkleプルーフで置き換えることができ、取引サイズを縮小し、プライバシーを強化し、より大きな契約をサポートする利点があります。

MASTツリーの多くの実例がオンラインで提供されており、プログラム開発に精通している人々はMASTプロセスに関連するロジックを明確に理解できます。

MAST(抽象構文木)の出現に伴い、Bitcoinのネイティブ構文機能を拡張し、Taproot Scriptsの作成が必要となりました。

(3) Taprootスクリプト

BIP 342プロトコルで導入されたTaprootscriptは、オリジナルのビットコインスクリプトのアップグレード版であり、基本的には他のBIPの実装をサポートするコマンドを含む操作コードのコレクションです。また、Taprootscriptは10,000バイトのスクリプトサイズ制限をなくし、ビットコインネットワーク上でスマートコントラクトを作成するためのより良い環境を提供します。このアップグレードは、 Taprootのscript-path sendスクリプトを利用して追加データを添付するOrdinalsの開発の基礎も築きました。詳細については、公式ウェブサイトをご覧ください。

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

TaprootScriptの機能はまだ十分に活用されておらず、将来のさらなる開発によってその潜在能力が示されるでしょう。特に、Bitcoinの第一層ネットワークと第二層技術を接続する場合には、Taproot、MAST、およびTaprootScriptsがより広く使用される可能性が高いです。

2.3 Ordinals, Inscriptions, BRC 20, and Other Protocols

Segwit、Taproot、Schnorr、MAST、およびTaproot Scriptsなどの基本的なツールを備えたBitcoinエコシステムには、新しいアプリケーションが出現し始めました。最初はこれらのアプリケーションは軽量でシンプルでした。

(1) Ordinals Protocol、Inscriptions、および BRC 20

Ordinalsプロトコルの作成には、サトシの概念が深く関わっています。このプロトコルは、序数と銘文の概念を導入しています。序数は、ビットコインネットワーク上の各サトシに一意の番号を割り当てるナンバリングスキームであり、採掘された順序に従います。プロトコルでは、サトシが異なるウォレット間で転送された場合でも、序数識別子は変わらずに残ります。RodarmorのオープンソースソフトウェアORDを実行しているBitcoinフルノードは、これらの番号付きサトシを追跡し、各サトシを正確に追跡し、独自に検証するための正確なメカニズムを提供します。

銘文は、情報をサトシに刻むことを含みます。 SegWitとTaprootを活用することで、Ordinalsプロトコルは、1つのビットコインブロックのそれぞれのサトシに4 MB未満のファイルを刻むことを可能にします。これらは銘文であり、テキスト、画像、またはビデオなどさまざまな種類の情報を含むことができます。

単純に言えば、序数付き番号スキームは、各サトシに固有の追跡可能な識別子を提供し、それに代替不可能な特性を与えます。 銘文により、これらの序数に不可分のデータを追加することができ、まるで白紙のキャンバスに芸術を創造するかのようです。 これらを組み合わせることで、BitcoinはNFTの新たな標準をホストすることができます。 本質的には、OrdinalsはNFTプロトコルのようなものですが、ETHや他の一般的なブロックチェーンとは異なり、NFTメタデータが通常IPFSや集中型サーバーに格納されている場合、Ordinalsはメタデータをトランザクションの証人データに埋め込みます。 まるで特定のサトシに「刻まれた」かのように。

BRC-20:Ordinalsプロトコルに触発され、Twitterユーザー@domodata2023年3月8日、ビットコイン上で実験的な代替可能トークン規格BRC-20を作成しました。Ordinalsプロトコルは、各サトシに異なる「属性」を割り当てることでBTCネットワークNFTを作成し、一方、BRC-20はBTCベースの代替可能トークン(FT)に統一の「フォーマット」と「属性」を提供することで行います。BRC-20は、トークン契約の展開、トークンの鋳造、および転送のためにBTCの銘文にJSONテキストを記入するためにOrdinalsプロトコルを使用します。主要な展開の側面には、トークン名、総供給量、および一回の最大鋳造量が含まれます。転送や売買を含む取引に関しては、オフチェーンの残高を追跡する追加のNFTがあります。「先着順」の鋳造メカニズムにより、公正な発行と参加の機会が提供されます。ただし、BTCエコシステムの比較的未発展なインフラとその急激な学習曲線、低い流動性と組み合わされることで、ordi、sats、ratsなどのBRC-20トークンが急騰し、富の創出の神話を生み出しています。

(2) その他のプロトコル - Atomicals、ARC 20

Atomicalsプロトコルの開発は非常に劇的でした。創設者のArthurは当初、新しくリリースされたOrdinalsプロトコルの上にDIDプロジェクトを開発したいと考えていましたが、Ordinalsには多くの制限があり、実装したい機能の一部をサポートするのに不利であることに気付きました。その結果、2023年5月29日、アーサーはAtomicalsプロトコルのコンセプトについてツイートし、数ヶ月の開発期間を経て、2023年9月17日にローンチされました。その後、Atomicalsプロトコルは、Dmint、Bitwork、ARC-20、RNSなどの概念を生み出し、将来的にはAVMと分割ソリューションを導入する予定です。Ordinals や BRC-20 と同様に、Atomicals に代替可能なトークンを展開すると、ARC-20 が作成されます。ARC-20に興味のある方は、ARC-20トークンをご覧ください。

(3) その他のプロトコル - Rune

生態系が進化するにつれて、Ordinalsの創設者であるCasey Rodarmorは、BRC-20トークンが「UTXOの無秩序な拡散」という「不幸な結果」をもたらすと指摘し、代替UTXOベースの解決策としてRunesを提案しました。既存のプロトコルは一般的に複雑な実装、ユーザーエクスペリエンスの劣化、不要な未使用取引出力(UTXO)、およびネイティブトークンを必要とする操作に悩まされています。

Runes’ transfer uses OP_RETURN, and the first data output in the protocol message is decoded into a sequence of integers, interpreted as a series of (ID, OUTPUT, AMOUNT) tuples. If the decoded number of integers is not a multiple of three, the protocol message is invalid. ID refers to the Token ID to be transferred, OUTPUT is the output index assigned (i.e., which output it is assigned to), and AMOUNT is the quantity allocated. After processing all tuple allocations, any unallocated Runes Tokens are assigned to the first non-OP_RETURN output, with the rest potentially being inscribed with Runes Tokens in the OP_RETURN output containing the protocol message.

ルーンの発行は、同種トークンのUTXOトラッキングに基づいています。プロトコル メッセージに 2 番目のデータ プッシュが含まれている場合は、発行トランザクションを表します。2 番目のデータ プッシュは、SYMBOL と DECIMALS の 2 つの整数にデコードされます。追加の整数が残っている場合、プロトコル メッセージは無効です。SYMBOLは、序数の名前で使用されるものと同様に、基本的な26文字の読み取り可能な記号であり、有効な文字はAからZのみです。SYMBOL がまだ割り当てられていない場合、ルーントークンには ID 値 (1 から開始) が割り当てられます。SYMBOLがすでに割り当てられている場合、またはBITCOIN、BTC、XBTのいずれかである場合、新しいルーンは作成されません。これはRunesプロトコルの特別な機能で、残高記録をウォレットアドレスにリンクするのではなく、UTXO自体に保存します。新しいルーントークンは、発行トランザクションから始まり、供給、記号、小数点以下の桁数を指定し、この供給は特定のUTXOに割り当てられます。UTXOには、サイズに関係なく、ルーントークンをいくつでも含めることができ、残高の追跡にのみ使用されます。次に、転送関数はこのUTXOを使用して、異なる量のルーンを含む複数の任意のサイズの新しいUTXOに分割し、レコードを他の人に送信します。BRC-20と比較して、ルーンはコンセンサスレイヤーを簡素化し、オフチェーンデータに依存せず、ネイティブトークンを欠いながらよりシンプルになり、ビットコインのネイティブUTXOモデルに非常に適しています。

(4) その他のプロトコル - BTCスタンプ、SRC 20、SRC 721

Bitcoin Stampsシステムは、Mike In Spaceによって2023年3月に発表され、当初は2014年から存在しているBitcoin Layer 2であるCounterparty上の概念実証プロジェクトとして始まりました。基礎プロトコルの更新により、Stampsは完全にBitcoinに移行し、昨年夏にSRC-20として知られるようになりました。当初、MikeはStampsを永続的なBitcoin NFTを鋳造する方法として考えていました。しかし、その後、このプロトコルはBRC-20を複製するように拡張され、2023年1月にCasey RodarmorがOrdinalsを立ち上げたことによって引き起こされた銘板ブームのためにBitcoin上で繁栄しています。

StampsとOrdinalsの主な違いは、それらのアーキテクチャにあります。Stampsはそのメタデータをマルチシグネチャ未使用取引アウトプット(UTXO)に格納しますが、Ordinalsはそのメタデータをビットコイン取引の「ウィットネス」部分に格納します。このアーキテクチャ上の違いは、開発者が行ったトレードオフを強調しています。例えば、StampsのUTXO方式はそれらをプルーネブルにすることができませんので、永続的に見えますが、その製造コストはOrdinalsよりも高くなります。逆に、Ordinalsのウィットネスデータの使用は最終的にそれらをプルーネブルにし、その製造コストはStampsよりも低くなります。

したがって、オーディナルは、今日の暗号NFTにとって最良の耐久性-コスト比を提供するかもしれません(これらはイーサリアムでも入手可能ですが、より高い構築コストがかかります)、スタンプは現時点では直接的な永続性の最良の保証を提供するようです。

BTCスタンプの登場に続き、SRC 20とSRC 721が開発され、BRC-20と同様に動作します。BRC-20はOrdinalsプロトコル上に構築されている一方、SRC-20はBTC STAMPS上に構築されています。興味のある読者はこちらでSRC 20とSRC 721のドキュメントをさらに読むことができます:

SRC 20プロトコル

SRC 721 プロトコル

これにより、BitcoinのLayer 1ネットワーク上の重要な新技術に関する紹介が終わりました。さらなるスケーリングと拡張のためには、焦点をBitcoinの上位レイヤーインフラストラクチャに移し、Bitcoin Layer 2やLightning Networkを活用するソリューションなどに注力します。このトピックに関する詳細は、「ビットコインLayer 2インフラストラクチャの包括的ガイド、バージョン1.5」や「ステートマシンの視点から:将来のWeb3.0アプリケーションのアーキテクチャと構築経路を観察する」といった記事を読むことがお勧めされます。Bitcoin Layer 2の構築やアーキテクチャ設計に関連する他の記事も参照ください。

3. 新しい技術の利用と将来の開発ニーズ

セクション2の内容に基づくと、ビットコインエコシステム内の技術的進化がより広範な応用の基盤を築いていることがわかります。ただし、開発はプロセスであり、関連する一部の技術がまだ未熟であるため、現在の一般的なアプリケーションと将来の一般的な用途との間には重要な違いがあります。

3.1 新技術の利用方法

前のセクションから、ビットコインの技術開発の本質は、ブロック容量と機能の拡張に関するものであることがわかります。

ブロック拡張:セグリゲーテッドウィットネス(SegWit)は、ブロック容量を効果的に拡張しましたが、証人データを削減するさまざまな提案があるにもかかわらず、そのような事象は起こりにくいです、特に証人データがより重要性を増して以降です。

能力拡張:Taproot、Schnorr、MAST、およびTaproot Scriptsなどの技術は、Bitcoinの機能を強化しました。特に、MASTとTaproot Scriptsの組み合わせにより、Bitcoinのネイティブスクリプト言語の能力が拡張され、より複雑なシナリオの処理が可能になりました。ただし、これらの機能を拡張することは、Bitcoinの開発と理解の複雑さを増加させるため、スクリプト開発は高水準言語で行われていないことに注意が必要です。さらに、これらの機能の拡張は、ブロック容量の拡張に関するユーザーの理解と学習ペースに遅れています。

ブロック拡張の利用の簡易さと対照的に、能力拡張の複雑さが、初期にユーザーがビットコインのメインネット上で小さな画像NFTを保存する理由を説明し、それがBRC 20のようなアプリケーションの出現をもたらしました。現在、ビットコインのメインネット上のほとんどのアプリケーションは、ブロック後の拡張の利用を探っています。一部のアプリケーションは、BEVMの第1層と第2層の接続などの能力拡張を始めています。これには前述の基本的な要素を著しく利用しています。シュノア署名、MAST契約、そしてビットコイン軽量ノードネットワーク(BTC L2)の組み合わせは、第1層と第2層をどのように接続するかを学ぶ代表的なケースです。将来的には、より広範な能力拡張のケースが期待されています。

能力拡張の境界はどこにあるべきですか? 層状設計の観点から判断できます。これらの能力が主にビットコインの第1層と第2層の間の接続として意図されている場合、過度に複雑になるべきではありません。ただし、人間の創造性と資産発行および管理の強い魅力によって駆り立てられるため、一部のチームや個人は能力拡張のためのさらなるシナリオを探るでしょう。

3.2将来の開発ニーズ

ブロックチェーン技術が登場した最も直接の理由はデジタル通貨であり、資産の発行と管理はビットコインまたはブロックチェーン領域内での直接のニーズです。カラーコインの探求からBRC 20やARC 20などのアプリケーション、Ethereum上のICOやIDOまで、これらはすべて資産の発行の探求です。Uniswap、Lending、AMMなどのアプリケーションは資産管理に関するものです。これらの種類のアプリケーションはEthereumなどのネットワークで成熟しており、Bitcoinのエコシステム技術が進化するにつれて、これらの資産管理アプリケーションはおそらくBitcoinのエコシステム、特にBitcoinの第2層に移行する可能性があります。

資産の発行と管理のニーズを満たして初めて、Web3.0時代(バリューエイジとも呼ばれる)に向けた大規模なアプリケーションを開発する能力と時間が得られます。将来の大規模Web3.0アプリケーションのシステムアーキテクチャについては、「ステートマシンの観点からビットコインの第2層を見て、将来のWeb3.0アプリケーションのアーキテクチャと構築パスを観察する」で説明します。

建設への道は、継続的にニーズを満たす過程であり、短期、中期、長期の段階に分かれます。短期は、ビットコインメインネット上の新技術の適用と、主要な機能拡張を実現するためのブロックチェーンベースの第二層構築の単純な段階を含みます。中期は、ブロックチェーンベースの第二層および分散システム第二層のより高度な段階を含み、さまざまな金融および信頼アプリケーションに対応します。長期は、大規模なビットコインエコシステムの完全な構築を含み、Web3.0時代を実際に構築します。

免責事項:

  1. この記事は[から転載されていますForesightnews],すべての著作権は元の著者に帰属します[フシャオチン、SatoshiLab、万物岛 BTC 工作室]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
  2. 責任の免責事項:この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。

Bitcoinの急騰につながった新しい技術的な進展の概要

初級編4/29/2024, 1:25:25 AM
この記事は、ビットコイン技術の開発史について詳細に探求しており、特に大規模なアプリケーションや取引規模を扱う際の課題に焦点を当てています。記事では、ビットコインの元の技術の制約について分析し、UTXOモデル、チューリング完全でないスクリプト言語、ビットコインのフォークの歴史と理由などが挙げられています。その後、記事では、OP_RETURN、SegreGate.iod Witness(Segwit)、Taprootテクノロジー、Schnorr署名、MAST、Taproot Scriptsなど、ビットコインの開発におけるいくつかの重要な技術について詳細に紹介しています。また、記事ではOrdinals、Inscriptions、BRC-20などの新しいビットコインベースのプロトコルや、それらがビットコインエコシステムの発展を促進する方法についても議論しています。最後に、記事では新しい技術の潜在的な応用と将来の発展への可能性の影響についても取り上げています。

ビットコインの元の技術の主な探求と衝突

ビットコインのオリジナルの技術は、常に普及性と持っているべき機能との間での対立に直面してきました。スケーリングと取引量は、より複雑な取引コマンドや大きな取引スペースを意味するのでしょうか?すべての機能を単一のビットコインシステムで実装する必要があるということでしょうか?ビットコインのエコシステム技術の開発が未完了だった初期には、これらの問題はビットコインそのものに固有のもののように思えました。しかし、技術が進歩するにつれ、これらの問題の多くが明確になってきました。

この記事では、それらが発生し対処された過程とともに、関連する問題のいくつかを列挙しています。この記事を通じて、これらの問題と技術との関連性、およびBitcoinのメインチェーンと関連する「テストチェーン」の変化を見ることができます。Bitcoinの技術は、さまざまなプロジェクトやチーム(Bitcoinの欠陥の探求であるEthereumを含む)によって継続的に探求されてきました。しかし、Taprootなどの技術の出現まで、Bitcoinのメインネットでの変更はあまり顕著ではありませんでした。これにより、Ordinalsなどのプロトコルの開発を促進し、開発の急騰をもたらしました。

より広い観点から、これらの進展とそれらが生み出した技術を見ると、そのつながりを見て、さらなる展開や全体的なアーキテクチャの方向性を推測することができます。

1.1 ビットコインのスクリプト言語といくつかの命令削減

ビットコインのプログラミング言語は、逆ポーランド記法を使用したスタックベースのスクリプト言語であり、ループや条件付き制御文がないため(後の拡張機能であるTaproot&Taproot Scriptなどがこの機能を強化しています)、ビットコインのスクリプト言語はチューリング完全ではないとよく言われており、その能力が制限されています。

これらの制限のため、ハッカーはこのスクリプト言語を使用してネットワークを麻痺させる無限ループを書くことはできず、またDOS攻撃につながる可能性のあるコードを書くこともできません。したがって、BitcoinネットワークをDOS攻撃から守ることができます。Bitcoinの開発者はまた、特定の攻撃やネットワークの混雑を避けるために、コアブロックチェーンにチューリング完全性を持たせるべきでないと考えています。

ただし、これらの制限は、ビットコインネットワークが他の複雑なプログラムを実行したり、一部の「有用な」機能を実行したりすることができないことを意味します。特定の問題を解決し、ユーザーのニーズを満たすために開発された後続のブロックチェーンシステムがこの側面を変えました。たとえば、Ethereumが使用する言語はチューリング完全です。

Bitcoinスクリプト命令の一般的なタイプには、次のものがあります:

キーワード:

  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_1ADD(入力に1を追加)、OP_1SUB(入力から1を引く)

  7. 暗号化。例:OP_SHA1(SHA-1アルゴリズムで入力をハッシュ化)、OP_CHECKSIG

  8. 疑似キーワード

  9. 予約されたキーワード

Bitcoinスクリプトの一般的なタイプ:

  1. ビットコインアドレスに支払う標準トランザクション(支払い先公開鍵ハッシュへの支払い)

  2. 標準的なビットコイン鋳造トランザクション(公開鍵への支払い)

  3. 証明可能な未使用可能/削減可能な出力

  4. 誰でも使える出力

  5. パズル取引

5つの標準的なトランザクションスクリプトの種類には、公開鍵ハッシュへの支払い(P2PKH)、公開鍵への支払い、マルチシグ(最大15個のキーまで)、スクリプトハッシュへの支払い(P2SH)、およびデータ出力(OP_RETURN)が含まれています。

Bitcoinスクリプトに関する詳細情報については、以下をご覧ください: Bitcoin Wiki - スクリプト.

ビットコインのサポートされる命令の削減

歴史的に、Bitcoinはサポートされる命令を何度か削減してきました。次のチャートでは、赤い部分が削除された命令です。

  • 文字列操作

(2)

(3) 算術演算

指示を削減する理由は何ですか?セキュリティは考慮すべき要素の一つにすぎません。指示の削減を層状の設計の観点から見ると、基本プロトコルをより基本的で安定したものにする合理性が理解できます。おそらくサトシ・ナカモトはこの問題に初めから気づいていたため、積極的に指示を削減しました。一般的な考え方は、完全なコマンドとシステム機能を備えた小規模なシステムを構築することで、協力が必要な大規模なプロトコルではなく、ユーザーのニーズを直接満たすものです。

これはまた、事実につながります: 最初のレイヤーネットワークとして適しているのはビットコインだけです。私はこの現象を「高いビットコイン価格が新しい代替チェーンの出現を促す可能性について」の記事で分析し、経済的および技術的観点、およびビットコインの代替チェーンの出現の可能性を考慮しました。ただし、ビットコインの基本的な特性とレイヤー設計の観点から、ほとんどビットコインしか第1レイヤーネットワークインフラストラクチャとして機能できません。代替チェーンがあっても、それらは1.5レイヤープロダクトになります。第1層のレベルでは、本物のものはビットコインだけであり、最高で他のチェーンは質の劣る代替品として機能できます。

1.2. ビットコインフォークの歴史、理由、および重要性

ビットコインの開発史において、命令の削減の問題に加えて、もう一つの側面はブロックサイズの議論であり、これはしばしばビットコインのハードフォークを引き起こすことがあります。

BTCが確立された当初、同じ時間枠内で一定数の取引を処理するためのブロックサイズ制限はありませんでした。しかし、初期のBTC価格が非常に低かったため、悪意のある取引のコストも非常に低かったです。この問題に対処するために、Satoshi Nakamotoは2010年9月12日にソフトフォークを主導し、ブロックのサイズが1MBを超えることができない制限を導入しました。Satoshiはこの制限が一時的であり、将来的にはブロックの制限を管理された段階的な方法で拡大することができると述べています。

Bitcoinの人気が高まるにつれて、ネットワークトランザクションの混雑と確認時間の増加という問題が深刻化しています。2015年、Gavin AndresenとMike Hearnは、BitcoinXTの新バージョンでBIP-101提案を実装すると発表し、ブロックサイズの上限を8MBに引き上げることを期待していました。しかし、Greg Maxell、Luke Jr、Pieter Wuilleなどのコア開発者はこれに反対し、フルノードの運用の障壁が上がり、制御できない影響がある可能性があると主張しました。この議論は最終的に範囲と参加者が拡大しました。

上記の内容から、Satoshi Nakamotoも「ブロックサイズの制限は拡張の必要性を満たすために将来制御されたかつ徐々に増加させることができる一時的な制約である」と述べていることがわかります。しかし、いつフォークがより大きなブロックをサポートし、大きなブロックをサポートするために別のチェーンを分割することで問題を解決できるのでしょうか?継続的な論争の中で、多くの事例が浮上しています。たとえば、BCHのブロックサイズは8 MBで、後に32 MBに増加しました。BSVのブロックサイズは128 MBです。BCH(後にBSVも)以外にも、この期間には多くの他のBTCのフォークが見られました。BitMEXResearchによると、BCHのフォークの直後の1年間で少なくとも50種類の新しいフォークコインが登場しました。

後のコンテンツでは、ビットコインのメインネット上で、SegwitとTaprootがブロックサイズをある程度1MBから4MBに拡大させたことも示されます。

ビットコインのフォークは、ユーザー、マイナー、投資家、開発者などのニーズを含む、自らの変化を通じてより幅広いニーズに応えようとする開発探索の一形態です。

1.3. ビットコインの開発におけるいくつかの典型的な探求

サトシ·ナカモトが去った後、彼の後継者であるギャヴィン·アンドレセンがビットコインコアとビットコイン財団の設立を主導しました。この期間中、特に資産発行の分野でBTCのスケーラビリティに関する探究が続きました。

(1)カラードコイン(染色币)

eToroのCEOであるYoni Assiaは、2012年3月27日に発表された記事で、着色コインの概念を初めて提案しました。このアイデアは着実に進化し、Bitcointalkなどのフォーラムで注目を集め始めました。最終的に、Meni Rosenfeldが2012年12月4日に着色コインに関する詳細なホワイトペーパーを公開しました。

Colored coinsの背後にある考えは、ビットコインの特定の部分に特別なマーキング(つまり、着色)を追加することによって、より広範囲の資産や価値を表現することです。実装では、Colored coinsはいくつかのエンティティで登場しており、大まかに2つのカテゴリに分かれています。

1) OP_RETURNに基づいて: Flavien Charlonが2013年に提案したように、Open Assetsを使用して、OP_RETURN(Bitcoin v0.9.0で導入された、元々40バイトに制限されていたデータをBitcoinに格納するための80バイトに後で増やされた)を利用します。オペコードはスクリプトに格納され、外部読み取りによって「色付け」およびトランザクションが完了します(このモデルは外部インデックスに依存し、資産の合法性を決定するためにOrdinalsに類似しています)。

2) OP_RETURNに基づいて: 典型的な例は、2014年にChromaWayによって提案されたEPOBCプロトコルで、EPOBC資産の追加情報がBitcoin取引のnSequenceフィールドに格納され、各EPOBC資産のカテゴリと合法性を決定するためには、それらが起源取引にさかのぼって追跡される必要があります。

(2) MasterCoin (OMNI)

JRウィレットは2012年1月6日にMasterCoinのコンセプトを発表し、「2番目のBitcoinホワイトペーパー」と名付け、2013年7月にICOを通じてプロジェクトを正式に開始し、最終的に5120BTC(当時50万ドル相当)を調達しました。 MasterCoinとColored Coinsの違いは、Bitcoinブロックをスキャンして状態モデルデータベースを維持する完全なノードレイヤーを確立したことにあり、これはブロックチェーンの外部にあるノードに存在します。 この設計により、Colored Coinsよりも新しい資産の作成、分散型取引所、自動価格フィードバックメカニズムなど、より複雑な機能が提供されます。 2014年には、TetherもMastercoinプロトコルを介してTether USD(OMNI)として知られるステーブルコインをBitcoin上に発行しました。

(3) CounterParty

Counterpartyは2014年に正式に開始されました。Colored Coinsのように、CounterpartyもBTCネットワーク内にデータを格納するためにOP_RETURNを使用しています。しかし、Colored Coinsとは異なり、Counterpartyの資産はUTXOの形式で存在せず、代わりに情報がOP_RETURNを介して読み込まれ、資産の移転が示されます。資産保有者が保有アドレスを使用して特別なデータを含む取引に署名すると、資産が移転されます。この方法により、Counterpartyは資産の発行、取引、およびEthereumスマートコントラクトと互換性のあるプラットフォームを実装できます。

さらに、一部の見解では、イーサリアム、リップル、およびBitSharesも広い意味での「Bitcoin 2.0」の一部と見なされています。

1.4 ビットコインと階層プロトコルの不完全性

Bitcoinの不完全さ(または制限)は、主にいくつかの側面で表れています(この記事で言及されている不完全さは、イーサリアムのホワイトペーパーの要約に基づいており、必ずしも真の欠陥とは限りません)。

  1. ビットコインのUTXOアカウントシステム

現在のブロックチェーンプロジェクトでは、主に2種類の記録方法があります: アカウント/残高モデルとUTXOモデル。ビットコインはUTXOモデルを使用しており、一方、イーサリアム、EOS、その他はアカウント/残高モデルを使用しています。

ビットコインウォレットでは、通常、口座残高を確認できますが、ビットコインシステムの原設計者であるサトシ・ナカモトの元の設計では、「残高」という概念は存在しませんでした。 「ビットコイン残高」は、ビットコインウォレットアプリケーションの派生です。 UTXO(未使用取引出力)は未使用の取引出力を表し、ビットコイン取引の生成および検証における中核的概念です。 取引は鎖のような構造を形成し、すべての正当なビットコイン取引は、1つまたは複数の以前の取引からの出力にさかのぼることができます。 これらの鎖は採掘報酬で始まり、現在の未使用取引出力で終わります。

したがって、現実世界にはビットコインは存在せず、UTXOのみが存在します。ビットコイン取引は取引の入力と出力から成り立ちます。各取引は入力を消費して出力を生成し、それが「未使用取引出力」またはUTXOとなります。

スマートコントラクトの実装は、UTXOモデルにおいて重要な課題を抱えています。Ethereum Yellow PaperのデザイナーであるGavin Woodは、UTXOについて深い理解を持っています。Ethereumの最も重要な新機能はスマートコントラクトです。スマートコントラクトのため、Gavin WoodにとってUTXOに基づいたチューリング完全なスマートコントラクトを実装することは難しいです。それに対して、アカウントモデルは本質的にオブジェクト指向であり、それぞれのトランザクションを対応するアカウント(nonce++)に記録します。アカウント管理を容易にするために、各トランザクションがこのグローバルステートを変更するように導入されており、これは毎回の小さな変更が実世界に影響を与えるのに類似しています。したがって、Ethereumおよびその後の公共ブロックチェーンは、一般的にさまざまな種類のアカウントシステムに基づいています。

UTXOのもう一つの重大な欠陥は、口座の引き出し限度額に細かい制御を提供できないことであり、これはEthereumホワイトペーパーで議論されています。

  1. ビットコインのスクリプト言語、チューリング完全ではない

ビットコインのスクリプト言語はさまざまな計算をサポートできますが、すべての計算をサポートすることはできません。主な欠落点は、ビットコインのスクリプト言語にはループ文や条件付き制御文が欠けていることです。したがって、ビットコインのスクリプト言語はチューリング完全ではなく、その機能が制限されています。ただし、これらの制限により、ハッカーがこのスクリプト言語を使用して無限ループ(ネットワークを麻痺させる可能性がある)やDOS攻撃につながる悪意のあるコードを作成することが防がれ、これによりビットコインネットワークがDOS攻撃から保護されています。ビットコインの開発者たちはまた、コアブロックチェーンが攻撃やネットワーク混雑を防ぐためにチューリング完全であってはならないと考えています。ただし、非チューリング完全言語が安全である理由は十分ではなく、そのような言語は限られた機能しか実行できません。

  1. ビットコインの他の欠陥:セキュリティ、スケーラビリティ

マイニングの中央集権化は問題で、ビットコインのマイニングアルゴリズムは基本的にマイナーにブロックヘッダーを何百万回も微調整させて、ノードの変更されたバージョンのハッシュが目標値よりも小さくなるまで続けさせます。このマイニングアルゴリズムは中央集権攻撃の2つの形態に対して脆弱です。まず、マイニングエコシステムはASIC(Application-Specific Integrated Circuits)やビットコインマイニングのために特別に設計されたコンピュータチップによって制御されており、このタスクにおいて何千倍も効率的です。これは、ビットコインのマイニングが高度に分散化され、平等であるわけではなく、効果的な参加には相当な資本が必要とされることを意味します。次に、ほとんどのビットコインのマイナーはもはやブロックの検証をローカルで行わず、代わりに中央集権的なマイニングプールにブロックヘッダーを提供するようになっています。この問題は重要です。現在、トップ3のマイニングプールがビットコインネットワーク内の処理能力の約50%を間接的に制御しています。

ビットコインの拡張性は重要な問題です。ビットコインを使用すると、データは1時間あたり約1MB増えます。ビザのようにビットコインネットワークが1秒あたり2000取引を処理した場合、3秒ごとに1MB増えるため(1時間あたり1GB、1年あたり8TB増えます)。取引数が少ないことはビットコインコミュニティ内で論争を引き起こしており、大きなブロックチェーンはパフォーマンスを向上させる一方で、中央集権化のリスクがあります。

製品ライフサイクルの観点から、ビットコインの一部の軽微な欠陥は、現行のシステムによって制約されているが、そのシステム内で改善される可能性がある。ただし、これらの問題は、新しいシステムで対処される場合、古いシステムの制約を考慮しないで解決できる。新しいブロックチェーンシステムが開発されている場合、これらの軽微な機能的改善も設計およびアップグレードされるべきである。

Layered Design

レイヤー設計は、複雑なシステムを扱うために人間が使用する方法論および手法であり、システムを複数の階層構造に分割し、これらのレイヤー間の関係や機能を定義してシステムのモジュール性、保守性、拡張性を実現し、それによってシステムの設計効率と信頼性を向上させる。

広範囲かつ包括的なプロトコルシステムを使用する場合、層を使用することには明らかな利点があります。このアプローチにより、人々が理解しやすくなります。

,実装し、モジュールを改善します。たとえば、コンピューターネットワークでは、ISO/OSIモデルは7層の設計ですが、実際には、4層のTCP/IPプロトコルのように、いくつかの層を組み合わせることができます。プロトコル層の特定の利点には、各層の独立性と柔軟性、構造的な分割性、実装および保守の容易さ、標準化の取り組みの促進が含まれます。

レイヤードプロトコルの観点から見ると、Bitcoinの基盤レイヤーとしての位置付けは、UTXO、非チューリング完全性、長いブロック時間、小さなブロック容量、創設者の消失などの特性は、欠点ではなく、むしろ基本的なネットワークレイヤーが持つべき特性であるということを意味します。

注意: この著者は、「ビットコインレイヤー2(レイヤー2)構築基本知識システムV1.5の概要」でプロトコルの階層化について詳細な説明を提供しています。

2. ビットコイン開発の重要な新技術(ブロック拡張と機能強化)

前のセクションでは、元のビットコイン技術の主な葛藤といくつかの探索的ケースを探求しました。その多くはハードフォークやまったく新しい異種チェーンの作成につながりました。ただし、ビットコイン自体のブロックチェーン内では、これらの探求も多くの成果をもたらしました。主にブロックの拡張と機能の向上の形で基本的に表れています。これらは主に以下の側面で現れます:

2.1. OP_RETURN

ビットコインの開発者は常にビットコインの機能を拡張しようと努力しており、それはいくつかの方法で表れています。

(1) OP_RETURNの使用

OP_RETURNは、スクリプトを終了し、スタックのトップ値を返すために使用されるスクリプトオペコードです。このオペコードは、プログラミング言語のreturn関数に類似しています。 Bitcoinの歴史を通じて、OP_RETURNオペコードの機能は複数回変更されており、現在は主に台帳にデータを保存する方法として使用されています。 OP_RETURNオペコードの機能は過去に大きな変更を経ており、現在ではチェーン上に任意のデータを保存するための重要なメカニズムとなっています。

初めに、OP_RETURNはスクリプトの実行を早めに終了させるために使用されました。実行結果はトップスタックアイテムとして表示されます。このオペコードには初めは簡単に悪用できる脆弱性がありましたが、サトシ・ナカモトが迅速に修正しました。

OP_RETURN機能へのさらなる変更

Bitcoin Core v0.9.0へのアップグレードでは、「OP_RETURN出力」スクリプトが標準出力タイプに変更され、ユーザーが「使用できないトランザクション出力」にデータを追加できるようになりました。このようなスクリプトで利用可能なデータ容量は当初40バイトに制限されていましたが、後に80バイトに増加しました。

ブロックチェーン上でのデータの保管:

OP_RETURNを常にfalseに変更すると、興味深い結果がもたらされました。OP_RETURNの後に他のオペコードやデータが評価されないため、ネットワークユーザーはこのオペコードを使用して任意の形式でデータを格納するようになりました。

ビットコインキャッシュ(BCH)時代、2017年8月1日から2018年11月15日まで、OP_RETURN出力に添付できるデータ長が220バイトに拡張され、ブロックチェーン上でコンテンツを投稿するなど、より重要なデータを許容し、革新的なアプリケーションを育成することが可能となりました。

BSVでは、220バイトの制限が短期間で維持されました。その後、2019年1月に、OP_RETURNオペコードがスクリプトを終了させるため、ノードはその後のオペコードを検証しないため、ノードもスクリプトが最大スクリプトサイズ制限の520バイト以内であるかどうかをチェックしませんでした。その結果、ネットワークノードオペレーターは最大取引量を100KBに増やすことを決定し、開発者にアプリケーションイノベーションのためのより多くの自由を与え、新しいアプリケーションがビットコイン台帳により大きく、より複雑なデータを配置することが可能となりました。当時、BSV台帳にウェブサイト全体を収めた例もありました。

OP_RETURNにはいくつかの機能拡張がありますが、その全体的な機能はまだ限られています。これがセグリゲーテッドウィットネスの技術につながりました。

(2) SegWit(セグウィットネス)

Segregated Witness、またはSegWitは、Pieter Wuille(Bitcoinのコア開発者およびBlockstreamの共同創設者)によって2015年12月に初めて提案され、後にBitcoin BIP 141となりました。SegWitは、Bitcoinブロック内の取引データ構造をわずかに変更して、以下の問題に対処します。

1) トランザクション改竄問題。

2) SPVプルーフでは、送金トランザクションの署名の転送が任意となり、Merkleプルーフのデータ量が削減されます。

3) ブロック容量を間接的に増やす。

最初の2つのアイテムは主にセキュリティとパフォーマンスを向上させ、新技術に最も影響を与えるのは3番目のアイテムで、これは間接的にブロック容量を増やし(以下、ブロックウェイトの概念を参照)、Bitcoinの機能強化の基盤を築き、Taproot(Segregated Witnessの第2バージョン)のさらなる強化につながった。

実現がブロック容量を増加させましたが、SegWitはまだブロックサイズの制限の対象です。 Bitcoinのブロックサイズ制限は1 Mバイトであり、証人データがこの制限に含まれていないため、証人データの乱用を防ぐために、合計ブロックサイズに制限があります。 ブロックウェイトという新しい概念が導入されました:

ブロック重量=ベースサイズ*3+合計サイズ

ベースサイズとは、証人データを除いたブロックサイズのことです

総サイズは、ベースデータとウィットネスデータの両方を含む、BIP 144に従ってシリアル化された合計ブロックサイズです。

SegWitはブロックの重量を4 M以下に制限します。

SegWitは技術的にもビットコインの拡張を可能にし、ここでは詳細には触れませんが、ライトニングネットワークの利用も可能にしています。

(3) Taproot (セグリゲーテッドウィットネスV2)

直接Taprootという言葉を使うと、多くの人が新しい概念だと思うかもしれませんが、それがSegregated Witnessの第2版であることを理解すれば、多くの人がその関連性を把握するでしょう。 TaprootはBIP 340、341、342に関連しており、それぞれBIP 340(secp256k1用のSchnorr署名)、BIP 341(Taproot:SegWitバージョン1の支出ルール)と名付けられています。

BIP 342 (Taprootスクリプトの検証)。

2021年11月、Taprootはソフトフォークとして正式にアクティブ化されました。このアップグレードは、BIP 340、BIP 341、およびBIP 342を組み合わせています。その中で、BIP 340はSchnorr署名を導入し、複数のトランザクションを同時に検証できるようにしました。これにより、楕円曲線デジタル署名アルゴリズム(ECDSA)を置き換え、ネットワーク容量を再度拡大し、バッチトランザクションの処理を高速化し、複雑なスマートコントラクトの展開に可能性を提供します。BIP 341は、ブロックチェーン上のトランザクションデータの格納を最適化するためにMerklized Abstract Syntax Trees(MAST)を実装します。BIP 342(Tapscript)は、Bitcoinのスクリプトエンコーディング言語を使用してBitcoinのネイティブスクリプト機能を強化します。

SegwitとTaprootによるスペース拡張により、Schnorr署名、MASTツリー、Taprootスクリプトが生み出され、その使命はBitcoinメインネットの機能拡張です。

2.2 Schnorr Signatures、MAST、およびTaproot Scripts

セクション2.1から、我々はBitcoinのスケーリングと機能強化の進行を観察し、Schnorr、MAST、Taproot Scriptsなどの重要な技術とともにTaproot技術の開発によって、Bitcoinの機能が本当に拡大されました。

(1) Schnorr 署名

Taprootの進化は、機能を拡張する一方で、署名アルゴリズムから特定の要求を必要とし、それにより、楕円曲線デジタル署名アルゴリズム(ECDSA)を置き換えるためにSchnorr署名が導入されました。Schnorr署名は、効率的かつ安全に取引やメッセージに署名することができるデジタル署名スキームです。これは、1991年の論文で最初にClaus Schnorrによって述べられました。Schnorrは、その単純さ、証明可能なセキュリティ、直線性で称賛されています。

Schnorr署名の利点:

1) Schnorr署名は、ECDSAのすべての機能とセキュリティの前提を維持しながら、効率性と強化されたプライバシーを提供するいくつかの利点を提供します。これにより、より小さな署名サイズ、より高速な検証時間、および特定の種類の攻撃に対する改善された耐性が実現されます。

2) Schnorr署名の注目すべき利点の1つは、鍵の集約です。これにより、複数の署名が1つに集約され、それらの鍵の合計に有効なものとなります。言い換えると、Schnorrは複数の協力者が、公開鍵の合計に有効な1つの署名を生成することを許可します。署名の集約により、複数の署名者の署名を1つの署名に結合することが可能となります。

キーの集約は、マルチシグのセットアップからの電子署名が、単一当事者の取引からのものと同じスペースをブロック内に占めるため、取引手数料を削減し、基礎となるスケーラビリティを向上させることができます。Schnorrのこの機能は、マルチシグ支払いやマルチシグに関連するその他の取引(たとえば、ライトニングネットワークチャネル取引など)のサイズを削減するために使用することができます。

3) Schnorr署名のもう1つの重要な特徴は、それらの非改ざん性です。

4) 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が使用されています。他の情報源では、Merklized Alternative Script Trees(MAST)を中国語に翻訳する際には、Merklized Replacement Script Trees(MAST)とされています。書籍「Mastering Bitcoin」やある記事では、この略語が使用されています。https://cointelegraph.com/learn/a-beginners-guide-to-the-BIT-taproot-upgrade.

Merklized Abstract Syntax TreesとMerklized Alternative Script Trees(MAST)は、同じ機能を持っているように見えます。翻訳の観点からは、私個人としては、公式のBitcoin BIPプロトコルで見つかる使用法を維持するのが最善だと感じています。

MASTの背後にあるコンセプトは、抽象構文木とMerkle木という2つのアイデアから来ています。

抽象構文木(AST)は、コンピュータサイエンスのコンパイラ原理と形式言語学の領域に属しています。抽象構文木は、コンパイルプロセス中の中間表現であり、ソースコードの意味構造を表すのに使用されます。これは、ソースコードをツリー構造に変換し、各ノードが意味的単位を表し、エッジがそれらの関係を表すようにします。抽象構文木は、コンパイラの字句および構文解析段階で重要な役割を果たし、ソースコードの意味を理解し、その後の最適化およびターゲットコード生成プロセスを実行するのに役立ちます。要するに、抽象構文木(AST)は、プログラムを独立したブロックに分割して記述する方法であり、プログラムを分析および最適化しやすくします。ASTを生成するには、すべての等式と前提条件を同定するまで、矢印で接続する必要があります。以下は、スクリプトのASTです。

一方、マークルツリーを使用すると、セット全体を知らなくても、要素がセットに属しているかどうかを検証できます。たとえば、ビットコインの簡易支払い検証ウォレット(SPVウォレット)は、マークルツリーを使用してトランザクションがブロック内に存在するかどうかを検証し、ブロック全体をダウンロードしないことで帯域幅を節約します。

Merkleツリーを生成するには、各要素を個別にハッシュして一意の識別子を作成します。これらの識別子は次にペアになり、再びハッシュされてそのペアの識別子が作成されます。このプロセスは、1つの識別子だけが残るまで繰り返され、これは「Merkleルート」として知られ、全体を表す簡潔な識別子です。

要素がセットに属しているかどうかを確認する場合、セットの所有者は、その要素からマークルルートまでのすべての識別子を提供できます。これは、要素が実際にセットの一部であることを証明します。

ASTの背後にある技術により、プログラムを複数の小さなブロックに分割することができます。一方、Merkleツリーによって、これらのブロックが実際にプログラム全体の一部であることを検証できますが、プログラム全体を公開することなく行うことができます。これがMASTの基本原則であり、支出者は、1つの取引で未使用の条件をMerkleプルーフで置き換えることができ、取引サイズを縮小し、プライバシーを強化し、より大きな契約をサポートする利点があります。

MASTツリーの多くの実例がオンラインで提供されており、プログラム開発に精通している人々はMASTプロセスに関連するロジックを明確に理解できます。

MAST(抽象構文木)の出現に伴い、Bitcoinのネイティブ構文機能を拡張し、Taproot Scriptsの作成が必要となりました。

(3) Taprootスクリプト

BIP 342プロトコルで導入されたTaprootscriptは、オリジナルのビットコインスクリプトのアップグレード版であり、基本的には他のBIPの実装をサポートするコマンドを含む操作コードのコレクションです。また、Taprootscriptは10,000バイトのスクリプトサイズ制限をなくし、ビットコインネットワーク上でスマートコントラクトを作成するためのより良い環境を提供します。このアップグレードは、 Taprootのscript-path sendスクリプトを利用して追加データを添付するOrdinalsの開発の基礎も築きました。詳細については、公式ウェブサイトをご覧ください。

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

TaprootScriptの機能はまだ十分に活用されておらず、将来のさらなる開発によってその潜在能力が示されるでしょう。特に、Bitcoinの第一層ネットワークと第二層技術を接続する場合には、Taproot、MAST、およびTaprootScriptsがより広く使用される可能性が高いです。

2.3 Ordinals, Inscriptions, BRC 20, and Other Protocols

Segwit、Taproot、Schnorr、MAST、およびTaproot Scriptsなどの基本的なツールを備えたBitcoinエコシステムには、新しいアプリケーションが出現し始めました。最初はこれらのアプリケーションは軽量でシンプルでした。

(1) Ordinals Protocol、Inscriptions、および BRC 20

Ordinalsプロトコルの作成には、サトシの概念が深く関わっています。このプロトコルは、序数と銘文の概念を導入しています。序数は、ビットコインネットワーク上の各サトシに一意の番号を割り当てるナンバリングスキームであり、採掘された順序に従います。プロトコルでは、サトシが異なるウォレット間で転送された場合でも、序数識別子は変わらずに残ります。RodarmorのオープンソースソフトウェアORDを実行しているBitcoinフルノードは、これらの番号付きサトシを追跡し、各サトシを正確に追跡し、独自に検証するための正確なメカニズムを提供します。

銘文は、情報をサトシに刻むことを含みます。 SegWitとTaprootを活用することで、Ordinalsプロトコルは、1つのビットコインブロックのそれぞれのサトシに4 MB未満のファイルを刻むことを可能にします。これらは銘文であり、テキスト、画像、またはビデオなどさまざまな種類の情報を含むことができます。

単純に言えば、序数付き番号スキームは、各サトシに固有の追跡可能な識別子を提供し、それに代替不可能な特性を与えます。 銘文により、これらの序数に不可分のデータを追加することができ、まるで白紙のキャンバスに芸術を創造するかのようです。 これらを組み合わせることで、BitcoinはNFTの新たな標準をホストすることができます。 本質的には、OrdinalsはNFTプロトコルのようなものですが、ETHや他の一般的なブロックチェーンとは異なり、NFTメタデータが通常IPFSや集中型サーバーに格納されている場合、Ordinalsはメタデータをトランザクションの証人データに埋め込みます。 まるで特定のサトシに「刻まれた」かのように。

BRC-20:Ordinalsプロトコルに触発され、Twitterユーザー@domodata2023年3月8日、ビットコイン上で実験的な代替可能トークン規格BRC-20を作成しました。Ordinalsプロトコルは、各サトシに異なる「属性」を割り当てることでBTCネットワークNFTを作成し、一方、BRC-20はBTCベースの代替可能トークン(FT)に統一の「フォーマット」と「属性」を提供することで行います。BRC-20は、トークン契約の展開、トークンの鋳造、および転送のためにBTCの銘文にJSONテキストを記入するためにOrdinalsプロトコルを使用します。主要な展開の側面には、トークン名、総供給量、および一回の最大鋳造量が含まれます。転送や売買を含む取引に関しては、オフチェーンの残高を追跡する追加のNFTがあります。「先着順」の鋳造メカニズムにより、公正な発行と参加の機会が提供されます。ただし、BTCエコシステムの比較的未発展なインフラとその急激な学習曲線、低い流動性と組み合わされることで、ordi、sats、ratsなどのBRC-20トークンが急騰し、富の創出の神話を生み出しています。

(2) その他のプロトコル - Atomicals、ARC 20

Atomicalsプロトコルの開発は非常に劇的でした。創設者のArthurは当初、新しくリリースされたOrdinalsプロトコルの上にDIDプロジェクトを開発したいと考えていましたが、Ordinalsには多くの制限があり、実装したい機能の一部をサポートするのに不利であることに気付きました。その結果、2023年5月29日、アーサーはAtomicalsプロトコルのコンセプトについてツイートし、数ヶ月の開発期間を経て、2023年9月17日にローンチされました。その後、Atomicalsプロトコルは、Dmint、Bitwork、ARC-20、RNSなどの概念を生み出し、将来的にはAVMと分割ソリューションを導入する予定です。Ordinals や BRC-20 と同様に、Atomicals に代替可能なトークンを展開すると、ARC-20 が作成されます。ARC-20に興味のある方は、ARC-20トークンをご覧ください。

(3) その他のプロトコル - Rune

生態系が進化するにつれて、Ordinalsの創設者であるCasey Rodarmorは、BRC-20トークンが「UTXOの無秩序な拡散」という「不幸な結果」をもたらすと指摘し、代替UTXOベースの解決策としてRunesを提案しました。既存のプロトコルは一般的に複雑な実装、ユーザーエクスペリエンスの劣化、不要な未使用取引出力(UTXO)、およびネイティブトークンを必要とする操作に悩まされています。

Runes’ transfer uses OP_RETURN, and the first data output in the protocol message is decoded into a sequence of integers, interpreted as a series of (ID, OUTPUT, AMOUNT) tuples. If the decoded number of integers is not a multiple of three, the protocol message is invalid. ID refers to the Token ID to be transferred, OUTPUT is the output index assigned (i.e., which output it is assigned to), and AMOUNT is the quantity allocated. After processing all tuple allocations, any unallocated Runes Tokens are assigned to the first non-OP_RETURN output, with the rest potentially being inscribed with Runes Tokens in the OP_RETURN output containing the protocol message.

ルーンの発行は、同種トークンのUTXOトラッキングに基づいています。プロトコル メッセージに 2 番目のデータ プッシュが含まれている場合は、発行トランザクションを表します。2 番目のデータ プッシュは、SYMBOL と DECIMALS の 2 つの整数にデコードされます。追加の整数が残っている場合、プロトコル メッセージは無効です。SYMBOLは、序数の名前で使用されるものと同様に、基本的な26文字の読み取り可能な記号であり、有効な文字はAからZのみです。SYMBOL がまだ割り当てられていない場合、ルーントークンには ID 値 (1 から開始) が割り当てられます。SYMBOLがすでに割り当てられている場合、またはBITCOIN、BTC、XBTのいずれかである場合、新しいルーンは作成されません。これはRunesプロトコルの特別な機能で、残高記録をウォレットアドレスにリンクするのではなく、UTXO自体に保存します。新しいルーントークンは、発行トランザクションから始まり、供給、記号、小数点以下の桁数を指定し、この供給は特定のUTXOに割り当てられます。UTXOには、サイズに関係なく、ルーントークンをいくつでも含めることができ、残高の追跡にのみ使用されます。次に、転送関数はこのUTXOを使用して、異なる量のルーンを含む複数の任意のサイズの新しいUTXOに分割し、レコードを他の人に送信します。BRC-20と比較して、ルーンはコンセンサスレイヤーを簡素化し、オフチェーンデータに依存せず、ネイティブトークンを欠いながらよりシンプルになり、ビットコインのネイティブUTXOモデルに非常に適しています。

(4) その他のプロトコル - BTCスタンプ、SRC 20、SRC 721

Bitcoin Stampsシステムは、Mike In Spaceによって2023年3月に発表され、当初は2014年から存在しているBitcoin Layer 2であるCounterparty上の概念実証プロジェクトとして始まりました。基礎プロトコルの更新により、Stampsは完全にBitcoinに移行し、昨年夏にSRC-20として知られるようになりました。当初、MikeはStampsを永続的なBitcoin NFTを鋳造する方法として考えていました。しかし、その後、このプロトコルはBRC-20を複製するように拡張され、2023年1月にCasey RodarmorがOrdinalsを立ち上げたことによって引き起こされた銘板ブームのためにBitcoin上で繁栄しています。

StampsとOrdinalsの主な違いは、それらのアーキテクチャにあります。Stampsはそのメタデータをマルチシグネチャ未使用取引アウトプット(UTXO)に格納しますが、Ordinalsはそのメタデータをビットコイン取引の「ウィットネス」部分に格納します。このアーキテクチャ上の違いは、開発者が行ったトレードオフを強調しています。例えば、StampsのUTXO方式はそれらをプルーネブルにすることができませんので、永続的に見えますが、その製造コストはOrdinalsよりも高くなります。逆に、Ordinalsのウィットネスデータの使用は最終的にそれらをプルーネブルにし、その製造コストはStampsよりも低くなります。

したがって、オーディナルは、今日の暗号NFTにとって最良の耐久性-コスト比を提供するかもしれません(これらはイーサリアムでも入手可能ですが、より高い構築コストがかかります)、スタンプは現時点では直接的な永続性の最良の保証を提供するようです。

BTCスタンプの登場に続き、SRC 20とSRC 721が開発され、BRC-20と同様に動作します。BRC-20はOrdinalsプロトコル上に構築されている一方、SRC-20はBTC STAMPS上に構築されています。興味のある読者はこちらでSRC 20とSRC 721のドキュメントをさらに読むことができます:

SRC 20プロトコル

SRC 721 プロトコル

これにより、BitcoinのLayer 1ネットワーク上の重要な新技術に関する紹介が終わりました。さらなるスケーリングと拡張のためには、焦点をBitcoinの上位レイヤーインフラストラクチャに移し、Bitcoin Layer 2やLightning Networkを活用するソリューションなどに注力します。このトピックに関する詳細は、「ビットコインLayer 2インフラストラクチャの包括的ガイド、バージョン1.5」や「ステートマシンの視点から:将来のWeb3.0アプリケーションのアーキテクチャと構築経路を観察する」といった記事を読むことがお勧めされます。Bitcoin Layer 2の構築やアーキテクチャ設計に関連する他の記事も参照ください。

3. 新しい技術の利用と将来の開発ニーズ

セクション2の内容に基づくと、ビットコインエコシステム内の技術的進化がより広範な応用の基盤を築いていることがわかります。ただし、開発はプロセスであり、関連する一部の技術がまだ未熟であるため、現在の一般的なアプリケーションと将来の一般的な用途との間には重要な違いがあります。

3.1 新技術の利用方法

前のセクションから、ビットコインの技術開発の本質は、ブロック容量と機能の拡張に関するものであることがわかります。

ブロック拡張:セグリゲーテッドウィットネス(SegWit)は、ブロック容量を効果的に拡張しましたが、証人データを削減するさまざまな提案があるにもかかわらず、そのような事象は起こりにくいです、特に証人データがより重要性を増して以降です。

能力拡張:Taproot、Schnorr、MAST、およびTaproot Scriptsなどの技術は、Bitcoinの機能を強化しました。特に、MASTとTaproot Scriptsの組み合わせにより、Bitcoinのネイティブスクリプト言語の能力が拡張され、より複雑なシナリオの処理が可能になりました。ただし、これらの機能を拡張することは、Bitcoinの開発と理解の複雑さを増加させるため、スクリプト開発は高水準言語で行われていないことに注意が必要です。さらに、これらの機能の拡張は、ブロック容量の拡張に関するユーザーの理解と学習ペースに遅れています。

ブロック拡張の利用の簡易さと対照的に、能力拡張の複雑さが、初期にユーザーがビットコインのメインネット上で小さな画像NFTを保存する理由を説明し、それがBRC 20のようなアプリケーションの出現をもたらしました。現在、ビットコインのメインネット上のほとんどのアプリケーションは、ブロック後の拡張の利用を探っています。一部のアプリケーションは、BEVMの第1層と第2層の接続などの能力拡張を始めています。これには前述の基本的な要素を著しく利用しています。シュノア署名、MAST契約、そしてビットコイン軽量ノードネットワーク(BTC L2)の組み合わせは、第1層と第2層をどのように接続するかを学ぶ代表的なケースです。将来的には、より広範な能力拡張のケースが期待されています。

能力拡張の境界はどこにあるべきですか? 層状設計の観点から判断できます。これらの能力が主にビットコインの第1層と第2層の間の接続として意図されている場合、過度に複雑になるべきではありません。ただし、人間の創造性と資産発行および管理の強い魅力によって駆り立てられるため、一部のチームや個人は能力拡張のためのさらなるシナリオを探るでしょう。

3.2将来の開発ニーズ

ブロックチェーン技術が登場した最も直接の理由はデジタル通貨であり、資産の発行と管理はビットコインまたはブロックチェーン領域内での直接のニーズです。カラーコインの探求からBRC 20やARC 20などのアプリケーション、Ethereum上のICOやIDOまで、これらはすべて資産の発行の探求です。Uniswap、Lending、AMMなどのアプリケーションは資産管理に関するものです。これらの種類のアプリケーションはEthereumなどのネットワークで成熟しており、Bitcoinのエコシステム技術が進化するにつれて、これらの資産管理アプリケーションはおそらくBitcoinのエコシステム、特にBitcoinの第2層に移行する可能性があります。

資産の発行と管理のニーズを満たして初めて、Web3.0時代(バリューエイジとも呼ばれる)に向けた大規模なアプリケーションを開発する能力と時間が得られます。将来の大規模Web3.0アプリケーションのシステムアーキテクチャについては、「ステートマシンの観点からビットコインの第2層を見て、将来のWeb3.0アプリケーションのアーキテクチャと構築パスを観察する」で説明します。

建設への道は、継続的にニーズを満たす過程であり、短期、中期、長期の段階に分かれます。短期は、ビットコインメインネット上の新技術の適用と、主要な機能拡張を実現するためのブロックチェーンベースの第二層構築の単純な段階を含みます。中期は、ブロックチェーンベースの第二層および分散システム第二層のより高度な段階を含み、さまざまな金融および信頼アプリケーションに対応します。長期は、大規模なビットコインエコシステムの完全な構築を含み、Web3.0時代を実際に構築します。

免責事項:

  1. この記事は[から転載されていますForesightnews],すべての著作権は元の著者に帰属します[フシャオチン、SatoshiLab、万物岛 BTC 工作室]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
  2. 責任の免責事項:この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。
Start Now
Sign up and get a
$100
Voucher!