深層対話：底層から見るSuiのデザイン理念とネットワーク規模の拡張

著者：Sui Network

最近、私たちはGeorge Danezisにインタビューし、Suiインフラストラクチャの複雑さとスケーラビリティ、そしてSuiの取引処理システムがどのように高性能ネットワークを実現しているかを探りました。George DanezisはMysten Labsの共同創設者であり、最高科学者（Suiの初期貢献者）であり、ロンドン大学のセキュリティとプライバシー工学の教授でもあります。

以下は今回のインタビュー内容です： Q1 あなたは学術界から来たのですが、あなたの研究の焦点について教えていただけますか？

私はロンドン大学（University College London、UCL）の教授で、研究の焦点は広義にはセキュリティとプライバシーと呼ばれています。20世紀初頭には、ピアツーピアシステムや匿名システムに関してかなりの研究を行い、これらのシステムの多くはストレージに重点を置いた大規模な分散システムです。ブロックチェーン全体が実行により重点を置くようになったとき、特にイーサリアムを代表とするものとして、私は分散台帳やブロックチェーン、そしてスマートコントラクトをどのように実行するかに興味を持ちました。その中で、許可不要の特性には、初期のピアツーピアシステムの研究で非常に慣れ親しんでいました。それで、UCLの研究グループでより高性能なシステムを構築する方法を研究し始めました。私たちはChainspaceという会社を設立し、いくつかのアイデアを商業化しましたが、その後、チームはFacebookに買収されました。そして、私たちはFacebookがブロックチェーンLibra/Diemを拡張するためのソリューションを提案するのを手伝いました。しかし、その提案が進展しなかったとき、私は去り、高性能ブロックチェーンの理念を実現するための他の機会を探し続けました。 Q2 あなたは教授でもありますが、アプリケーションと研究の間にはどのような違いがあると思いますか？

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

私が研究で解決している主な問題は、ブロックチェーンのさまざまな機能をどのように拡張するかです。私はブロックチェーンのシステム面に焦点を当てています。たとえば、取引のスループットを増やし、遅延を減らす方法です。この分野の問題は明白です。イーサリアム上のあるコントラクトが非常に人気になると、イーサリアムプラットフォームはそのような取引量を処理できず、取引が混雑し、手数料が急騰します。ブロックチェーンが成功するたびに、私たちはそれが処理できる取引量が既存の能力を超えているのを見ています。したがって、問題は、人々がこれらのブロックチェーン上でやりたいことを満たすのに十分な能力がないことは明らかです。これは私たちの考えからだけではなく、何度もこの状況が発生するのを見てきました。しばらくの間、これは価値のある挑戦と見なされており、私のチームだけでなく、実際には学術界全体がブロックチェーンを研究し、さまざまな方法でこの問題を解決しようとしています。現在、これらの課題を解決するためにブロックチェーンの能力を拡張するために開発された技術はかなりあります。しかし、その当時は、多くの人々が異なる方法でそれを解決しようとしていることは周知の事実でした。 Q4 L2ネットワークは、拡張問題を解決するために提案された方法の一つですが、Suiのような新しいL1ネットワークを構築することとの違いや利点は何ですか？

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

トークンのような代替可能な資産の場合、このブリッジ活動は比較的スムーズに行われます。なぜなら、人々は2つのアカウントとブリッジミドルウェアを持っているからです。しかし、より一般的な資産の場合、効果は良くありません。イーサリアム上でL2ネットワークを使用してトークンよりも複雑なアプリケーションを開発するには、両方の側にスマートコントラクトが必要です。一つはミント（mint）用、もう一つはバーン（burn）用です。それらは2つの異なるエコシステムを行き来しなければならず、これは各コントラクトのカスタマイズされた活動です。単に「L2ネットワークを作成し、すべての資産を持ち去り、自分の意志で操作し、再び持ち帰る」という概念はありません。これは手動のプロセスであり、非常にエラーが発生しやすいです。したがって、これはあまり良い体験ではありません。想像してみてください。あなたは複数の異なるL2ネットワークに資産を持っており、異なるL2ネットワークにこれらのカスタマイズされたスマートコントラクトがあります。あなたが別のL2ネットワーク上のある状態に対して操作を行いたいとき、あなたはL1にブリッジし、再びL2に戻る必要があります。あなたは簡単に「私はこのブロックチェーン上で何かをしたばかりで、次に別のブロックチェーンで何かをしたい。どのL1またはL2であるかを考える必要はない」と言うことはできません。すべてがここにあり、今手に持っていて、アクセスしたい任意の状態でさらに取引を行う準備ができています。これが、状態がL2ネットワークに分散している体験が良くない理由です。異なるチェーン間で資産を移動することは非常に厄介であり、ユーザーにとっても明らかです。これが、L2ネットワークが私の興味を引かなかった理由です。

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

