著者： Sui Foundation編集：Cointime.com 237

私たちは最近、Mysten Labs の CTO であり、Move プログラミング言語の作成者である Sam Blackshear 氏に話を聞き、新しいスマート コントラクト プログラミング言語を開発した理由、Sui がどのようにスケーラビリティを可能にするか、開発者にとっての分散化のメリットについて話し合いました。

まず、プログラミング言語とは何か、開発者がプロ​​グラミング言語を選択する際に最も重要な資質は何か、そして独自の言語を開発しようと思った動機について説明していただけますか?

プログラミング言語は、コンピューターと友好的かつ安全に対話するための単なるツールであり、コンピューターにとって効率的かつ明確であることが特に重要です。自然言語の目的はその豊かさと表現力にあるため、私たちは自然言語を使用してコンピューターと通信することはできません。たとえば、イントネーションや単語の選択を少し変えるだけで、文や段落がまったく異なるものになる可能性があります。一方、プログラミング言語では、セマンティクスが正確に定義されていることが最も重要です。プログラムを作成すると、それが何をするかがわかります。それに小さな変更を加えると、何が変更されたのかもわかります。そして、この正確な定義は、ソース言語でコードを書くのと同じように、複数のレベルで維持され、コードには意味があり、その後、機械部品のシリコンに至るまで、同じ意味を持つはずの中間表現に変換されます。 。

プログラミング言語は、本質的にドメイン固有またはタスク固有であるという点で自然言語とは異なると思います。そうでなければ、すべてを実行できるプログラミング言語は 1 つだけになってしまいます。しかし、複数のプログラミング言語が存在する理由は、すべてを得意にすることはできないからです。彼らは特定の問題領域をターゲットにして、そこに非常に集中しようとしています。したがって、Sui ブロックチェーンや Mysten 上で動作するその他のシステムの作成に使用している Rust プログラミング言語を見てみると、非常に高速でパフォーマンスが高く、しかも安全なコードを書くことに重点が置かれています。これにより、基礎となるメモリ、スレッド構造、同時実行性にアクセスできるようになりますが、古い C 言語や C++ 言語のように混乱することはありません。

Moveのストーリーも非常に似ています。私がそれを作成したとき、それは新しい言語を作成することではありませんでした。もう 1 つの質問は、開発者が言語に何を求めているのかということです。彼らは「これは私がやりたいタスクに適していますか?」と尋ねますが、それよりも重要なことは、「この言語には大規模なコミュニティがあるか? 利用可能なライブラリがたくさんあるか? 多くのプログラマーが使用しているか? 優れた教育リソースがあるかどうか」だと思います。これは非常に重要であるため、新しい言語を作成するための参入障壁は非常に高くなければなりません。また、言語自体が優れていたとしても、そのサポートがなければその長所は重要ではありません。そして、ゼロから大規模で活気のあるコミュニティを築くのは非常に困難です。

Move の開発について少し教えていただけますか?

Move の起源は、Facebook の Libra プロジェクトにまで遡ることができます。当時の私の使命は、新しい言語を作成することではなく、「Libra はスマート コントラクトに対応する必要があるので、何をすべきかを考え出す」ことでした。私は可能性を検討しました。イーサリアム仮想マシンで Solidity を使用できますか? WASM や JVM のような通常の共通語を使用し、Libra に使用する必要がありますか?それとも独自に作成する必要がありますか?独自のものを作成するという決定は、既存のスマート コントラクトを調査し、プログラマーが何をしようとしていたのか、その言語がどこに役に立ち、どこに失敗したかを理解することに基づいていました。私の結論は、多くの場合、彼らを失望させるということです。

