Move言語の父：Sui Moveスマートコントラクト言語はWeb3製品に適しています

来源： Sui Network

私たちは最近、Mysten Labs の CTO であり、Move プログラミング言語の作成者である Sam Blackshear 氏に、新しいスマート コントラクト プログラミング言語である Sui Move を開発した理由、Sui が拡張できる機能、および利益の構築に対する分散型テクノロジーの影響について話を聞きました。受信者の。

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

**Q1. まず、プログラミング言語とは何か、開発者がプログラミング言語を選択する際に最も求める資質、そして独自のプログラミング言語を開発する動機について説明していただけますか? **

プログラミング言語は、コンピュータとの友好的、安全、効率的かつ明確な対話のための単なるツールであり、これはコンピュータにとって特に重要です。自然言語の意味全体は豊かで表現力豊かであることであるため、私たちは自然言語でコンピューターと通信することはできません。わずかに異なるトーンを使用したり、微妙に異なる言葉の表現方法を選択したりすると、文や段落がまったく異なる意味を持つ可能性があります。

**プログラミング言語で最も重要なことは、セマンティクスを正確に定義することです。 **プログラムを作成するときは、それが何を行うかがわかります。それに小さな調整を加えれば、その変化がどこに起こるかがわかります。これは複数のレベルで維持する必要があります。ソース言語でコードを書くと、コードには意味があり、それから他の表現形式に翻訳され、その後、マシンの言語に到達するまで、同じ意味を持つ必要があります。処理モジュールについても同様です。

**プログラミング言語は、自然言語とは異なり、本質的にドメイン固有またはタスク固有であると思います。 **それ以外の場合は、1 つのプログラミング言語だけですべてを行うことができます。しかし、プログラミング言語が複数存在するのは、すべての分野で優れているわけではないからです。彼らは特定の問題領域をターゲットにし、それらの問題の解決に集中しようとしています。例として、Sui ブロックチェーンを作成するために使用する Rust プログラミング言語と、Mysten で行う他のシステム作業のほとんどを見ると、セキュリティを維持しながら高速でパフォーマンスの高いコードを作成することに重点が置かれています。メモリ、スレッド構造、同時実行性などの低レベルの詳細にアクセスできますが、C や C++ などの以前の言語のような間違いを犯すことはできません。

つまり、Move のストーリーもそれに非常に似ています。私がそれを作成したとき、それは新しい言語を作成することではありませんでした。先ほど、開発者が言語に何を求めているかについて触れました。彼らは「この言語は私が達成しようとしていることに適していますか?」と尋ねますが、おそらくもっと重要なことは、「*この言語には大規模なコミュニティがあるか?利用可能なデータベースがたくさんあるか?多くのプログラマが使用しているか?良い教育リソースはありますか? *" これらは非常に重要なので、たとえ言語自体が優れていたとしても、新しい言語を作成するハードルは非常に高くなければなりません。しかし、言語にこれらの要素がなければ、その利点は無意味です。大規模で活気のあるコミュニティをゼロから構築するのは非常に困難です。

**Q2、****Move の開発について詳しく教えてください。 **

**MoveはFacebookのLibraプロジェクトから生まれました。 **当時の私の課題は新しい言語を作ることではなく、「Libra にはスマートコントラクトが必要なので、何をすべきかを見つけてください」ということで、いろいろなことを検討しました。 EVM で Solidity を使用できますか? WASM や JVM などの通常の汎用言語を Libra に使用する必要がありますか?それとも独自に作成する必要がありますか?

独自のものを作成するという決定は、既存のスマート コントラクトを調査し、プログラマーが何をしようとしていたのか、特定の言語がどこで役に立ち、どこで失望したかを理解することに基づいていました。 私の結論は、多くの場合、既存のスマート コントラクト言語では期待を裏切られるということです。

これは、Solidity の貧弱なセキュリティ記録から明らかですが、より根本的に、これらのスマート コントラクトはあまり伝統的なタイプのプログラムではありません。 Solidity は、人々が現在行っていることのために構築された言語ではありません。これは人々がそれを使って何をしたいのかまだわかっていない最初のスマートコントラクト言語であるため、私はそれを批判しているわけではありません。人々がそれを使って何をしようとしているのかを見れば、Solidity 言語が提供していない別の抽象化とプログラミング ツールのセットが必要であることは明らかだと思います。

これらのスマート コントラクトは非常にシンプルで、基本的に 2 つのことを行います。 これらは、アセットをいつ転送できるか、アセットで何ができるか、誰が読み取り、誰が書き込みできるかに関するルールを含む、アセットのタイプを定義します**。 **** また、アクセス制御ポリシーを確認して、資産の所有者、使用を許可されているユーザー、操作を許可されているユーザーを決定します。 **すべては資産を中心に展開しており、それらの資産には物理的な資産と同じ属性が必要です。私があなたに何かを渡した場合、あなたはそれを持っているはずで、私はもうそれを持ちません。

