Sui専門家が語る高性能ブロックチェーン設計：迅速なパスとコンセンサスパスの革新的な応用

最近、私たちはブロックチェーンの専門家にインタビューを行い、Suiインフラストラクチャの複雑さと拡張性、さらにSuiの取引処理システムがどのように高性能ネットワークを促進するかについて探りました。この専門家は某有名大学のセキュリティとプライバシー工学分野の教授です。

以下は今回のインタビュー内容です：

Q1：あなたは学術分野に属していますが、あなたの研究の重点について紹介していただけますか？

私はある大学の教授で、研究の重点は広義には安全とプライバシーです。20世紀初頭に、私はピアツーピアシステムと匿名システムに関してかなりの研究を行いましたが、これらのシステムの多くはストレージを重視した大規模な分散システムでした。全体のブロックチェーンが特にイーサリアムを代表とするように実行により重点を置くようになったとき、私は分散台帳とブロックチェーン、そしてスマートコントラクトの実行方法に興味を持ちました。その際の許可不要の特性には、私は初期のピアツーピアシステムの研究で非常に慣れ親しんでいました。そこで、大学の研究グループでより高性能なシステムを構築する方法を研究し始めました。私たちは会社を設立し、私たちのアイデアのいくつかを商業化し、後にチームは大手テクノロジー企業に買収されました。そして、私たちはその会社にブロックチェーンの拡張ソリューションを提案するのを手伝いました。しかし、提案が進展しなかったとき、私は離れ、ハイパフォーマンスなブロックチェーンの理念を実現するための他の機会を追求し続けました。

Q2：あなたはまだ教授ですか、それでは応用と研究の違いは何だと思いますか？

実際にはあまり大きな違いはありません。私たちが研究を行う際には、高性能のブロックチェーンや特定の機能を構築するなど、特定の目標を達成するためのすべての可能性を考慮します。当然、ブロックチェーンを構築する際や、実際のシステムで使用する特定の機能を選択する際には、その中から1つを選ばなければなりません。私たちは常に判断を下さなければならず、これらの良いアイデアの中で、実際に人々にとって最も役立つものはどれか？人々が求めているのはどれか？ブロックチェーンの採用にはどのようなボトルネックが存在するのか？何が人々がやりたいことを実現するのを妨げているのか？システムを構築する際には、すべての可能性を考慮し、学術文献から可能な状況を理解し、最も関連性の高いものを選択しようとします。これは単なる知識の興味だけでなく、ユーザーに価値を創造することです。

Q3：理論から実際の応用に移る際、どの問題を解決するかをどのように決定しましたか？

私が研究で解決した主な問題は、ブロックチェーンの異なる機能をどのように拡張するかということです。私はブロックチェーンのシステム面に焦点を当てています。例えば、取引スループットをどのように増加させ、遅延を減少させるかです。この分野の問題は明白で、あるプラットフォーム上の契約が非常に人気を博すと、そのプラットフォームはそのような大量の取引を処理できず、取引の混雑が発生し、手数料が急騰します。ブロックチェーンが成功するたびに、私たちはそれが処理できる取引量が既存の能力を超えているのを目にしています。したがって、明らかに問題は、人々がこれらのブロックチェーン上で行いたいことを満たすのに十分な能力がないということです。これは私たちの考えに基づくものだけではなく、私たちは何度もこの状況が発生するのを見ています。しばらくの間、これは貴重な挑戦であると見なされており、私のチームだけでなく、実際には学術界全体がブロックチェーンを研究し、皆が異なる方法でこの問題を解決しようとしています。現在、これらの挑戦に対処するためにブロックチェーンの能力を拡張するためにかなりの技術が開発されています。しかし当時、多くの人が異なる方法でそれを解決しようとしていたことは周知の事実です。

Q4：L2ネットワークは、人々が拡張問題を解決するために提案した方法ですが、Suiのような新しいL1ネットワークを構築することとは何が違い、どのような利点がありますか？

L2はあるエコシステムにおける拡張ソリューションですが、アプリケーション開発者にとってはL2ネットワークの使用が少し難しいです。L2ネットワークがL1と相互作用しようとする場合、ブリッジング活動が必要になりますが、これはどのL2/L1の関係にも当てはまります。L1でcoin、資産、またはその他の内容を表す状態はL2でミラーリングされる必要があり、その逆もまた然りです。さらに、L2にはL1がその中で発生するすべてを検証できるメカニズムが必要です。しかし、これは第一の部分に過ぎず、L1に存在する資産はL2に移転される必要があり、L2で何らかの活動が発生し、その後、何らかの方法で資産をL1に戻す必要があります。これは非常に面倒です。