Suiでは、私たちのソリューションは大規模なデータベースを構築することです。実際には、すべての検証ノードが複製した状態が含まれています。一度取引を完了すると、同じデータベース内のすべての状態が次の取引に使用でき、ユーザーはL1とL2の間で資産状態を絶えず移動させる必要がありません。 Q5 Sui LutrisはSuiプロトコルの基盤であり、その重要な革新は何ですか？それがSuiに高スループットと低遅延の特性をもたらすのですか？

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

? Sui Lutris：

https://tech.mystenlabs.com/sui-lutris-the-distributed-system-protocol-at-the-heart-of-sui

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

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

これら2つの異なるパスには異なる利点があります。独占オブジェクトの高速パスの遅延は非常に低く、1秒未満で非常に速く、広範にスケールできます。合意パスの遅延は高く、通常は1秒を超え、容量もかなり高いですが、最初のパスと比較してスケールしにくいです。Sui上では、実際に毎日数百万回の取引を通じてチェーン上のアプリを推進している人々は通常、最初のパスを使用し、アプリを主に独占オブジェクトでの取引に構造化していますが、共有取引ではありません。一方、複雑な作業を行うプロトコル（たとえばDeFi）は、通常、第二のタイプの取引を実施します。なぜなら、それらは多くの異なる人の入札や流動性を組み合わせて操作を実行する必要があるからです。 Q6 Sui上のアプリ開発者は、彼らのアプリを高速パスを利用するように設計できますか？

はい、絶対にできます。私はこれがアプリ設計者の核心的な仕事だと思います。スマートコントラクト開発者は、彼らがコントラクト内で操作するオブジェクトが特定の時間に単一の実体の独占オブジェクトであるか、共有オブジェクトであるかを完全に制御できます。Suiでアプリを拡張するための一つのコツは、基本的に大部分の操作が独占オブジェクト上で行われることを確保することです。なぜなら、Suiは非常に低遅延で多くの操作を管理できるからです。これは非常に良い体験です。ゲームに必要な操作はこのカテゴリーに含まれるべきであり、共有状態や共有オブジェクトを介して調整する必要がある操作と比較して、遅延は非常に低いです。一度クリックすれば、取引はネットワーク上で即座に完了します。

スマートコントラクト設計者はこれに完全に制御権を持っており、基本的に各カテゴリー内の取引が何であるかを正確に指定できます。もちろん、コントラクトの最初のバージョンでは、すべての内容が共有状態と見なされ、すべてが高遅延の合意パスを通じて行われますが、拡張が必要になるにつれて、開発者はどの程度までこれらの部分を必要としないようにできるかを考慮する必要があります。 Q7 プログラム可能な取引ブロックはどのように機能しますか？

プログラム可能な取引ブロックは、高速パスまたは合意パスで機能します。もしプログラム可能な取引ブロックがあなたの独占オブジェクトだけを含む場合、これはあなたが1つのチェーン上で複数の操作を実行できることを意味します。たとえば、あなたがCEXアプリで、多くの人がここで異なるcoinsを売買している場合、あなたはチェーン上で1回の取引を行うことができ、概念的には人々が売買している内容に対応します。しかし、あなたが取引所であるため、すべてはあなたに属し、同時に1000の取引を決済できるため、これは高速パスです。一方、プログラム可能な取引ブロック内のいくつかのオブジェクトが共有されている場合、それは合意パスに入り、遅延は少し高くなり、1秒未満ではなく数秒かかります。 Q8 メインネットが立ち上がってから100日以上が経過しましたが、Suiのパフォーマンスはあなたの仮説の研究理論を証明していますか？驚いたことはありますか？