これは、Solidity の貧弱なセキュリティ記録からもわかりますが、さらに重要なことに、これらのスマート コントラクトは非常に型破りなタイプのプログラムです。 Solidity は、今日の人々のニーズを満たすために構築された言語ではありません。これらは最初のスマート コントラクト言語であり、人々がそれを使って何をしたいのかわからないからです。人々がそれを使って何をしようとしているのかを見れば、Solidity が提供する言語とは異なる抽象化とプログラミング ツールのセットが必要であることは明らかだと思います。

したがって、これらのスマートコントラクトは非常にシンプルです。彼らは主に 2 つのことを行います。まず、資産の形状を定義します。これには、いつ転送できるか、何ができるか、誰が読み書きできるかなどのルールが含まれます。次に、アクセス制御ポリシーを調べて、誰が資産を所有するか、誰がその資産を使用できるか、誰がその資産に対して操作を行うことができるかを決定します。すべては資産を中心に展開しており、それらの資産には物理的な資産と同じ属性が必要です。私があなたに何かをあげたら、あなたはそれを受け取るべきですが、私はもうそれを受け取ることができません。

コンピュータ上では、すべてはビットやバイトに過ぎず、自由にコピーできます。ご存知のように、これらの概念はコンピューターには存在しません。したがって、所有権と代替可能性について優れた抽象化を提供する言語が必要になります。現実世界と同様ですが、プログラマーに車輪の再発明を強いることはありません。これらの基本的なセキュリティ保証が必要です。

それが Move の機能であり、私たちが最終的に新しい言語を作成することに決めた理由でもあります。これらの基本的なタスクは、既存のスマート コントラクト言語を含む他の言語で再現するのが難しいスマート コントラクト プログラミングに存在します。私たちは、これらの基本的な要素を提供するように言語全体を設計し、プログラマーがコードを書くたびに車輪の再発明をすることなく、安全かつ効率的にコードを記述できるようにしたいと考えています。

スイは、スイムーブと呼ばれるムーブのバリエーションを使用します。こうした変化のきっかけは何でしょうか?また、Sui Move のどの機能が Web3 で製品を構築するのに特に適しているのでしょうか?

これらの変化にはいくつかの要因が寄与しています。当初の Libra プロジェクトの目標の 1 つは、規制に準拠した決済ネットワークを構築することでした。そこで私たちは、Move を共通言語として設計しようとしました。しかし、私たちはLibraが要求する制約を満たすために意識的に何かをしました。大きな問題の 1 つは、人々が特定の資産を移動できるようにしたくないということです。彼らは、ユーザーに明示的にアカウントを作成してもらい、アカウントの所有者が KYC 検証に合格する必要がある、アカウントの作成に料金がかかる、少数のユーザーのみが作成できるなど、アカウント作成に関するいくつかのルールを設定することを望んでいます。アカウントを作成する権限を持つ人。これらの制限が存在するのは、Libra の全体の目的が、準拠した支払いと準拠したスマート コントラクトを行うことであるためです。しかし、より一般的な Web3 の分野では、その逆が当てはまります。コンプライアンスの概念を内部に持たせたくありません。それがスマート コントラクトの概念です。できる限り無料であることが望まれますが、任意のアドレスに何かを送信することは完全に可能です。その場合、さまざまなユースケースを妨げるため、明示的なアカウント作成は行わないでください。これは重要な要素です。

もう 1 つの要因は、Move では資産に焦点を当てていましたが、Libra プロジェクトでは、この資産の焦点をトランザクション自体にどのように組み込むかが当時考慮されていなかったということです。したがって、Move でコードを記述するのは問題ありませんが、トランザクション レベルに達すると、まだこの API しかなく、数値やブール値などを入力する必要があります。アセットを取得して一連の操作を実行します。結局のところ、実行しているコードのほとんどは、これを取り出し、あれを取り出し、他のものを取り出し、というようなひどい簿記になっており、必要な資産はすべて揃っています。それらは揃ったので、今私は何か意味のあることを始めることができます。そしてその後、「分かった、これらの資産をこの口座に戻して、その口座に戻して、再編成してください」と言うのです。