**スマートコントラクトには所有権と所有権の移転という概念がありますが、コンピュータ上ではすべてが単なるビットとバイトであり、自由にコピーできます。 **そしてご存知のとおり、これらの概念は現実世界には存在しません。したがって、所有権と均質化について適切に抽象化できる言語が必要です。現実世界とまったく同じですが、プログラマーに再発明を強いることはありません。基本的なセキュリティの保証が必要です。

これが Move の機能であり、私たちがこの新しい言語を作成することになった理由です。これらのタスクは、スマート コントラクト プログラミングの基礎です。これらは、既存のスマート コントラクト言語を含む他の言語で再現するのが困難です。私たちは、プログラマーが毎回コードを作成する必要がなく、安全かつ効率的にコードを作成できるように、これらの基本的な機能を提供することを中心に言語全体を設計したいと考えています。

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

こうした変化を引き起こした要因はいくつかありますが、そのうちの 1 つは、準拠した決済ネットワークを構築するという当初の Libra プロジェクトの目標でした。そこで、私たちは Move を (汎用言語として) 設計しようとしました。しかし、Libra には制約が必要なので、意識的にいくつかのことも行いました。重要なことの 1 つは、人々が特定の資産をリブラに送信できないようにすることです。彼らは、人々が明示的にアカウントを作成し、アカウントの所有者が KYC 検証を受ける必要があるなど、アカウントの作成時にいくつかのルールを設定することを望んでいます。あるいは、アカウントの作成に料金がかかる場合や、アカウントの作成にのみ許可される場合もあります。アカウントを作成する権限を持つ小さな人によって作成されています アカウントを作成する人もいます。Libra の全体の目的は、準拠した支払いと準拠したスマート コントラクトを行うことであるため、これらの制限があります。しかし、より一般的な Web3 の世界では、それは逆です。基本レベルで準拠する必要はありません。これはスマート コントラクトの概念です。物事をできる限り自由にしたいと考えており、任意のアドレスに何かを送信することは完全に可能です。その場合、明示的なアカウント作成はすべきではありません。これは、さまざまなユースケースを妨げることになりますが、これは重要な要素です。

もう1つの要因は、Moveでは資産に焦点を当てていましたが、Libraでは当時、資産の焦点を取引自体にどのように持ち込むかについて考えていなかったということです。したがって、トランザクション レベルに達しても、この API だけが存在し、数値やブール値、その他資産ではないものを入力し、Move ではそれらの数値を使用してアカウントから資産を引き出したり、その他のことを実行したりします。実行するコードのほとんどは、これを取り出し、あれを取り出し、他のものを取り出すという厄介な簿記であることがわかりました。そして、必要な資産はすべて揃っています。彼らはここ、私のスタジオにいます、そして今、私は何か意味のあることを始めることができます。そして、プロセスの最後に、「OK、これらの資産をこのアカウントに戻して、そのアカウントに戻して、再編成します」と言うかもしれません。

Sui では、すべてのプログラムがこのように始まり、終わる場合、それを抽象化できるかどうかを考え抜きました。したがって、トランザクションを処理するロジックはプログラマーに代わって実行し、プログラマーの観点からは、必要なアセットを準備するだけで、すぐに興味深い作業を開始できます。 これは、Sui に存在する **** オブジェクト中心のデータ モデルです。 **元の Move では、アカウントベースのデータ モデルがあり、アセットはアカウントの下に保存され、プログラマーはそれらを明示的に抽出する必要がありました。 Ai では、トランザクションの Move 部分に入った時点で、アセットは、Sui ランタイムによってすでに取得されています。これは、簿記の前後にこれらすべてを行う必要がないため、プログラマにとってより便利であり、実際に実行せずに、あるトランザクションを別のトランザクションと並行して実行できるかどうかを判断することもできます。他にもいくつかのことをより効率的に行うことができます。

また、プログラム可能なトランザクション ブロックにオブジェクトベースのデータ モデルを活用するなど、他にも非常に興味深い取り組みを行ってきました。これはやや技術的なトピックなので、詳しくお話したいと思います。しかし、これら 2 つの要因が、オリジナルの Move からの乖離の主な要因でした。

**Q4、****プログラマブル トランザクション ブロックとその機能について詳しく教えてください。 **

