MeerToken シリーズ - UTXO モデル VS アカウントモデル

KAHF ウォレットのベータ版を開き、Meer (テストネット) に切り替えます。友人たちは、Meer 通貨に加えて、QITID と METID というかわいい名前の資産が 2 つあることに気づいたはずです。これら 2 つは、Qitmeer の MeerToken 資産発行システムによって発行された第 1 世代のセカンダリ資産です。普通に見えるかもしれませんが、実はとても興味深いものです。

Qitmeer は設立当初から、このプロジェクトを包括的な価値循環のインフラストラクチャとして位置付けており、基盤となるパブリックチェーンには安定性、セキュリティ、効率性が求められます。そのため、MeerToken 資産発行システムの元帳では、当時普及していたアカウントモデルを採用せず、より安定した従来の UTXO モデルを採用しました。

一見単純に見える元帳モデルの選択には、実際には難しいトレードオフが伴います。これは、価値循環モデルを選択するだけでなく、より重要なのはスマートコントラクトモデルを選択することだからです。 UTXO はすでに価値の循環という点で十分に有用であり、新しい元帳モデルを再発明する必要がないため、アカウントモデルは Ethereum スマートコントラクトとともに登場しました。イーサリアムに代表される「スマートコントラクトこそ正義」のいわゆる「ブロックチェーン2.0」時代では、多くの新しいパブリックチェーンプロジェクトがスマートコントラクトの迅速なサポートを優先し、イーサリアムのコードに基づいて直接拡張することになります。基礎となる元帳モデルがプロジェクトの位置付けと一致しているかどうかについては、優先事項ではありません。

スマートコントラクトのエンジニアリング実装を優先することは、コミュニティの認知を追求するほとんどのプロジェクトにとって合理的な選択ですが、 Qitmeerと同様のコンセプトを持つプロジェクトも存在します。私の知る限り、 NervOSの元帳モデルCell は拡張UTXOモデルであり、そのスマートコントラクトはオフチェーンのコントラクトジェネレーター(Generator)によって生成および計算されますが、オンチェーンで検証されます。これの利点は、オンチェーン計算が非常に簡単になり、安定性が大幅に向上し、スマートコントラクトのプログラミングインターフェースが非常に柔軟かつ効率的になることです。たとえば、現在の開発フレームワークCapsule は、 Rustなどの安全で効率的な高級言語に基づいています。 Ethereumのスマートコントラクト言語Solidityよりも強力な言語表現能力と開発環境を備えています。必要に応じて、将来的には他の言語での開発フレームワークをサポートすることもできます。

まず、スマートコントラクトがサポートされているかどうかは、アカウントモデルであるか UTXO であるかとは必ずしも関係がないことを述べておく必要があります。スマートコントラクトがサポートされているかどうかは、トランザクションが全順序をサポートしているかどうかにのみ関係します。これは簡単に理解できます。なぜなら、2 つの同時トランザクションに同じスマートコントラクトアカウントに対する操作が含まれる可能性が十分にあるからです。ここでは2つのレベルの問題があります。まず、スマートコントラクトはオンチェーンスマートコントラクトですか、それともオフチェーンスマートコントラクトですか?第二に、オンチェーンの場合、スマートコントラクトをサポートしていますか?

最初の質問については、NervOS が最も代表的なケースです。前述のように、NervOS の元帳の本質は UTXO モデルです。 UTXO モデルは、コンセンサス拡張の特別な必要性がない限り、通常、完全なトランザクション順序付けをサポートしません。これは実は非常に理解しやすいです。たとえば、下の図では、2 つのトランザクション Tx3 と Tx4 が同時に生成されています (ここでは並列ではなく同時という単語が使用されていることに注意してください。同時実行では、論理的に同時に発生することのみが要求されますが、並列処理では、時間的に同時に発生することが要求されます)。厳密に言えば、時間的な順序が存在する必要がありますが、これら 2 つのトランザクションは完全に独立しているため、2 つのトランザクションの順序はトランザクションのセキュリティに影響しません。したがって、UTXO では 2 つのトランザクションの順序を決定する必要はありません。利点は、取引の確認が可能な限り速くなることです。これは簡単に理解できるはずです。 2 つのトランザクションの順序を気にしない場合は、ノードはトランザクションを受信するとすぐにそれを検証して確認できます (これは単なる単純な確認であり、セキュリティ確認ではないことに注意してください。セキュリティ確認は、トランザクションを覆すことが理論的に困難になるまで待つ必要があります)。順序付けを考慮する場合、ネットワーク要因によりトランザクションの到着順序が不安定になるため、受信および検証後、十分な数のトランザクションが受信されてから確認が行われるまで、時間がかかる場合があります。これを保証するにはコンセンサスプロトコルが必要です。