Sui では、すべてのプログラムがこのように始まり、終わる場合、それを抽象化できるか? という問題についてよく考えました。したがって、トランザクションを処理するロジックがプログラマーに代わってそれを行います。プログラマーの観点から見ると、必要なアセットを準備するだけで、すぐに興味深い作業を開始できます。これは、Sui に存在するオブジェクト中心のデータ モデルの基礎です。オリジナルの Move では、アカウントベースのデータ モデルがあり、アセットはアカウントの下に保存され、プログラマーはそれらを明示的に取得する必要がありました。一方、Sui では、Sui を実行するときにトランザクションの Move 部分にすでに抽出されています。プログラマにとっては、このような何度も行ったり来たりの簿記を行う必要がないため、はるかに使いやすくなっています。また、実際にトランザクションを実行せずに、あるトランザクションを別のトランザクションと並行して実行し、Sui を水平方向にスケーリングできるかどうかを判断できる方法でもあります。トランザクション、および他の操作をより効率的に実行するためのヒント。

また、オブジェクトベースのデータ モデルを利用したプログラム可能なトランザクション ブロックなど、他にも非常に興味深いことをいくつか実行しました。これはもう少し技術的なトピックなので、喜んで説明させていただきます。しかし、これら 2 つの要因が、オリジナルの Move からの乖離の主な要因でした。

ご希望であれば、プログラム可能なトランザクション ブロックとその機能に関する詳細情報を共有できます。

また、オブジェクトベースのデータ モデルを利用したプログラム可能なトランザクション ブロックなど、他にも非常に興味深いことをいくつか実行しました。これはもう少し技術的なトピックなので、喜んで説明させていただきます。しかし、これら 2 つの要因が、オリジナルの Move からの乖離の主な要因でした。

ご希望であれば、プログラム可能なトランザクション ブロックとその機能に関する詳細情報を共有できます。

私がここで使いたい例えは、他のブロックチェーンはショッピングモールのフードコートのようなものです。アイスクリームが食べたいと思ったら、アイスクリームスタンドに行き、クレジットカードを取り出して支払います。しかし、ハンバーガーも食べたいと思ったら、バーガースタンドに行ってお金を払います。私は食いしん坊ではありませんが、8 つ食べたい場合は、8 回に分けて取引する必要があります。一方、Sui は無制限のビュッフェのようなものです。各トランザクションは単なるアイテムではありません。ビュッフェの料金を支払ったら、追加料金なしでできることがたくさんあります。アイスクリームを食べることも、ハンバーガーを食べることも、すべてを一緒に食べることもできます。

この概念をもう少し具体的にするには、100 個の NFT をミントするために 100 個のトランザクションを送信する単純なケースでは、100 個の NFT をミントするために 1 つのトランザクションを送信できます。このようなコストは、NFTの鋳造コストにほぼ匹敵します。また、ブロック内の最初のトランザクションでマルチシグ ウォレットからマリオ キャラクターを取得し、2 番目のトランザクションでマリオをリクエストしてゲームをプレイさせるなど、異種パッケージ化されたトランザクションを実行することもできます。ゲームに勝ってトロフィーを獲得した場合、おそらく 3 回目のトレードでそのトロフィーがトロフィー キャビネットに入れられ、友人と共有されることになります。これの優れた点の 1 つは、プログラマブル トランザクション ブロックにより、ゲームがマルチシグ ウォレットやマリオの保存方法を気にする必要がないような方法でプログラマがコードを記述できることです。また、トロフィー キャビネットやその実装方法について何も知る必要もありません。