Suiの設計を証明するいくつかの事柄がありますが、考えさせられることもいくつかあります。一つは、取引量が特に多いとき、特に特定の瞬間に、1日の取引量が6000万件を超えることがあり、そのほとんどの取引が高速パスにあります。Sui Lutrisは非常にスケーラブルで、非常に低遅延です。それ以前は、このパスが誰かによって使用されるかどうかは不明でしたが、大量の取引と低遅延が必要なときに、それが使用され、非常に効果的でした！これは簡単に見える方法です。その日々、Suiの取引量は他のすべてのブロックチェーンの合計を超えました。これはSuiの設計が合理的であることを証明する興味深い検証です。

同時に、Suiコミュニティはこの高速パスが少し微妙であることを発見しました。なぜなら、オブジェクトの所有者はある程度、自分のオブジェクト上の操作の順序を管理しなければならず、時には間違えることがあるからです。時には、彼らは彼らを助けないライブラリを使用することさえあり、ライブラリ自体がエラーを起こすことがあるため、時にはオブジェクトがロックされることがあります。通常、それらは1日の終わり、つまりエポックの終わりにロック解除されますが、これはあまり良い体験ではありません。スマートコントラクトを設計する人々は、これがエラーを引き起こす可能性があることを心配し、低遅延とスケーラビリティの施設を十分に活用することを妨げるかもしれません。エラーでロックされたオブジェクトを迅速に解除できるようにするために、一連の技術が開発されています。したがって、もしあなたが高速パスを使用し、エラーが発生し、オブジェクトがロックされた場合、エポックの終わりを待つことなく、合意パスを使用してそれを解除できます。

さらに奇妙なのは、これは単にエラーを避けるためだけでなく、開発者が高速パスを通じてより多くのことを表現できるようにすることです。いくつかのオブジェクトが単に1つの当事者によって所有されているのではなく、潜在的な技術が存在します。たとえば、あるオブジェクトはあなたと私が共同で所有しているものであり、これは共有されているため、通常、そのオブジェクト上の取引は合意パスを通じて行われる必要があります。しかし、もしSuiがオブジェクトを迅速に解除する方法を持っているなら、開発者は実際に高速パスを通じて取引を試みることができます。あなたと私がちょうど同じ時間に同じオブジェクトに対して取引を行う場合、システムはロックされ、どの取引が次に発生するかを決定できず、Suiはそれを解除し、合意パスを通じてそれを共有し、解決します。しかし、人々が意図的に競争しようとしない限り、この状況は発生しません。一度Suiがオブジェクトを解除する機能を持つと、複数の人に属するオブジェクトが高速パスを通じて取引されることができるはずです。これは、高速パスを通じてできるだけ多くの取引量を伝達しようとするゲームであり、これはビルダーコミュニティを支援するために開発されているタイプのものです。 Q9 現在、オブジェクトがロックされる原因について詳しく教えていただけますか？

あなたのオブジェクトがあなたに属しているとき、合意を通じてSuiに一連の操作の順序を伝える必要がないのは、他の誰もあなたのオブジェクトを操作できないからです。Suiは、あなたがシステムに対して、アクションAが最初に発生し、アクションBが次に発生し、アクションCが最後に発生することを伝えることに依存しています。システムは依然としてA、B、Cがすべての人によって同じ順序で見られているかどうかを確認する必要があります。このシステムは分散プロトコルを通じて実現され、私たちがA、B、Cを順番に見たかどうかを確認します。問題は、あなたが間違いを犯した場合や、あなたのソフトウェアが間違いを犯した場合です。たとえば、あなたの携帯電話があなたの資産を制御し、あなたのコンピュータがあなたの資産を制御している場合、あなたの携帯電話は最初にAが発生したと表示し、あなたのコンピュータは最初にBが発生したと表示します。あなたは異なる2つの事柄の順序を間違えてしまいました。これは矛盾です。この場合、Suiは「さて、私に順序を伝えることを委託された人が矛盾する2つの事柄を与えたようです。だから、私はどうすればいいかわかりません。私はこの問題を解決する方法がわかりません」と言います。なぜなら、Suiは通常、この問題を合意パスを通じて解決するからです。しかし、ここではあなたは高速パスを使用しようとしています。したがって、Suiは手を挙げて「さて、ここでエラーが発生しました」と言います。

最初の仮定は、この状況が頻繁には発生しないというものでしたが、実際には人々が異なるデバイスを使用したり、同じオブジェクトに対して同時に取引を試みたりするため、頻繁に発生することが判明しました。現在、これらのオブジェクトがロックされると、Suiはエポックが終了するまでそれらを解除しません。これは非常に懸念されることです。もしあなたの資産が1日中使用できない場合、これは実際に深刻な問題になる可能性があります。

