オリジナルタイトル「RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态」を転送する

要約：· CKBチームによって提案されたRGB++アセットプロトコル提案の本質的なアイデアは、「同型結合」と呼ばれるもので、UTXOプログラミングモデルに基づいたCKB、Cardano、Fuelなどのブロックチェーンを機能拡張レイヤーとして使用し、RGBアセット「コンテナ」を保持するものです。この同型結合は、AtomicalやRunesなどのUTXO特性を持つビットコインエコロジカルアセットプロトコルにも適用され、ビットコインのオフチェーンスマートコントラクトレイヤーを簡単に構築できるようになります。

・RGB++プロトコルでは、ユーザーはクライアントを実行して取引データを個人的に検証する必要はなく、資産の有効性検証やデータの保管などのタスクをCKBやCardanoなどのUTXOチェーンに任せることができます。上記のパブリックチェーンのセキュリティが比較的信頼できると考えているのであれば、自分で検証する必要はありません。

・RGB++プロトコルは、ユーザーがクライアント検証モードに切り替えることをサポートしています。この時、データを自分で保持する必要なく、データストレージ/DAレイヤーとしてまだCKBを使用することができます。RGB++プロトコルはクロスチェーン資産を必要とせず、Bitcoinアカウントを介してCKBチェーン上の資産を運用することができ、BitcoinチェーンへのCommitmentsの発行頻度を低減させることができるため、Defiシナリオのサポートにも貢献しています。

EVM契約システムの下にある場合、RGB++の多くの機能をサポートするのは簡単ではありません。総じて、同型結合を実現するのに適した公開チェーン/機能拡張レイヤーは、次の特性を持つべきです。

1. UTXOモデルまたは類似の状態ストレージスキームを使用します;

2. かなりのUTXOプログラム可能性があり、開発者がアンロックスクリプトを書くことができます;

3. 資産状態を保存できるUTXO関連の状態空間があります;

4. スマートコントラクトまたはその他の手段を通じてビットコインの軽量ノードの運用をサポートできます;

・CKBに加えて、CardanoとFuelも同型結合をサポートできます。ただし、後者の2つはスマートコントラクト言語や契約設計の詳細においていくつかの制約があるかもしれません。現時点では、同型結合されたビットコイン資産プロトコルの機能拡張層としては、CKBの方が後者2つよりも適しているように見えます。

2017年、Nervos CKBの共同創設者であるCipherは、初めて等価結合の製品アイデアを提案しました。他のビットコインレイヤー2ソリューションと比較して、等価結合はRGB、Runes、Atomicalなどの資産プロトコルとよりよく互換性があり、追加のセキュリティ負担をもたらすクロスチェーン資産などの要因を回避できます。

要するに、同型結合は、UTXOをCKBおよびCardanoチェーン上で「コンテナ」として使用し、RGBなどのUTXO資産を表現し、これによりプログラム可能性とより複雑なシナリオを追加します。以前、Geek web3が「BTCからSui、ADA、Nervosへ：UTXOモデルおよび関連する拡張プログラマブルUTXOをサポートする一連のブロックチェーンを要約した後、この記事では、これらのブロックチェーンが同型結合スキームに適応できるかどうかについてさらに探求します。

RGB++と同型結合

異なるUTXOチェーンの同型バインディングとの互換性を分析する前に、同型バインディングの原則を最初に紹介する必要があります。同型バインディングは、RGB++プロトコルでCKBチームが提案した概念ですので、ここではRGB++ワークフローを使用して、CKBベースの同型バインディングとは何かを紹介します。

RGB++プロトコルを紹介する前に、RGBプロトコルを簡単に理解しましょう。RGBは、ビットコインチェーンの下で実行される資産プロトコル/P2Pネットワークであり、ライトニングネットワークのようなものです。さらに、RGBはビットコインUTXOに基づく寄生資産プロトコルでもあります。寄生とは、RGBクライアントがビットコインチェーンの下で宣言することを意味し、特定のRGB資産がビットコインチェーン上のどのUTXOにバインドされているかを示します。このUTXOを所有すると、それにバインドされたRGB資産も利用できるようになります。