プログラム可能なトランザクション ブロックは、入力オブジェクトと出力オブジェクトを含むトランザクションで構成されます。トランザクションが入力オブジェクトを必要とする場合、どこから来たのかを気にせずにそのオブジェクトを取得し、どこへ行くのかを気にせずに必要な場所に出力を渡すことができます。他のブロックチェーンでは結合度が高いため、ゲームをマルチシグ ウォレットやトロフィー ロッカーと統合するか、すべてのブロックチェーンに共通のインターフェースを実装して結合度を高くする必要があります。スイを使用すると、いわゆる即興演奏がはるかに簡単になります。たとえば、パイプラインが一致すれば、1 つのトランザクションですべてを実行できます。

では、プログラム可能なトランザクション ブロックはユーザーにとってどのようなメリットがあるのでしょうか?

ユーザーの観点から見ると、次のようなメリットがあると思います。 すべての操作を複数のトランザクションを個別に行うのではなく 1 つのトランザクションにまとめられるため、ガス料金が安くなります。さらに、承認数も減少しました。トランザクションの承認が必要なシステムを使用する場合は、トランザクションの承認を 1 回行うだけで済み、その後はすべて一度に行うことができます。さらに、原子性にはもう一つポイントがあると思います。 3 つの異なることを実行し、最初の 2 つが成功した場合にのみ 3 つ目が成功するようにしたい場合、それらの処理が別々のトランザクションでなければならない場合、それは機能しません。しかし、それらすべてを 1 つのトランザクションに入れることができれば、問題はありません。

プログラマにとって、Sui での開発経験がいかに重要であるかについて他の人に話しているのを聞きました。経験豊富なWeb3プログラマーと初心者のWeb3プログラマーがSui Moveを使い始めることについて共有できる逸話はありますか?

他の Web3 プログラミング言語を使用している開発者にとっては、Move と Sui Move の方が生産性が高いと感じます。同時に、この方法はより安全でもあります。私はバケットプロトコルに関するポッドキャストに出演していましたが、彼らはSui上で本当にクールなDeFiプロジェクトを構築していました。これらはシステム アーキテクチャを示しながら、さまざまなコンポーネントがどのように連携して動作するかを示します。このプロジェクトを Solidity で書いていたら 8 か月かかったかもしれないが、Sui Move では 2 か月しかかからず、セキュリティには非常に自信を持っていると彼らは言いました。 Sui Move のプログラミング モデルは、アイテムをどのように構成するかという彼らのアイデアに非常に近いものです。 Solidity の世界では、このつながりはより間接的です。

これはほんの一例であり、言語の上達が早くなり、終了したときの結果に自信が持てるという同様のケースをたくさん聞きます。これはとても嬉しいことです。しかし、ある意味、それは驚くべきことではありません。 Solidity を調査したところ、問題があることがわかりました。私たちの設計は、より安全かつ高速にする方法を中心に展開しています。私たちは、言語を使用する人々が解決しようとしている問題を考え、既存の言語だけではなく、彼らのニーズを満たす言語をどのように設計するかを考えます。この言語は、人々が直面する問題に合わせて設計されているため、この言語に切り替えると、その利点を実際に感じることができます。

「先手勝ち」と言いますが、この場合は「後手勝ち」とも言えるのではないでしょうか。

はい、そうです。

Sui Move と、Sui の一般的なオブジェクト指向の性質について言及するときに、すでにこのことについて話しています。しかし、Sui Move の設計と、特に低レイテンシ、低コスト、スケーラビリティの観点から、Web3 の大量採用を達成する Sui の能力との関係をより明確に説明できますか?

Sui Move と、Sui の一般的なオブジェクト指向の性質について言及するときに、すでにこのことについて話しています。しかし、Sui Move の設計と、特に低レイテンシ、低コスト、スケーラビリティの観点から、Web3 の大量採用を達成する Sui の能力との関係をより明確に説明できますか?

