RGB Magic: ビットコインのクライアント側契約

これは、スタートアップの創設者、コンサルタント、教育者としての経験を持ち、Bitcoin プロジェクトに長年貢献してきた Federico Tenga による論説です。

「スマート コントラクト」という用語は、ブロックチェーンとビットコイン自体が発明されるよりも前に登場しました。 その最初の言及は 1994 年 Nick Szabo の記事、彼はスマートコントラクトを「契約条件を実行するコンピューター化されたトランザクションプロトコル」と定義しました。 この定義では、スクリプト言語のおかげで、Bitcoin は最初のブロックからスマート コントラクトをサポートしていましたが、この用語は、後で Ethereum 推進者によって普及しました。通信網"

コードの実行をグローバルなコンセンサス ネットワークに委譲することには利点がありますが (たとえば、一般的に自動化されたマーケット メーカーなど、未払いの契約を展開するのは簡単です)、この設計には XNUMX つの大きな欠点があります。それは、スケーラビリティ (およびプライバシー) の欠如です。 ネットワーク内のすべてのノードが同じコードを重複して実行する必要がある場合、ノードを実行するコストを過度に増加させずに (したがって分散化を維持して) 実際に実行できるコードの量は少ないままです。実行されました。

しかし、ネットワークのすべてのメンバーではなく、関係者のみが契約条件を実行および検証するシステムを設計できたらどうでしょうか? 株式を発行したい会社の例を想像してみましょう。 発行契約をグローバル台帳で公に公開し、その台帳を使用して将来のすべての所有権の譲渡を追跡する代わりに、単純に株式を非公開で発行し、購入者にさらに譲渡する権利を渡すことができます。 その後、所有権を譲渡する権利は、元の発行契約の修正であるかのように、新しい各所有者に引き継がれます。 このようにして、各所有者は、元の契約を読み、株式を移動させた修正のすべての履歴が元の契約に定められた規則に準拠していることを検証することにより、受け取った株式が本物であることを個別に確認できます。

これは実際には新しいことではありません。公簿が一般的になる前に財産を譲渡するために使用されたのと同じメカニズムです。 イギリスでたとえば、90 年代までは、所有権が譲渡されたときに物件を登録することは義務付けられていませんでした。 これは、今日でもイングランドとウェールズの土地の 15% 以上が未登録であることを意味します。 未登録の不動産を購入する場合、登記簿で売主が真の所有者であるかどうかを確認する代わりに、少なくとも 15 年 (売主が所有者であると想定するのに十分長いと考えられる期間) までさかのぼって、切れ目のない所有権の連鎖を確認する必要があります。財産に対する十分な所有権）。 その際、所有権の譲渡が正しく行われ、以前の取引で使用された住宅ローンが全額返済されていることを確認する必要があります。 このモデルには、所有権よりもプライバシーが改善されているという利点があり、公有地登記簿の管理者に頼る必要はありません。 一方、買い手にとっては、売り手の所有権の確認がはるかに複雑になります。

未登記物件の譲渡はどうすれば改善できますか？ まず第一に、それをデジタル化することによって。 所有権移転のすべての履歴が元の契約規則に準拠していることを確認するためにコンピューターで実行できるコードがあれば、売買ははるかに迅速かつ安価になります。

第二に、売り手が資産を二重に使うリスクを回避するために、公開証明システムを実装する必要があります。 たとえば、すべての所有権の譲渡は、有名な新聞の事前定義された場所にコミットする必要があるというルールを実装できます (たとえば、ニューヨークの最初のページの右上隅に所有権の譲渡のハッシュを配置します)。回）。 転送のハッシュを同じ場所に XNUMX 回配置することはできないため、これにより二重支出の試みが防止されます。 ただし、この目的で有名な新聞を使用することには、いくつかの欠点があります。

1. 検証プロセスのために新聞をたくさん購入する必要があります。 あまり実用的ではありません。
2. 各契約には、新聞に独自のスペースが必要です。 あまりスケーラブルではありません。
3. 新聞の編集者は簡単に検閲したり、さらに悪いことに、スロットにランダムなハッシュを入れて二重支出をシミュレートしたりして、資産の潜在的な購入者に以前に売却されたと思わせ、購入を思いとどまらせることができます. あまり信用できない。

これらの理由から、所有権譲渡の証明を投稿するためのより良い場所を見つける必要があります。 そして、検閲耐性と分散化を維持するための強力なインセンティブを備えた、すでに確立された信頼できる公開台帳であるビットコイン ブロックチェーンよりも優れたオプションはありますか?

ビットコインを使用する場合、ニューヨーク タイムズの編集者と同じように、マイナーがそれを台無しにする可能性があるため、所有権を譲渡するというコミットメントが発生する必要があるブロック内の固定された場所を指定するべきではありません (たとえば、最初のトランザクション)。 より良いアプローチは、事前定義されたビットコイン トランザクション、より具体的には、発行される資産の所有権がリンクされている未使用のトランザクション出力 (UTXO) から発生するトランザクションにコミットメントを配置することです。 資産とビットコイン UTXO の間のリンクは、資産を発行するコントラクトまたはその後の所有権の譲渡のいずれかで発生し、ターゲット UTXO が譲渡された資産の管理者になるたびに発生します。 このようにして、所有権を譲渡する義務がどこにあるべきかを明確に定義しました (つまり、特定の UTXO から発生したビットコイン トランザクション)。 Bitcoin ノードを実行している人は誰でも独立してコミットメントを検証でき、マイナーも他のエンティティも、資産の転送を検閲し​​たり干渉したりすることはできません。