RGBプロトコルやERC-20などのアセットプロトコルは非常に異なる方法で動作します。 Ethereum上のERC-20コントラクトは、すべてのユーザーのアセットの状態を記録し、Ethereumノードクライアントはすべての転送情報を同期化および検証し、アセットコントラクト内の転送後の状態更新を記録します。 実際、これは長い間人々に知られており、それはアセットの状態変更がスムーズに行われることを保証するためにEthereumの合意プロセスに依存しているに過ぎません。 Ethereumノードの合意が非常に信頼性が高いため、ユーザーはクライアントを実行していなくても、ERC-20コントラクトに基づくアセットカストディプラットフォームを「問題なし」としてデフォルトできます。

RGBプロトコルは非常に奇妙です。プライバシーを向上させるために、単にノード/クライアントの合意を削除するだけで、これはブロックチェーンの世界では従来のことです。ユーザーはRGBクライアントを自分で実行し、自分に関連する「資産データ」のみを受信および保存する必要があります。他の人が何をしたかを見ることはできません。EthereumとERC-20とは異なり、すべての送金記録がチェーン上で見えます。

この場合、誰かがRGB資産をあなたに送金した場合、そのお金がどのように作成され、誰から所有者が変わったのかを事前に知ることはできません。相手側が何もないところから資産を宣言し、その一部をあなたに譲渡した場合、通貨の偽造というこの邪悪なシナリオにどのように対処しますか?

RGBプロトコルはこの考えを採用しています：各転送が行われる前に、受信者はまず送信者に資産の全履歴を提示するよう要求します。例えば、作成段階から現在まで、誰がこれらの資産を発行したか、誰がそれを通過したか、およびこれらの人々の間で発生するすべての資産転送が会計基準（1人が加算、1人が減算）に違反していないかどうかを確認します。

こうすることで、相手から渡されたお金が「怪しいお金」かどうかを知ることができるので、取引の当事者にクライアントを走らせて検証してもらうのがRGBの本質です。クライアント検証モードに基づいて、合理的な人ゲームの仮定に対応して、関係者が合理的であり、クライアントソフトウェアがOKである限り、問題のある資産譲渡が有効にならないか、他の人に認識されないことを保証できます。

RGBプロトコルは、ビットコインチェーンのトランザクションデータをコミットメント（基本的にはMerkleルート）に圧縮し、ビットコインチェーンにアップロードします。これにより、チェーン下の転送記録を直接ビットコインメインネットワークに接続できるようになります。接続してください。

（RGBプロトコルインタラクションフローチャート）

RGBクライアント間で合意がないため、RGBアセット契約のリリースはすべてのノードに「非常に信頼性が高く」伝播することはできません。契約の発行者やユーザーは単に電子メールやTwitterを通じてRGBアセット契約の詳細を自発的に知るだけであり、その形式は非常にカジュアルです。

以下の図は悪意のあるRGBアセット転送シナリオを示しています。RGBユーザーとして、RGBアセットに対応するスマートコントラクトをクライアントにローカルに保存する必要があります。他の人が私たちにお金を送金する際、ローカルに保存されたアセット契約の内容に基づいて、現在の送金が契約で定義されたルールに違反しているかどうかを知ることができます。対向する側で提供されたアセットソース情報（履歴記録）に基づいて、他の当事者の資産の出所に問題があるかどうか（無駄な資産が宣言されたかどうか）を確認することができます。

上記のプロセスを見直すと、異なるRGBクライアントが受信および保存するデータはしばしば独立しており、他の人がどの資産を持っていてその量がどれほどかをよく知らないことがよくあることが難しくないことがわかります。逆に、他の人は基本的にあなたの資産状況を知りません。

これは典型的なデータアイランドであり、つまり、誰もが保存するデータが一貫していない状態です。理論的にはプライバシーを向上させることができますが、多くの問題をもたらします。RGBアセットデータをクライアントでローカルに保持する必要があります。このデータが失われると、深刻な結果をもたらします（アセットは利用できなくなります）。しかし、実際には、ローカルデータを適切に管理すれば、RGBプロトコルは基本的にビットコインメインネットと同等のセキュリティを提供できます。

また、RGBクライアント間の通信に使用されるBifrostプロトコルは、ユーザーが他のクライアントとのP2P通信を支援します。彼らは自分の資産データを暗号化して他のノードに広め、それらに保管を手伝ってもらうことができます（これは暗号化されたデータであり、相手は平文を知りません）。ローカルデータが失われても、鍵を失わなければ、ネットワーク内の他のノードを介して元々所有していた資産データを復元することができます。