私たちはSuiへの貢献には非常に慎重であり、これは他のプラットフォームも同様に直面している問題だと思います。キャパシティが限られている場合、それがイーサリアムの 15 TPS (1 秒あたりのトランザクション数) であっても、100 または 1,000 であっても、固定数であれば、プラットフォームが成功しすぎるとキャパシティの限界に達します。この時点で、プラットフォームを使用するすべてのユーザーのエクスペリエンスが低下します。スロットが 1,000 個しかない場合は、おそらくガス オークションなどを通じて、どの 1,000 個が最も重要かを選択する必要があります。すべてのユーザーの価格が上昇するか、すべてのユーザーの遅延が増加するか、あるいはその両方になります。最も高い料金を支払った人だけが勝ち、他の人は他の人に行くか、より長く待たなければならないため、多くのユースケースが除外されます。これは理想的ではありません。

スイの目標は水平方向のスケーラビリティです。一定量のハードウェアを割り当てると、一定量のスループットを達成できます。より多くのスループットが必要な場合、バリデーターはより多くのハードウェアを導入できます。これに上限はありません。これがすべての Web2 サービスの仕組みです。もちろん、いくつかのエンジニアリング上の制約や問題を回避する必要があり、それが確実で簡単なことではありませんが、スケーラブルな Web サービスを設計するときは、誰もが水平方向のスケーラビリティを実現したいと考えています。

より多くの顧客またはユーザーを獲得できれば、Sui が成長し続けることが目標となり、すべてが機能するはずです。そしてもちろん、レイテンシーは非常に低く抑えられます。スループットを高めるためにレイテンシを犠牲にする必要はありません。

Libra システムでは、これらの特性は考慮されません。これは小規模な決済システムであり、おそらく 1 日に数百の決済オペレーターが参加し、おそらく数千または数百万件の支払いが行われますが、それを超えることはありません。したがって、よりシンプルで使いやすい単一フレームワーク アーキテクチャを採用しました。しかし、Sui にとって、Libra システムには水平方向のスケーラビリティ機能が欠けているため、機能しないことがわかっています。そこで私たちは、これを実現できるシステムをゼロから設計するにはどうすればよいかを考えました。ここでオブジェクト指向データ モデルが登場します。私たちは基本的に古いアカウントベースのデータ モデルから離れました。それが水平方向のスケーラビリティの実現を非常に困難にしていたからです。一方、すべてをオブジェクトに編成すると、グローバル状態はオブジェクト ID からオブジェクトまでの 1 つの大きなマップになります。これは Key-Value ストアであり、私たちは Key-Value ストアをスケーリングする方法を知っています。これは単純な工学的な質問です。

ここで問題となるのは、キー/値ストアからのデータのフェッチとその更新に対応するトランザクション構造をどのように設計するかということです。 Key-Value ストアをどのようにシャーディングするのでしょうか?どのトランザクションを処理する必要があるかをどのように決定すればよいでしょうか?基本的にはそれだけです。同様に、これは私たちがスケーリングする方法を知っているものです。これを、認証読み取りを実行したり、移動などを使用したりして、ブロックチェーンの特性を持つシステムに変えるにはどうすればよいでしょうか。そして、それをできるだけスムーズにまとめるにはどうすればよいでしょうか。

大まかに言えば、Web2 開発者に懐疑的な人々に分散テクノロジーの可能性をどのように伝えるのでしょうか?

ブロックチェーンや仮想通貨は本質的に摩擦を取り除く技術だと思います。情報がこれらの障壁を越えることができないか、これらの障壁を越える場合には第三者の支援が必要になるため、私たちが金融取引を行ったり、アプリケーションを構築したり、情報を設定したりすることを非常に困難にするいくつかの障壁があります。彼らはそれに一定の料金を請求します。

典型的な例は、家を購入する場合、買い手と売り手が存在しますが、実際の支払いが行われるときは、買い手と売り手が存在するため、そこに座ってお金を保持するだけの第三者の保証人が存在する必要があります。お互いを完全に信頼しないでください。これは現実の事実です。これに対処していきます。ただし、保証エージェントが、当事者の両方が閲覧できるコードである場合、または第三者によって精査されている場合は、無料または大幅に安くその仕事を行うことができます。ブロックチェーンの目的は、不動産保証を排除することではありません。それはあくまで応用例です。しかし、これは一般原則です。