トークンのような代替可能な資産の場合、人々は2つのアカウントと1つのブリッジングミドルウェアを持っているため、このブリッジング活動はかなりスムーズです。 しかし、より一般的な資産の場合、それはうまくいきません。 L1上のL2ネットワークを実際に使用して、トークンよりも複雑なアプリケーションを開発するには、ミント用とバーン用のスマートコントラクトを両側に用意する必要があります。 彼らは2つの異なるエコシステム間を移動する必要があり、これは契約ごとにカスタムアクティビティです。 単純に「L2ネットワークを作り、すべてのアセットを好きなようにして戻す」というわけにはいきません。 これは、非常にエラーが発生しやすい手動のプロセスです。 だから、それは素晴らしい経験ではありません。 複数の異なるL2ネットワークに資産があり、これらのカスタムスマートコントラクトが異なるL2ネットワークにあると想像してください。 別の L2 ネットワーク上のステートで動作させるたびに、L1 にブリッジして L2 に戻す必要があります。 このブロックチェーンで何かをしたばかりで、その後別のブロックチェーンで何か別のことをするつもりで、それがどのL1またはL2にあるかを考える必要がないと簡単に言うことはできません。 それはすべてここにあり、私は今手元にいて、アクセスしたいどの州でももっと取引する準備ができています。 そのため、L2ネットワークを介して州を分散させるのは良い経験ではありません。 異なるチェーン間で資産を移動するのは難しく、ユーザーにとっては明らかです。 そのため、L2ネットワークにはあまり興味をそそられませんでした。

もう一つの例は、ある有名なプロジェクトで、非常に興味深いエコシステムを持ち、異なるアプリに異なるブロックチェーンを使用することで拡張するという別のアプローチを採用しています。私たちは異なるチェーン上で異なる取引速度を行うことができ、異なるアプリ間で操作を行う必要があるときは、チェーン間で資産をブリッジすることができますが、同じ問題に直面しています。異なるアプリを使用したいときは、まずブリッジ操作を行う必要があり、これはユーザーにとって微妙で明らかです。その後、そのアプリを使用して、再度ブリッジします。資産を一つのチェーンから別のチェーンに移動させるのに、実際にやりたいことをするよりも多くの時間を費やしていることに気付くでしょう。

Sui上では、私たちのソリューションは大規模なデータベースを構築することです。実際、それはすべての検証されたノードが複製した状態を含んでいます。トランザクションが完了すると、同じデータベース内のすべての状態が次のトランザクションに使用でき、ユーザーはL1とL2の間で資産の状態を絶えず移動させる必要がありません。

Q5：Sui LutrisはSuiプロトコルの基盤であり、その重要な革新は何ですか？それによってSuiは高いスループットと低遅延の特性を持つことができますか？

Sui Lutrisは二つの重要な理念から成り立っています：（1）ブロックチェーン上の多くの操作は、実際にはコンセンサスを必要としない；（2）コンセンサスが必要な場合には、これら二つの方法を組み合わせた非常に高いスループットを持つアプローチがあります。Sui LutrisはSui分散システムの核心であり、分散ネットワーク上で取引が行われる際に、プロトコルに従った二つの異なる検証ノードが決して不整合な状態にないことを保証します。これにより、一つの検証ノードがあなたが一つのcoinを使ってAliceに送信したと考えている一方で、もう一つの検証ノードが同じcoinが実際にはBobに送信されたと考えるという事態は発生しません。

二つの異なるパスがあり、一つはコンセンサスを必要としない（ファストパス）、もう一つはコンセンサスを必要とする（コンセンサスパス）です。操作対象が自分自身に属している場合、例えば自分のNFTキャラクターと、それに組み合わせたい帽子がある場合、理論的には他の人がそれらを操作するべきではありません。こうした場合、Suiはファストパスを使用します。これは、自分のオブジェクトを操作でき、コンセンサスを待つことなく取引の最終性を得られることを示し、取引が発生し、帽子が自分のNFTの頭にかぶせられることを保証します。

