6 月 10 日、RGB++ プロトコルの作成者で CELL Studio 創設者の Cipher、DotSwap 共同創設者の Lin、Shell Finance 共同創設者の Timxie、TBC (Turingbitchain) CMO NIGO が UTXO Stack の Twitter スペースにゲストとして登場し、UTXO モデルが使用できるかどうかについて議論しました。ビットコインエコロジーの新しいモデルの誕生。

UTXO スタックは、モジュール式の BTC L2 ワンクリック チェーン発行プラットフォームで、プロジェクト開発者が UTXO アーキテクチャに基づいてビットコイン L2 をワンクリックで発行できるようにし、RGB++ プロトコルをネイティブに統合します。セキュリティ面では、UTXO Stackはビットコイン、CKB、ビットコインL1の資産を担保することでL2のセキュリティを確保します。簡単に言うと、UTXO スタックは、ビットコイン エコシステムの OP スタック + EigenLayer と考えることができます。

UTXO Stackは、ABCDEとSNZ Capitalが共同主導し、OKX Ventures、Waterdrip Capital、Matrixport、y2z Ventures、DRK Lab、ベンチャーキャピタル部門UTXO Managementなどの著名な機関の参加を得て、シードラウンドの資金調達を完了した。 Bitcoin Magazine の親会社 BTC Inc.

以下は、音声に従って整理された主要なコンテンツです。

1. 設計哲学、セキュリティ、効率などの観点から、UTXO モデルとアカウント モデルの本質的な違いと利点は何ですか?

Cipher: 主に設計哲学と効率においていくつかの違いがあると思います。セキュリティはコンセンサス メカニズムに依存する部分が大きく、アカウント モデルとはほとんど関係がありません。

設計哲学の観点から見ると、UTXO は実際には計算よりも検証に重点を置いています。イーサリアムのアカウント モデルはわかりますが、送信した結果はアクションや関数呼び出しだけです。トランザクションはブロックにパッケージ化されるまで結果はわかりません。

典型的な例としては、アカウントに 0.1 ETH しかない場合、0.2 ETH を送金するトランザクションを送信できますか?はい、送信することはできますが、トランザクションがトランザクション プールに入った後、パッケージ化されてエラーが返される可能性があります。資金がそれほど多くないためですが、ガス料金は差し引かれます。しかし、あなたが送金するのと同時に誰かがあなたのアカウントにたまたま大金を送金し、あなたのアカウント残高が 0.2 ETH を超えた場合、あなたの取引は正常に実行され、もちろんガス料金は差し引かれます。

ただし、UTXO モデルの場合、アカウントに十分な資金がなく、十分な入力を収集できないため、トランザクションを送信できません。したがって、UTXO モデルではトランザクションの失敗などの状態は存在せず、トランザクションの成功または送信の失敗の 2 つの状態しかありません。つまり、いわゆるトランザクションの失敗は検証が失敗したことを意味し、手数料はかかりません。差し引かれます。 UTXOは、ブロックチェーンは計算機ではなく検証機であると考えており、アカウントモデルを使用するイーサリアムはかつて世界コンピューターと呼ばれていた計算機であり、これとは全く異なる設計思想です。

効率の点でも、両者の間には非常に大きな違いがあります。 UTXO は、以前にどの状態が使用されていたかを明確に示し、それを破棄して新しい状態に更新します。イーサリアムが関数を呼び出す場合、呼び出し前にどの状態にアクセスするかわからないため、最悪のシナリオ、つまりすべての状態の前処理が行われないシナリオのみに対処できます。したがって、イーサリアムの各トランザクションは連続的にのみ実行できます。通常のデスクトップ コンピューターには少なくとも 6 コアと 12 スレッドの CPU が搭載されていますが、標準の EVM の場合は依然として単一スレッドで実行されます。 UTXO は当然ながら並列であり、競合するトランザクションであってもトランザクション プールに送信されません。 。もちろん、この問題を何らかの形で解決しようとする並列EVMという言説も今は存在しますが、本質的には解決できないことは、今の説明からも誰でも分かると思います。

Tim Xie: 私は、Cipher が今言ったことに非常に同意します。「ビットコインの UTXO モデルは検証に重点を置き、イーサリアムのアカウント モデルは計算に重点を置いています。」 DeFi サマー期間中はいくつかのスワップが行われ、イーサリアムのガス料金は非常に高くなりますが、イーサリアムはビットコインよりもブロックの生成速度が速く、ブロックが大きく、パフォーマンスが優れていますが、拡張の需要は実際にはビットコインよりも高いです。ビットコイン。なぜ？その理由は、イーサリアムがコンピューティング モデルであるためです。 DeFi をプレイする場合、支払うガス料金の 98% が計算に費やされる可能性があります。アカウント ステータスの検証、伝達、保存にかかるコストは実際には非常にわずかです。ビットコインは計算を行わない検証ネットワークであるため、同じシナリオでレンディングやスワップを行うと、実際にはイーサリアムよりも手数料が安くなります。