私は他のブロックチェーンがショッピングモールのフードコートのようなものであることを説明するために例えを使いたいと思います。アイスクリームが食べたいと思ったら、アイスクリームスタンドに行き、クレジットカードを取り出して支払います。しかし、それでもハンバーガーが食べたいと判断した場合は、バーガースタンドに行って再度お金を支払うことになります。私は食いしん坊ではありませんが、8 つのものを食べたい場合は、8 回の別々の取引を行う必要があります。 **Sui はビュッフェに近いものですが、それぞれの取引は 1 つだけではありません。ビュッフェの料金を支払ったら、追加料金なしでできることがたくさんあります。 **アイスクリームを食べてもいいし、ハンバーガーを食べてもいいし、それらをすべて混ぜ合わせてもいいです。

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

**プログラム可能なトランザクション ブロックは、入力オブジェクトと出力オブジェクトを含むトランザクションで構成されます。 **入力オブジェクトが必要な場合は、そのオブジェクトがどこから来たのかを気にせずにそのオブジェクトを取得し、その出力をそれを必要とするオブジェクトに渡すことができます。また、その出力先も気にする必要はありません。他のブロックチェーンでは結合がより強力であるため、ゲームをマルチシグ ウォレットやトロフィー ロッカーと統合するか、すべてのブロックチェーンに共通のインターフェイスを実装して結合を強化する必要があります。 **Sui を使用すると、いわゆるアドホックな組み合わせがはるかに簡単になります。 **同様に、パイプが一致する場合は、1 つのトランザクションで実行できます。

**Q5、****ユーザーにとってプログラム可能なトランザクション ブロックの利点は何ですか? **

ユーザーにとって、プログラム可能なトランザクション ブロックの利点には、すべての操作を個別のトランザクションを実行する代わりに 1 つのトランザクションにまとめられるため、ガスコストの削減が含まれます。さらに、必要な承認が少なくなります。トランザクションの承認が必要なシステムを使用している場合は、トランザクションの承認を 1 回行うだけで、すべてが一度に実行されます。もう 1 つの利点は アトミック性 です。3 つの異なる処理を実行し、最初の 2 つの操作が成功した場合にのみ 3 番目の操作を成功させたい場合、それらの操作が独立したトランザクションである必要がある場合、それを実現することはできません。ただし、それらすべてを 1 つのトランザクションに入れることができれば、これを簡単に達成できます。

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

他の Web3 プログラミング言語から来ている開発者にとって、Move および Sui Move での開発エクスペリエンスは実際により効率的かつ安全です。ちょうどバケットプロトコルについてのポッドキャストに出演していたのですが、彼らはSui上で本当にクールなDeFiプロジェクトを構築しています。システム アーキテクチャをデモンストレーションしながら、さまざまなコンポーネントがどのように連携して動作するかを説明します。このプロジェクトを Solidity で書いていたら 8 か月かかったかもしれないが、Sui Move では 2 か月しかかからなかったとのことで、セキュリティには非常に自信を持っています。この言語の仕組みは、彼らの頭の中にあるプロジェクトのポートフォリオのアイデアに非常に近いものです。 Solidity の世界では、つながりはそれほど直接的ではありません。

これはほんの一例にすぎませんが、言語の上達が早くなり、学習を終えると自信が持てるという同様のケースをたくさん聞きます。そう言っていただけると嬉しいです。しかし、これはある意味、驚くべきことではありません。私たちは Solidity を調査し、問題について学びました。私たちはそれをより安全かつ高速にする方法を中心にシナリオを明示的に設計しました。私たちは、この言語の開発者が何をしようとしているのか、また、既存のものに応えるのではなく、彼らのニーズを満たすように言語を設計する方法を検討しました。この言語は人々が抱えている問題に合わせて設計されているため、切り替えた人はその言語に本当に感謝します。

**先行者利益が重要だと言われますが、この場合、より重要なのは後発者利益のほうだと思います。 **

そうです、それです。

**Q7、****Sui MoveとSui全体のオブジェクト指向機能について触れた際にも触れられましたね。しかし、Sui Move の設計と、Web3 の大量採用、低レイテンシ、低コスト、およびスケーラビリティを実現する Sui の能力との関係をもっと明確に説明できますか? **

私たちがSuiに貢献すること、そして他のプラットフォームが直面する問題について非常に慎重であることの1つは、イーサリアムのような1秒あたり15トランザクション（TPS）のようなものであっても、100または1,000のトランザクションであっても、容量が限られている場合であるということです。固定数にすると、プラットフォームが成功しすぎると、容量の上限に達します。この時点で、プラットフォームを使用するすべてのユーザーのエクスペリエンスが低下します。欠員が 1,000 件しかない場合は、最も重要な 1,000 件を選択する必要があります。これはガス入札またはその他の方法で選択できます。いずれにしても、ガソリン価格が上昇するか、待ち時間が増加するか、あるいはその両方が発生します。最も高い料金を支払うことができるものだけが成功し、他のものは他のものを探すか、より長く待たなければならないため、多くの使用例は除外されました。これは良い状況ではありません。

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

