対話 Move言語の父：Moveは後発ならではの利点を持ち、ブロックチェーンは根本的に摩擦を排除する技術である
TechFlow厳選深潮セレクト
対話 Move言語の父：Moveは後発ならではの利点を持ち、ブロックチェーンは根本的に摩擦を排除する技術である
他のWeb3プログラミング言語からの開発者にとって、MoveおよびSui Moveでの開発体験は確かにさらに効率的で安全である。
Web3業界の深掘り報道に専念し潮流を洞察最近、Mysten LabsのCTOであり、Moveプログラミング言語の生みの親であるSam Blackshear氏と対談し、なぜ彼がSui Moveという新しいスマートコントラクト言語を開発したのか、Suiが実現できる拡張性、そして分散型技術が開発者にもたらす利点について話し合いました。
以下はそのインタビュー内容です。
01. まず、プログラミング言語とは何か、開発者が言語を選ぶ際に重視するポイントは何でしょうか。また、自ら言語を開発しようと思った理由を教えてください。
プログラミング言語とは、コンピュータと友好的かつ安全で効率的、明確にやり取りするためのツールです。特にコンピュータにとっては非常に重要です。自然言語を使ってコンピュータと会話することはできません。自然言語は豊かさや表現力を持つことが目的ですが、わずかな言い回しやトーンの違いによって意味が大きく変わってしまうからです。
一方で、プログラミング言語において最も重要なのは、厳密に定義された意味論（セマンティクス）を持つことです。プログラムを書くとき、それが正確に何をするのかを理解している必要があります。小さな変更を加えても、それがどのような結果をもたらすのかを把握できなければなりません。これは複数のレベルで一貫して保たれなければならず、ソースコードとして記述されたものがある意味を持ち、それが他の形式に変換されても同じ意味を持ち続け、最終的にマシンの処理モジュールに到達するまで同じでなければなりません。
自然言語とは異なり、プログラミング言語の本質は特定の分野やタスクに特化していると考えています。そうでなければ、すべての作業を一つの言語で完結できるはずです。しかし、さまざまなプログラミング言語が存在するのは、すべての領域で優れたパフォーマンスを発揮することは不可能だからです。各言語は特定の問題領域をターゲットにしており、それらの問題解決に集中しています。たとえば、SuiブロックチェーンやMystenでの他のシステム開発に使われているRust言語は、高速かつ高性能なコードを安全に記述することに焦点を当てています。メモリ、スレッド構造、並行処理などの低レベルな詳細にアクセスできますが、CやC++のような従来の言語のように誤った使い方をしやすいリスクはありません。
この点でMoveの物語も非常に似ています。私がMoveを作ったのは、新しい言語を作りたいという動機ではなく、「Libraにはスマートコントラクトが必要だから、どうすべきか見つけろ」という任務でした。当時、EVM上でSolidityを使えるか？ WASMやJVMといった汎用言語をLibraに使うべきか？ それとも独自のものを開発すべきか？ 様々な選択肢を検討しました。
02. Moveの開発について詳しく教えていただけますか？
MoveはFacebookのLibraプロジェクトに端を発しています。私の任務は新しい言語を作ることではなく、「Libraにはスマートコントラクトが必要だ。だから、どうすればいいか調べろ」でした。さまざまな選択肢を検討しました。EVMでSolidityを使えるか？ WASMやJVMのような一般的な汎用言語をLibraで使えるか？ あるいは独自の仕組みを作るべきか？
独自のものを開発するという決断は、既存のスマートコントラクトに関する研究や、プログラマーが何をしようとしているのか、どの言語が彼らを助けているか・失敗させているかを調査した結果でした。私の結論では、多くの場合、既存のスマートコントラクト言語はプログラマーを裏切っていると感じました。
これはSolidityのひどいセキュリティ記録から明らかですが、さらに根本的には、スマートコントラクトは伝統的なプログラムとは異なる性質を持っています。Solidityは、今人々が行おうとしていることに適していない設計になっています。第一号のスマートコントラクト言語である以上、当初は人々が何をしたいのかわかっていなかったわけですから、それを非難するつもりはありません。しかし、人々が実際に何をしようとしているのかを見れば、Solidityが提供する抽象化やプログラミングツールでは不十分であり、別のアプローチが必要だとわかります。
これらのスマートコントラクトは非常にシンプルで、基本的に二つのことを行います。資産の種類を定義します。いつ資産を移転できるか、どのように使えるか、誰が読み書きできるかというルールを設定します。そして、アクセス制御ポリシーをチェックし、誰がその資産を所有しているか、誰が使用・操作を許可されているかを確認します。すべては資産を中心に回っており、物理的な資産と同じような性質を持たせたいのです。もし私が何かをあなたに渡したら、あなたがそれを所有し、私はもう持っていない状態になるべきです。
スマートコントラクトには「所有権」と「所有権の譲渡」という概念がありますが、コンピュータ上ではすべてがビットやバイトであり、自由に複製できます。このような概念はデジタル世界には元々存在しないため、物理世界のように扱えるよう、所有権や非代替性に関する良い抽象化を言語側で提供すべきです。開発者が毎回それを再発明する必要がないように、基本的な安全性を保証すべきなのです。
これがMoveの存在意義であり、なぜ最終的に新しい言語を作成したのかという理由です。これらの機能はスマートコントラクトプログラミングにとって基本的ですが、他の言語、特に既存のスマートコントラクト言語では再現が困難です。そのため、こうした基本機能を核とした言語を設計することで、開発者が安全かつ効率的にコードを書けるようにし、毎回「車輪の再発明」をしなくて済むようにしたかったのです。
03. SuiはMoveの変種であるSui Moveを使用しています。これらの変更を促した要因は何ですか？ Sui Moveのどの特徴がWeb3での製品開発に適しているのでしょうか？
変更を促した要因はいくつかあります。まず、初期のLibraプロジェクトの目標は規制対応型の決済ネットワークを構築することでした。そのため、Move（https://docs.sui.io/learn/sui-move-diffs）は汎用言語として設計しようとしましたが、同時にLibraの制約に合わせて意図的にいくつかの制限を設けました。重要な例として、特定の資産を任意の場所に送信できないようにすることです。ユーザーは明示的にアカウントを作成し、KYC認証を受けたり、アカウント作成料を支払ったり、ごく一部の許可された人物のみがアカウントを作成できるようにする必要がありました。これはLibraが規制準拠の支払いとスマートコントラクトを目指していたためです。しかし、より汎用的なWeb3の文脈では逆になります。基盤レベルで規制を課すのではなく、あらゆるものが任意のアドレスに送信可能であるべきです。また、明示的なアカウント作成はさまざまなユースケースを阻害するため望ましくありません。これが大きな要因の一つです。
もう一つの要因は、Moveでは資産に注力しましたが、当時のLibraでは資産の関心をトランザクション自体にどう持ち込むかを考慮していませんでした。そのため、トランザクションレベルでは、数字や真偽値など、資産ではないものを入力とするAPIしかなく、Move内でそれらの数字を使ってアカウントから資産を取り出すなどの操作を行う必要がありました。その結果、多くのコードが「面倒な帳簿作業」になってしまい、これを取り出し、あれを取り出し、他のものも取り出して、「よし、必要な資産をすべて手に入れた。これらを自分の作業スペースに置いた。これでようやく意味のある処理を始められる」といった流れになります。処理の最後には、「これらの資産をこのアカウントに戻し、それらをあのアカウントに戻して整理する」といった後片付けが必要です。
Suiでは、すべてのプログラムがこのように始まり終わりするのであれば、これを抽象化できないかと考えました。トランザクション処理のロジックがこの作業を代行することで、開発者は必要な資産を用意するだけで、すぐに本質的な処理に取りかかれます。これがSuiに存在するオブジェクト中心のデータモデルです。オリジナルのMoveではアカウントベースのデータモデルを採用しており、資産はアカウント下に格納され、開発者が明示的に取り出す必要がありました。一方、Suiでは、トランザクションがMove部分に入る時点で、Suiランタイムがすでに資産を取得しています。これにより、開発者は前後の帳簿作業から解放され、より便利になります。また、実行せずにトランザクション間の並列実行可能性を判断でき、Suiの水平スケーリングや他の効率的な処理を可能にする鍵でもあります。
他にも、オブジェクト中心のデータモデルを活用したプログラマブルトランザクションブロック（Programmable Transaction Blocks）など、非常に興味深い機能を実装しています。これはやや技術的な話題ですが、詳しく説明できます。ただし、これらの二点がオリジナルのMoveとの差異を生んだ主な要因です。
04. プログラマブルトランザクションブロックとその機能について詳しく教えていただけますか？
たとえば、他のブロックチェーンはショッピングモールのフードコートに例えられます。アイスクリームを食べたいなら、アイスクリームのスタンドに行き、クレジットカードで支払います。ハンバーガーも食べたいなら、また別のスタンドに行って支払います。私は大食いではありませんが、8つの料理を食べたいなら、8回の個別取引が必要です。一方、Suiはビュッフェに似ており、各トランザクションは一つのことだけではありません。一度ビュッフェの料金を払えば、追加コストなしにさまざまなことができます。アイスクリームも食べられ、ハンバーガーも食べられ、混ぜることもできます。
より具体的に言えば、100件のNFTをミントするために100回のトランザクションを送る代わりに、100件のNFTを一度にミントする単一のトランザクションを送れます。そのコストは1件のNFTミントとほぼ同じです。また、異種のトランザクションをまとめることが可能です。たとえば、ブロック内の最初のトランザクションでマルチシグウォレットからマリオキャラクターを取り出し、次のトランザクションでマリオを使ってゲームをプレイし、勝てば賞品を得て、さらに次のトランザクションでその賞品を友人と共有するトロフィーケースに収めることができます。素晴らしいのは、プログラマブルトランザクションブロックにより、ゲームはマルチシグウォレットやマリオの保存方法、トロフィーケースの実装を知る必要がないことです。
プログラマブルトランザクションブロックは、入出力オブジェクトを持つトランザクションで構成されます。必要な入力オブジェクトがあれば、それがどこから来たかに関わらず取得でき、出力を必要とする先にも、どこへ行くかに関わらず渡せます。他のブロックチェーンでは結合度が高くなるため、ゲームはマルチシグウォレットやトロフィーケースと統合されなければならず、共通のインターフェースを実装する必要があり、より強い結合が生まれます。Suiでは、いわゆる「一時的な組み合わせ」が容易になります。パイプが合えば、一つのトランザクション内で完結できます。
05. プログラマブルトランザクションブロックはユーザーにとってどのようなメリットがありますか？
ユーザーにとっての利点にはガス費用の削減があります。すべての操作を一つのトランザクションにまとめられるため、別々の取引を行うよりも安価です。また、承認の回数が減ります。システムがトランザクション承認を要求する場合、一度だけ承認すれば、すべての処理が一括で完了します。さらにアトミック性もあります。三つの異なる操作を行い、最初の二つが成功した場合にのみ三つ目を成功させたい場合、それらが独立したトランザクションであれば実現できません。しかし、一つのトランザクションにまとめれば、簡単に実現できます。
06. Suiでの開発はプログラマーにとって非常に良い経験になると、あなたや他の人から聞いたことがあります。経験豊富なWeb3開発者や初心者の開発者がSui Moveを始める際のエピソードを共有していただけますか？
他のWeb3言語から移ってきた開発者にとって、MoveおよびSui Moveでの開発体験は確かに効率的で安全です。最近Bucket Protocolのポッドキャストに参加しました。彼らはSui上で非常にユニークなDeFiプロジェクトを構築しています。システムアーキテクチャを紹介する中で、異なるコンポーネントがどのように連携するかを説明していました。もしSolidityでこのプロジェクトを書くなら8ヶ月かかるところ、Sui Moveならたった2ヶ月で完了し、セキュリティにも自信があると述べていました。この言語は、彼らが頭の中で考えているプロジェクトの構成方法に非常に近い形で機能します。一方、Solidityの世界ではそのつながりはそれほど直感的ではありません。
これは一例にすぎませんが、同様の声は多く聞きます。「この言語では開発速度が速く、完成後も安心感がある」と。こうした声を聞くと嬉しいですが、驚くべきことではありません。私たちはSolidityを研究し、その問題点を理解した上で、より安全で迅速にすることを明確に設計しました。この言語を使う開発者が何をしようとしているのか、そのニーズに合うように設計したのです。既存の状況に合わせるのではなく、実際に遭遇する問題のために設計した言語なので、切り替えたときに本当に評価されるのです。
先行者利益が重要だと言われますが、この場合はむしろ後発者利益の方が重要だと思います。
まさにそうです。
07. Sui MoveとSui全体のオブジェクト指向的特性についてすでに触れられていますが、Sui Moveの設計と、SuiがWeb3の大規模採用、低遅延、低コスト、スケーラビリティを実現できる点との関係をより明確に説明していただけますか？
Suiの開発では、他のプラットフォームが抱える問題を非常に意識しています。容量が限定されている場合、たとえばイーサリアムの秒間15トランザクション（TPS）や100、1000であっても、固定値であれば、プラットフォームが成功しすぎると容量上限に達します。すると、すべてのユーザーの体験が低下します。1000の空きしかない場合、最も重要な1000を選ばなければならず、ガス競争などで決定されます。結果として全員のガス料金が上がり、遅延が増え、あるいはその両方が発生します。多くのユースケースが排除され、最高料金を払えるものだけが成功し、他の人は別の場所に移るか長時間待つしかありません。これは好ましい状況ではありません。
Suiの目標は水平方向のスケーラビリティです。一定量のハードウェアを割り当てれば、一定のスループットが得られます。さらにスループットが必要であれば、バリデータノードがさらなるハードウェアを追加できます。上限はありません。これはすべてのWeb2サービスが動作する方式です。もちろん工学的な制約を解決する必要があり、簡単なことではありませんが、拡張可能なWebサービスを設計する際には誰もが水平スケーラビリティを実現しようとするでしょう。
Suiのユーザーが増えても、Suiが成長し続け、すべてが正常に動作することを目指しています。もちろん、同時に非常に低い遅延を維持することも重要です。スループットを増やしても遅延を犠牲にしてはいけません。
Libraシステムでは、こうした特性は考慮されていませんでした。それは小規模な決済システムで、数百の決済事業者がいて、1日数千万の支払いがあるかもしれないが、それ以上ではありません。そのため、単一のボックスアーキテクチャを採用し、よりシンプルで十分だと判断しました。しかしSuiでは、Libraのアプローチは通用しないことを理解していました。なぜなら、水平スケーラビリティの特性を持っていないからです。そこで、ゼロからこれを実現できるシステムをどう設計するかを考えました。それがオブジェクト中心のデータモデルの起源です。アカウントベースの古いデータモデルを捨てました。なぜなら、それでは水平スケーラビリティを実現するのが極めて困難だったからです。一方、すべてのデータをオブジェクトとして整理すれば、グローバル状態はオブジェクトIDからオブジェクトへの巨大なマッピングに過ぎません。これはキー・バリューのストレージであり、そのスケーリング方法はわかっています。これは単純な工学的課題です。
次に、キー・バリューのストレージからデータを取得・更新するプロセスに適合するトランザクション構造をどう設計するか？ キー・バリューのストレージをどうシャーディングするか？ トランザクションをどこで処理するかをどう決定するか？ それが基本的にすべての出発点です。つまり、これらをスケールさせる方法はわかっているのです。それをブロックチェーンの属性（検証可能な読み取り、Moveとの連携など）を持ったものにどう変えるか。そして、それらをできるだけスムーズに統合していくかということです。
08. より高いレベルで、Web2の開発者に対して、分散型技術の可能性をどう説明しますか？
ブロックチェーンと暗号資産は、根本的に摩擦を除去する技術だと考えています。金融取引やアプリ構築、情報の設定が非常に困難になる障壁があり、情報はその障壁を越えにくく、越えようとすると第三者の支援が必要になり、その支援に対価が発生します。
よく使われる古典的な例は住宅購入です。買い手と売り手がいますが、実際に支払いを行う際にはエスクロー代理人が必要になります。買手と売り手が互いに完全に信頼できないため、資金を預かる役割を果たす人が必要になるのです。これは現実の生活です。しかし、このエスクロー代理人が、双方が確認できるコードまたは第三者検証済みのものであれば、無料または低コストで同じ役割を果たせます。ブロックチェーンの目的は不動産取引のエスクロー代理人を排除することではありません。これは一例にすぎず、多くの場面で同様のことが起こります。
アプリAとアプリBの間に相互運用性の障壁がなく、同じ基盤プラットフォーム上で構築されていれば、アプリ内アイテム、データ、クロスプロモーション、あるいはその上に構築されるサードパーティ製品などが、アプリ間を自由に流れるようになります。あるいはインターネットを想像してください。サイトはCookieを通じてデータを共有しますが、Cookieは読み取り専用のメタデータにすぎません。もしCookieが通貨になったら？ あるいは消費可能なアイテムになったら？ 忠誠プログラムやクーポンになったら？ すべてにその機能が内蔵されています。非常に抽象的ですが、これが可能性です。通常、何かを構築しようとする人は、これらを新たな超能力として、より魅力的なものを構築する手段と捉えます。
09. 最終ユーザー、特に技術知識のないユーザーが「コードを信頼する」という概念に対して抵抗を感じることはないでしょうか？ たとえもう一方の選択肢が不透明な巨大中央集権的組織であったとしてもです。
そうは思いません。私たちが日々していることだからです。メールにログインしても、「このコードが私のメールを削除したり、送信しても実際には送られない」と心配しません。そんなことが起きたら、メールの利用をやめるか、別のプロバイダーを使うでしょう。これは非常に似ています。もちろん、誰もがコードの中身を読んで確認できるわけではありません。
それに、メールのコードを確認したいと思っても、コードは公開されていないのでできません。透明性がここでは重要な要素です。誰もがそれをできるわけではないが、一部の人がサンプリングチェックできます。それに加えて、繰り返しの利用と不変性です。これが鍵です。メールにログインしても、前回操作してからコードが変更されたかどうかわかりません。そこに透明性がありません。しかしWeb3ではそれが可能であり、他の場所では不可能です。
10. Sui Moveの将来について、どのような期待をお持ちですか？
現在注力している多くの機能は、Sui Moveパッケージの最初のリリースを行った開発者たちとの経験に基づいています。彼らがそれらの機能をどう進化させたいか、どの機能が拡張しやすく、どの機能が難しいかを観察しています。Sui Moveはパッケージを初めてリリースするには最適ですが、「この型を変更したい」「フィールドを追加したい」「関数を追加したい」という要望に対して、初期パッケージのユーザーの信頼を損なわず、一貫性を持たせて進化させるのは非常に難しい課題です。私たちはこの問題に取り組み、プログラマーに柔軟性を提供しつつ、初期コードのユーザーの信頼を維持できる言語レベルの機能を追加できるかを検討しています。
特に列挙型（enum）など、関連する多くの機能を研究しています。また、Moveとフロントエンドコードの接続体験の改善にも多くの取り組みを行っています。よく冗談で言うのですが、「典型的なSuiアプリは5%がMoveコード、95%がフロントエンドコード」です。そのため、この95%に非常に注力しています。Moveの話ばかりしてきましたが、他の部分をいかに効率化し、接続を容易にするかも非常に重視しています。全体としては、アプリのより多くの部分をMoveで構成することで安全性を高めること、そしてこの95%のコードをMoveプログラマーにも非Moveプログラマーにも理解しやすくすることに注力しています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Sui Network
