原作者：スイワールドDAO
昨年、a16z およびその他の機関が、Sui に代表される Move パブリック チェーンを強力に推進したことで、Move 言語がメタ ディエムの廃墟から復活しましたが、同時に、Sui Move が登場した瞬間から、次のような否定的な声が常に存在していました。
Move 言語が Solidity や他の開発言語よりも優れている可能性があるという理由だけで、新しいスマート コントラクト言語が必ずしも必要になるのでしょうか。また、新しいレイヤー 1 を最初から構築しても問題ありませんか?
最近、a16z Crypto チームと MystenLabs の共同創設者兼 CTO、Move 言語の父である Sam Blackshear が「プログラミング言語と暗号」をテーマにポッドキャストで対談し、Move が重要な方向性である理由について話し合いました。将来のスマートコントラクトに向けて。
このポッドキャストでは、a16z Crypto と Sam Blackshear が、デザイン思考、オブジェクト指向およびアセット プログラミング、セキュリティ、共有形式検証、ガバナンスとコミュニティ ツール、クロスプラットフォームの適応性などのトピックについて話し合います。
主な共有コンテンツは次のとおりです。
1. プログラミング言語とスマートコントラクトの歴史
従来のプログラミングから、スマート コントラクト プログラミング、そして Move プログラミングまで。 Move は、型システム、静的型付け、コンパイル時チェックなどの問題に対応する言語を設計する方法を最も早く検討したものでした。
2. Moveスマートコントラクトの革新
EVM は、イーサリアム用に設計されたプラットフォームの実装詳細をオーバーフィットします。開発者は最終的に、イーサリアムの拡張を困難にするいくつかのバグを含め、イーサリアムによって行われた設計上の決定の多くを継承する必要がありました。 Move は、コア言語にブロックチェーン固有のものを何も追加せずに設計されました。ソースコード言語レベルでの革新は非常に重要であり、Move が最終的に提供できるのは、コード検証機能と、他のプログラマによる攻撃からの VM レベルの保護です。
3.Sui Moveの設計思想
Move は、ユーザー トランザクションとスマート コントラクトを実行するために使用される実行可能なバイトコード言語です。 Sui Move では、ベリファイアをより効率的に並列化できるため、これらをプロトコル レベルでエンコードする必要がなく、ユーザーやプログラマが考慮できるようになり、保存と実行が容易になります。
4. セキュリティ
スマートコントラクトの世界では、私たちは制約にさらされています。非常に少量のコードを作成しますが、コードは完璧である必要があり、セキュリティが最優先事項である必要があります。ムーブ セキュリティとは、プログラマーが自ら足を踏み出すことを防ぐことですが、同時に、プログラマーが攻撃から防御できるように、可能な限り正しいプリミティブを提供することも目的としています。
5. オブジェクト指向とアセット
ほとんどの Web2 オブジェクト指向プログラミング言語がそのようなものであるため、Move はオブジェクト指向およびアセット指向のスマート コントラクト プログラミング言語として設計されました。 Sui Move では、オブジェクト上に物事の中心点を配置することで、きめの細かいアクセスを可能な限り正確に表現できるようにするという高いインセンティブが生まれます。 Sui Move のグローバル ストレージの構造は、オブジェクト ID からオブジェクト ID へのマッピングです。
6. セキュリティの比較
Move は、構築により、スマート コントラクト プログラミングにおける再入性と権限チェックの欠落を排除します。 Move では、オブジェクトの所有権情報は実際にはオブジェクトのメタデータに保存されますが、これはプログラマが制御できるものではありません。 Move Prover は、スマート コントラクトを作成する際の言語エラーを防ぐように設計されており、開発者が多くの基本的な間違いを犯すのを防ぐことができます。
7. スマートコントラクト言語のガバナンス
当初、Move は実際のガバナンスを持たずに Facebook で開発されました。私たちは言語を非常に慎重に拡張します。シンプルさが重要ですが、それを積極的に拡張していきます。 Sam Blackshear 氏は、チェーン EDM の基本機能の一部を引き続き適用できるクロスプラットフォーム言語として Move を設計するなど、非常に具体的な希望を持っています。また、スマート コントラクト開発の専門家と Web2 初心者の両方を非常に柔軟にカバーします。 。
8. 開発者向けの学習提案
たくさんのコードを読むことが、言語について学ぶ最良の方法です。喜んで共有し、さらに深く掘り下げて、あなたのコードを他の人と共有したり、一緒にオープンソース コミュニティを構築したりすることを本当に楽しんでくれる人を見つけてください。仕事を楽にするツールであれば、それがどのように機能するかを学ぶ必要があります。
最初のレベルのタイトル
ホスト ソナル チョクシの紹介
Web 3.0 へようこそ。a16z Crypto チームによる次世代インターネットの構築に関する番組です。私はあなたのホスト、ソナル・チョクシです。
この番組は、開発者、クリエイター、アーキテクト、ビジネス リーダー、政策立案者など、暗号化と Web 3.0 に関連する問題を理解し、さらに深く掘り下げようとしている人を支援するように設計されています。私たちは今、ショーの新しいシーズンを開始しています。今日のエピソードは、既存のスマート コントラクト プログラマーとこの分野への参入を検討している他の開発者の両方を対象として、プログラミング言語と暗号通貨に焦点を当てています。プログラミング言語の進化と出現に興味がある人にとっても良い選択肢です。
今日のスペシャルゲストは、Sam Blackshear 氏、MystenLabs の共同創設者兼 CTO、同社は Web 3.0 の分散型の未来に向けた基礎を築いています。 Sam は、博士号取得から Facebook での勤務、そしてスマート コントラクトを構築するためのオープンソース プログラミング言語である Move の作成と著者に至るまで、プログラミング言語に関して長い歴史を持っています。このテーマについてはまた詳しくお話します。
プログラム全体を通じて、次のような方も招待します。Noah、a16z Crypto のスマート コントラクト リサーチ エンジニア、彼と別のパートナーは最近、Helios と呼ばれるイーサリアム用の軽量クライアントを開発し、困難なガス最適化を勝ち取りました。
私たちも招待しますEddy Lazzarin 氏、a16z Crypto のリードエンジニア最初のレベルのタイトル
プログラミングとスマートコントラクトの歴史
司会者ソナル・チョクシ：
最初にノアが話して、次にサム・ブラックシアとエディが話して、伝統的なプログラミングの歴史から始めます。
a16z Crypto Noah：
私たちは、プログラミングの歴史がスマート コントラクト プログラミングの歴史にどのような影響を与えるかを理解したいと考えています。これは、従来のプログラミング、スマート コントラクト プログラミング、および Move 言語の 3 つがあると思うからです。 3つのものにはそれぞれ独自の歴史がありますよね？
Sui CTO Sam Blackshear：
はい、私はこのフレームワークが好きです。人々が構文を設計したり、人々を幸せにするために言語を使用するのは事実ですが、それ以上のものです。したがって、私はこの全体像のフレームワークがとても気に入っています。
a16z Crypto Eddy Lazzarin：
これに基づいて、従来のプログラミングには、過去 20 ～ 30 年の間にさまざまな傾向があります。従来のプログラミング言語は変化しており、いくつかのホットなトピックが生まれては消えていきます。非常に緩やかな型チェックを備えた動的プログラミング言語が非常に人気があった時期が長くありました。一般的には、型や技術的な詳細をすべて忘れて、ただコードを書くだけで作業に取りかかることが、より人間工学に基づいた方法であると考えられています。
Sui CTO Sam Blackshear：
しかし最近では、プログラムを実行する前にできる限り詳細を知るために、型システム、静的型付け、コンパイル時チェックなどについてより深く考えるようになりました。これらのトレンドは常に変化しています。ただし、スマート コントラクト プログラミングについては、非常に新しいため、スマート コントラクト プログラミングにおいてこの種の歴史は見たことがなく、これは大きく異なります。
Move 言語は、これ (型システム、静的型付け、コンパイル時チェックなどの問題) に対応するために言語をどのように設計できるかを私たちが見た中で最も古い証拠だと思います。静的型付けや動的型付けなど、スマート コントラクト プログラミングでどのような変更が予想されるのか知りたいと思っています。現在、Solidity という 1 つの言語しか存在しないため、これらのトピックはまだ取り上げられないかもしれません。
司会者ソナル・チョクシ：
では、これはスマート コントラクト プログラミングへの移行とどのように関係するのでしょうか?サム、もう一度答えてください?
Sui CTO Sam Blackshear：
このスマート コントラクトの分野では、EVM がスマート コントラクト言語の最初の参入者として、さまざまな傾向が見られます。スマートコントラクトで何をしたいのか分からない人はいませんか?それらをどのように書くか、またはこの種のもののいずれかを使用するため、使用法を発見する必要がある専門家の種類を理解しようとする柔軟性の方が重要だと思います。これで私たちは、構成要素について何かを知ったか、少なくとも何かを知ったような気がします。
スマート コントラクトの傾向は非常にドメイン固有であり、資産のテンプレートを定義し、資産を転送するためのポリシーを定義し、アクセス制御と権限を確認します。
これが基本であり、コンパイラやオペレーティング システムなど、スマート コントラクト言語で記述する必要はありません。つまり、汎用プログラミング言語に比べて、非常に優れた利点があります。
ERC-20 標準が EVM がプログラム可能になってからずっと後に制定されたにもかかわらず、EVM がイーサリアム プログラムを作成するための基本的な構成要素の 1 つとさえ考えられていると、人々は過小評価しているように思います。それまでに最も基本的なことが明らかであるという明確な証拠は見当たりません。
おっしゃるとおり、型を当然のこととして受け入れることができるようになりました。これらのタイプとバイパスには、ある程度の技術的負債が生じる可能性があると思います。規模が小さく、とにかく早く進めたいだけで、コードを破棄できる場合は、この種の技術的負債は完全に許容されます。しかし、それを会社やスタートアップの規模、つまり急速に成長している小規模な会社、誰もがコードベース全体を理解していて、この種の技術的負債は許容できるという観点から説明しているのは興味深いです。
しかし、それが非常に大規模になると、構築している新しいオブジェクトやシステムの影響を知らないでコードを変更する人が大量に存在します。これを型システムに組み込むことで、曖昧さのない直接的な方法でコードを記述し、後で誰かがぶつかる可能性のあるガラスのフェンスを誤って作成する代わりに、障害物にぶつかることができます。
たとえば、皆さんが話したように、重複を防止できること、アセットの最大供給量を設定できることなどです。これらの制約は非常に重要であり、プロジェクトの規模に関係なく維持する必要があります。これらは、プロジェクトの健全性とセキュリティを維持するための非常に重要な制約です。これらの境界を知るということは、境界を強制できるプログラミング言語を作成できることを意味します。私は Move 言語をそのように見ています。
正しいことを行うために必要な制約の種類を学習すると、それらを言語自体に組み込むことができるようになります。したがって、あなたが言ったように、それはタイプにある程度似ていると思います。
健全性と安全性をプログラムするには型が非常に重要であるとおっしゃいました。小規模なプロジェクトには動的型付けが適しているかもしれないが、プロジェクトが成長するにつれて静的型付けを使用する必要があると皆さんは言います。私は少し同意しませんが、完全に静的な型指定の方が適しているのではないかと思います。これは斬新な解釈かもしれません。それはプログラマーの健全性のためです。私が今まで見た中で最も恐ろしいのは、ショートカット「control k」を押すと、関数のシグネチャが何であるかを教えてくれることです。 Python を書くときにこれが怖いです。関数のシグネチャを確認すると、パラメーターの名前だけが表示されます。私は、一体何をしてほしいのですか？
a16z Noah：
コードを書いたら二度とコードを見ないという考えを人々が受け入れるとは信じられません。
a16z Eddy Lazzarin：
彼らは、システムの要件を念頭に置くことができるというデフォルトの前提を受け入れます。
a16z Noah：
しかし、たとえ 100 行のプログラムであっても、これをデフォルトにすることは不可能だと思います。
Sam Blackshear ：
機能しますが、完璧ではありません。
a16z Eddy Lazzarin：
あなたが正しいと思います。そしてそのメンタリティも進化したと思います。以前は、型システムはプログラマを同僚から保護するために使用されていました。スタートアップが大きくなりすぎる場合に便利です。でも今は、自分を守るという気持ちが強いです。
スマート コントラクトの文脈では、攻撃者から私を守ってくれます。これが本当の違いです。通常のプログラムでは、攻撃者が型システムに束縛されている場合はプログラムをデプロイしないからです。攻撃者は他の言語でマシンコードを書くことができます。独自のファイアウォールを保護する必要があるだけです。しかし、ここでは、攻撃者のコードに流れ込んでそのままの状態に保つ、この適切に型付けされたオブジェクトを作成します。型システムは私を安全に保たなければなりません。
あなたが言ったように、これはさまざまな要件をもたらす優れたツールであり、コピーの防止などの要件を強制する必要があります。これは、通常の型システムでは考慮する必要のないことです。また、削除を防止したり、値を特定の方法で使用または破棄したりする必要もありません。これはすべて、私たちがスマート コントラクトに取り組んでおり、これらのユースケースに意味のある型システムを考え出そうとしているためです。そのため、最終的にはこれらの機能を追加して、将来のスマート コントラクト言語も追加することになるでしょう。
司会者ソナル・チョクシ：
実際、皆さん、従来のプログラミングとスマート コントラクト プログラミングのその他の違いについてもう少し詳しく話しましょう。しかし、先に進む前に、スマート コントラクト プログラマーが利用できる言語の概要を簡単に説明してもらえますか? SolidityやViperなどの現状を見ていきたいので、全体像を見る必要があると思います。どのようなコンテンツを知っていれば、より早く始めることができます。
Sui CTO Sam Blackshear ：
そうですね、基本的には、スマート コントラクトを作成したい場合は、ほぼ常に Solidity を使用することになると思います。あなたがたまたま他のいくつかの小さなエコシステムのいずれかに属している場合を除きます。
Polkadot エコシステムに参加している場合は、既存のプログラミング言語である ink! (Sui World Note: ink! は、Rust でスマート コントラクトを記述し、Wasm コードにコンパイルするためにパリティによって開発されたスマート コントラクト言語です) を使用することになります。 StarkNet エコシステムに参加している場合は、Cairo を使用します (Sui World 注: Cairo は STARK 証明システムのプログラミング言語の 1 つです)。
しかし、ほとんどの場合、スマート コントラクトの書き方についてアドバイスするとしたら、Solidity を少し学んでから EVM を学ぶことをお勧めします。 Viper を使用することもできますが、唯一の欠点は、Viper の方が新しく、バグが発生しやすい可能性があることです。数年前、デポジット契約を検証した際に、Viper コンパイラに多数のバグが発見されたことを思い出します。これらのバグを発見した男は現在 16z で働いており、Day June であり、正式な検証の専門家です。
Day June は形式検証の専門家であるため、現在は a16z で働いています。そして現実には、いくつかのコンテンツや言語を学ぶ必要があります。
EVM を深く理解する必要さえあり、本当に優れたスマート コントラクト エンジニアになりたいのであれば、とんでもないレベルまで EVM を理解する必要があります。、各操作のガスコストを知ることができるように、ガスコストに関連する正確なコードを伝えることができます。これが私たちが現在住んでいる世界です。
a16z Eddy Lazzarin：
ソフトウェア エンジニアは、コードを実行しているマシンについていつでも知ることができるということは、おそらく言及する価値があるでしょう。プログラミング環境については知るべきことがたくさんあります。しかし、スマート コントラクト プログラミングでは、環境は非常に豊富で複雑です。言語自体とはほぼ独立して、理解すべきコンテキストがたくさんあります。それは、あなたの周りで何が起こっているのか、周りにどのような物体があるのか、さまざまなコードがどのように呼び出されるのか、ということです。これはとても不思議なことです。
司会者ソナル・チョクシ：
では、Solidity の学習に最も近い人は JavaScript を知っている人であるというのは本当でしょうか?
Sui CTO Sam Blackshear ：
JavaScript と同じように「関数」というキーワードが使用されているため、人々はこれを JavaScript だと言います。しかし、残念ながら、それらはあまり似ていません。
a16z Eddy Lazzarin：
文法の観点から見ると、Solidity は多くの JavaScript 機能を継承しています。目を細めたり、機嫌が悪い場合は似ているように感じるかもしれませんが、実際はまったく異なります。仮想マシン環境は多種多様であるため、共通点はほとんどありません。
司会者ソナル・チョクシ：
似たようなプログラミング言語はありますか?
a16z Noah：
はい、直接似たプログラミング言語はないと思います。 Was (Sui World Note: WebAssembly Studio、C/C++ および Rust コードを WASM 形式にコンパイルするためのオンライン ツール) に精通しており、高度な分離が必要な環境 (Surplus など) でコードを記述しようとしている場合)、これはおそらく、これらのコードが独立して実行されるものに最も近いものですが、ある程度の通信が必要です。しかし、それでもあまり似ているわけではなく、考え方も全く異なりますし、表面的な類似性は危険なこともあります。
a16z Eddy Lazzarin：
おそらく、プログラミング言語の歴史におけるいくつかの大きな間違いが関係しているでしょう。ブロックチェーンに関しては、間違った道を歩むという厄介な歴史があるのかどうかはわかりません。私たちはひどい道を歩んでしまったのでしょうか？
司会者ソナル・チョクシ：
それは良い質問です。
Sui CTO Sam Blackshear ：
それは良い質問です。 1977 年には C 言語がリリースされ、Standard ML がリリースされた年でもありました。標準 ML は非常に影響力があります。現在、OCaml 言語と Rust 言語はその影響を大きく受けており、Move 言語もその影響を受けています。しかし、こうした考えは昔から存在していました。多くの人が、C が主流になる代わりに、強力な型付けや安全性の組み込みなど、Standard ML の考え方が広く受け入れられる代替の未来について考えていると思います。
司会者ソナル・チョクシ：
では、コンピューター技術におけるこの傾向は何でしょうか?それが間違いだと言っているわけではありませんが、Standard ML のような言語は現在でも非常に現代的に見えると思います。別世界を想像するのは面白いもので、最初にそれを発見したときは衝撃を受けました。
a16z Eddy Lazzarin：
好奇心から質問しますが、C などの言語はなぜそれほど単純で命令型であると思いますか?彼らはコンピューターについて比較的低いレベルで考えており、プログラミング言語としてはあまり多くのことを行っていません。私は C についてそう考えています。なぜこの道を選んだのでしょうか?
Sui CTO Sam Blackshear ：
当時のハードウェアの制約により、C を使用する必要があったと思います。効率的なプログラムを作成したい場合、またはコンピューティングの限界を押し広げたい場合は、ハードウェアを推進する場合は別の道を選択することになると思います。しかし、私の意見では、関数型プログラミングは難しく、多くの点で直観に反しています。 C言語が難しくないとは言いませんが、C言語の方がとっつきやすいと思います。そのとき、私は非常に複雑な、あるいは理由を説明するのが難しいことを行ったことに気づきましたが、もう手遅れです。それは良い考えです。関数型言語は学習曲線がより急になりますが、一度コツを掴めば、自分でコードをかなりうまく考えることができ、物事がかなりうまくいくことがわかります。
a16z Eddy Lazzarin：
コンピューターがハードウェア レベルでどのように動作するかをよく考えると、C のような言語の方が簡単だと思います。ただし、プログラミング言語についてあまり知らない場合は、C 言語の方が簡単に始めることができます。しかし、プログラミング言語をよく知っているのであれば、ML や関数型プログラミングの種類の言語については、さらに探究すべき点があると思います。
Sui CTO Sam Blackshear ：
これは大局的な答えです。しかし、私が言いたいのは、小規模な「コンピュータ言語エラー」問題についてです。
a16z Noah：
関数型プログラミングがどれほど素晴らしいかをよく耳にするので、これについては少し躊躇していますが、理解するのが少し難しいと感じています。しかし、私がいつも疑問に思っているのは、関数型プログラミングがそれほど優れているのであれば、なぜ関数型プログラミングは現在のプログラミング言語のネットワーク効果を克服できなかったのかということです。私を驚かせるのはそのありようです。
ただし、関数型プログラミングが私たちにもたらす大きな貢献は、私たちが使用するすべての命令型言語が借用されたものであると考えていることを付け加えておきたいと思います。しかし最も良い点は、先ほどおっしゃったように、Rust は標準電子メールの影響を大きく受けていますが、Rust は基本的に命令型言語であるということですよね。しかし、そこには、それらを見つめることから来る素晴らしい妖精の粉がすべて含まれています。
Sui CTO Sam Blackshear ：
一般に、本当の問題は、命令型言語が 1977 年以降、あまりにも大きな影響力を持ってきたことだと思います。それから PRFP があります。あなたが言ったように、PRFP は最高のものではありません。独自の素晴らしいアイデアがあり、それぞれが独立して、誰もが独自の問題を抱えています。私たちは今、ラストのような本物の異人種間が美しく結婚しているのを見ているだけです。それは本当に風景を変えます。
そこで、私が言及したいことの 1 つは、トニー ホア氏がノード参照の 10 億ドル規模のエラーと呼ぶものです。当時彼は誇張していたかもしれないが、間違いを犯さなかったよりも、間違いの方が明らかに高価だった。
a16z Eddy Lazzarin：
最初のレベルのタイトル
スマートコントラクトの革新的な開発
a16z Noah：
実は、あなたが仮想マシン層とプログラミング言語層のイノベーションと、それらがスマートコントラクトの開発にどのような影響を与えるかについてあまり話していないことに興味があります。
Sui CTO Sam Blackshear ：
素晴らしい質問ですね。仮想マシン層とプログラミング言語層の違いなどの区別について、人々は十分に考えていないように思います。実際、EVM や新しい仮想マシン層以外にも、Viper などのソース コード言語など、多くの革新があります。これらは多くの点で Solidity よりも優れており、楽しいです。
Move が私たちが期待する Web 3.0 の法的標準になるのであれば、仮想マシン層でのイノベーションはゆっくりと漸進的に行われることになると思います。コアは修正されているため、完全な再設計ではなく、新しいものを追加するだけになります。
ただし、ソースコード言語レベルでの革新は非常に重要になると思います。現時点ではソース コード言語は 1 つだけですが、それはバイトコード形式と密接に関係しています。しかし、セキュリティを重視してスマート コントラクトを使用するクライアントが増えているため、試すべきソース コード言語が多数存在することが想像でき、これは興味深い研究分野です。おそらく、これまでの事実を書き留めることから始めて、プログラム内でそれらの情報を合成したり、制限事項の提案をしたりすることもできるでしょう。
おそらく、移動の前に事実を書くことから始めて、その後、合成プログラムにプログラムを入力させるか、制約を提案させることができます。
たとえば、シーン階層のような非常に特殊なゲームのコンテキストで移動を作成できます。おそらく、これは Python ライブラリで書かれていますが、Move のバイトコードにコンパイルされています。おそらく、Solana やその他のプラットフォームと同様に、Move の統合を検討しているものの、仮想マシンは統合したくないのですが、Move のバイトコードを Salina のバイトコード形式にコンパイルし、開発者レベルで Move ソース コード言語を使用することによって実現します。
JVM（Java Virtual Machine）のように、さまざまなアプローチがあると思います。 JVM は、元々は Java のみをサポートしていた素晴らしい汎用仮想マシンです。しかし、それは時の試練に耐え、現在では、Scala、Groovy、およびこれらのプリミティブを使用して、人々がやりたいことに非常に一致した、さまざまなプログラミング エクスペリエンスを設計するためのその他の興味深い方法が用意されています。
したがって、私は、Viper にはソース言語レベルで実験する余地がたくさんあるという偏見を持っています。
a16z Eddy Lazzarin：
すべての代替 EVM バイトコード言語についてどう思いますか? EVM 用に、よりスマートでより複雑な言語を構築するための FE、Iron、Viper などの興味深い取り組みがあると楽観的ですか?
Sui CTO Sam Blackshear ：
したがって、これらは EVM バイトコードにコンパイルされたさまざまなソース コード言語です。
a16z Eddy Lazzarin：
はい、EVM バイトコードにコンパイルされます。
Sui CTO Sam Blackshear ：
Facebook で Move の設計を開始したとき、他のソース コード言語が EVM を構築しているのを見て、Solidity と Viper を検討し、EVM の構築を開始しました。私たちが最終的に到達した結論は、人々が安全なスマート コントラクトを作成する上で最も難しい問題は、EVM の根本的な性質であり、型指定された値を信頼できる境界上でどのようにフローさせるか、動的な意思決定などであるということです。 EVM の機能。
より優れたソース コード言語を構築すると、開発者が失敗しにくくなります。もしかしたらもっと高度な検証ができるかもしれない、しかし最終的に、Move が提供できるもの、そして私たちが重要だと考えているものは、コードバリデーターと他のプログラマーからの VM レベルの保護です。
ソース コード言語ではこれを実現できません。VM に組み込む必要があります。完璧なソース コード言語を得るために EVM で何度繰り返しても、Solidity は素晴らしいと思いますし、私たちはもっと改善できると思いますが、私はこれらの基本的な保護手段が VM に組み込まれていると、結果は他のパスほど良くありません。ハーフはクールだと思うので恥ずかしいわけではありませんが、最終状態が他のパスほど魅力的ではないと思うからです。
初期のスマート コントラクト言語、特に EVM は、トランザクション構造、アカウント構造、特定の種類の暗号化の使用などに関する指示を内部的に含む、イーサリアム用に設計されたプラットフォームの実装詳細に過剰適合していると思います。
これにより、イーサリアムのようなチェーンではないチェーンで EVM を使用することが非常に難しくなり、最終的にはイーサリアムが行った設計上の決定の多くを継承する必要があり、場合によっては、イーサリアムが行った設計上の決定の一部を継承する必要があると思います。イーサリアムは難しい、拡張エラー。
Move を設計する際、私たちはコア言語にブロックチェーン固有のものを追加せず、特定のブロックチェーンから可能な限り独立させることを強く意識しました。
そのため、スウェーデンでこれを行っている可能性のあるクレイジーなトランザクション構造を持つプルーフ・オブ・ワーク・チェーンや、オーストラリアでこれを行っている別のチェーンでMoveを使用することができます。このようにして、Move 開発者になるために特定のチェーンに賭ける必要はありません。将来のチェーンを含め、さまざまなチェーンにわたってスキルを使用できます。言語の最大の資産はコミュニティであるため、これはスマート コントラクト言語の存続にとって重要であると私たちは考えています。また、スキルを 1 つの言語に過度に適合させるのではなく、クロスプラットフォームにできるようにすることで、コミュニティを拡大し、成功に向けて有利な立場に立つことができます。そして、大きなコミュニティのおかげで、ツールや公共図書館への多額の投資、そして言語が有名になって成功するために本当に必要なものすべてへの投資が可能になります。
それが私たちが最初からやろうとしてきたことであり、今では言語の統合方法が大きく異なる複数の実際に異なる Move チェーンが見られました。
a16z Eddy Lazzarin：
これがnode.jsの根底にあるテーマだと思いますよね？
司会者ソナル・チョクシ：
はい。
a16z Eddy Lazzarin：
JavaScript を知っていて、いろいろなことをやりたいと思っている人はたくさんいます。彼らはさまざまなライブラリを共有したいと考えています。既存のコードはサーバーサイド JavaScript インスタンスを開始できるため、ノードが便利になります。これは、バックエンド プログラミングを行わなくても、バックエンド プログラミングに積極的に取り組み始めて、それを自分の分野にすることができるあらゆる種類の開発者が存在することを意味します。
Sui CTO Sam Blackshear ：
良い比較だと思います。また、プログラミング言語のガバナンスについても少し話したいと思いました。なぜなら、Node には明らかに非常に注目度の高いガバナンスの分割と分割があり、どのプログラミング言語コミュニティにも多くの注目度の高いガバナンスの分割と方向性があるからです。 Node については取り上げましたが、私のお気に入りの 1 つです。しかし、この話題は必ず終わらせたいと思います。他に何か言うことはありますか？あなたは私たちの大好きなラジオ番組の常駐オールディーズだと思います。
a16z Noah：
それで、私には対位法というか、クールなアイデアがあります。なぜ誰も Move 用の OP ロールアップを作成しないのか不思議に思っていましたが、それは本当に素晴らしいことです。OP の Rollup 担当者がイーサリアムに実装されていることを考慮すると、彼らは MetaMask と ECDSA 署名を使用していますが、Move が ECDSA を使用していないようであるように、私たちと同じ署名形式を使用しているようには見えません。
Sui CTO Sam Blackshear ：
はい、イーサリアムの EdDSA および ECDSA 署名形式をサポートしています。
a16z Noah：
完璧ですが、私が言いたいのは、本当に興味深いものを構築できるということです。しかし、Moveを学ぼうとしていたとき、私はDessertとActor Dogを見つめ続けました。私は混乱しています。
Sui CTO Sam Blackshear ：
確かに問題ですよね？ Move を学習し始めると、混乱するかもしれません。スマート コントラクト言語を学習しているのに、ブロックチェーンはどこにあるのでしょう?両方のプラットフォーム用のコードを作成しようとすると、両者の違いによって問題が発生する可能性もあります。したがって、私たちがまだ理解しようとしている課題は、プラットフォームを選択し、デザートを選択し、Optus を選択し、それを深く学習すると、スキルとコードを別のプラットフォームに簡単に移行できることがわかるということだと思います。ここにはいくつかの固有の問題と、これを容易にするために解決する必要があるドキュメントの問題がいくつかあると思います。
a16z Eddy Lazzarin：
おそらく、SQL を移植可能なスキルと考えるかどうかによって類推が決まります。 SQL には多くの方言があります。アンチ SQL があります。それが何であるかは誰も知りませんが、SQL を学ぶことはできます。少し目を細めれば、どのデータベースでも使用できます。特定の関数名や特定の型については少し混乱するかもしれませんが、大まかに言うと、同じ形。これにより、SQL が非常に強力で耐久性のあるものになると思います。それが今でもデータの共通語の一部である理由です。おそらくこれがMoveの未来です。もっとうまくできると思います。
Sui CTO Sam Blackshear ：
最初のレベルのタイトル
スマートコントラクトプログラミングのユニークな点
司会者ソナル・チョクシ：
私たちは、従来のプログラミングとスマート コントラクト プログラミング、特定の制約と相違点、さらにはトレッド プログラミングとスマート コントラクト プログラミングの類似点について行ったり来たりしてきました。スマート コントラクト プログラミングについて、私たちがカバーしなかった何か独特なものはありますか?
a16z Eddy Lazzarin：
スマート コントラクトのコンテキストでもう 1 つ非常に重要なことは、Solidity のガス メータリングなどのリソースの使用です。多くの場合、コンピューティング リソースは比較的豊富ですが、計算コストも非常に重要です。しかし、スマートコントラクトのコンテキストやブロックチェーンのコンテキストの外では、それはあまり触れられず、考慮されないことを意味します。消費するリソースという言語の概念は、スマート コントラクト プログラミングにとって興味深いリソースになる可能性があると思います。
Sui CTO Sam Blackshear ：
これは私たちが非常に重視していることであり、EVM にガスメータリングを組み込んでいます。これは、おっしゃるとおり、従来のプログラミング言語とは大きく異なります。
将来の傾向としては、ガス会議はコマンドごとに細かく設定されるのではなく、リソース乱用などの深刻な問題を防ぐために、ますます粗めのものになるだろうと思います。
私は実際、ガス ゴルフ (Sui World 注: ガス ゴルフとは、一連のスマート コントラクト ジャンプ インタラクションで最もガス効率の高いコードを書くという開発者への挑戦を指します) のようなものは非常に興味深いと思いますが、実際にはコーディングにとって非常に重要です。 . スタイルと安全性はどちらも多くの害をもたらします。
皮肉なことに、命令ごとの課金モデルについてしかわかっていない理由は、おそらく、巨大な仮想マシンがある場合、実際に実行時間を測定する場合、100k 命令を実行する場合と 500k 命令を実行する場合の違いは重要ではないためです。
では、なぜ注文ごとに料金を請求するのでしょうか?したがって、これをどのようにしてより粗くするかという傾向が見られると思います。
Solidity コードでこれらすべての安全でないブロックや大量のインライン アセンブリを見るたびに、私たちが今どれほど早い段階にあるのかを思い出します。これはスマート コントラクト開発者が考慮すべきプログラミングの課題ではなく、成熟したことの兆候ではないからです。開発エコシステム。しかし、私たちはその方向に進んでいます。エッジケースを考慮する必要があるという点には同意します。適切なアルゴリズムの選択、適切なデータ構造の選択、適切な一般的なアプローチの選択は、ほとんどのソフトウェア エンジニアリングの場合と同様に、すべて重要です。しかし、各命令のコストを正確に計算するという些細な問題は、おそらく多大な労力を要します。
司会者ソナル・チョクシ：
ガス、種類、資産、セキュリティの最適化について話しました。他にどのような制限を考慮する必要がありますか?
Sui CTO Sam Blackshear ：
これはガスに似たスレッドですが、私が念頭に置いている特定のサブセットは状態です。これは私にとって大きな問題です。ガス運用について考えるとき、私はガスを徹底的に最適化することを好みます。
ただし、実際の資金を保持する実際のスマート コントラクトを扱う場合、私の一般的なアドバイスは、以前に使用した状態よりもわずかに少ない状態をわざわざ使用する場合を除き、合理的に整理する必要があるということです。これは永遠のリソースのようなものであり、データの場所である実行または呼び出しのすぐ上に配置する必要があるため、使用する状態を減らすという愚かなことができる場合は、アセンブリの大きなブロックを使用するのはそのときだけです。
a16z Eddy Lazzarin：
基本的にお金がかかると思うので、この点は全く同感です。プラットフォームですべてのコントラクトが任意の状態にアクセスできる場合、並列化は困難になります。そして、Squeeze や他のいくつかの新しいブロックチェーン プラットフォームが採用しているアプローチは、トランザクションがアクセスできる状態を明示的に制限することです。少なくともいくつかはお知らせします。このようにして、高レベルでは、プラットフォームは実行とコンセンサスを含むトランザクションをより簡単に並列化できます。したがって、これは一部のプログラマが考慮する必要があることです。状態にアクセスするときはできるだけ速くし、不要な状態に触れないようにして、バリデーターがより効率的に並列化してより多くのブロック領域を実現できるようにします。
a16z Noah：
これにより、ロールプレイング以外の状況であっても、すべてのバリデーターが完全な状態をダウンロードする必要があるわけではないという事実が明らかになりますか?状態を簡単に分離して、バリデーターが処理できるトランザクションのみを提供できるようにすることは可能でしょうか?
Sui CTO Sam Blackshear ：
そんな世界は本当に実現できると思います。これにより、さまざまなアプローチへの道も開かれます。
プログラマーの観点から要約すると、さまざまなトランザクションにわたって全世界にアクセスできることは非常に価値があります。ただし、ロールアップを介して、または複数のトランザクションにわたって実装する必要があるほど、この利点を強調することはできません。これにより、ユーザーが気づくセキュリティが低下する可能性があります。
ブロックチェーンの価値はこの抽象化から来ていると思います。台帳があり、すべての貴重な状態がこの台帳にあり、それらすべてに一度に触れることができます。プログラマーの観点から見ると、ここにブロックチェーンの価値があります。問題は、舞台裏で物事をより効率的に機能させるにはどうすればよいかということです。バリデーターをより効率的に並列化できるように、よりスパース化するにはどうすればよいでしょうか? Sui では、バリデーターは複数のワーカーを持つことができ、各ワーカーは状態の一部を担当します。しかし、プログラマの観点から、さらには他のバリデータの観点からも、それはすべてを実行する論理的なエンティティのように見えます。
最初のレベルのタイトル
スマートコントラクトプログラミングに対する考え方の変化
司会者ソナル・チョクシ：
スマート コントラクト プログラミングに関連するいくつかのユニークな側面について説明しました。他にどのような考え方の変化がありましたか?少し話しましたが、エディが言ったように、大きな変化は、プログラミングの世界では、少なくともコンピューティングの初期の頃から、私たちは豊かな世界にいますが、この世界では、限界の世界にいます。それは考え方の一例です。他にどのような考え方の変化がありますか?特に、スマート コントラクト プログラミングに触れているプログラマーの皆さんにとって、何が驚いたのか、何を教えられたのか、あるいは特定の事柄について違う考え方をさせられたのかは何ですか?
a16z Eddy Lazzarin：
少しばかげた例かもしれませんが、ERC-20 トークンの残高はあなたのアカウントが所有するものではないことを数年前に初めて知ったときのことを今でも覚えています。あなたのアドレスにはトークン残高がありません。代わりに、どのアドレスにどれだけの残高があるかを記録するトークン コントラクトがあります。誰かにトークンを転送したいときは、その人にトークンを送信するわけではありません。代わりに、契約に入り、これらすべての低レベルの操作を実行して、アドレスとそのアドレスが保持する残高を変更する必要があります。あなたにはその契約を操作および変更する権限があります。これは非常に直観に反するアプローチであり、EVM と Slippery で初めて気づいた Move に関する考え方の興味深い変化です。私たちがよく聞く英語の単語は必ずしもプログラミング モデルに対応しているわけではないため、これは興味深い考え方の変化です。
Sui CTO Sam Blackshear ：
実際にやるときの話だということを付け加えておきたいと思います。通常、私たちは開発者の生産性について非常に懸念しています。それは、バグがほとんどないコードを大量に記述するのがエンジニアの仕事であり、それらのバグはそれほど重大ではないからです。一方、スマート コントラクトの世界では、非常に少量のコードを記述することが仕事であり、コードは完璧でなければなりません。あらゆる面で完璧でなければなりません。そうしないと、何億もの他人のお金を失うことになります。それは全く異なる考え方への転換です。 2 か月かけて 1,000 行のコードを見つめ、コードを改善する方法、さらに重要なことに、コードを完璧にする方法を考え出します。その後、レビュー担当者も同じことを行い、コードが完璧かどうかを判断します。
司会者ソナル・チョクシ：
これは大きな考え方の転換です。プログラミングの世界では、少なくともコンピューティングの初期から、私たちは豊かな世界にいますが、この世界では制約の世界にいます。
a16z Eddy Lazzarin：
もう 1 つの考え方の変化は、ERC 20 トークンの世界では、アドレスはトークンの残高を表すものではないということです。トークンを送信することはできません。トークン コントラクトにアクセスし、トークン コントラクト内のアドレスに対応するトークン残高を見つけて、アドレスと残高を変更してトークンの転送を完了する必要があります。これは直感に反する考え方ですが、EVM と Move では非常に重要な考え方の変化です。
Sui CTO Sam Blackshear ：
スマート コントラクト プログラミングでは、あなたの仕事は小さなコードを書くことですが、このコードは何億もの人々の資金の安全に関わる可能性があるため、コードは完璧でなければなりません。コードが正しいことを確認するには、コードを精査する必要があります。
また、スマート コントラクトではコードが不変であるため、スマート コントラクトのアップグレードはモバイル アプリや Web サイトのアップグレードよりも困難です。スマート コントラクト プログラミングでは、安全なアップグレードと信頼をサポートし、従来のエコシステムに近づける方法を考える必要があります。
しかし、スマート コントラクト プログラミングでは、敵対的な考え方が必要ですが、他の分野の人には馴染みがないかもしれません。これは、スマート コントラクトのデプロイメント モデルのため、アプリケーションの予想される使用法だけでなく、意図しない使用法も考慮する必要があります。従来のプログラミングでは、自分自身を隠す方法、小さな API に制限する方法、ファイアウォールを使用して攻撃者の行動を制限する方法などが存在するためです。
しかし、スマート コントラクトの重要な点は、作成したものが想像もしていなかったコードと対話でき、それを安全に実行できることです。したがって、この状況のメリットとデメリットを考慮する必要があります。これは間違いなく、従来のプログラミングからの考え方の変化です。
司会者ソナル・チョクシ：
これは非常に重要な質問であり、スマート コントラクトの作成方法やスマート コントラクト プログラミング言語の使用方法について議論する際に優先すべき質問ですか?
Sui CTO Sam Blackshear ：
そのとおり。実はそれは私が話すのが一番好きなことなんです。これはとても怖いのですが、スマート コントラクト言語の設計者が考慮する必要がある問題はセキュリティです。それが主な焦点であり、それが邪魔にならない限り、おそらく唯一の焦点です。
私の意見では、スマート コントラクトのセキュリティは、より広範な暗号通貨の普及にとって存続を脅かす脅威です。私がこれを言う理由は、Ethereum と Solidity、そして最も人気のあるプラットフォームである EVM と Solidity を見てみることができるからです。このコードを書いた初期のプログラマーを見ると、彼らは非常に高い資格を持っており、基盤となるブロックチェーンをよく理解しており、セキュリティを非常に意識していました。彼らは自分たちが何をしているのか知っています。彼らは、数億ドル、数十億ドルを管理するコードを書く責任を非常に真剣に受け止めていると思います。
しかし、どこのスマートコントラクトのセキュリティ記録を見ても、それはかなりひどいものであり、それはこれらの人々のせいではありません。これはとても難しい質問だと思います。そして、言語がさらに難しくすると思います。したがって、私のお気に入りのサイトである rakt.news を見ると、リーダーボードを確認したり、規模に応じて毎週または毎月発生する、非常に日常的な、数千万ドルまたは数億ドル相当の 10 件のハッキングを確認したりできます。同時に、スマート コントラクトの開発者コミュニティは非常に小さく、フルタイムの EVM プログラマはわずか約 5,000 人であり、従来の開発者コミュニティと比較すると非常に小規模です。
したがって、もし私たちの従業員が最も熱心で安全を意識しているが、開発慣行と安全記録が持続不可能であるとあなたが信じているなら、そのときあなたの結論は、安全を確保せずにこのスペースが生き残る方法はないということだと思います。問題が継続する場合悪い方向に成長するということは、まったく成長しないことを意味する可能性があります。あるいは、Web3 に参入したいと考えている大手金融機関や企業のように、スマート コントラクト開発者を雇用する必要があるかどうかを検討しているのでしょうか。ハッキングされて何千万ドルも取られると不安になります。この状況は時間が経つにつれてさらに悪化するでしょう。彼らは傍観者に留まるかもしれない。したがって、新しいスマート コントラクト言語を設計しようとしている人は、セキュリティを最初に考慮する必要があります。
司会者ソナル・チョクシ：
実際、資産を失わないという文脈でそれをほのめかしましたが、それは非常に重要なので、具体的には何を意味しますか？
Sui CTO Sam Blackshear ：
セキュリティとは、プログラマーが自ら足を踏み出すことを防ぎ、プログラマーが攻撃から防御できるようにできる限り正しいプリミティブを提供するということです。スマート コントラクトは、コードが攻撃にデプロイされるセットアップであるためです。攻撃者の隣では、攻撃者はコードを直接呼び出したり、コードに直接リンクしたりできます。コードはオープンソースであるか、少なくともバイトコードはオープンソースです。
これは、私たちがこれまで見てきた中で最も敵対的なプログラミング環境であり、間違いを犯すと最も高くつくものです。したがって、スマート コントラクトのプログラミング設計について話している場合、セキュリティは常に最優先されるべきだと思います。セキュリティの問題を解決したら、他のより表現力豊かな要素について考えることができます。ここで、私の少し退屈ではありますが、非常に重要だと思う答えを示します。
a16z Eddy Lazzarin：
どの機能がセキュリティに影響を与える可能性がありますか?これにはどのような例がありますか?
Sui CTO Sam Blackshear ：
最も重要なことはカプセル化、特にカプセル化の個々のサブ機能だと思います。コードを記述するときは、攻撃者が何をしようとするかを予測できないため、攻撃者が何をしようとするかを予測せずに推論できる必要があります。したがって、ソース コード レベルだけでなく、バイトコード レベルでも強力な型システムが必要です。そうすることで、ソース コードを作成したときに得られる保証は、ブロックチェーン上でコードを公開し、他の人が依存するときにも保証されます。 on オンのままで対話します。
他のドメインで人気のある特定の機能 (動的ディスパッチなど) は、スマート コントラクト プログラミングでは本質的に不適切であることがわかりました。
従来のプログラミングでは、インターフェイスや動的ディスパッチなどが、普遍的な重要な抽象化メカニズムです。あなたがインターフェイスを定義し、その後、他の人がそのインターフェイスを別のロジックで書き換え、そのインターフェイスに対してプログラミングすることができ、すべてがうまくいきます。しかし、「コードが法律である世界では、インターフェイスは犯罪である」という皮肉があります。
a16z Noah：
これは冗談です、ちょっとやめましょう。コードが法律である世界では、インターフェイスは犯罪です。
司会者ソナル・チョクシ：
先に進む前に、この文をもう少し説明してもらえますか?あまり急いで飛び越えたくありません。
Sui CTO Sam Blackshear ：
はい、正確に。ここでの考え方は、インターフェイスは動作を定義するのではなく、期待される動作を定義するということです。たとえば、インターフェイス、パラメータ名、さらには型の仕様を読むと、何を達成したいのかがわかります。しかし、それが起こるという保証はありません。
したがって、何かを保護するためにコードを書いたとしても、実際には攻撃者のために空の小切手を残し、他の誰かが記入することになります。これは契約法上の犯罪と思われます。これは内容の定めのない契約です。私はこの機能がとても気に入っています。従来のプログラミング言語でよく使われているものです。しかし、スマートコントラクトでは、これがさまざまな問題を引き起こすと考えています。たとえば、再入には動的なスケジューリングが必要です。たとえば、動的スケジューリングをキャンセルすると、再入はまったく行われなくなります。イーサリアムのポイズントークンのようなことは、転送関数を書き換えるために起こりますが、それが資金の転送にのみ使用され、おそらく他には何もしないことは誰もが直感的に知っています。しかし今度は、お金を盗むなど、予想を超えた行動をとらせるようになりました。これは、この機能の一例です。これを削除すると、コードを推論して適切にカプセル化することがはるかに簡単になります。呼び出しサイトを見るたびに、それが何をしようとしているのかが正確にわかり、他のことを心配する必要がなくなるからです。後であなたを驚かせるようなことをする人々。
a16z Eddy Lazzarin：
正確に言うと、4 本の脚と 1 つの座席を持つ椅子に関するインターフェースを定義し、それを行動レベルではなく具体的なレベルで記述する場合、記述していないものは暗黙的である可能性がある、というような類推だと思います。またはデフォルト 椅子に関するその他のこと、たとえば、ある種の構造的完全性があること、特定の素材であること、特定の方法で配置されていることなどです。
a16z Eddy Lazzarin：
回避することができます。つまり、インターフェイスは、強制したいセキュリティ制約を捉えていない、単なる任意の記述のセットです。
a16z Noah：
まさにその通りの定義です。
a16z Eddy Lazzarin：
間違ったレベルで物事を定義する。私は興味がある。
Sui CTO Sam Blackshear ：
しかし、インターフェイスを超えてモジュール化するにはどうすればよいでしょうか?インターフェイスが犯罪であるとしたら、おそらく私も犯罪者でしょう。なぜなら、複雑なスマート コントラクトを構築する私のお気に入りの方法の 1 つは、異なる目的を持つ異なるコントラクトを作成することだからです。そして、特に非常に複雑なシステムでは、モジュールが何らかのインターフェイスに従うモジュールベースの基盤があり、メイン コントラクトはさまざまなモジュールを呼び出す方法を知ることができます。これらのモジュールは通常、ガバナンスを通じてライセンスが付与されますが、Super Express のプラグ アンド プレイのモジュール性はどのようにして取得しますか?標準化されたインターフェイスはありませんか?遺産を取得するにはどうすればよいですか？
a16z Eddy Lazzarin：
インターフェースに関係することはすべてそうですか?
Sui CTO Sam Blackshear ：
これはまさに正しい質問です。彼らは一日中これに反対することができますが、有用なコードを書くための何かを提供するのはどうでしょうか?家から出ることを禁止されていれば、犯罪は起こらないのと同じです。しかし、私たちがそれを行う方法は、インターフェイスと継承だけが唯一の方法ではないということです。私は合成で考える傾向があります。動的スケジューラ インターフェイスを必要としないいくつかの構成プリミティブが提供されています。
その一つがジェネリック医薬品です。私たちは、あなたが持っているものとよく似た実行時継承を持っています。 Clr (Sui World Note: 共通言語ランタイム、共通言語ランタイム) 非常に具体的な例を挙げましょう。そうしないと、すぐに抽象的になってしまいます。
ERC-20 のようなものですが、これは明らかに基本的に重要な暗号化標準です。あなたのプラットフォームや言語でそれができない場合、それはあまり役に立ちません。 Move のような言語では、t という型の点 (t はジェネリック型パラメーター) を定義してから、コイン用の関数 (たとえば 2 つの点を結合する関数) を実装します。これはすべての種類のコインに当てはまります。それは誰かがカバーしたいことではありません。スプリットを定義するのはあなたです。
誰かにトークンの動作をカスタマイズしてもらいたい場合は、いわゆるケイパビリティ パターンを使用します。たとえば、トークンの場合、カスタマイズしたいことの 1 つは、総供給量はいくらか、より根本的にはそのポリシーは何かということです。これは次のように表現できます。 OK、型「t」のポイント構造体があり、ドル、ポンド、その他の通貨型などの t のさまざまなインスタンスが存在します。カスタマイズしたいものについては、機能レベルで提供し、トークン関数を作成します。あなたは、これが私のトークンの型パラメータであり、それから「資金庫の能力」と呼ばれるものを与えると言いました。次に、t の財務容量を保持している人だけがタイプ t のトークンを鋳造および破棄できることを保証する別のロジックがあります。この財務容量を取得して、別の契約にロックし、総供給量の制限を強制することができます。コメントを火曜日のみにして木曜日にはコメントしないなど、どこかに置くこともできます。制御の流れを逆転させることで、任意の組み合わせが可能になります。これはトリックの一例ですが、このトリックはほぼどこでも機能するため、動作を特定の方法で機能させたい場合は、それをハードコーディングする必要があります。悪く聞こえるかもしれませんが、特定の 2 つのメソッドを実装し、許可する機能に対してそれらの機能を定義します。
a16z Eddy Lazzarin：
機能は、従来のプログラマのように見えるインターフェイスに追加できる制約だと思いますか?
Sui CTO Sam Blackshear ：
はい、これらのインターフェイス パターンのほとんどは非常に簡単に変形できると思います。コンパイルは少し難しくなりますが、このインターフェイスが実行しようとしているものと同等の機能モデルであると主張できます。
司会者ソナル・チョクシ：
ところで、サム、これで満足ですか？自由に反対してください。多少の衝突は良いことです。
Sui CTO Sam Blackshear ：
私はそれで問題ありません。なぜなら、非常に事前定義された動作を持つモジュールに組み込むことができる組み込み機能を備えたモジュールまたは構造体があれば、モジュールがそれを行うのと同じように、まったく同じ動作を実現できると思うからです。モジュールは抽象構造体を受け入れ、その構造体はそのモジュール内で定義され、その構造体内には組み込み機能があります。これは実際に非常にうまく機能します。なぜなら、非常に優れた許可スタイルのレジストリを取得できるからです。それらはいわゆる DS-Off レジストリのように、ほぼ自然にここから出てくるものですよね。
a16z Noah：
最初のレベルのタイトル
オブジェクト指向および資産指向プログラミング
a16z Eddy Lazzarin：
したがって、私はことわざより少し先を行っているかもしれませんが、これらの機能は型システムから認識できるのでしょうか?プログラムの静的解析中に、これらの機能はプログラムのどの時点で表示されますか?機能が含まれるインスタンス化固有のコードを作成した場合、その機能を実行する前に、その機能に違反していることを早期に検出することはできますか?
a16z Noah：
はい、これらの機能は型システムに表示され、プログラムの静的解析フェーズ中に表示されます。機能を使用して特定のインスタンス化された型のコードを作成すると、仮想マシン上で実行しなくても、機能に違反しているかどうかを非常に早い段階で見つけることができます。
Sui CTO Sam Blackshear ：
質問に簡単に答えてから、背景情報をいくつか提供します。それらはコンパイラから認識され、型システムの一部です。これは私たちにとって非常に重要な活用ポイントです。ただし、Move モビリティ システムの構造と、それが監査のようなレベルの機能にどのように関与するかについて少し話したいと思います。それが気を散らすものでなければ。
Move には構造体型があり、他の言語の構造体と同様に、フィールド、プリミティブ型のフィールド、または他の構造体を持つことができます。さらに興味深いのは、おそらくさらに異なる点は、これらの構造には能力があるということです。 Rust に精通している場合、機能はトランザクションのマーキングに似ています。これらは、構造体に対して実行できる組み込み操作を宣言します。
同様に重要なことは、能力がなければそれらのことを行うことはできません。比較的単純な能力、つまりコピーする能力が非常に重要です。コンピューター内にトークン タイプまたは不均質トークンのようなものがある場合、それはほんの一部ですが、他の人がこれを自由にコピーできるようにしたくありません。
Move では、コピーできる構造体を宣言しない場合、「man copy」に相当するものを使用することはできません。
したがって、整数や文字列などにはコピーがあります。しかし、自分のタイプにコピーされる機能を持たせたくない場合は、コピーされる機能を与えないでください。さらに、破棄など、ドロップ機能と呼ばれる他の機能もあります。ここで線形タイプの興味深い機能が登場します。スコープ外に置いたり上書きしたりするなど、何かをドロップしたい場合は、それにドロップ機能を与えます。しかし、ドロップを与えない場合、それを取り除く唯一の方法は、そのタイプのモジュールが期待するポリシーを定義することです。
共通言語ランタイム (CLR) 具体的な例として、トークンの総供給量を維持したい場合は、トークンにドロップ機能を与えません。その場合、それが宣言されているモジュールで定義されている、総供給量を更新する burn 関数以外にそれを取り除く方法はありません。これらはすべて使えるトリックです。グローバル ストレージに保存できるかどうかなど、ストレージ関連の機能もいくつかありますが、この質問とはあまり関係がないため、詳細は説明しません。しかし、基本的に、機能は監査プログラムに組み込まれており、監査プログラムは型システムを理解し、型システムを使用して問題を解決する方法を知っています。そのようなものは 1 つだけであるという声明を書けば、監査人はこれを使用してこの特性を証明できます。したがって、機能と型システムの保証は密接に関連しています。
a16z Noah：
あなたがドロップについて話したとき、私は私の好きなものについて話したかったのです。ホットポテトモードとは何なのかについて少し話していただけますか?他にこのようなクールなものがあるとすれば、これは Move から出た私のお気に入りの奇妙なものの 1 つです。
Sui CTO Sam Blackshear ：
これは実に奇妙なことである。これは能力と非常に密接に関係しています。通常、プログラミング言語では、値がいつ破棄されるかをあまり制御できません。おそらく、値がいつ消えるかを示すデストラクターがあるかもしれません。ただし、デストラクターの保証が弱い場合や、「私の型は削除できない」などと単純に言えない場合もあります。これは奇妙な制限のように聞こえるかもしれませんが、特に動的ディスパッチがない場合、実際には非常に強力です。
まず注目のジャガイモの例から始めて、その後、フラッシュ ローンなどに掘り下げていきます。イーサリアムでフラッシュ ローンを行う場合、これは標準であり、オーバーライドできます。基本的に、フラッシュ ローン契約のようなコールバック関数を公開します。お金を渡すと、コールバック関数が返されます。その後、Move でお金を返します。やり方としては、誰かがフラッシュローン契約に行き、「おい、53ドルくれ、でも彼らはいわゆるホットポテトオブジェクトもくれる。
ホット ポテト オブジェクトは構造体であり、機能はありません。コピーされていないので、コピーすることはできません。グローバルストレージ機能がないため、契約書に記載するように隠しておくことはできません。ドロップ能力もないので落とすことはできません。したがって、それを取り除く唯一の方法は、フラッシュローン契約に戻すことです。フラッシュローン契約のコードを送り返し、返済を強制します。そうしないと、そのプログラムは実行時に失敗し、型チェックにも合格しません。これは、値の破壊を制御する興味深い機能であり、プログラマーは、これらのオブジェクトをいつ破壊できるかについて、いつでも任意の不変条件を課すことができます。これらは、API 呼び出しパターンが非常に特殊であることによく似ています。もう 1 つの非常に明白な例は、誰かにロック解除を呼び出した後にロックを呼び出すように強制したいが、その間に相手が望むことを何でもしたい場合、この方法でも行うことができます。
a16z Eddy Lazzarin：
最初に「ホット ポテト」パターンについて聞いたとき、私は「ミュート テキサス」のようなロックの興味深い使用方法について考えました。これは、人間工学的な目的のみで型システムを利用し、特定のオブジェクトの使用を強制するものです。この方法は、ほとんどビジネスロジックレベルの要件。これは非常に賢いと思いますし、非常に現代的だと感じます。これは、従来のプログラミング言語ではまだあまり一般的ではないプログラミング言語における人間工学の質の高い使用法ですが、スマート コントラクト環境では明らかに非常に有用です。ここでは、関係する可能性のある価値とセキュリティを考慮した、より論理的な要件です。
Sui CTO Sam Blackshear ：
具体的な例について話す前に、オブジェクト システムの概要を簡単に説明してもらえますか?オブジェクトとは何ですか? 誰が所有していますか?オブジェクトはどのように他のオブジェクトを所有し、モジュールはそれらのオブジェクトとどのように連携するのでしょうか?
a16z Noah：
はい、正確に。これは、Move 言語、特に Sui Move の方言に関するものです。この基礎は、私たちが使用していたオリジナルの Move ダイアレクトのグローバル ストレージ スキームとは異なるグローバル ストレージの構造です。オリジナルの Move グローバル ストレージ スキームは、イーサリアムで使用されている企業モデルと非常によく似ています。
Sui Move では、オブジェクト上に物事の中心点を置きたいと考えており、きめの細かいアクセスを可能な限り正確に表現できるようにすることが強く望まれています。これは、トランザクションをより効率的に処理したり、ウォレットユーザーにトランザクションの内容を通知したりするなど、このポッドキャストでは詳しく説明しませんが、多くのことを行うのに役立ちます。
したがって、Sui Move では、グローバル ストレージ構造はオブジェクト ID からオブジェクト ID へのマッピングになります。オブジェクトは、キーと呼ばれる機能を備えた単なる Move 構造体になります。これは、「ねえ、私はキーになれるよ。」というもので、グローバル オブジェクト プールに表示される可能性があります。次に、各オブジェクトにはグローバルに一意の ID が必要です。その後、オブジェクトを入力として直接受け取ることができるモジュールのエントリ ポイント関数を作成できます。トランザクションを作成している場合、この WeRunTime にはオブジェクト ID が含まれます。トランザクションを作成している場合、WeRunTime はこれらの ID を使用して ID をオブジェクトに解決し、それらを関数に挿入できます。
このオブジェクト指向および資産指向のプログラミング体験は素晴らしいものです。オリジナルの Move バージョンで行ったことよりもはるかに簡単です。親オブジェクトと子オブジェクト、およびオブジェクト階層についても言及しました。これは非常に便利ですが、それでも大規模なコレクションなどを表現できるようにする必要があります。
DNS のようなレジストリを構築していて、数百万のエントリが必要だとします。オブジェクトのサイズには制限があり、オブジェクトは数メガバイトまで可能ですが、それを超えることはできません。ただし、DNS のようなものがある場合は、任意に大きくする必要があります。これを表現する方法はオブジェクトの親子関係を使用することであり、基本的にオブジェクトを異種マップとして見る方法があります。その後、動的選択フィールドを使用してキーを追加できます。これはある意味 JavaScript に非常に似ています。このオブジェクトにはマップが含まれていると言え、このマップに何かを入れることができます。または、このオブジェクトを定義するときは 10 個のフィールドがあると言えますが、実際には後で新しいフィールドを追加したいので、契約をアップグレードする予定です。事後的に新しいフィールドを追加したい。
これを表現する方法は、これらの親オブジェクトと子オブジェクトの関係であり、各子オブジェクトはキー値に関連付けられます。キー値は、文字列や u 64 などの任意の Move 値、またはその他の任意の値にすることができます。
a16z Noah：
はい、親オブジェクトの概念に関連して、私にとって本当に「ひらめきの瞬間」になったと思うのは、実際に数か月前に時間を取って、Sui Move を詳しく調べ、オブジェクトを 1 つだけ持つプログラムを書くことから始めたときです。 Uniswap V2 スタイルのカードの組み合わせのほとんどを再実装します。私が行った小さなプロジェクトで、オブジェクトのオブジェクトを持つことがいかに貴重であるかを実感しました。このプロジェクトには、ロック、ゴールド、空のバリアの 3 つのオブジェクトしかありません。キーオブジェクトが所有するゴールドを作成することを想像できる非常に基本的なモジュールがあります。その場合、ゴールドを取り出す唯一の方法は、ロックとキーを取得し、明らかにロックを破壊してゴールドを渡し、その後キーを破壊する関数を用意することです。このアプローチは非常に興味深いもので、この方法でオブジェクト間の関係を記述し、非常にきめ細かい方法で権限を記述することができます。
Sui CTO Sam Blackshear ：
最初のレベルのタイトル
MoveとSolidityのセキュリティ比較
司会者ソナル・チョクシ：
ところで、Wired 誌に来る前にゼロックス パークで 6 日間過ごしましたが、そこでオブジェクト指向プログラミングの歴史について少し思い出しました。あなたが今言ったことは非常に興味深いものです。なぜなら、彼らは今日のオブジェクト指向フレームワークの多くの初期の前身である Smalltalk を発明したからです。とにかく、他に議論したいトピックはありますか?
a16z Noah：
一般的な質問なのですが、EVM の世界で発生するハッキングなどで、型システムのせいで Move を使用していれば最初は起こらないと思われるものはありますか。
Sui CTO Sam Blackshear ：
EVM の世界では、動的割り当てとリエントランシーについてはすでに述べましたが、Move は構造ごとにリエントランシーを排除し、リエントランシー関連の問題はすべて解消され、人々は良い仕事をしていると思います。さて、これで反応と閲覧が避けられると思います。
a16z Eddy Lazzarin：
しかし、なぜ Move によってこれらの問題が不可能になるのか説明できますか?
Sui CTO Sam Blackshear ：
再入場ですよね？どうしたの？いくつかのコードを記述して、特定の関数を呼び出します。問題は、最初から予期していなかった関数の実装を誰かが提供してしまうことです。これが機能するには、関数呼び出しが動的である必要があります。コードを呼び出す必要があります。コードは基本的に、呼び出し元 (おそらく攻撃者) によって提供される関数ポインターです。動的な関数呼び出しがなく、関数呼び出しのターゲットが常にわかっている場合は、他の呼び出しと同様、このようなことはまったく起こりません。コードが何をするのかはわからないかもしれませんが、それが何をするのかは知っています。は、テストでき、検証でき、すべてがそこにあります。したがって、基本的に、モジュールを予想とは異なる動作にするコードを他人が提供することは不可能です。これは単なる静的な関数呼び出しであるためです。とてもクール。
a16z Eddy Lazzarin：
したがって、これにより、Solidity 開発における永遠の問題であったリエントランシー攻撃が排除されます。
Sui CTO Sam Blackshear ：
はい、Move は基本的に、スマート コントラクト プログラミングにおける権限チェックの欠落の問題を解決すると思います。すべてのアカウントを明示的に渡す必要があるコードを作成するときに、これを行う権限があるかどうかを確認する必要がある場合があります。簡単なコードを書きましたが、送信者が誰かであるかどうか、またはその人がそれにアクセスできるかどうかを確認するのを忘れていました。このような問題はかなり頻繁に起こると思います。
したがって、Move では、オブジェクトの所有権情報は実際にはオブジェクトのメタデータに保存されます。これはプログラマが制御できるものではありません。
これらのオブジェクトを見ると、「私はこのアドレスによって所有されています」、「私はこの他のオブジェクトによって所有されています」、「私は共有オブジェクトです」、または「私は不変オブジェクトです」と言います。 」。ランタイムはこのSuiオブジェクトに渡されたコードを実行する前にチェックするため、プログラマは所有者をチェックすることを忘れることはできません。ランタイムは、「このやり取りを見て、彼らが使用したいすべてのオブジェクトを確認しました。彼らが実際にこれらのオブジェクトを所有しているか、またはそれらを中間的に所有するオブジェクトを持っているので、それらを使用する権限があるかどうかを確認しています。」
プログラマーに依頼する権限チェックの多くは最終的に We Run Time で行われ、これらのチェックを忘れることはできません。これは非常に重要だと思います。なぜなら、守るのが最も難しいのはプログラマが教えなかった仕様だからです。これらの規範は忘れられやすく、どの規範が重要であるかを常に誰かに理解してもらう必要があるため、静的分析やその他の方法を使用して把握するのは困難です。
司会者ソナル・チョクシ：
ところで、長期的または短期的な計画の観点から、このように人々がより協力したときに、企業規模で何が起こるかは非常に興味深いものになると思います。なぜなら、それは明らかに分散していて、A 社だけでなく、時には人々が協力するからです。しかし、今昔のやり方を考えると、同じような開発者がいて、ベストプラクティスがすべてあります。
IOS
Android