もしSuiの顧客やユーザーが増えれば、私たちの目標はSuiが成長し続けることであり、すべてがうまくいくはずです。もちろん、非常に低いレイテンシーを維持しながら。スループットを向上させながらレイテンシを犠牲にすることは望ましくありません。

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

そこで問題となるのは、キーバリュー ストアからのデータのフェッチと更新に対応するトランザクション構造をどのように設計するかということです。 Key-Value ストアをシャーディングするにはどうすればよいでしょうか?トランザクションをどこで処理するかをどのように決定すればよいでしょうか?それは基本的にそこから来ています。とはいえ、私たちはこれらをスケールする方法を知っています。これを、ブロックチェーンのプロパティ、検証可能な読み取り、移動などを備えたものにするにはどうすればよいでしょうか。そして、それらをできるだけスムーズにまとめる方法。

Q8、** より高いレベルで、Web2 に懐疑的な開発者と分散テクノロジーの可能性についてどのように議論しますか? **

**ブロックチェーンや仮想通貨は基本的に摩擦を取り除く技術だと思います。 **金融取引の実行、アプリケーションの構築、または情報の設定を非常に困難にする障壁が存在します。これは、情報がこれらの障壁を越えることができないか、これらの障壁を越える場合には第三者の支援が必要となるためです。サードパーティは、サポートを提供するために料金を請求します。

人々が好んで使用する典型的な例は、住宅の購入です。買い手と売り手が存在しますが、実際に支払いを行う場合、買い手と売り手はお互いを完全に信頼していないため、そこに座って資金をエスクローするだけのエスクローエージェントが必要になります。これは現実の事実です。これに対処していきます。ただし、エスクロー エージェントが、双方が閲覧できるコードである場合、または第三者によって検証される場合は、無料または大幅に低コストでその仕事を行うことができます。ブロックチェーンの目的は、不動産におけるエスクローエージェントを排除することではありません。これは使用例の 1 つにすぎませんが、よくあるケースです。

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

Q9、** エンドユーザーにとって、たとえ技術的な知識がなくても、たとえ他の選択肢が不透明な大規模な中央エンティティだったとしても、コードトラストを考慮することにためらいを感じますか? **

そうは思わない。だって私たちは毎日こんなことをしているんですよね？電子メールにログインするときに、コードによって電子メールの 1 つが削除されるのではないか、または電子メールを送信しても実際には送信されないのではないかという心配はありません。そうなれば、メールの使用をやめるか、別のプロバイダーを使用することになるでしょう。これは非常に似ていると思いますが、もちろん誰もが実際に何かを読んでそれがどのように機能するかを確認できるわけではありません。

そして、電子メールのコードを確認したくても、コードが存在しないため確認できません。したがって、透明性はその重要な側面です。誰もがこれを実行できるわけではありませんが、サンプルを実行できる人もいます。そして、それをあらゆるものの再利用と不変性と組み合わせます。それがここでの鍵です。メールにログインすると、最後に何かを行ったときからコードが変更されたかどうかわかりません。これについては透明性がありません。この情報を知っていても、Web3 では入手できますが、他では入手できません。

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

**私たちが現在注力している機能の多くは、Sui Move パックの初期バッチをリリースし、その後それらの機能をどのように進化させたいのか、どの機能が開発しやすいのか、どの機能が開発しやすいのかを検討した開発者との経験に基づいています。ものはもっと難しかったです。 **Sui Move は最初のリリース パッケージとしては優れた言語ですが、これから変更するタイプについては、いくつかのフィールドを追加し、いくつかの関数を追加します。一貫性がありながらも、初期パッケージの使用に反しない方法でユーザーが信頼する方法で運用するには、これは非常に困難な問題になります。私たちが行うことの多くは、これを見て、元のコードのユーザーの信頼を維持しながらプログラマーが拡張できる柔軟性を提供するために、どのような言語レベルの機能を追加できるかを決定することです。

**私たちはこれに関連する多くの機能、特に列挙型に取り組んでいます。 **私たちはまた、Move とフロントエンド コードを接続するエクスペリエンスを改善するために多くの作業を行っています。私たちはよく、典型的な Sui アプリケーションは 5% が Move コードで、95% がフロントエンド コードであると冗談を言います。したがって、私たちはその 95% に非常に重点を置いています。私たちは Move について話すことに多くの時間を費やしましたが、他の部分の効率化や接続の容易化にも重点を置きました。一般に、私たちはセキュリティを強化するために、アプリケーションをどのように Move で構成するかに重点を置いています。同時に、コードの 95% を Move プログラマと非 Move プログラマの両方が理解できるようにするにはどうすればよいでしょうか。