アプリ A とアプリ B を相互運用できないようにする代わりに、それらを同じ基盤プラットフォーム上に構築すると、アプリ内アイテム、データ、クロスプロモーションなど、あるアプリから別のアプリに物事をフローさせることができます。 、またはその両方の上に構築されたサードパーティの機能。あるいは、サイトが Cookie を介してデータを共有するインターネットのことを考えてみましょう。ただし、それらの Cookie は単なる読み取り専用のメタデータです。これらの Cookie が通貨になるとしたらどうなるでしょうか?それとも消費可能なオブジェクトになるのでしょうか？これがロイヤルティ プログラムやクーポンだったらどうでしょうか?すべてのものにこの機能が組み込まれています。非常に抽象的ですが、そこに可能性が秘められています。通常、構築している人々は、これらがより魅力的なものを構築するために使用できる新しいスーパーパワーであると考えています。

エンドユーザーにとって、たとえ技術専門家でなくても、コードを信頼することを考えるとき、たとえ他の選択肢が不透明な大規模な中央エンティティだったとしても、ためらいを感じますか?

エンドユーザーにとって、たとえ技術専門家でなくても、コードを信頼することを考えるとき、たとえ他の選択肢が不透明な大規模な中央エンティティだったとしても、ためらいを感じますか?

そうは思わない。だって私たちはこれを毎日やってるんですよね？メールにログインするときに、コードによってメールが削除されるのではないか、送信しても実際には送信されないのではないかという心配はありません。そうなれば、メールの使用をやめるか、別のプロバイダーを使用することになるでしょう。ここでも非常に似ていると思いますが、もちろん実際に何かを読んでそれがどのように機能するかを確認できるのは多くの人だけです。メールをチェックしたくても、コードがないのでチェックできません。したがって、透明性はその重要な側面です。実際には、誰でもできるわけではありませんが、スポットチェックができる人もいます。また、再利用と不変性もあります。それがここでの鍵です。メールにログインすると、最後に何かを行ったときからコードが変更されたかどうかわかりません。これについては透明性がありません。 Web3 でも、この部分の情報は入手できますが、他では入手できません。

今後のSui Moveの展開に期待することは何ですか？

私たちが現在注力している機能の多くは、Sui Move パックの初期バッチをリリースし、その後そのパックをどのように成長させたいのか、何が成長しやすく何が難しいのかを見た人々との経験に基づいています。 Sui Move はパッケージの最初のリリースに最適な言語ですが、初期パッケージの使用ルールに違反することなく、型を変更したり、フィールドを追加したり、関数を追加したりして、相乗的な方法で実行したい場合はどうすればよいですか? ユーザーの信頼、すると非常に難しい問題になります。私たちが行っている作業の多くは、この問題を検討し、元のコードを使用している人々への信頼を維持しながら、プログラマーがコードを拡張できる柔軟性を提供するために、どのような言語レベルの機能を追加できるかを考え出すことです。

私たちはこれに関連する多くの機能、特に列挙型の開発に取り組んでいます。また、Move をフロントエンド コードに接続するエクスペリエンスに関連する他の作業にも取り組んでいます。私たちは、典型的なスイ アプリの 5% が Move コードで、95% がフロントエンド コードであると冗談を言います。したがって、私たちはその 95% を非常に重視しています。私たちは Move について話すことに多くの時間を費やしていますが、他の部分の生産性を高め、接続を容易にすることにも非常に気を配っています。一般に、セキュリティを向上させるために、アプリケーションをより多くの Move で構成するにはどうすればよいでしょうか?同時に、コードの 95% を、Move プログラマと非 Move プログラマの両方がアクセスしやすくするにはどうすればよいでしょうか。