NervOS の Cell モデルはトランザクションをサポートしていないので、NervOS はスマートコントラクトをどのようにサポートするのでしょうか?これは、冒頭で述べた、オンチェーン契約なのかオフチェーン契約なのかという最初のレベルの質問に戻ります。明らかに、NervOS はオンチェーンモデルをサポートしていませんが、オフチェーンでは完全にサポートできます。

ここで付け加えておくべきことは、NervOS のコンセプトは Qitmeer と非常に似ていますが、それでも違いがあるということです。どちらも UTXO モデルであり、オフチェーンスマートコントラクトですが (Qitmeer のクロスチェーンスマートコントラクトもオフチェーンスマートコントラクトソリューションです)、その出発点は基盤となるパブリックチェーンの安定性です。ただし、Qitmeer の基盤となるチェーンは、完全なトランザクションソートをサポートする UTXO モデルに基づいて強化された MeerDAG プロトコルを使用しているため、オンチェーンスマートコントラクトをサポートする機能があります。ここで NervOS を軽視する意図はまったくありません。実際、必要に応じて、NervOS はコンセンサスプロトコルを完全に強化して同じ効果を実現できます。実際、MeerDAG は、より公平な報酬ルールのサポートなど、全体的なアーキテクチャを考慮して、完全なトランザクションのソートをサポートしています。 MeerDAG は当初、スケーラビリティは比較的弱いものの、確認速度が速い SPECTRE プロトコルを検討しました。最終的に、総合的に検討した結果、より強力なスケーラビリティとより速い確認速度を備えた GhostDAG プロトコルに目を向けました。今後 MeerDAG について議論する際には、Qitmeer コンセンサスプロトコルの開発履歴をより詳しく共有する予定です。

したがって、ここで言及されている 2 番目のレベルの質問は、チェーン上でスマートコントラクトをサポートするかどうかです。 NervOS と同様に、Qitmeer は現時点ではサポートしていませんが、前述のように、MeerDAG コンセンサスプロトコルを拡張してオンチェーンスマートコントラクトをサポートすることができます。まだサポートしていない理由は、エンジニアリングの実装とプロジェクトの位置付けの間のトレードオフです。 Ethereum の仮想マシンはアカウントモデルに基づいているため、スマートコントラクトエンジニアリングの実装を容易にするために、多くのプロジェクトが Ethereum コードに基づいて開発されます。アカウントモデルと UTXO モデルのどちらがプロジェクトの位置付けに適しているかは、優先事項ではありません。 Ethereum スマートコントラクトの実装が UTXO モデルに基づいている場合は、UTXO モデルを選択することもできます。 Qitmeerは、プロジェクトの位置付けの観点からUTXOの方が合理的であると考え、独自のオフチェーンスマートコントラクトソリューションであるクロスチェーンを選択しました。

上記は、UTXO モデルに基づく MeerToken の歩みをコミュニティの友人と共有した比較的詳細な内容です。元帳モデルによって、資産発行メカニズムの設計が決まります。イーサリアムの資産発行メカニズムは、実際にはスマートコントラクトの簡略化されたバージョンです。次回は、Qitmeer の UTXO ベースの資産発行メカニズムの原理と、Ethereum に代表される資産発行メカニズムと比較したメリットとデメリットについて引き続き紹介します。乞うご期待。

<<: 呉氏は週刊鉱業情報1227-0102

>>: データを通じて2021年を振り返り、トレンドを追って2022年を展望する