ビットコインのブロックチェーンでは、譲渡自体の内容ではなく、所有権譲渡のコミットメントのみを公開するため、売り手は、所有権譲渡が有効であるというすべての証拠を買い手に提供するための専用の通信チャネルを必要とします。 これは多くの方法で行うことができ、プルーフを印刷して伝書鳩で発送することもできますが、これは少し非現実的ですが、それでも機能します。 しかし、検閲とプライバシー侵害を回避するための最良の選択肢は、直接ピアツーピア暗号化通信を確立することです。これには、ハトと比較して、相手から受け取った証明を検証するソフトウェアと簡単に統合できるという利点もあります。

クライアント側で検証されたコントラクトと所有権の譲渡について説明したこのモデルは、まさに RGB プロトコルで実装されたものです。 RGB を使用すると、権利を定義し、それらを XNUMX つまたは複数の既存のビットコイン UTXO に割り当て、所有権の譲渡方法を指定するコントラクトを作成できます。 コントラクトは、「スキーマ」と呼ばれるテンプレートから作成できます。コントラクトの作成者は、従来の法的な契約と同様に、パラメータと所有権のみを調整します。 現在、RGB には XNUMX 種類のスキーマがあります。RGB20) と収集品を発行するための秒 (RGB21）、しかし将来的には、プロトコル レベルでの変更を必要とせずに、パーミッションレスな方法で誰でもより多くのスキーマを開発できるようになります。

より実用的な例を使用すると、代替資産 (会社の株式、ステーブルコインなど) の発行者は、RGB20 スキーマ テンプレートを使用して、発行するトークンの数、資産の名前、および関連する追加のメタデータを定義するコントラクトを作成できます。それと。 次に、どのビットコイン UTXO が作成されたトークンの所有権を譲渡する権利を持っているかを定義し、二次発行を行う権利や資産を再指名する権利など、他の UTXO に他の権利を割り当てることができます。 このコントラクトによって作成されたトークンを受け取る各クライアントは、Genesis コントラクトの内容を検証し、受け取ったトークンの履歴にある所有権の譲渡がそこに定められた規則に準拠していることを検証できます。

では、今日実際に RGB を使って何ができるでしょうか? 何よりもまず、トークン化された資産の発行と転送を、既存の代替手段と比較して優れたスケーラビリティとプライバシーで可能にします。 プライバシーの面では、RGB はすべての転送関連データがクライアント側に保持されるため、ブロックチェーン オブザーバーはユーザーの財務活動に関する情報を抽出できません (RGB コミットメントを含むビットコイン トランザクションを区別することさえできません)。さらに、受信者は、UTXO 自体ではなく、盲目的な UTXO (つまり、アセットを受信したい UTXO と乱数の間の連結のハッシュ) のみを送信者と共有するため、そうではありません。支払者が受取人の将来の活動を監視することが可能です。 ユーザーのプライバシーをさらに高めるために、RGB は防弾暗号メカニズムを採用して、資産譲渡の履歴の金額を隠します。これにより、資産の将来の所有者でさえ、以前の所有者の財務行動について難読化されたビューを持つことができます。

スケーラビリティに関しても、RGB にはいくつかの利点があります。 まず第一に、ブロックチェーンはコミットメントレイヤーとしてのみ使用されるため、ほとんどのデータはオフチェーンに保持され、支払う必要のある料金が削減され、各クライアントはすべてのトランザクションではなく、関心のある転送のみを検証します。グローバルネットワークの活動。 RGB 転送には依然としてビットコイン トランザクションが必要なため、手数料の節約は最小限に見えるかもしれませんが、トランザクションのバッチ処理を導入し始めると、すぐに膨大になる可能性があります。 実際、UTXO に関連付けられたすべてのトークン (または、より一般的には「権利」) を、XNUMX 回のビットコイン トランザクションで XNUMX 回のコミットメントで任意の量の受信者に転送することができます。 あなたが一度に複数のユーザーに支払いを行うサービスプロバイダーであると仮定しましょう。 RGB を使用すると、XNUMX 回のビットコイン トランザクションで、さまざまな種類の資産を要求する数千のユーザーに数千回の送金をコミットできるため、XNUMX 回の支払いの限界費用を完全に無視できます。

価値の低い資産の発行者が手数料を節約できるもう XNUMX つのメカニズムは、RGB では資産の発行に手数料を支払う必要がないことです。 これは、発行コントラクトの作成をブロックチェーン上でコミットする必要がないために発生します。 コントラクトは、新しく発行された資産が既存のどの UTXO に割り当てられるかを定義するだけです。 したがって、収集価値のあるトークンの作成に関心のあるアーティストであれば、無料で好きなだけ発行し、購入者が現れてトークンを UTXO に割り当てるように要求したときにのみ、ビットコイン取引手数料を支払うことができます。

さらに、RGBはビットコイン取引の上に構築されているため、Lightning Networkにも対応しています。 執筆時点ではまだ実装されていませんが、通常の Lightning トランザクションと同様に、アセット固有の Lightning チャネルを作成し、それらを介して支払いをルーティングすることが可能になります。

まとめ

RGB は、まったく新しいパラダイムを使用して新しいユース ケースを開く画期的なイノベーションですが、それを使用するためにどのツールが利用可能ですか? テクノロジー自体のコアを試してみたい場合は、直接試してみてください。 RGB ノード. プロトコルの複雑さを深く掘り下げることなく、RGB の上にアプリケーションを構築したい場合は、 rgb-lib ライブラリ、開発者にシンプルなインターフェースを提供します。 アセットを発行して転送したいだけの場合は、で遊ぶことができます Android用アイリスウォレット、そのコードはオープンソースでもあります GitHubの. RGBについてもっと知りたい場合は、チェックアウトできます このリソースのリスト.

これは Federico Tenga によるゲスト投稿です。 表明された意見は完全に独自のものであり、必ずしも BTC Inc または Bitcoin Magazine の意見を反映するものではありません。