ただし、元のRGBプロトコルの欠点はまだ明らかです。まず、各トランザクションには、2つの当事者間で複数の通信が必要です。受信側はまず送信者の資産の出所を確認し、次に送信者の転送リクエストを承認する受領書を送信する必要があります。このプロセスでは、少なくとも2つの当事者間で3つのメッセージがやり取りされなければなりません。この種の「インタラクティブな転送」は、ほとんどの人々が慣れ親しんでいる「非インタラクティブな転送」とは深刻に一致していません。誰かがお金を送金したいとき、彼らがあなたに資金のデータを送って確認をしてもらわなければならないと想像してみてください。あなたの受領メッセージを受け取った後にのみ、送金プロセスを完了できますか？（フローチャートは以前の記事で確認できます）

第二に、ほとんどのDefiシナリオでは、透明なデータと検証可能な状態を持つスマートコントラクトが必要ですが、RGBプロトコルはそうしたシナリオを固有にサポートしていないため、Defiには非常に不親切です。さらに、RGBプロトコルでは、ユーザーは自分のタスクを実行するためにクライアントを実行する必要があります。万が一、何万人もの人々に渡って資産が移動した場合、その資産が何万回もの取引を検証しなければならないことさえあります。明らかに、ユーザーにすべてを自分で解決させることは、製品自体の普及と採用には有益ではありません。

上記の問題に関して、RGB++の解決策は、ユーザーがクライアントの自己検証モードとサードパーティーのホスティングモードを自由に切り替えることを可能にすることです。ユーザーはデータの検証や保管、スマートコントラクトのホスティングなどの負担をCKBに任せることができます。もちろん、ユーザーは、POWパブリックチェーンであるCKBが信頼性があると楽観的であり、信頼している必要があります。一部の人々がセキュリティとプライバシーをより高く追求する場合、例えば、大量の資産を持つ大規模な投資家は、元のRGBモードに戻ることもできます。ここで強調すべきことは、RGB++と元のRGBプロトコルが理論上互換性があるということです。

(RGB++プロトコル相互作用フローチャート[短縮版])

以前の記事「RGBからRGB++へ：CKBがビットコインの生態資産プロトコルを強化する方法」、私たちはRGB++の「等質バインディング」を簡単に紹介しました。ここでは、すばやくレビューします：

CKBは、BTCチェーン上のUTXOよりもプログラマブル性の高いCellと呼ばれる独自の拡張UTXOを持っています。 「同型結合」は、CKBチェーン上のCellをRGBアセットデータの「コンテナー」として使用し、RGBアセットのキー パラメーターをCellに書き込むことです。

RGB資産とBitcoin UTXOの間にはバインディング関係があるため、その資産の論理形式はUTXOの特性を持っています。また、UTXOの特性を持つandCellも、自然とRGB資産の「コンテナ」として適しています。RGB資産取引が発生するたびに、対応するCellコンテナも類似の特性を示すことができます。これは、実体と影の関係のようなものであり、「同型バインディング」の本質です。

例えば、Aliceがビットコインチェーン上のUTXO Aと100のRGBトークンを所有し、CKBチェーン上でCellを持っている場合、このCellには「RGBトークン残高：100」と記載され、アンロック条件はUTXO Aに関連しています。

アリスがボブに30個のトークンを送りたい場合、まずコミットメントを生成できます。対応するステートメントは、UTXO Aに関連付けられたRGBトークンのうち30個をボブに転送し、70個をボブが管理する他のUTXOに転送します。

その後、アリスはUTXO Aをビットコインチェーンで使用し、上記の声明を公開し、その後、CKBチェーンでトランザクションを開始して、100 RGBトークンを保持するセルコンテナを消費し、30トークンを保持する新しいコンテナを2つ生成しました（ボブ宛に1つ、アリスが制御する70トークンを保持するもの）。このプロセスにおいて、アリスの資産の妥当性およびトランザクション声明の妥当性の検証は、ボブの介入なしにCKBネットワークノードによってコンセンサスを通じて完了されます。CKBは現在、ビットコインチェーンの下で検証レイヤーおよびDAレイヤーとして機能しています。

