Maxim Orlovsky、LNP/BP Standards Association
論文では、必要なソフトフォークなしでビットコインレイヤー1（ブロックチェーン/タイムチェーン）をアップグレードする方法を提案します。クライアント側の検証のアップグレードレバレッジプロパティは、段階的であり、許可されている展開オプション（つまり、多数派サポートやマイナー協力を必要としない）を持ち、注文のスケーラビリティがあります
Bitcoinという言葉は複数の意味を獲得しているため、より具体的な用語を使用してそれらを区別します。システム全体を示す一般的な傘の用語としてビットコインを使用します。これには、複数のレイヤー（将来を含む）と、中本atoshi由来のピアツーピア電子キャッシュシステムの全体的なアイデアが含まれる場合があります。同時に、 BTCを使用して、ビットコインをデジタル希少性、お金、通貨として示します。また、ビットコイン捕虜のコンセンサス（次のブロックプロデューサーを選択するというルール）、中本コンセンサス（鉱山労働者罰の暗号経済的手段で強化されたPoWコンセンサスを含む）、ビットコインブロックチェーン（または、タイムチェーンと呼ばれる）、ビットコインレイヤー1の特定の現在の実装として区別しています。ビットコインプロトコル（BP）は、鎖でビットコイントランザクションを操作するための一連の標準、テクノロジー、ツールとして（任意のレイヤー1で）。
中本atoshiによるビットコインの当初の実装は、誰もが全世界のトランザクションを検証する必要があるという奇妙な考えをもたらしました。このアイデアは、ブロックチェーンの名前、または時にはタイムチェーン- これは、一般にアクセスできる元帳のe曲表現になりました。元帳の導入により、2つの問題が発生しました。スケーラビリティの欠如とプライバシーの低下。 1つ目は、採用とネットワーキング効果が発生するのを防ぎます。もう1つは、ビットコインの元のCypherpunk精神と矛盾し、戦略的文明的リスクを表しています（適切な文明とCyphernoxマニフェストのためのCypherpunkの不可避性を参照）。
スケーラビリティと部分的に、プライバシーの問題は、Lightningネットワークやその他の提案されたソリューションなど、レイヤー2システムの導入によって後に対処されました。その中で、最も実り多いものは、プログラム性の低い問題のみを解決しながら、元のブロックチェーン技術の制限のほとんど（すべてではないにしても）を継承したSidechainのアイデアでした。 Lightning Network-既に展開および運用可能なより成功したレイヤー2ソリューション - 流動性の過剰担保化の必要性、ゴシップトラフィックスループットの制限（ネットワーク集中化につながる）、セキュリティ/信頼性の低下により、独自のスケーラビリティの問題があります。高い基本層条件下で[..]。箱舟のような他の提案された代替案には、いくつかの基本層の変更（1つまたは2つのソフトフォーク）が必要であり、展開の課題を提示します。最後に、既存または提案されている第2層ソリューションのいずれも、元のビットコインベースレイヤープライバシーの問題を解決するものではなく、他のプライバシーに焦点を当てたレイヤー-1ソリューション（コインジョインなど）は、法的当局から保護せず、BTCの追加の問題を導入していません。
したがって、上記の問題を解決するために完全に再考する必要があるのは、ビルディングレイヤー1の元帳ベースのブロックチェーンアプローチであると結論付けることができます。この分野の最初のアイデアは、2016年と2017年にピータートッドが戻ってきたときに、ある州の所有者（たとえばBTCやその他のステートフル契約）が取引履歴の一部を確認する必要があることを指摘したときに行われました。彼らの所有権に直接関係し、残りを省略します。彼は彼のアプローチをクライアント側の検証と名付けました。 Giacomo Zuccoは、 RGBという名前のこのアプローチで資産を作成できるプロトコルを設計しました。 LNP/BP Standards Associationでの以前の研究では、RGBをさらに開発し、豊富な状態と境界のあるチューリングコンピューティングを備えた最初のジェネリッククライアント側のスマートコントラクトシステムに変換することができました。ブロックチェーンベースのスマートコントラクトで行うことができますが、ユーザーデータを保存するパブリック元帳/ブロックチェーンがあり、ビットコインPowコンセンサスプロトコルのダブルアンチダブル支出プロパティを直接利用できます。このシステムは4年間に公開され、2023年4月にリリースされました。
現在の提案では、ビットコインは、ステートフルなクライアント側の検証レイヤー（RGBなど）を提供する場合、パブリック元帳（ブロックチェーン）の制限特性なしにシステムにアップグレードできることを実証し、Pow Consensusプロトコルを保存しながら、新しいスケーラブルな非ブロックチェーンレイヤー1（コードネームのプライム）に再ベースすることができます。このレイヤーは、状態、コンピューティング、検証が上記のクライアント側の検証層に移動するため、理論的に不定の数のトランザクション（少なくとも1分あたり数十億）をホストすることができます。このような設計では、最悪のシナリオの上部に雷ネットワークやその他のスケーラビリティと支払い層が必要ありません。
プロトコルには3つの展開オプション（許可なし、マイナー活性化、ソフトフォーク）があり、最初の2つはソフト（またはハード）フォークを必要としません。オプションは独立していますが、結果として展開することもできます。
この提案は、デジタル現金としてビットコインにいくつかの利点を提供します。
提案されたシステムの相対的な欠点は次のとおりです。
提案されたシステム（コードネームプライム）は、4つの主要なコンポーネントで構成されています。
これらのコンポーネントは、ブロックチェーンタイプの元帳との機能において共同で同等です。しかし、私たちの設計では、それらは抽象化され、他のどのブロックチェーンシステムよりもはるかにスケーラビリティとプライバシーを提供します。
Foundation Primeでは、タイムスタンプサービスを実行し、ヘッダーのシーケンスを作成します。
classdiagram
方向LR
`ヘッダーn` <| - `ヘッダーn+1`
クラス `ヘッダーn` {
prev_commitment
merkle_root
merkle_tree_height
タイムスタンプ
// Pow Fields
tlv_extensions
}
クラス `ヘッダーn+1` {
prev_commitment
merkle_root
merkle_tree_height
タイムスタンプ
// Pow Fields
tlv_extensions
}
各ヘッダーには、オプションのTLV拡張機能が装備されており、将来のプロトコルアップグレードに使用できます。そのサイズは、クライアント側の検証データのマークルツリーに含まれるトランザクションの数とは無関係であり、100バイト程度です（TLVデータによって異なります）。
Primeは、2倍の支出からの保護を提供しません。これは、システムのクライアント側検証部分によって提供されます。検証されたタイムスタンプシステムの唯一の部分（コンセンサスルール）は次のとおりです。
プライムヘッダーは、公的およびグローバルに利用できるようにするために必要な唯一の情報です。これは、分散したP2Pネットワークを使用することで実現できます。
プルーフマークルツリー（ PMT ）は、クライアント側の検証データをヘッダーにリンクする仲介およびはかない構造です。 PMTは鉱夫によって生産され、ヘッダーと同じまたはその他の手段を介して一般に公開されます。ただし、ヘッダーとは異なり、持続する必要はありません。各ネットワークユーザーは、すべての新しいPMTを追跡し、所有している状態に関連する情報の一部を抽出し、クライアント側の検証データの独自の隠し場所に保存し、PMTの残りを破棄します。
一時的な性質のため、次のヘッダーをマイニングするためにPMTコンテンツを知る必要はなく、PMTサイズはシステムのスケーラビリティに影響しません。したがって、PMTは（複数の）ギガバイトサイズであり、数十億と数十億の取引にコミットしている可能性があります。
木の葉には、シングルユースシールを閉じる証人が含まれています。次のセクションで詳細に説明されているメカニズムです。 PMTは、マルチプロトコルの決定論的コミットメントスキームLNPBP-4標準に従って構築され、今日のRGBでビットコイントランザクション（ライトニングなどのチェーンおよび内部のオフチェーンプロトコルの両方）でコミットメントをホストするために使用されます。これは、各シングルユースシールがPMTにユニークな事前定義された配置を持っていることを意味します。これにより、単一のマークルパスと葉の証人が、特定のシングルユースシールの閉鎖または閉鎖の閉鎖 - または閉鎖の不在を証明するのに十分であることを意味します。与えられたヘッダー。ユーザーは、まだ閉じられていない一連の使用したシールのセット（UTXOセットのアナログ）を追跡し、新しく生成された各PMTから相対的な証明を抽出します。彼らのアザラシが閉じられていない場合、これらは非操作の証拠です（目撃者はその経路で異なる単一使用シールが閉じられていることを示しているため）。
この証明は、クライアント側の検証履歴の時間依存の成長部分を構成します。ノードのメモリ要件は、次のように時間依存的に成長します
どこ
これは、メモリ要件が次のように成長しているブロックチェーンノードのスケーラビリティよりも対数的に優れています
どこ
どこ
どこ
シングルユースシールプロトコルは、システムに対する二重支出攻撃を防ぎます。
シングルユースシール（またはアザラシ）は、ピータートッドが提案した暗号化の特別な形式です。プリミティブは、ハッシュ関数やタイムスタンプを含む他の形式の暗号化のコミットメントと比較できます。
シングルユースシール構造の詳細については、LNPBP-8標準に記載されています。 Primeは、既存のプロトコル（RGBなど）で使用されているものとは異なる特別に設計されたシングルユースシールを使用します。
シングルシールの定義は、2つのコンポーネントで構成されています。
unique_id ：契約_ID、契約操作ハッシュ、契約操作出力番号から決定論的に生成できるグローバルに不自然なユーザー生成識別子。spending_conditions_cmt ：シールを将来閉じることができる条件のコミットメント（ハッシュ）（ビットコイントランザクション出力のscriptPubkeyに似ています）。シールは、クライアント側の検証されたスマートコントラクトシステム（RGBまたはRGB様）で定義されています。各シールには、たとえばBTCバランスまたはその他の豊富なデータなど、割り当てられた状態（RGBのように）があります。ユーザーがその状態を更新することを好む場合、または所有権を別のユーザーに転送する場合、新しいシングルユースシールと新しい状態を定義して、状態移行を準備する必要があります。次に、シングルユースシールが構築され、州の移行データにコミットし、ソーススクリプトを提供し、支出条件のコミットメントとそのスクリプト/条件を満たすデータに一致する目撃者が構築されます。提案は、使用されている特定のスクリプトシステムからの要約です（今日のRGBと同様にシンプルであり、Aluvm、およびEVMを望んでいます:);スクリプトエンジンはversionフィールドを使用して指定できます。これにより、新しいエンジンまたはオペコードを時間の経過とともに導入できます（アップグレード可能性セクションを参照）。
classdiagram
方向LR
定義<| - 証人：unique_id
クラス定義{
unique_id
sapping_conditions_cmt
}
クラスの証人{
バージョン
unique_id
state_transition_cmt
sapping_conditions_src
満足_data
}
目撃者は、Ptreeの葉の内側に明示的な形に置かれ、鉱夫に提供され、PtreeとHeadersを構築します。葉は、たとえばスロットへのシールに関して、シールのunique_idに関して決定論的にメルクルの木の内側に置く必要があります
葉へのメルクルパスは、一意のunique_id葉の内容（証人データを提供する）とともに、各単一使用シールがスマートコントラクトの歴史の中で一度だけ閉じられたこと、そしてスクリプトの満足度を満たして閉じられたことを確認できます条件。定義の時点から閉鎖までの単一使用unique_idごとに蓄積する必要があることに注意してください。シールが間に閉じられていないことを証明するための要件です。これらの証明は、異なるunique_id実証する限り、プライバシーに敏感な支出条件ソースコードと満足度データを省略し、ハッシュだけを提供する可能性があります。したがって、歴史的な証人は固定されたサイズである可能性があります。前述のように、スケーラビリティのために、ゼロ知識証明を使用して、証明の履歴をさらに圧縮することもできます。
システムは、許可のないオプションで展開される場合、独自のコンセンサスプロトコルが必要です。プロトコルのセキュリティは、以下で説明する専用のメカニズムを備えたビットコインパウセキュリティに固定されているため、重要ではありません。コンセンサスの唯一の要件は、検閲に耐えることです。つまり、アイデンティティのない鉱夫/バリデーターのオープンセットを意味します。これらのプロパティを満足させることが知られている2つのコンセンサスプロトコルは、鉱山労働者の報酬によって暗号経済的に保護されたBFTコンセンサスのクリプシン状のバリアントであり、POWとUSOBOROS CRYPSINOUSバリアントです。
タイムスタンプサービスは暗号通貨をまとめることはなく、鉱夫は1日目からの料金で報われます。マイナー料金の専用契約は、RGBまたは他のクライアント側の検証されたスマート契約プロトコルによって提供されます。 、Stablecoinまたはトークン化された支払い）。鉱夫は、プロトコルのユーザーが「次のヘッダーを採掘する人」に料金を支払う取引を装備した証人を公開する許可されていない匿名のP2Pネットワークに参加する必要があります。鉱夫は、クライアント側の検証済みの歴史にこれらの取引を含め、それを行うことにより、将来獲得した資金を使用する能力を持っています。
システムの起動時に、ビットコインブロックチェーンには、デュスト上のSATの量のSATを含む専用の「誰でも支出」出力が作成されます。このUTXOに関する情報は、創世記の一部になり、マイニングシングルユースシールの定義として機能します。 POWチャレンジを解決する鉱山労働者は、その出力を費やして支出のビットコイントランザクションを使用する必要があります。ビットコイントランザクションは、採掘されたヘッダーへのTapretのコミットメントと、次の鉱山労働者のための新しい「誰でも支出」シングルシールを提供しなければなりません。これにより、作成されたヘッダーがユニークな方法でビットコインブロックチェーンに固定されているため、唯一の有効なタイムスタンプヘッダーシーケンスは、このシングル使用シールのシーケンスに従うものです。
当事者が、コミットメントを作成せずに現在の鉱山労働者を使っている場合、または十分な捕虜なしでヘッダーにコミットする場合、そのような閉鎖は無効と見なされます。この場合、すべての当事者は、新しいマイナーシングルユースシール（プロトコルリセット）に関する公開可能なOP_RETURN情報（「発表」）を提供する特別なビットコイントランザクションを作成することが許可されています。適切な手順で閉鎖されている最初のOP_RETURN発表のみが、コンセンサスルールの下で有効と見なされます。
POWシングルユーザーシールアンカーは、他の追加コンセンサス（POWまたはBFT）なしでシステムが実行できる完全なコンセンサスプロトコルを表します。あるいは、2番目のコンセンサスプロトコルのセキュリティがビットコインPowセキュリティよりも低い場合を除き、ビットコインPowが優先順位を持っている場合、2番目のコンセンサスプロトコルのセキュリティがビットコインPowセキュリティよりも低い場合、これが主要なコンセンサスとして二次コンセンサスに戻るというルールと組み合わせることができます。状態は満たされていません。
複数の代替システムが共存し、市場主導の方法で競争する可能性があるため、この提案におけるP2Pネットワーク構造の問題に故意に対処しません。代わりに、ネットワークプロパティはプロジェクトの目標にとって重要であるため、P2Pネットワークの選択に関する一般的な要件を定義します。
現在の瞬間に、前述のプロパティを満たしているネットワークはありません。ただし、それらに向かって発展する可能性を秘めたいくつかのネットワークがあります。
Storm Protocolからの以前の作業を利用し、BIP-324スタイルのエンドツーエンド暗号化を使用して、Renostrプロジェクトに取り組む予定です。他のプロジェクトは代替ソリューションを構築する可能性があり、最良のオプションは市場で選択する必要があります。
提案されたソリューションをビットコインに展開する方法について、3つのステップまたはオプションが表示されます。各ステップはオプションです。システムは、1つまたは2つなしで動作できます。また、各オプションには独自のトレードオフがありますが、結果の手順として展開された場合、これらのトレードオフは徐々に解決されます。
このシステムは、ビットコインタイムチェーンから独立して発売でき、シングルユースシール（この論文で説明）に基づく専用メカニズムを介して、ビットコインPowのセキュリティにコンセンサスが固定されています。これには、マイナー側やビットコインソフト/ハードフォークの変更は必要ありませんが、このセットアップでは、BTCを新しいシステムに1つの方法でのみ信頼できるように転送できます。また、他の方法ではフェデレーションが必要です。
ビットコインマイナーは、プライムトランザクションの処理を開始し、マイニングされたマイニングの場合と同様に、ビットコインブロックチェーンコインベースへのタイムスタンプサービスヘッダーへのコミットメントを行います。これにより、専用のプライムコンセンサスが必要になりますが、ハッシュパワー攻撃に対して脆弱であり、鉱山労働者の大多数が展開前にプロトコルに参加する必要があります。
この提案には特定のソフトフォークは必要ありませんが、現在のビットコインコンセンサスルールでは、BTCが新しいプライムシステムからビットコインブロックチェーンに移動するための信頼性のない方法を提供することはできません。これを要件とは見なしていませんが（Primeはブロックチェーンよりも多くの利点があるため、ブロックチェーンはすでに長期的に死んでいると考えています）、短期的には、これはプラットフォームの採用に課題となる可能性があります。
このような機能を可能にする可能性のあるさまざまなソフトフォーク提案があります。それらは2つの主要なカテゴリに分類されます。
これらの提案のいずれかを採用することで、プライムプラットフォームでBTCの信頼のないペグアウトが可能になります。私たち自身の好みは、他の多くの利点があり、ドライブチェーンでは避けられないトレードオフを提供しないため、ゼロ知識を有効にするOPコードを追いかけます。
クライアント側の検証システムのアップグレードは、ブロックチェーン - またはP2Pネットワーク（Lightningなど）のアップグレード可能性とは大きく異なります。これは、ブロックチェーンが完全に複製された状態マシンであるコンセンサスプロトコルであり、クライアント側の検証は部分的な複製を使用するという事実によって引き起こされます。これは、一方では、未知の状態に関連する部分でシステムをアップグレードすることをより簡単にしますが、他方では、ネットワークが提供するグローバルにアクセス可能な状態に非クリプトコノミック主導の保証がないため、 、アップグレードを調整することははるかに困難です。
言い換えれば、クライアント側の検証のアップグレードは、ブロックチェーンのハードフォークやソフトフォークと根本的に異なり、新しい概念と用語の導入が必要です。
何かが無効で、アップグレード後に有効になった場合（この早速の変更と呼ばれます）、既存のすべてのユーザーは影響を受けません。彼らはすでに有効な状態を所有および管理しています。ただし、ソフトウェアの古いバージョンを実行しているユーザーと対話できない場合があります。これは、仲間がアップグレードに同意した場合に解決できる問題です。アップグレードは、それらが所有している州のいずれも使用しないため、これらのピアにリスクを提示しません。アップグレードは歴史的なデータに触れません。
一方、何かが有効であり、新しいルールの下で無効になった状況は非常に異なります。ユーザーは既存の状態を永久に失う可能性があり、可能な限りアップグレードに反対する必要があります。このようなアップグレードをプッシュバックと呼び、重要なバグが発見された場合にのみ、それらを許容できると考えています。アップグレードは、バグによって導入された問題を回避するために、誠実/非誘導ユーザーの欲求によって「調整」されます。
RGBまたはRGBにインスパイアされたシステムがスマートコントラクトコンポーネントとして使用されている場合、この部分へのアップグレードには別の特徴的な機能があります。 RGBは、各プログラム（「スマートコントラクト」）をサンドボックスに分離します。また、契約が発行されると、プロトコルの新しいバージョンにアップグレードできません。アップグレードの唯一の方法は、発行者（またはコミュニティを含む発行者によって委任された当事者）が古い契約から新しい契約への州への州への譲渡を行う場合、新しい契約を作成することです。所有者はそれに同意します。
副次的な利点として、このアプローチは、ブロックチェーンの世界で達成できない新機能、指示などを徐々に導入できるようになります。新しい契約の発行者は、以前のプロトコルバージョンに依存せず、追加のアップグレードリスクや追加のアップグレードリスクなしでより高度なソリューションを提案できます。コミュニティの調整。
著者は、制約されたブロックチェーンへのビットコイン依存を削除し、クライアント側の検証を今後の方法として見るという考えでインサイピングしていたGiacomo Zuccoに感謝しています。長年にわたって彼とピーター・トッドとの複数の議論が、システムの多くの部分を設計するのに役立っていました。著者は、クライアント側の検証、ブロックチェーンの欠陥、ブロックチェーンレスのデザインに関連する問題について何時間も費やした対談者であったAlex Kravets、Federico Tenga、Olga Ukolovaに言及したいと思います。