しかし、特定の状況では、取引は単に自分自身のオブジェクトだけに関与するわけではなく、多くの人々が共有しているものです。たとえば、小さな帽子を販売するオークションがある場合、この種のオークションはSuiで共有オブジェクトとして表されます。人々は入札を行い、最高入札者が帽子を獲得します。この種のオークションは、単一の実体に属さないオブジェクトであり、すべての人が入札し、共有し、最新の入札状況を更新できる必要があります。このような操作には追加の合意が必要です。Sui Lutrisは、共有オブジェクトを持ち、その上で取引を実行できるようにし、他のオブジェクトを所有したり、共有オブジェクトの状態を変更したり、新しい共有オブジェクトを作成したりすることができます。これは、特定の個人が所有する独占オブジェクトと、複数の人々が共有する共有オブジェクトの間で相互作用を可能にし、2つの道が共存することを許可します。

この二つの異なるパスは、それぞれ異なる利点を持っています。独占オブジェクトの高速パスは遅延が非常に低く、所要時間は1秒未満で非常に速く、広範なスケーラビリティを持っています。一方、コンセンサスパスの遅延は高く、通常1秒を超え、キャパシティもかなり高いですが、最初のパスと比較するとスケーラビリティが難しいです。Sui上では、毎日数百万回の取引を通じてチェーン上のアプリを推進する人々は通常最初のパスを使用し、アプリを主に独占オブジェクトで最も多くの取引を行うように構造化しています。一方、複雑な作業を行うプロトコル（例えばDeFi）は通常、第二のタイプの取引を実施します。なぜなら、これらは多くの異なる人々の入札や流動性を組み合わせて操作を実行する必要があるからです。

Q6：Sui上のアプリ開発者は、迅速なパスを利用するように彼らのアプリを設計できますか？

はい、絶対に可能です。私はこれがアプリケーションデザイナーのコアな仕事を拡張するものだと思います。スマートコントラクト開発者は、特定の時間内にコントラクト内で操作するオブジェクトが単一エンティティの独占オブジェクトであるか、共有オブジェクトであるかを完全に制御できます。Suiでアプリを拡張するための一つのコツは、ほとんどの操作が基本的に独占オブジェクト上で行われることを確認することです。なぜなら、Suiは非常に低い遅延で多くの操作を管理できるからで、これはとても良い体験です。ゲームに必要な操作はこのカテゴリで行われるべきであり、共有状態と共有オブジェクトを介して調整する必要がある操作と比べて、それらの遅延は非常に低いです。一度クリックすれば、取引はネットワーク上ですぐに完了します。

スマートコントラクトの設計者はこれに完全なコントロールを持ち、基本的に各カテゴリーの取引が何であるかを正確に指定できます。もちろん、契約の最初のバージョンではすべての内容が共有状態と見なされ、すべての内容が高遅延のコンセンサスパスを通じて行われますが、拡張が必要になるにつれて、開発者はこれらの部分を必要としない程度を考慮する必要があります。

Q7：プログラム可能な取引ブロックはこの中でどのように機能しますか？

プログラム可能な取引ブロックは、ファーストパスまたはコンセンサスパスで機能することができます。もしプログラム可能な取引ブロックがあなたの専有オブジェクトのみを含む場合、それはあなたが一つのチェーン上で複数の操作を実行できることを意味します。例えば、あなたがCEXアプリであり、多くの人々がここで異なるコインを売買していると仮定しましょう。あなたはチェーン上で一度の取引を行うことができ、その概念は人々が売買する内容に対応します。しかし、あなたが取引所であるため、すべてはあなたのものであり、同時に千の取引を決済することが可能で、これがファーストパスです。一方で、プログラム可能な取引ブロック内のいくつかのオブジェクトが共有されている場合、それはコンセンサスパスに入ります。この場合、遅延は少し高くなり、1秒未満ではなく数秒かかることになります。

Q8：メインネットが立ち上がって100日以上経過しましたが、Suiのパフォーマンスはあなたの仮説の研究理論を証明していますか？驚いたことはありますか？

Suiの設計を証明するいくつかの事柄がある一方で、考えさせられることもいくつかあります。一つは、取引量が特に多いとき、さらには特別な瞬間に、毎日の取引量が6000万件を超えることがあり、そのほとんどの取引が迅速な経路にあります。Sui Lutrisは非常にスケーラブルで、非常に低遅延です。それ以前は、この経路を使用する人がいるかどうかは不明でしたが、大量の取引と低遅延が必要なときに、それが使用され、非常に効果的でした！この手法は容易に理解できます。その日々、Suiの取引量はを超えていました。