これは、イーサリアムERC-20契約の状態が変わるたびに、ユーザーがクライアント検証を実行する必要がないという事実と似ています。その原則は同様です。コンセンサスプロトコルとノードネットワークがクライアント検証を代替します。さらに、誰もが所有するRGBアセットデータはCKBチェーンに保存されており、グローバルに検証可能であり、流動性プールやアセット担保プロトコルの実装を促進しています。

これは実際に重要な信頼の前提を導入しています：ユーザーは、コンセンサスプロトコルに依存する大量のノードで構成されたネットワークプラットフォーム、または信頼性が高くエラーがないと楽観的に考える傾向があります。CKBに信頼がない場合、元のRGBプロトコルでのインタラクティブなコミュニケーションと検証プロセスに従い、クライアントを自分で実行することもできます。

もちろん、誰かがRGB++クライアントを自分で実行して他の人々の資産の歴史的ソースを検証したい場合、彼はCKBチェーン上のRGBアセットコンテナセルに関連する履歴を直接検証することができます。 CKBライトノードを実行し、Merkle ProofとCKBブロックヘッダーを受信すれば、受信した歴史データがネットワーク内の悪意のある攻撃者によって改ざんされていないことを確認できます。ここでは、CKBは歴史データの保存層として機能します。

単純に言えば、同型結合はRGBにのみ適用されるのではなく、RunesやAtomicなどのUTXO特性を持つさまざまな資産プロトコルにも適用されます。これにより、ユーザークライアントにローカルに格納されている資産の状態、履歴データ、および対応するスマートコントラクトをUTXO公開チェーン（CKBやCardanoなど）に転送して保存およびホスティングします。前述のUTXO資産プロトコルは、資産の形状と状態を示すためにCKBやCardanoのUTXOモデルを「コンテナ」として使用できます。これにより、スマートコントラクトなどのシナリオとの協力が容易になります。

等価結合プロトコルの下、ユーザーは、チェーンを越えることなく、Bitcoin アカウントを直接使用して、CKB などの UTXO チェーン上の RGB アセットコンテナを操作できます。Cell の UTXO 機能を利用して、Cell コンテナのアンロック条件を、特定の Bitcoin アドレス/Bitcoin UTXO に関連付けるだけでよいです。Geekweb3 の以前の RGB++ 普及記事で Cell の特性をすでに説明しているため、ここでは詳細には触れません。

RGBアセット取引に関与する両当事者がCKBのセキュリティを信頼できる場合、ビットコインチェーンで頻繁にCommitmentsを発行する必要さえありません。多くのRGB転送が行われた後、Commitmentをビットコインチェーンに送信できます。これを「トランザクション折り畳み」機能と呼びます。使用コストを削減できます。

ただし、等価結合で使用される「コンテナ」には、UTXOモデルをサポートするパブリックチェーン、または状態保存に類似した特性を持つインフラが必要であり、EVMチェーンは明らかに適していません。技術的な実装上の問題が生じる可能性があります。まず最初に、前述のように、RGB++は「クロスチェーンなしでCKBチェーン上でアセットコンテナを操作できる」と述べられていますが、EVMチェーンでは基本的に実装不可能です。強制的に実装したとしても、コストが非常に高くなる可能性があります。

さらに、RGB++プロトコルでは、多くの人がクライアントを実行したり、資産データをローカルに保存する必要はありません。この契約でみんなの資産残高を記録するためにERC-20方法が使用されている場合、誰かがクライアントの自己検証モードに戻り、誰かの資産のソースをチェックすることを提案しようとした場合、この時点で資産契約とやり取りするすべての取引レコードをスキャンする必要があるため、膨大な圧力をもたらす可能性があります。

率直に言って、ERC-20などの資産契約は、誰もが資産の状態をカップル化して保存します。それらのうちの1つの資産の変更履歴を個別に確認したい場合、それは難しくなります。まるで公開チャットルームのように、誰が王剛にメッセージを送ったかを知りたい場合、チャットルーム全体のメッセージ記録をめくらなければなりません。UTXOは一対一のプライベートチャットチャンネルのようであり、履歴を確認するのが簡単です。

