UTXOの独自性は新たな生態系モデルを生み出せるか？(前の記事）

6月10日、RGB++プロトコルの作者でありCELL Studioの創設者であるCipher氏、DotSwapの共同創設者であるLin氏、Shell Financeの共同創設者であるTimxie氏、そしてTBC（Turingbitchain）のCMOであるNIGO氏がUTXOスタックのTwitterスペースにゲストとして登場した。NIGOがUTXOスタックのツイッタースペースにゲストとして登場し、UTXOモデルがビットコインのエコシステムに新たなパラダイムをもたらすかどうかについて語った。

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

UTXOスタックは、OKXベンチャーズをリード投資家として、ABCDEとSNZキャピタルが主導するシードラウンドの資金調達を完了した。

UTXOスタックは、OKXベンチャーズを筆頭に、OKXベンチャーズ、Waterdripキャピタル、Matrixport、y2zベンチャーズ、DRKラボ、そしてビットコインマガジンの親会社であるBTC Inc.のベンチャーキャピタル部門であるUTXOマネジメントが続きます。

以下は、音声に基づくハイライトです：

1.設計思想、安全性、効率性などの点で、UTXOモデルとアカウントモデルの本質的な違いや利点は何ですか？

サイファー：設計思想と効率性には若干の違いがあると思いますし、セキュリティはおそらくコンセンサスメカニズムに関するもので、アカウントモデルとはあまり関係がないでしょう。

設計思想ですが、UTXOは実際には計算よりも検証です。私たちはイーサリアムのアカウントモデルを知っています。プログラムを書いたり、トランザクションを送信したりするとき、そのトランザクションの結果はわかりません。

典型的な例として、アカウントに0.1ETHがあるとします。はい、送ることはできますが、おそらくプールに入り、パックアップされ、それだけのお金を持っていないのでエラーを返しますが、ガス料金はまだ差し引かれます。

しかし、UTXOモデルの場合、アカウントに十分な資金がないため、送ることができません。UTXOモデルには取引失敗の状態はなく、取引成功か送金失敗の2つの状態しかない。つまり、いわゆる取引失敗は検証の失敗であり、手数料を差し引かれることはない。 UTXOはブロックチェーンは計算機ではなく検証機だとさえ考えている。アカウントモデルを採用するイーサはかつて「世界のコンピュータ」というニックネームで呼ばれていた。ワールド・コンピューターは、計算するためのものであり、全く異なる設計思想である。

効率という点でも非常に大きな違いがあります。UTXOでは、どの状態が以前に使用されていたかを明示的に示し、それを破棄して新しい状態に更新します。一方イーサネットは、関数呼び出しの時点では呼び出し前にどの状態にアクセスするかわからないので、すべての状態の前処理を行わないという最悪のケースを想定して対処しなければなりません。その結果、イーサは各トランザクションをシリアルにしか実行できません。平均的なデスクトップコンピュータは少なくとも6つのコアと12のスレッドを持つCPUを持っていますが、標準的なEVMの場合はまだシングルスレッド実行です。UTXOとは異なり、UTXOは当然並列であり、そのすべてのトランザクションは競合するトランザクションと自動的に区別され、競合するトランザクションであってもトランザクションプールには送られないので、UTXOブロックチェーンの効率はアカウントモデルよりもかなり高い。もちろん、現在ではこの問題を何らかの形で解決しようとするパラレルEVMと呼ばれる物語もありますが、先ほどの説明でお分かりのように、本質的な解決にはなりそうもありません。

Tim Xie: 今サイファーが言った「ビットコインのUTXOモデルはより検証指向で、イーサリアムのアカウントモデルはより計算指向」に同意します。".私たちがDeFi Summerでスワップをしに行ったとき、イーサリアムのガス代はとても高く、イーサリアムはビットコインに比べてブロックから出るのが速く、ブロックも大きく、パフォーマンスも良いのですが、イーサリアムのスケーリングの必要性は実はビットコインよりもさらに高いのです。なぜか？イーサリアムは計算モデルだからです。私たちがDeFiをプレイするとき、ガス料金を支払いますが、おそらくその98%は計算に費やされ、検証、伝播、アカウント状態の保存にはほとんど費やされません。ビットコインは検証ネットワークであり、計算を行わないので、同じシナリオでビットコインのセカンドレイヤーでレンディングやスワッピングを行う場合、手数料はイーサリアム側よりも安くなります。

2つ目は並行性で、なぜEVMはシリアルなのか、サイファーが非常に明確に説明しましたが、UTXOは並行性を実現できます。Etherで融資を行う場合、お金を借りる前にお金を預ける必要があります。ビジネスロジックでは担保が必要で、担保付き取引が確認され、状態が確定するのを待つ必要があります。一方、UTXOは並行処理を行うことができ、すべてのトランザクションを可能な限り圧縮することができます。つまり、ユーザーの入金トランザクションと借入トランザクションをマージすることができ、効率が向上します。

私たちの経験からすると、ビットコイン上のDeFiにUTXOモデルを使用することは、人々が思っているほどユーザーにとって悪い経験にはなりません。

Lin: 一つ付け加えます。既存の技術は進化していますUTXOは計算をしないのではなく、同じように計算可能だと思います。例えば、最近みんなが話題にしているビットコインのオペコードOP_CATは、有効にするとビットコインのUTXOで状態を保持できるようになります。さまざまなビットコインネイティブの制限を取り除けば、ビットコインの UTXO で無限のイーサリアムをエミュレートでき、それぞれがイーサリアムのステートとなり、そのステートでデータと実行を継続することで、ステートをずっと外挿できるようになりますが、これは必ずしも完全な EVM 互換ではありません。

ですから、ビットコインも同様に計算を行うことができると思います。ビットコインのロジックは、いつでも新しいスレッドを開始することができ、いつでも新しいUTXOを分割することができ、新しいUTXOは元のUTXOから完全に切り離され、これがビットコインのUTXOの計算の特徴の1つです。

OP_CATの追加は、いくつかの非常に巧妙なアプリケーションシナリオにつながるでしょう。たとえば、Ether ERC-20トークンは、どの口座にどれだけのお金が入っているかのリストを管理しています。OP_CATを追加することで、ビットコインでもEtherと同じようなこと、そしておそらくそれ以上のことができるようになります。

UTXOでは、データ共有は実は大きな未知の領域です。たとえばコベナンツはまだ進行中であり、これが前進すれば、UTXO全体でデータを共有する方法や、トランザクションの外のデータをトランザクションで参照する方法などにブレークスルーがあるかもしれません。

NIGO：イーサがビットコインのUTXOモデルからアカウントベースモデルに変更したのは、問題を追加し、並行処理が可能なシステムをタンデムシステムに変えた典型的なケースだと常々思っています。 イーサは世界のコンピュータとして多くの人に知られており、なぜ一般人の計算タスクを世界中のマイナーによって計算されなければならないのか。このプロセスは膨大なエネルギーを使用し、コストがかかるが、実質的な利益をもたらさず、かえって全体的な効率を遅らせる。イーサがPoS化された後、ネットワーク全体のマイナー（ノード）は進化の勢いを失った。サトシ・ナカモトによって設計されたUTXOモデルは、高い同時実行性と高いパフォーマンスに自然に適しており、より多くのWeb3ユーザーがUTXOモデルの可能性を見出すと信じています。

2.UTXOモデルは、ビットコインにスマートコントラクト機能を持たせなかったのでしょうか？スマートコントラクト機能がUTXOモデルの上に実装される場合、一般的にどのようなメカニズムが使用されますか？

サイファー: UTXOモデルの上にスマートコントラクト機能を実装する方法は確かにいくつかあります。

CKBはロックスクリプトを導入します。これはビットコインのロックスクリプトと同じで、入力として証人にあるデータと現在のトランザクションに基づいて、UTXOが使われたときに自動的に実行されます。ロックスクリプトはUTXOが消費されると自動的に実行される。ビットコインのロックスクリプトとの違いは、ビットコインの非常に限られたスクリプト環境とは対照的に、完全なチューリング完全仮想マシンをサポートしていることです。

同時に、CKBは入力と出力の両方で実行されるタイプスクリプトフィールドを導入しており、それはより資産のクラスとして、または同じ資産に対して同じタイプとして実行されます。例えば、トランザクションの前後でカビ可能なトークンの総量が変わらない、トランザクションの前後でカビ不可能なトークンの量が変わらない、コンテンツが変わらない、あるいは誰がどのように新しいアセットを発行する権利を持っているかを決定するために使用される、などです。

CKBのVMは、RISC-Vハードウェア命令セットに基づいており、どのような調整もチップの再フローを伴うため、RISC-V命令セットは非常に合理化され、効率的で、よく練られています。

要約すると、CKBはチューリング完全なRISC-V VMを使用しており、スマート・コントラクト・スクリプト用のロック・スクリプトとタイプ・スクリプト、スマート・コントラクト・ステータス用のデータ・フィールドを持っています。また、スマート・コントラクト・スクリプト用のロック・スクリプトとタイプ・スクリプト、スマート・コントラクト・ステータス用のデータ・フィールドを備えています。

Tim Xie: シェルファイナンス製品を構築する過程で、融資プロトコルと清算を行いたいため、高度なコントラクト機能が必要になりました。私たちはDLC（Discreet Log Contracts）を選びました。DLCはライトニング・ネットワークと同レベルのスケーリング技術で、オフチェーンですが、ライトニング・ネットワークが主に決済用であるのに対し、DLCは主にオラクル用という違いがあります。私たちはチューリング完全ではなく、まだ多くの制約がありますが、そうした制約があっても、DLCを通じて融資を行うことができています。

ビットコインには多くのOPコードがあります。ドットスワップの林氏が言及したOP_CATや、その他のOPコードのようなものを有効にしたり、ロックを解除したりすることができれば、ライトニングネットワークやDLCの路線に沿って進み、より多くの可能性を生み出すことができますし、スマートコントラクトは間違いなく可能です。スマート・コントラクトは間違いなく可能です。核心的なポイントは、需要があるかどうか、ユーザーがいるかどうか、市場があるかどうか、それを構想し、利用し、ユーザーのニーズを満たすために時間とエネルギーを投資する人がいるかどうかにある。それを使う人がいて、市場がある限り、新しいアイデアや新しいコンセプトは自然に生まれてくる。

ビットコインのエコシステムは、EVM側とは全く異なるものになると確信しています。おそらくビジネスレベルでは、ユーザーエクスペリエンスは似ていて、同じスワップアンドレンディングであり、同じオラクルですが、その背後にあるシステムや最終的に使用できるツールは大きく異なります。メインのビットコインネットワーク上であれば、その差はさらに大きくなります。そのため、より優れたUTXO構造を持つL2が、ビットコインエコシステムの可能性をより大きく解き放つことができるため、私は実際に楽しみにしています。

林氏：チューリング完全であるように何かを設計するのは本当に難しいことではなく、むしろチューリング不完全であることが難しく、チューリング完全でないようにスクリプトを設計するのは非常に高度な技術的課題だと思います。

ビットコインのオリジナルのスクリプトはチューリング完全でした。ただ、ビットコインの機能の多くが、現在ブロックされています。たとえば、先ほど述べたOP_CATは非常に重要な機能ですが、オペレーターによって無効化されています。ビットコインは当初、このようなオペレーターなしで設計されました。ビットコインは当初、多くのオペレータを備えていましたが、いわゆるセキュリティ、いわゆるセキュリティ上の懸念、あるいはオペレータが何であり、どのように機能するのかが明確でないなどの理由から、特定のオペレータは無効化されました。しかも、スマートコントラクトに利用できたはずのこの機能の多くは、いわゆる標準的な取引によってフィルタリングされている。ビットコインは分散型システムだとみんな言っていますが、この分散型システムには意外なことに標準取引というものがあって、これは特定の組織によって決められています。マイナーはどんな正当な取引でもパッケージ化することができるため、マイナーの領域には標準的な取引は存在しません。

つまり、全体として、オリジナルのビットコインの能力はそれ自体非常に強力だったと思います。BTCの隠された歴史。ビットコインの生の力は封印されているため、私たちはあらゆる場所で道を探すことを余儀なくされている、それが今直面している現状だが、ビットコインの未来、そしてビットコインの未来は間違いなく良くなっている。

私は、今世の中にあるいわゆるビットコインL2の多くは、実はビットコインに価値を貢献していないパラサイトプロトコルであり、マイナーの所得を高くする方法はないと言ってきましたが、ビットコインは非常に制約が多いため、本当に方法がないのです。例えるなら、HTTPプロトコルはTCP/IPプロトコルの上にL2が構築されており、私たちのHTMLプロトコルはHTTPプロトコルの上に構築されています。トランザクションデータをTCP/IPから完全に分離し、プロトコルの上位レイヤーから分離し、別の場所で実行し、戻って人々にこれはレイヤー2プロトコルだと言うのではなく、レイヤーバイレイヤーの概念だと思います。真のレイヤー2プロトコルは、実際には1つのレイヤーの上にもう1つのレイヤーが積み重ねられているので、私たちが構築しようとしているこれらのL2は、上位レイヤー内部でも正当なトランザクションとして受け入れられるべきです。これが、私たちが今スワップのレイヤーを模索している大きな理由のひとつです。いわゆるアセットブリッジを作って、みんなの資産を別の場所に移動させようというのとは対照的です。

NIGO: UTXOモデルは複雑なスマートコントラクト機能をサポートできますか？もちろん可能です。コントラクトのロジックとデータをUTXOに格納し、コントラクトの呼び出しとパラメータを入力として使用してコントラクトのロックを解除しようとし、BVM（ブロックチェーン仮想マシン）を通じてコントラクトのロジックを実行し、最終的にロック解除関数を通じてtureまたはfalseを返すことで、コントラクトの状態を制御するという目的を達成します。このパターンはイーサリアムのスマートコントラクト開発者にとっては少し奇妙かもしれませんが、実際には、関数型プログラミングのアイデアをいくつかの概念変換と組み合わせれば、UTXOスマートコントラクトは非常に複雑なロジックを実現できます。

UTXOモデルは、グローバルな状態が存在しないため、コントラクトの状態とロジックをUTXOに保存し、UTXOトランザクション呼び出しの連鎖を通じて状態を渡し、変換する必要があります。UTXOトランザクションはそれぞれ、前のUTXOを消費して新しいUTXOを生成する。したがって、UTXOをアンロックできるかどうかは、コントラクトの実行結果、つまり状態を転送できるかどうかに対応する。コントラクトが、転送を許可しない、データの変更を許可しないなど、状態の変更を許可しないと判断した場合、falseを返し、UTXOのロックは解除されず、コントラクトの実行は失敗する。

コントラクトをデータの状態を転送するステートマシンと考えることで、UTXOコントラクトとアカウントベースコントラクトの違いがわかります。アカウントベースのコントラクトのEVMはグローバルな状態を維持し、1つのトランザクションがEVMに複数の状態転送を実行させる可能性があり、コントラクトが実行されるかガスが消費されるまで、状態データが頻繁に変更される。一方、UTXOコントラクトのトランザクションはインプットコントラクトであり、状態遷移のトリガーは1回のみである。コントラクトの内部ロジックがいかに複雑で、状態遷移が何回行われたとしても、BVMは最終的な状態遷移の結果のみをチェーン上に記録する。そのため、UTXOコントラクトはグローバルな状態を持たず、実行待ちの関数のみを持ちます。

UTXOはマルチインプット・マルチアウトプットであり、モナドを含むEtherCorpがやりたい並列EVMは、実際にはUTXOで実現できます。 ステートを転送する必要がある場合、ステートがある関数を見つけ、関数呼び出しによってステートを変更し、新しい関数を生成する必要があります。このパターンによって、UTXOコントラクトの状態転送がより明確になる。

UTXOコントラクトは外部のステートに依存しないため、コントラクトの呼び出しは、何度呼び出されても、常に特定の結果になります。一方、EVMコントラクトはグローバルな状態に依存するため、コントラクトの実行結果は外部環境の影響を受けやすく、例えば残高が十分であればある結果になり、十分でなければ別の結果になるなど、コントラクトの実行結果に不確実性が生じます。つまり、これはEVM契約の安全性と予測可能性にとって重要な問題なのです。

もちろん、毎回状態を受け渡すことにコストがかからないわけではありません。 トレーサビリティが要求されるシナリオでは、トレーサビリティにはチェックサムが必要なため、UTXOの受け渡しの連鎖が増えるにつれて状態が増大する可能性があり、受け渡すデータが増えれば増えるほど、状態自体が無限に膨れ上がることになります。私たちTBCは、ハッシュやデータ抽出といった他の技術や暗号的手段によって、ステートの膨張という大きな問題を解決してきた。したがって、他のUTXOチェーンと異なるTBCのスマート・コントラクトの重要な特徴は、UTXOモデルがTBCの無限膨張を実行するための基礎であり、UTXOモデルで標準的な送金トランザクションを非常に簡単に実行できることです。

まとめると、TBCはUTXOモデルの長所と短所を十分に考慮し、イーサリアムや他のUTXOパブリックチェーンのエッセンスを取り入れた上で、BVMの概念やその他の技術を導入し、真のワンレイヤーUTXOスマートコントラクトを実装しました。開発ツールと組み合わされ、BVMスマート・コントラクトの記述と展開の敷居を下げています。