2 つ目は同時実行性です。 EVM シリアルはなぜ UTXO と併用できるのかをわかりやすく説明しました。イーサリアムで融資を行う場合、ビジネス ロジックでは担保が必要であるため、借りる前に入金する必要があります。また、正味価値を計算するには、住宅ローン取引が確認され、ステータスが固定されるまで待つ必要があります。担保の支払いや、お金を借りるための清算の基準など、すべてが連続しています。 UTXO は同時実行が可能で、すべてのトランザクションを可能な限り圧縮できるため、ユーザーの預金トランザクションと借入トランザクションをマージして効率を向上させることができます。

私たちの観点から見ると、ビットコインの DeFi に UTXO モデルを使用すると、最終的なユーザー エクスペリエンスは人々が想像するほど悪くはありません。ただし、エクスペリエンスはイーサリアムやアービトラムのアプリケーションほどスムーズではありませんが、それでもそれほど悪くはなく、まだ使用可能です。

林：補足させてください。既存の技術は常に進化していると思いますが、UTXO は計算を行うことはできません。たとえば、最近議論されたビットコイン オペレーション コード OP_CAT は、有効にするとビットコインの UTXO に状態を保持できます。ビットコインのネイティブな制限をすべて取り除くと、ビットコインのUTXOで無数のイーサリアムをシミュレートし、その状態でデータを保存し、実行することができます。ただし、これによって完全な EVM 互換性が必ずしも達成されるわけではありません。

つまり、ビットコインでも計算が可能であり、いつでも新しいスレッドを開くことができ、いつでも新しいUTXOを分割できるというのがビットコインのロジックだと思います。新しいUTXOは元のUTXOから完全に分離されます。ビットコイン コンピューティングにおける UTXO の特徴。

OP_CAT を追加すると、非常に賢いアプリケーション シナリオが実現します。たとえば、イーサリアム ERC-20 トークンは、どのアカウントがどれだけの資金を持っているかを知るためのリストを維持します。OP_CAT を追加すると、ビットコインでも同様のことが可能になり、イーサリアムよりも優れた結果が得られる可能性もあります。

UTXOの中でもデータ共有は実は未知の部分が大きい。例えば、コベナント（制限事項）の構築にはまだ時間がかかりますが、この件が進めば、異なるUTXO間でデータを共有する方法や、トランザクション内でトランザクション外のデータを参照する方法などがブレークスルーとなる可能性があります。

NIGO: 私はいつもイーサリアムがビットコインのUTXOモデルをアカウントモデルに変更したと思っていましたが、これは実際には典型的な余分なステップであり、元々同時実行が可能だったシステムをシリアルシステムに変えてしまいます。イーサリアムは多くの人々から世界のコンピューターと呼ばれていますが、なぜ一般人の計算タスクが世界中のマイナーによって計算される必要があるのでしょうか?このプロセスは大量のエネルギーを消費し、非常にコストがかかるにもかかわらず、実質的なメリットは得られず、遅延が発生します。全体的な効率。イーサリアムが PoS に切り替わった後、ネットワーク全体のマイナー (ノード) は進化の勢いを失いました。サトシ・ナカモトによって設計された UTXO モデルは、当然ながら高同時実行性と高性能に適しています。より多くの Web3 ユーザーが UTXO モデルの可能性を理解するでしょう。

2. ビットコインにスマートコントラクト機能がない原因はUTXOモデルですか? UTXO モデルに基づいてスマート コントラクト機能を実装したい場合、それを実現するために一般的にどのようなメカニズムが使用されますか?

Cipher: UTXO モデルに基づいてスマート コントラクト機能を実装する方法は確かにたくさんあります。私が最もよく知っている CKB がどのように実装されているかを紹介しましょう。

CKB は、ビットコインのロック スクリプトと一致するロック スクリプトを導入しました。この UTXO が使用されると、ロック スクリプトが監視内のデータに基づいて入力として使用され、現在のトランザクションも使用されます。を入力として実行します。これとビットコインのロック スクリプトの違いは、ビットコインの非常に限定されたスクリプト環境ではなく、完全なチューリング完全仮想マシンをサポートしているため、ロック解除のこの段階ではチューリング完全です。

同時に、CKB は、入力か出力かに関係なく実行されるタイプ スクリプト フィールドを導入しました。これは、アセットのカテゴリとして実行されるか、同じタイプが同じタイプのアセットを表します。たとえば、代替可能トークンの総量は取引の前後で変化せず、代替不可能なトークンの量と内容は取引の前後で変化しません。または、誰が新しいトークンを発行する権利を持っているかを決定するために使用できます。資産などこれはチューリング完全 VM そのものでもあります。