したがって、現在Suiは、何かがロックされているときに適切な行動を取るために発展する必要があります。もし正しい順序を提供することを委託されたエンティティが不明確な順序を与えた場合、Suiは全体の状況を合意を通じて解決します。これは数秒以内に発生し、エポックの終了時に発生するのではありません。 Q10 あなたの多くの研究はプライバシーに関するものです。公的なブロックチェーンが透明性、追跡可能性、プライバシーをどのように最もよくバランスさせるべきかについて、あなたはどう考えていますか？

公的なブロックチェーンにおける透明性、追跡可能性、プライバシーのバランスを取る方法は、アプリケーションに非常に関連する問題です。 私のプライバシーに関する見解は、何をプライバシーとして保持する必要があるかは、アプリケーション自体に大きく依存するということです。たとえば、Sui上でアプリ開発者がユーザーのプライバシーを保護するためのコントラクトを開発することは合理的です。なぜなら、ある人々はゲームを開発したいだけであり、プライバシーの問題に対する関心がそれほど高くないかもしれません。ある人々はブロックチェーン上で金融取引を処理したいと考えており、プライバシーがより懸念されるかもしれませんが、同時に他の種類の規制の問題も関わってきます。したがって、Suiの態度は、私たちはあなたに良いプラットフォームを提供し、そのプラットフォーム上でプライバシーを構築する必要があるということです。

人々がプライバシーを構築するのを助けるために、Suiはいくつかの暗号化ネイティブサポートを提供しています。これらはスマートコントラクトを設計する際に彼らに役立つかもしれません。その中で最も重要なのは、Sui上でゼロ知識証明を検証する能力です。最も広く使用され、理解されているスキームの一つである、私の同僚Jens Grothが開発したGroth16スキームを検証するためのローカル関数があります。これは、実際にはアプリの設計者が特定のイベントをオフチェーンで検証できることを意味し、それらのイベントが何であるかを明らかにする必要がありません。これは、いくつかの状態をオフチェーンに保持しつつ、オフチェーンで発生したことが正しいことを検証できるプライバシーに優しいアプリの基本的な構築モジュールです。

アプリ開発者は、彼らのアプリがどのようなプライバシー保護を必要とするかを決定し、これらのネイティブサポートを使用して、オンチェーン、オフチェーン、オンチェーン暗号化などの戦略を組み合わせて、彼らが直面する可能性のあるプライバシーの問題に対処します。 Q11 Suiには、より多くのプライバシーに関するネイティブサポートがありますか？

コミュニティは、開発者がよりプライバシーに優しい状況でスマートコントラクトを記述するために必要なサポートについて考えています。ゼロ知識証明はその一つであり、Suiはより一般的な数学的または暗号学的関数がオンチェーンに必要だと考える人もいるかもしれません。私たちは、スマートコントラクトの設計者が欠けている部分についてフィードバックを提供することを非常に望んでいます。また、プライバシーを保護するために使用できる他の一連の技術、たとえばマルチパーティ計算や信頼できるハードウェアなどがあります。異なるブロックチェーンはこれらの方向に進んでおり、非常に複雑な追加システムが必要です。コミュニティには、人々がこれらの技術を望んでいるという十分な証拠が必要です。なぜなら、これらはSuiアーキテクチャにいくつかの基本的な変化をもたらすからです。しかし、もしコミュニティがこの方向に進みたいのであれば、プライバシー保護の方法を追加することを提案するプロセスが存在します。 Q12 今後6〜12ヶ月でSuiはどのように発展すると考えていますか？

これは、人々がSui上でどのようなアプリを開発するかに依存します。短期的には、多くの改善が人々が実際に構築するアプリに焦点を当てます。非常に長期的な観点から見ると、ブロックチェーンの基準の下で、6〜12ヶ月は非常に長い時間と見なされ、私たちはSui Lutrisプロトコルを改善し、より低い遅延、よりシンプルなプロトコルを実現し、Suiがより良くスケールできるようにします。さらに、経済をより効率的にし、検証ノードがより制限されたハードウェア上で動作できるようにし、既存のハードウェアを実際の取引の実行に使用し、暗号学やブロックチェーンの他のオーバーヘッドを行わないようにします。これが私たちが期待している内容です。