Move 言語におけるイノベーションとチャンス
まとめ
最初のレベルのタイトル
Solidity 言語と Rust 言語に続いて、崩壊したプロジェクト Libra から考案された新世代のプログラミング言語である Move が、パブリック チェーン プロジェクト Aptos と Sui のおかげで再び注目を集めています。ブロックチェーンの開発の歴史を通じて、新興のパブリック チェーンの各バッチの台頭は、開発パラダイムのある程度の変化を意味することがよくあります。 Moveの再登場は、新しい言語の物語がパブリックチェーン競争の新たな戦場になりつつあることを暗示しているようだ。
資産セキュリティをより良く実現するために、Move は言語設計、仮想マシン、および検証ツールに革新的な変更を加えました: Move はデジタル資産の新しいリソース タイプを定義し、リソースが満たすべき 2 つの基本属性 (希少性とアクセス権) を抽象化します。強力なデータ抽象化のモジュールシステムによりアカウントの権限管理を実現、RustのOwnershipシステムを継承することでアセットの所有権の移転を実現します。さらに、静的呼び出し、形式検証、バイトコード検証機能などのメカニズムの導入により、デジタル資産のセキュリティに対する複数の保証も共同で提供されます。
言語の受け入れの観点から見ると、Move は開発者にとって非常にフレンドリーです。その目的は、開発者のセキュリティのしきい値を下げることであり、これにより契約開発者はビジネス ロジックに集中でき、簡単に開始でき、開発者の移行にかかる全体的なコストは高くありません; エコロジー ご覧のとおり、Move の実際のアプリケーション シナリオはまだ初期段階にあり、アプリケーション エコロジーはまだ大規模に展開されていません。現在、Move が育成しているパブリック チェーン プロジェクトは、Aptos、Sui、国内の Starcoin のみです。将来的には、Move for Financeの特性やトラックの成熟度などの要因により、DEX、DeFi、ウォレットなどの金融インフラが最初に実装され、次にSocialfiやGamefiなどの金融関連アプリケーションが実装される予定です。
概要
最初のレベルのタイトル
最近、パブリック チェーン トラックは非常に活発です。Aptos とSui という 2 つの新しいパブリック チェーンが市場に反発し、5 億米ドル近くの資金を調達し、業界で広く注目を集めています。なぜ彼らがこれほど優れた能力を持っているかと言えば、創設チームのほとんどが消滅したステーブルコインプロジェクトLibra（後にDiemに改名）の深い背景を持っているという事実を除けば、彼らがDiemから中核的な遺産を受け継いでいる可能性が高いです。 . ——言語を動かす。
過去数年間、ブロックチェーン分野における新しいパブリックチェーンの波には、ある程度の開発パラダイムシフトが含まれていました。現在、Move が率いる Diem パブリック チェーンは、新しいプログラミング言語の物語がパブリック チェーン競争の戦場の 1 つになっていることを示唆しているようです。
最初のレベルのタイトル
1. Moveが生まれた理由
世界には非常に多くの言語があるのに、なぜLibraはMoveを「圧倒的に」デザインしているのでしょうか？私たちは、リブラのビジョンが世界通貨の金融インフラとなり、何十億もの人々に力を与えることであることを知っています。したがって、Move は資産セキュリティを設計目標の最上位に置く必要があります。しかし、過去のプログラミング言語はこの要件を十分に満たしていませんでした。
SlowMist Hacked の不完全な統計によると、2021 年だけでも、ブロックチェーン エコシステム内で公表されているセキュリティ インシデントが 200 件以上発生し、損失額は 98 億米ドルを超えると予想されています。その中で、セキュリティ問題の大部分は、エコロジカルな DApp または DeFi プロトコルに現れています。
典型的な契約セキュリティ攻撃には、フラッシュ ローン、リエントリー攻撃、二重支払い攻撃、数値オーバーフロー、トランザクション リプレイ、トランザクション レシートなどが含まれます。これらはいずれも、Solidity に代表される旧世代のプログラミング言語が、言語機能、コントラクト操作、仮想マシン設計の点で多かれ少なかれセキュリティ リスクを抱えていることを反映しています。
そこで、Libra は古いスマート コントラクト プログラミング言語を断固として放棄し、より安全な Move 言語を開発しました｡この記事では、Move のさまざまなセキュリティ機能についても主に説明します。
2. Move は資産のセキュリティをどのように確保するのか
資産セキュリティにおける Move のパフォーマンスは、以前のプログラミング言語よりも優れています。これは主に、前任者が受け継いだ革新的な改善が加えられたためです。これらの改善は主に、言語設計、仮想マシン、オフチェーン検証ツールの 3 つの側面に反映されています。
副題
2.1 言語設計: デジタルファイナンスのために生まれた
Moveは徐々に「デジタル」属性を弱め、「アセット」属性を強調している。なぜそんなことを言うのですか？まず、チューリングの完全なスマート コントラクト言語が過去にどのようにデジタル資産を定義したかを見てみましょう。
イーサリアムがアカウント モデルを使用していることはわかっていますが、それ自体が巨大なトランザクション ステート マシンであり、すべてのトランザクションはイーサリアムの世界の状態を変更し、トランザクションはブロックにパッケージ化されています。したがって、イーサリアムは、トランザクションがブロックにパッケージ化されて形成される台帳チェーンであると見なすこともできますが、他方では、ブロックの生成によって、ある世界状態から別の世界状態への連続的な遷移とみなすこともできます。ステートマシン。
さらに、各アカウントの情報の総和がその時々の世界の状態を構成します。同時に、アカウントごとに、アドレスからアカウントのステータスへのマッピングが行われます。この表現はもっと抽象的かもしれませんが、私たちはこのような一般的な方法で理解することができます。財布を開くと、それぞれの銀行カードが銀行口座に対応します。キャッシュカードのカード番号は口座の住所に相当し、カード番号に含まれる資金残高、消費明細、資産管理商品の保有状況などはすべて口座のステータスとなります。したがって、各カードは特定の時点の状態に対応します。すべての銀行カードのコレクションは、世界の資金状況に対応します。銀行カードを取引や消費に使用すると、銀行カードのステータスが変化し、世界における資金のステータスも変化します。
このマッピング関係は主に、イーサリアム アカウントのキー フィールドの残高に反映されます。直感的には、これは典型的な KV キーと値のペア ((アドレス => uint256) 公開残高のマッピング) であり、値はアカウントの何らかのトークン残高に反映されます。したがって、Solidityではトークンは整数値変数(uint)で表現され、異なるアカウント間のトークンの移動処理はデジタル的な加減算で行われます。
以下は、Solidity を使用して実装された ERC20 転送ロジックです。「送信元ユーザー」 (つまり、送信者はトークンの値を「宛先ユーザー」 (受信者) に転送します。主なプロセスは次のとおりです。
i. 送信者アドレス (from) から初期残高をマッピングし、oldFromVal 変数に割り当てます。
ii. oldFromVal が value より大きいこと、つまり送信者に十分な残高があることを要求します。
iii. 受信者のアドレス (to) から初期残高をマッピングし、oldToVal 変数に割り当てます。
iv. oldToVal + 値を newToVal に割り当てます。
v. oldFromVal — 値を newFromVal に割り当てます。
vi. newFromVal を送信者アドレス (from) の新しい残高に設定します。
vii. newToVal を受信者の (to) 新しい残高として設定します。
一般的な例で単純化すると、アリスは 10 元をボブに送金し、スマート コントラクトを呼び出してアリスのアカウント アドレスから 10 を減算し、ボブのアドレスに 10 を加算します。残高を変更するプロセス全体は、一元的な財務シナリオにおける一般的な控除ロジックです。
ただし、オンチェーンの世界は異なります。たとえば、ボブの残高は 10 増加したが、アリスの残高は変わらないという状況は発生しますか?答えは「はい」です。オンチェーンの動作のほとんどはスマート コントラクトに依存しており、スマート コントラクトは事前に設定されたルールに従って自動的に実行されることがわかっています。上の例に戻ると、送信元アドレスと送信先アドレスが同じ場合、つまり自分自身にトークンを送信する場合です。コードの実行順序によれば、最初に送金者のアドレスから送金金額が減算されますが、その後newToValの値がnewFromValの値で上書きされ、口座残高が増加している効果がありますが、減額はされません。が作られました。これにより、トークンの無制限の発行に抜け穴が生じました。
この例から、ユーザー間のトランザクション プロセスは契約コードのロジックに依存して実装され、最終的にアドレスの下にある対応する番号の更新に反映されることがわかります。その信頼性は契約の開発者に依存しており、何らかの人的エラーが発生しないことを保証することは困難です。結局のところ、Solidity はブロックチェーン スマート コントラクト用の言語であり、資産指向の言語ではありません。 Solidity におけるデジタルアセットは、型の定義がなく単純に足し算や引き算が可能な数値であり、数値の表現力だけでは不十分であり、アセットの差別化が必要となります。
a) ファーストクラスのリソース — — デジタル資産を実現する
上記の問題を解決するために、Move はデジタル資産用の新しいデータ型である First-class Resource を具体的に定義します。直訳すると、リソースは第一級市民です。第一級市民の意味は分かりやすい、つまりプログラミング言語は第一級市民をプログラム対象とするべきであり、リソースについては要するに数に限りがあるリソースのことであるそして価値を生み出すことができます。 Move はこの考えに従い、プログラミング時にリソースが従うべき 2 つの制約、つまり希少性とアクセス権を抽象化します。
●希少性
希少性は、物理世界の金の延べ棒などの貴重な物理的資産の重要な特性です。この金の延べ棒は、途中で何度循環しても、1 から 2 に変化することはなく、突然消滅することもありません。デジタル資産には、本質的に物理的な希少性はありません。したがって、Move は、デジタル資産の計算ルールがプログラムによってこの希少性を強制する必要があると考えています。システム内の資産の供給は制限されるべきであり、資産はどこからともなく消えてはならず、既存の資産のコピーは禁止され、新しい資産の作成は特権的な操作であるべきであると規定されています。ここで言うプログラミング手法とは、Move で定義された文法構造の Abability を指します。これには、Move がさまざまな変数の抽象化する 4 つの属性が含まれており、コピー (コピー)、インデックス付け (キー)、破棄 (ドロップ)、および保存 (ストア) できます。開発者は、これらのフィールドを組み合わせて使用して、変数に異なるアビリティを与えることができます。変数が Resource タイプとして宣言されると、使用できるのは Key 属性と Store 属性のみとなり、Copy および Drop に追加することはできないことに注意してください。このようにして、Move はプログラミング構文構造からのリソース タイプの不足を保証します。
● アクセス権
資産所有者は、何らかのアクセス制御ポリシーを通じて資産を保護できる必要があります。イーサリアムは主に公開鍵署名メカニズムに依存していることがわかっており、Move はこれに基づいた新しいモジュール システムを提供します。 Module については後ほど詳しく説明しますので、ここでは省略します。
一般に、Move は Resource を使用して最下位層から資産の概念をカプセル化し、デジタル資産を真のコントラクト変数にし、保存して割り当てるだけでなく、関数/プロシージャのパラメーターや戻り値としても使用できます。上記は、Move がリソース変数に対して作成した必須ルールを反映しています。これにより、アセットがどこからともなく消えたり、任意にコピーされたりすることがなくなり、前述の無限コピーや追加発行の抜け穴などのセキュリティ リスクが十分に回避されます。
b) モジュール — — 権限制御と構成可能性を実装します。
Module はモジュールであり、Rust の Mod や Solitidy の Contract に似ており、内部で Resource、Struct、Function を含む一連のデータ型と関数を宣言できます。Struct と Resource の両方は新しいデータ構造型を定義するために使用されます。違いは、Resource をコピーしたり破棄したりできないことです。Function 関数に関しては、他のほとんどの言語と同様で、モジュールで宣言された型の作成、破棄、更新に使用できます。全体として、モジュールには次の特徴があります。
●強力なデータ抽象化
Module が強力なデータ抽象化である理由は、データ型が宣言された Module の内部では透明で外部では不透明であることが規定されており、各 Resource オブジェクトが特定の Module にカプセル化されており、これはすべての Control によって決定され、モジュールのアカウントが更新されるためです。所有者を管理し、詳細なポリシーに従って資産を作成、変更、破棄するための外部機能を提供します。前述したように、この機能は Move のアクセス制御にもよく使用されます。モジュールの外部はモジュールをバイパスして内部リソースを直接操作することはできず、提供された関数を通じていくつかの制限付きでリソースを使用する必要があります。コードに反映されているように、外部開発者はモジュール内のパブリック型の関数のみを呼び出すことができ、モジュール内の定義に従って動作するため、誤った呼び出しによって引き起こされる潜在的な安全上の問題が回避されます。
●柔軟性と無国籍性
このモジュールは、設計時にコントラクト間で相互に組み合わせたり、リソースを使用したりするために、外部から提供されたモジュールのパブリック インターフェイスを保持しています。機能的には、Solidity で使用されているインターフェイス標準と大きな違いはありません。違いは、Move 言語のモジュールであることです。はい、状態はグローバル ストレージに保持されます。具体的には、Solidity での ERC-20 コントラクトのトークン実装は台帳に似ており、台帳の状態変更を通じて各ユーザーとコントラクトとのやり取りの完全なデータが記録され、Move はモジュールを使用して資産をカプセル化して保存します。アカウント 住所の下には、ラベルが付いた内蔵型金庫のようなものがあります。
c) 所有権システム - 資産所有権の実現
この概念は Rust から継承されており、所有権を次のように定義します。
1. 各値には、owner と呼ばれる対応する変数があります。
2. 値には常に 1 人の所有者しかいません。
3. 所有者が範囲外になると、値は破棄されます。
簡単に言えば、値には一意の所有者のみが存在し、所有者は関数になることができます。新しい関数に値を渡すと、その関数が新しい所有者になります。関数に値を渡すことは、変数に値を割り当てることと意味的に似ています。
したがって、Resourceのリソース属性を振り返ると、ユーザー間のリソーストランザクションは依然としてアセットの価値に応じて加減され、インデックス付けされますが、Solidityのコードロジックを強制的に使用して1つの残高を減らすのとは異なります。アドレスを指定して、別のアドレスの残高を増やします。これらの方法には本質的な違いがあります。リソースの転送プロセスは、レンガを移動し、あるアカウントから別のアカウントにリソースを移動することに似ており、転送中に損失や重複が発生することはありません。資産の安全性がより確実に保証されます。
一般に、Move は線形タイプの概念を通じてデータの所有権を明確にし、リソースの希少性、保護、およびアクセス制御を強調し、モジュール システムを使用して各リソースのライフ サイクル、ストレージ、およびアクセス モードを定義します。これらの機能を組み合わせることで、デジタル資産が何もないところから作成され暗黙的に破棄されることがなくなり、二重支出や無制限の発行などのセキュリティ上の問題の発生が軽減されます。
副題
2.2 仮想マシン: ランタイム バイトコード ベリファイア — — 実行中に脆弱性を探します
Move の言語設計機能は上で紹介されており、開発者はこれらの機能を使用して、特定のニーズに合わせたスマート コントラクトを作成できます。ただし、Move と Solidity はどちらも高水準プログラミング言語であり、コンピューターはこれらのソース コードを直接読み取って実行することができないため、特定のコントラクトを実装するには専用の実行プログラムに依存する必要があります。
現在、仮想マシンはスマート コントラクトの主流の実装の 1 つであり、Move も例外ではありません。最下層まで完全に透過的な実行環境をプログラムに提供でき、その目的は、プログラム開発者が異なるサーバーごとに互換性を持たせるために異なるバージョンのプログラムを作成できるようにするのではなく、「一度書けばどこでも実行できる」という機能を実現することです。この設計の理由は、スマート コントラクトは、合意に達するためにビザンチンのフォールト トレランスを必要とする分散システム環境で実行されるためであり、すべてのノードはスマート コントラクトで規定されたルールに従って同じ計算結果を生成する必要があり、そうでない場合はコントラクトの結果が生成されません。コンセンサス; 一方で、仮想マシンはブロックチェーンノード自体の実行環境の差異をシールドし、すべてのノードで一貫して実行できるため、スマートコントラクトの確実性を実現します。
Move 仮想マシンは、典型的なスタックベースのバイトコード インタープリタです。入力はバイトコードに現在のワールド状態を加えたもので、出力はワールド状態への変更です。システム全体を実行および処理するための独立した命令セットがあります。状態が変化すると、ユーザーは Move が提供するバイトコード比較テーブルでコマンドの対応する意味を見つけることができます。
●ワークフロー
Move 仮想マシンの具体的なワークフローは次のとおりです: まず、ソース コードがコンパイラを通じて低レベルのバイトコード バイトコードに変換され、仮想マシンに渡されます。バイトコードを受信した後、仮想マシンはまず検証のためにバイトコード ベリファイアを呼び出します。検証者は、Move ソース コード内のさまざまなタイプのエラーをチェックアウトできます。最後に、仮想マシン インタプリタがスクリプトを解釈して順番に実行し、各データまたはバイトコードを左から右にたどります。ランタイムはスタック実行に基づいています データが見つかるとスタックにプッシュされます バイトコードが見つかったら対応するデータのデータがポップアップされます バイトコードは計算に使用されます 計算後、計算結果終了するまでスタックに戻されます。
このプロセスでソース コードをチェックするときに発生する可能性のある型エラーには、主に次のようなものがあります。
i. スタックの範囲外チェック。オペランド スタックにアクセスする各関数のスコープとスタックの高さが正当であるかどうかを確認してください。ここでのスタックとは、バイトコード ベリファイアによって作成された各バイトコードの命令ブロック (基本ブロック) です。
ii. タイプと種類のチェック。導出スタック内の変数の特定の型が正しいかどうかを確認します。たとえば、スタック クラスは Resource 型変数に CopyLoc バイトコードを使用できませんが、これは資産不足の直接の現れでもあります。
iii. 引用チェック。未解決の参照を防ぐために、各参照は割り当てられた記憶場所を指す必要があります。
EVM は、スマート コントラクト用のチェーン ノードによって作成された分離された決定可能なサンドボックス環境であり、複数のコントラクト プログラムが同じプロセス内の異なる仮想マシン サンドボックスで実行されます。これは、イーサリアム コントラクト間の呼び出しは、同じプロセス内の異なるスマート コントラクト仮想マシン間の呼び出しであり、セキュリティはスマート コントラクト仮想マシン間の分離に依存することを意味します。
Move 仮想マシンは並列実行をサポートしています。コントラクト間の呼び出しはサンドボックスに集中的に配置され、このアーキテクチャの下では、コントラクトの状態のセキュリティは主に、分離のために仮想マシンに依存するのではなく、プログラミング言語の内部セキュリティによって分離されます。
副題
2.3 オフチェーンツール: 正式な検証 — 実行前に脆弱性を検出
理想的には、Move はバイトコード検証を実行することでコントラクト ランタイムのセキュリティ ホールを見つけることができます。ただし、この種のオンチェーン検証の計算コストは非常に高く、この種の計算は多くのネットワーク リソースを消費することが多く、チェーン上の TPS に影響を与えます。したがって、Move が採用したいと考えている戦略は、主要なセキュリティ属性の軽量のオンチェーン検証のみを実行し、他のセキュリティ問題についてはオフチェーンの静的検証ツールに依存することです。この戦略に基づいて、Move は人的エラーを防止し、コードのセキュリティを向上させるための独自の Move Prover 形式検証ツールを開発しました。
いわゆる形式的検証は、特定の形式的な仕様または属性に従ってプログラムの信頼性を検証することです。これらの仕様は通常、数学的モデルを確立することによって確立されます。展開前にバグは存在しませんでした。従来の手動監査コード セキュリティと比較して、形式的検証は、手動手段では考えられる入力を網羅的に列挙できないという欠点を解決できます。
● 静的呼び出し
Move Prover は静的検証ツールであることに言及する価値があります。これは、Move が機構設計から動的呼び出しをまったくサポートしていないためです。動的呼び出しとは、プログラムが別のプログラムを呼び出す場合、呼び出しのターゲットを実行時に決定する必要があることを意味し、この種のコントラクト呼び出しは動的と呼ばれます。メカニズムの観点から見ると、これはサーバーのリモート呼び出しに似ています。ただし、動的呼び出しをループ内で呼び出すと、同時実行の問題が発生する可能性があります。たとえば、コントラクト A はコントラクト B を呼び出し、コントラクト B はコントラクト A を呼び出します。コントラクト A の前回の実行が完了せずに次の実行が実行されると、後続の実行で以前の中間状態を読み取ることができなくなり、最終的には次のような状態になります。セキュリティの脆弱性。有名な DAO 事故は、コントラクトダイナミックコールの問題によって引き起こされました。したがって、Move 設計では、各関数呼び出しは静的であり、開発者はプログラムを実行する前に、どの関数が特定の順序で呼び出されるかを知ることができます。この種の静的型システムは、正式な検証による推論により適しており、コンパイル段階の前に問題を明らかにして、実行時のバグの可能性を減らし、セキュリティ チェックのプレッシャーをうまく分散します。
最初のレベルのタイトル
3. まとめと展望
Bitcoin Script から Ethereum Solidity への移行がコントラクト表現機能の変更である場合、Solidity から Move への移行はコントラクト セキュリティ機能の進化です。したがって、ムーブには市場の期待も高まっています。
言語メカニズムの観点から見ると、Move による資産セキュリティの探求は非常に興味深いものです。言語設計、仮想マシン、検証ツールの 3 つのレベルで革新的な変更を加えました。これらの設計は有機的な全体です: 資産指向のプログラミング設計により、Move 言語は分散型金融アプリケーションの展開に自然に適応します。ロジック、アクセス制御、静的呼び出し、正式な検証も、デジタル資産のセキュリティに対する複数の保証を提供します。
新しいパブリックチェーンの今回の物語の最大の焦点は間違いなくMoveであり、この株主スタイルを利用して市場に大きな変化をもたらすことができるかどうか、私たちは皆それを楽しみにしています。
参考文献
2. https://move-book.com/cn/index.html
3. https://move-dao.github.io/move-book-zh/modules-and-scripts.html
4. https://jolestar.com/why-move-1/
5.https://mirror.xyz/0xbuidlerdao.eth/MePeSGYe63OX8xXb8IwIrXzGk_S606NG7SR879XMXRE
6. https://mp.weixin.qq.com/s/bSS9GAcVp6tuWjedpTysQw
7. https://starcoin.org/zh/developers/others/starcoin_ecology/
8. https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/design/virtual_machine/evm.html
9. https://doc.rust-lang.org/book/
10. https://solidity-cn.readthedocs.io/zh/develop/
最初のレベルのタイトル
公式ウェブサイト：
お問い合わせ：
相談用メールアドレス：research@huobi.com
公式ウェブサイト：https://research.huobi.com/
Twitter： Huobi_Research
https://twitter.com/Huobi_Research
Medium： Huobi Research
https://medium.com/huobi-research
Telegram： Huobi Research
https://t.me/HuobiResearchOfficial
免責事項
1. Huobiブロックチェーン研究所は、本レポートに関与するプロジェクトやその他の第三者とは、レポートの客観性、独立性、公平性に影響を与える可能性のあるいかなる関係も有しません。
2. このレポートで引用されている資料とデータはすべて準拠したルートからのものであり、資料とデータの出所は Huobi Blockchain Research Institute によって信頼できると考えられており、その信頼性、正確性、完全性について必要な検証が行われていますが、Huobi Blockchain当研究所は、その真正性、正確性、完全性についていかなる保証もいたしません。
3. レポートの内容は参考のみを目的としており、レポート内の結論や意見は、関連するデジタル資産に関する投資アドバイスを構成するものではありません。 Huobiブロックチェーン研究所は、法令に明示的に定められている場合を除き、本レポートの内容の利用により生じたいかなる損失についても責任を負いません。読者は、このレポートのみに基づいて投資決定を行ってはならず、また、このレポートに基づいて独立した判断を下す能力を失ってはなりません。
4. 本レポートに含まれる情報、意見、推測は、本レポート作成日時点における研究者の判断を反映したものであり、将来、業界の変化やデータ情報の更新に基づいて、意見や判断が更新される可能性があります。 。
3. レポートの内容は参考のみを目的としており、レポート内の結論や意見は、関連するデジタル資産に関する投資アドバイスを構成するものではありません。 Huobiブロックチェーン研究所は、法令に明示的に定められている場合を除き、本レポートの内容の利用により生じたいかなる損失についても責任を負いません。読者は、このレポートのみに基づいて投資決定を行ってはならず、また、このレポートに基づいて独立した判断を下す能力を失ってはなりません。
IOS
Android