CKB の仮想マシンは RISC-V ハードウェア命令セットに基づいており、調整には再シリコンが必要となるため、RISC-V 命令セットの設計は非常に合理的で効率的かつ包括的です。

要約すると、CKB は Turing Complete である RISC-V 仮想マシンを使用しており、スマート コントラクト スクリプトを保存するためのロック スクリプトとタイプ スクリプトの 2 つの場所もあり、スマート コントラクト スクリプトを保存するためのデータと呼ばれるフィールドもあります。契約の状態を把握できるため、完全な契約実行環境となります。

Tim Xie: Shell Finance の製品構築プロセス全体では、融資プロトコルと清算を行う必要があるため、最終的には DLC (Discreet Log Contracts) を選択しました。 DLCとLightning Networkはどちらも同レベルの拡張技術であり、どちらもオフチェーンである点が異なります。Lightning Networkは主に決済に使用され、DLCは主にオラクルに使用されます。実はまだチューリングが完成しておらず、まだまだ制約が多いのですが、たとえ制約が多くても、すでにDLCを通じてレンディングが可能になっています。

実際、ビットコインには多くの OP コードがあり、以前に DotSwap の Lin が言及した OP_CAT やその他のオペコードを有効化またはロック解除できれば、実際にライトニング ネットワークや DLC に沿ってさらに多くのオペコードを作成し続けることができます。 、スマートコントラクトは間違いなくそれを行うことができます。重要な点は、需要があるかどうか、ユーザーがいるかどうか、市場が存在するかどうか、そしてより多くの人がそれを考案し、使用し、ユーザーのニーズを満たすために時間とエネルギーを投資するかどうかです。使う人がいてマーケットがある限り、自然と新しいアイデアやコンセプトが出てきます。

私が今確信しているのは、ビットコインのエコシステムの形はEVMのそれとはまったく異なるものになるだろうということです。おそらくビジネスレベルでは、ユーザーは同じような感情を持っているかもしれません。どちらもスワップと融資を行っており、オラクルもありますが、その背後にあるシステムと最終的に使用できるツールは実際には大きく異なります。それがビットコインのメインネット上にある場合、その差はさらに大きくなります。そのため、より優れた UTXO 構造を備えた L2 がビットコイン エコシステムの可能性を最大限に引き出すことができるため、私は実際に期待しています。

リン: チューリング完全なものを設計することは難しくないと思いますが、チューリング不完全なものをチューリング不完全なものにすることは、実際には非常に高度な技術的な作業です。

ビットコインの元のスクリプトはチューリング完全である可能性がありますが、現在ではビットコインの多くの機能が封印されています。たとえば、前述した OP_CAT は非常に重要な機能ですが、この機能はビットコインにこれ​​らがなかったと言うのではなく、オペレーターによって無効にされています。最初に設計されたときの演算子。ビットコインは当初多くの事業者が関与していましたが、いわゆるセキュリティ、あるいはそのセキュリティに隠れた危険性、あるいはそれが何であるか、どのように使用するかなどが明確に理解されていなかったため、一部の演算子は無効になっています。さらに、スマート コントラクトに使用できたはずの多くの機能が、いわゆる標準トランザクションによってフィルタリングされています。ビットコインは分散型システムであると誰もが言いますが、この分散型システムには、特定の組織によって決められた標準トランザクションと呼ばれるものがあります。マイナーはあらゆる法的トランザクションをパッケージ化できるため、標準トランザクションはユーザー側に基づいたポリシーの問題です。

したがって、一般的に、元のビットコイン自体の能力は非常に強力だと思いますが、現在ビットコインはハイジャックされています。興味がある場合は、ロジャー・バーの著書「ハイジャック・ビットコイン：BTCの隠された歴史」を読むことができます。ビットコインの本来の性能が封印されてしまったために、様々なところで活路を見出さざるを得なくなっているのが現状ですが、ビットコインの将来は確実に良くなります。