要約すると、同型結合を実現するために適したパブリックチェーン/機能拡張レイヤーは、次の特性を持つ必要があります:

1. UTXOモデルまたは類似の状態保存スキームを使用してください;
2. かなりのUTXOプログラム可能性があり、開発者がアンロックスクリプトを書くことができます；
3. 資産の状態を保存できるUTXO関連の状態空間があります;
4. ビットコイン関連のブリッジやライトノードがあります;

もちろん、私たちは同型結合に使用されるパブリックチェーンが強力なセキュリティを持っていることも望んでいます。一方で、パブリックチェーン上のUTXOのアンロック条件がプログラム可能であることも望んでいます。これにより、ユーザーは署名スキームを変更せずにBTCの署名方式を直接使用して、他のパブリックチェーン上で同型的にバインドされたUTXOをアンロックできるようになります。

現在、CKBのUTXOロックスクリプトはプログラム可能であり、公式も異なる公開チェーンの署名スキームと互換性があります。同型結合のために、CKBネットワークは基本的に上記の特性を満たしています。他のUTXOベースの公開チェーンはどうでしょうか？FuelとCardanoの予備検査を行い、同型結合を理論的にサポートできると考えています。

燃料：UTXOに基づいたEthereum OP Rollup

Fuelは、UTXOに基づいたEthereum OP Rollupであり、Ethereum Layer 2エコシステムに詐欺証明の概念を導入する先駆者です。通常のUTXO機能サポートに加えて、Fuelは基本的にBTCと一致しています。

Fuelは、内部のUTXOを次の3つのカテゴリに分けています:

入力コイン：標準UTXO、ユーザー資産を表すために使用され、ネイティブなタイムロックを持ち、ユーザーがアンロックスクリプト述語を書くことを許可します；

入力契約：契約呼び出しに使用されるUTXOには、契約の状態ルートや契約資産などのデータが含まれています;

入力メッセージ：UTXOを使用して情報を送信するためには、主に情報受信者などのフィールドが含まれています。

ユーザーがUTXOを消費すると、次の出力が生成されます。

通貨：標準的な資産の転送に使用します；

コントラクトの実行結果：コントラクト間の相互作用によって生成された出力には、コントラクト間の相互作用後の状態ルートが含まれています；

出力契約作成：契約を作成する際に生成される特別なUTXOで、契約のIDと状態ルートが含まれています；

CKBのCellが内部にすべての契約状態を含むのに対し、FuelのUTXOは実際にはすべてのトランザクション関連契約状態を持っていません。FuelはUTXO内に契約の状態ルートStaterootのみを保持し、これは状態ツリーのルートです。契約の完全な状態はFuelの状態ライブラリ内に保存され、スマートコントラクトが所有しています。

スマートコントラクトのステータス処理に関して、Fuelコントラクトとsolidityコントラクトは思想的に一貫しており、プログラミング形式でも比較的近い関係にあります。以下の図は、FuelのSway言語で書かれたカウンターコントラクトを示しています。この契約にはカウンターが含まれています。ユーザーがincrement_counter関数を呼び出すと、契約に格納されているカウンターが1増加します。

Sway契約の書き込みロジックは、一般的なSolidity契約と似ています。まず契約のABIを与え、次に契約の状態変数、そして契約の具体的な実装を行います。すべてのコードの書き込みプロセスは、FuelのUTXOシステムに関与しません。

したがって、Fuelの契約プログラミング体験は、CKBやCardanoなどのUTXOプログラミング言語とは異なります。FuelはEVMスマート契約のプログラミングおよび開発により近い体験を提供します。開発者はSway言語を使用して、特別な署名アルゴリズムの検証論理または複雑なマルチサインアンロックロジックを実装するためのアンロックスクリプトを構築することもできます。

Fuel内で同型バインディングを実装することは基本的に可能ですが、まだ次の問題があります:

Fuelが使用するスウェイ言語は、BTCやCKBおよびCardanoよりもスマートコントラクトの設計においてEVMチェーンに近いです。RGBやAtomicsなどのUTXOアセットの発行者は、Fuel上で特定のスマートコントラクトを構築する必要があります。CKBや他のチェーンは別のものを使用しており、かなり複雑です。

カルダノ: POSに基づくeUTXOパブリックチェーン

