Suiの創設者の直筆:バスに乗ることを例に挙げてSuiの性能の優位性を説明する
著者:Mysten Labs CEO兼共同創設者 Evan Cheng
出典:https://twitter.com/EvanWeb3/status/1569414553322274818
編纂:Azuma,Odaily 星球日報
最近、Suiを解析する記事がいくつか出てきましたが、これらの記事の多くは最も重要な革新、すなわちSuiのデータモデルと取引処理チャネルを見逃しています。これについて、次のツイートで3つの部分に分けて説明します:
Part1:従来のブロックチェーンの取引処理チャネル
Part2:Suiの取引処理チャネル
Part3:Suiの優位性
ブロックチェーンの運用ロジックは、時間の経過とともに、検証者たちが共同でチェーン上に新しいブロックを追加することです。取引処理チャネルは「ブロック構築------合意------実行------マークルツリー更新」というプロセスの最前方に位置し、すべての取引はこのプロセスの下流に進む前に処理されなければなりません。そして、新しいブロックの構築が始まると、取引の処理も一時停止されます。
以下は、従来のブロックチェーンの取引処理チャネルとその問題に関する図です。多くのプロジェクトがこれらの問題を異なる方法で解決しようとしています。
Suiのアプローチは「オブジェクト(objects)」を通じてデータを区別し、整理することです。あるNFT、あるトークンの残高、あるスマートコントラクト、これらはすべて異なるオブジェクト(タイプとして理解できます)であり、Suiチェーン上の取引はオブジェクトの違いに基づいてグループ処理できます。
下の図は、3つのグループに分けられる5つの異なる取引の簡単な例です(後で特定のオブジェクトと共有オブジェクトについて再度お話しします)。これらの3つのグループの取引は完全に並行処理が可能です。
他の従来のブロックチェーンでは、単一のブロック内のすべての無関係な取引は順番に処理される必要があります。例えば、ボブがブルースにBAYC NFTを送信し、アリスがアレックスにPunk NFTを送信し、ジェーンがあるDEXを使用するなど、これらすべての取引は合意によって集団的に順序付けられ、実行され、最終的にマークルツリーに反映されます。
例えるなら、これはバスに乗ることに似ています。従来のブロックチェーンでは、すべての乗客が順番に(合意)バスに乗り込み、各乗客は出発前に切符を確認(実行)され、同じ場所で降りる(マークルツリー更新)必要があります。バスが再び空になるまで新しい乗客を受け入れることはできず、チェーンは前に進むことができません。一方、Suiでは、チェーンは目的地(オブジェクト)に基づいてすべての旅客をグループ化し、各グループの旅客の切符を並行して確認し、異なる車両で並行して目的地に送ります。
Suiの革新は、取引の並行処理だけにとどまりません(この点については、将来的にさらに多くの内容を共有します)。取引結果は実行後にオブジェクトに提出され(例えば、あるトークンの残高が10で、5を送信した場合、残高は5になります)、それらは将来の取引の入力(input)として即座に使用できます。Suiはマークルツリーを新しいブロックの一部のチェックポイントとして使用し、一連の関連取引が最終的に確定した後にのみ記帳します。
さらに注意すべき点は、前述のケースでは、一部の取引は特定のオブジェクトにのみ対応していることです。例えば、ボブだけが彼が所有するBAYC NFTに関する取引を開始できます。特定オブジェクト型の取引は合意をスキップできます(ビザンチン合意のブロードキャストのみが必要です)、なぜなら所有者が取引の順序を確認できるからです。
一方、いわゆる共有オブジェクト型取引(例えばDEXスマートコントラクト)は、順序を決定する単一の所有者がいないため、合意形成を経る必要があります。これが私たちのNarwhal & Bullshark合意の活用される場面です。
簡単に言えば、特定オブジェクト型取引は並行して実行でき、共有オブジェクト型取引も互いに並行して実行できますが、各共有オブジェクトは順序通りに実行する必要があります(ここでは他の静的/動的技術が適用されています)。
要するに、あなたは次のように理解できます:
従来のブロックチェーンでは、すべての取引が集団的に順序付けられ、その後実行される必要があります。
Suiでは、すべての取引が一定のロジックに基づいて区別され、整理された後に順序付けられ、その後実行されます。データモデルは異なる取引間の依存関係をより明確にし、共有オブジェクトの取引のみが集団的に順序付けられる必要があり、特定オブジェクトの取引はこの合意形成プロセスを必要としません。
では、Suiのこのアーキテクチャはどのような製品の問題を解決できるのでしょうか?引き続き見ていきましょう。
まずは水平スケーラビリティの能力です。 Sui上では、各グループの取引は並行処理されます。これは前述のように、各グループの旅客が異なる車両に乗ることに似ています。したがって、より多くのグループの旅客(取引)がいる場合、Suiは単により多くの車両を用意すればよいのです。この点について、Suiは内部検証者を通じてシャーディングスケーリングを実現できます ------ より多くの作業者がより多くの取引を処理します。
なぜ水平スケーラビリティが重要なのでしょうか?いくつかの大規模プロジェクトが基盤を考える際のニーズを考えてみてください。彼らは基盤がその規模の持続的な成長を支えられることを確認する必要があります。性能上限のあるブロックチェーンは、これらのプロジェクトの参加を妨げる障害となります。Suiの設計は、こうした需要のピークに対応するためのものです。
次に、コンポーザビリティです。 Sui上で可能だが、他のスマートコントラクトプラットフォームでは不可能なことは何でしょうか?例えば、資産を関数にパラメータとして渡すこと、関数から特定の資産を返すこと、あるいは資産をデータ構造内に保存すること、または別の資産内に直接保存することなどです。
将来的には、コンポーザビリティに関する特別なツイートを書くかもしれません。これは非常に複雑なテーマだからです。ただ言いたいのは、Suiは契約レベルと資産レベル(異なるタイプのオブジェクトが他のオブジェクト内にネストできる)でコンポーザビリティを大幅に向上させたということです。
次に、部分的なリプレイ能力です。ブロックチェーンはすべての取引の履歴を提供しますが、これは過去の情報を確認するのに役立ちます。しかし、ある製品がチェーン上のデータに関心を持つ必要がある場合、読み取りは非常に高価になる可能性があります。Suiのアーキテクチャは、これらのプロジェクトが関心のあるオブジェクトの進化にのみ焦点を当てることを可能にします。これが部分的なリプレイです。
例えば、すべてのキャラクターをSui上に置くRPGゲームは、これらのキャラクターを表すオブジェクトを簡単に観察できます。彼らはマークルツリーのデータ構造からすべてのデータを掘り起こす必要はありません。
最後に、チェーン上のストレージです。ゲームの種族、レベル、経験などのさまざまな資産データは、Suiのオブジェクト内に保存できます。Suiは従来の方法を使用してチェーン上のストレージを拡張でき、現在はチェーン上の資産を更新するコストが大幅に低くなっています。
この長いツイートはここで終了します。これらの内容は高次元ですが、あまり包括的ではありません。しかし、これらの内容を通じてSuiについての理解を深めていただければ幸いです。