私は、いわゆるビットコイン L2 の多くは実際には寄生プロトコルであり、ビットコインにそれ自体の価値を提供するものではなく、マイナーがより高い収入を得られる方法はない、と述べてきましたが、実際にはその方法はありません。ビットコインには多くの制限があります。たとえて言えば、HTTP プロトコルは実際には TCP/IP プロトコルに基づいて構築された L2 であり、HTML プロトコルは HTTP プロトコルに基づいて構築されています。これは、トランザクション データが TCP/IP から完全に分離され、上位層のプロトコルから分離され、別の場所に実行され、その後向きを変えて、これがレイヤー 2 であることを他の人に伝えるというよりも、レイヤーごとの概念だと思います。プロトコル。実際のレイヤー 2 プロトコルは実際にはレイヤーごとに積み重ねられているため、構築する L2 も上位レイヤーで合法的なトランザクションとして受け入れられる必要があります。これは、現在スワップの 1 つのレイヤーを検討している非常に重要な理由です。私たちは、ほとんどの場合、実際には 1 つのレイヤーに落ち着く必要があり、いわゆるアセットブリッジを構築してから全員の資産を移動すると言うのではなく、最初のレイヤーに関する多くの検証と合意が必要であると考えています。資産を別の場所に移す これは特に良いことではないかもしれない場所。

NIGO: UTXO モデルは複雑なスマート コントラクト機能をサポートできますか?もちろん可能です。コントラクトのロジックとデータを UTXO に保存し、コントラクトの呼び出しとパラメーターを入力として使用してコントラクトのロックを解除しようとし、BVM (ブロックチェーン仮想マシン) を通じてコン​​トラクトのロジックを実行し、最終的にリターンすることで制御を実現します。ロック解除機能からの true または false。このモデルはイーサリアム スマート コントラクトの開発者には馴染みのないものかもしれませんが、実際には、関数型プログラミングのアイデアを組み合わせていくつかの概念を変換すると、UTXO スマート コントラクトは非常に複雑なロジックを実装できます。

UTXO モデルにはグローバル状態がないため、コントラクトの状態とロジックを UTXO に保存し、UTXO トランザクション コール チェーンの送信を通じて状態を転送および変換する必要があるため、各 UTXO トランザクションは以前の状態を消費します。 UTXO を作成し、新しい UTXO を生成することで、コントラクトのチェーン状態転送を実現できます。したがって、UTXO のロックを解除できるかどうかは、コントラクトの実行結果と状態遷移を許可するかどうかに対応します。転送が許可されていない、データの変更が許可されていないなど、ステータスの変更が許可されていないとコントラクトが判断した場合、 false が返され、UTXO のロックは解除されず、コントラクトの実行は失敗します。

コントラクトをデータの状態を転送するステート マシンとみなします。そのため、ここで UTXO コントラクトとアカウント タイプのコントラクトの違いがわかります。アカウント コントラクトの EVM はグローバル状態を維持するため、コントラクトが実行されるかガスが消費されるまで、トランザクションにより EVM が複数の状態転送を実行し、状態データを頻繁に変更することがあります。 UTXO コントラクト トランザクションに関しては、これは入力コントラクトであり、呼び出しは状態転送をトリガーするだけであり、コントラクト内のロジックがどれほど複雑であっても、状態が何回転送されても、BVM は最終的な状態転送のみを記録します。結果がチェーンに加わります。したがって、UTXO コントラクトにはグローバル状態はなく、実行を待機している関数のみがあります。

UTXO は多入力多出力です。Monad もやりたい並列 EVM を含め、イーサリアムがやりたいことは、実際に UTXO を通じて実現できます。状態を転送する必要がある場合、まずその状態が存在する関数を見つける必要があります。このモデルは、UTXO コントラクトの状態転送をより明確にします。

UTXO コントラクトは外部状態に依存しないため、コントラクトが何度呼び出されても、その結果は確実である必要があるため、コントラクトの分析、デバッグ、単体テストに大きな利便性をもたらします。 EVM契約はグローバルな状態に依存するため、契約の実行結果が外部環境の影響を受けやすく、たとえば残高が十分であれば1つになるなど、契約の実行結果が不確実になります。結果が十分でない場合は、別の結果になります。したがって、これは EVM 契約のセキュリティと予測可能性にとって重要な問題でもあります。

もちろん、トレーサビリティが必要な一部のシナリオでは、トレーサビリティを検証する必要があり、データが増えるにつれてステータスが増加する可能性があります。それ自体が無限に広がります。私たちの TBC は、他のテクノロジーや、ハッシュやデータ抽出などの暗号化手段を通じて、状態拡張という大きな問題を解決しました。したがって、TBC のスマート コントラクトを他の UTXO チェーンと区別する重要な特徴は、UTXO モデルが TBC の無制限の拡張の基礎であることです。UTXO モデルを使用して標準の転送トランザクションを実行するのは非常に簡単です。

要約すると、TBCはUTXOモデルの長所と短所を十分に考慮し、イーサリアムやその他のUTXOパブリックチェーンの本質を吸収することに基づいて、BVMの概念とUTXOスマートコントラクトの実際の層を実装するその他のテクノロジーを導入します。より使いやすいスマート コントラクト開発ツールと組み合わせることで、BVM スマート コントラクトの作成と展開の敷居が低くなります。

（つづく）