Cardanoは、UTXOモデルを使用する別のブロックチェーンですが、Fuelとは異なり、レイヤー1のパブリックチェーンです。Cardanoは、システム内のUTXOプログラミングモデルを指すeUTXO（拡張UTXO）を使用しています。CKBと比較すると、CardanoのeUTXOには以下の構造が含まれています。

スクリプト：スマートコントラクトは、UTXOをアンロックして状態遷移を実行できるかどうかを検証するために使用されます;

リディーマー：UTXOのロック解除のためにユーザーによって提供されるデータは、一般的にビットコインのWitnessと類似した署名データです。

データ:スマートコントラクトの状態空間には、資産の状態などのデータを格納できます;

トランザクションコンテキスト：UTXOトランザクションのための文脈データ、入力パラメータやトランザクションの結果など（UTXOチェーンのトランザクション計算プロセスは直接オフチェーンで実行され、計算結果はチェーンに提出されます。検証に合格すれば、トランザクション結果がチェーンにアップロードされます）

開発者は、PlutusCore言語を使用して、Cardanoチェーン上のUTXOをプログラムすることができます。CKBと同様に、開発者は、ロック解除スクリプトやステータス更新のためのいくつかの関数を書くことができます。

CardanoのUTXOプログラミングモデルを紹介します。UTXOベースのオークションプロセスを行います。オークション終了前に入札を行う必要がある資産オークションDAPPを実装する必要があります。具体的には、ユーザーは自分自身のUTXOを消費し、このオークションとのUTXOを契約し、新しいUTXOを生成します。誰かがより高い入札を行うと、新しいオークション契約UTXOを生成するだけでなく、前の人の返金UTXOも生成されます。具体的なプロセスは以下の通りです:

上記のオークションプロセスを実装するには、現在のオークションの最高価格や入札を行った人など、いくつかの状態をオークションスマートコントラクトのUTXOに格納する必要があります。以下の図は、PlutusCore内部の状態声明を示しています。bBidderとbAmountでは、オークション入札と入札を行ったウォレットアドレスが表示されます。オークションパラメータには、オークションの基本情報が含まれています。

ユーザーがこのUTXOを使うと、契約内の状態を更新できます。以下の図は、オークション契約内の特定のステータス更新とビジネスロジックを示しています。例えば、ユーザーの入札を検証するロジックや現在のオークションがまだ進行中であるかを確認するロジックです。PlutusCoreは純粋な関数型プログラミング言語であるHaskellであるため、多くの開発者はその意味を直接理解することができないかもしれません。

Cardanoで同型バインディングを構築することは可能であり、Datumを使用して資産ステータスを保存し、ビットコイン関連の署名アルゴリズムと互換性のある特定のスクリプトを記述できます。しかし、深刻な問題は、ほとんどのプログラマーが契約プログラミングにPlutusCoreを使用することに適応できない可能性があることです。さらに、そのプログラミング環境はセットアップが難しく、開発者にとって友好的ではありません。

要約

等価結合には、チェーンが次の特性を持っている必要があります:

1. UTXOモデルを使用する
2. 開発者がアンロックスクリプトを書くことを可能にするかなりのUTXOプログラム可能性があります
3. 資産状態を格納できるUTXO関連の状態空間があります
4. スマート契約やその他の手段を通じて、Bitcoinライトノードの実行をサポートすることができます。

そのスマートコントラクトプログラミングのアイデアの特異性のため、Fuelは等価結合に対応していますが、それでもいくつかの重荷を招きます。一方、Cardanoは契約プログラミングにHaskellプログラミング言語を使用しており、これによりほとんどの開発者が迅速に始めることが難しい状況です。上記の理由に基づいて、RISC-V命令セットを採用し、UTXOプログラミングの特性でよりバランスが取れたCKBが、等価結合により適した機能拡張層となる可能性があります。

免責事項：

1. この記事は[から転載されていますジーケーウェブ3].オリジナルタイトル「RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态」を転載。すべての著作権は原著者[Shew]に帰属します. もしこの転載に異議がある場合は、お問い合わせくださいGate Learn(ゲート・ラーン)チーム、そして彼らは迅速に対処します。
2. 責任の免責事項：本文に表現されている意見および見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 翻訳はGate Learnチームによって他の言語に行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。