RDX Works のヘッド プロトコル アーキテクトである Josh Primero による意見です。  Babylon ネットワーク上で Radix Engine V2 を起動した後、私は DeFi シーンに浮上している VM の新しい波を詳しく調べました。これらの中で最も魅力的なものの 1 つは、Diem のオリジナル MoveVM を改良した、Sui の MoveVM です。 私は、Sui のアーキテクチャが Radix といくつかの重要な技術哲学を共有しているため、しばらくの間興奮していました。 移動セマンティクスを使用してアセット指向プログラミングを可能にします。 状態の依存関係の知識を活用して、部分的な順序付けを通じてコンセンサスをスケールします (当時の流行である、スケーラビリティを過度に抽象化して上位層に移動するのではなく) 技術的に言えば、ロジックの実行に必要な最小限の状態依存関係を静的にキャプチャする言語とコンパイルされたバイト コードをどのように活用しているかが非常に素晴らしいと思いました。 これにより、実行が迅速になるだけでなく、トランザクションの状態依存関係と状態書き込みが適切に制限されるため、セキュリティ上の利点も得られます。 ただし、この達成には代償も伴います。 DeFiプログラマーは、EVMのよく知られた問題を繰り返すなど、より困難で、時には直感的ではないモデルを管理する必要があります。 では、Sui の VM で私が発見した 4 つの欠陥について、これらの問題を見てみましょう。  1.汎用的すぎるオブジェクトプリミティブ Sui の MoveVM (または一般的に MoveVM) の最大の革新は、バイトコード層での移動/借用セマンティクスの使用です。これは、低レベルのマシンがオブジェクトの所有権と移動を理解できることを意味します。かなりクールです！ したがって、Sui の VM 内のすべてのオブジェクトは 、所有、移動、共有できる関連ロジックを備えた型付きの値。  NFTのように動作します 残念なことに、このモデルではオブジェクトがより多くの一般的なことを実行できるため、DeFi プログラマーは複雑なオブジェクトのライフタイム ステート マシンを定義して管理するという負担を負っています。  具体的には、Sui では、新しい構造を定義するときに、プログラマは 4 つの能力 (「コピー」、「ドロップ」、「キー」、「ストア」) の組み合わせを指定する必要があり、それぞれが異なる方法でステート マシンに影響を与えます。さらに、プログラマは、インスタンス化時にオブジェクトを共有するか、転送するか、値として返すか、凍結するかを管理する必要があります。 これらの設定が間違っていると、微妙なバグが発生し、資金の損失につながる可能性があります。 たとえば、次のコードでは、Sui の 簡単なフラッシュローンを実装します。問題？誤って受信にドロップ機能を追加してしまいました。  ホットポテトパターン この小さな間違いにより、借り手は自分で領収書を落として返済せずにローンを持ち逃げする可能性があります。 (FlashLoan と Receipt の関係には別のバグがあります。見つけられるかどうかを確認してください。) したがって、一連の機能を備えた単一のオブジェクト抽象化を中心に VM を編成することは概念的にはエレガントでシンプルですが、プログラマの観点から見ると、低レベルの状態が非常に多く存在するため、それぞれの影響を理解するのは困難です。管理。 これは、古い言語のメモリ管理の問題と、ガベージ コレクション VM が大きな成功を収めた理由とそれほど似ています。アプリケーション プログラマは、いつメモリを解放してもよいかといった低レベルの状態の管理には関心がありません。彼らはオブジェクトとそれらのオブジェクト間の関係に関心を持っています。 同様に、DeFi プログラマーは基本的に資産と、これらの資産の移動と所有権に関するロジックに関心を持っています。資産自体には固有のロジックはなく、これらの資産を管理するロジックを「移動」したり「所有」したりする必要はありません。  Sui の MoveVM は、これら 2 つのまったく異なるものを 1 つの汎用オブジェクト抽象化として統合しており、これにより、難しい DeFi プログラミングのメンタル モデルが作成されます。  2. 動的ディスパッチなし MoveVM の特徴的な機能は、静的ディスパッチの使用です。これは、関数呼び出しと実行時の実行の間に間接層が存在しないことを意味します。関数呼び出しとその基礎となるロジックは、新しいパッケージの公開時に静的にリンクされます。これにより、VM は高速で予測可能になりますが、柔軟性が低下し、プログラミング環境が使いにくくなります。 動的ディスパッチの欠如による 3 つの影響を見てみましょう。  2a) 関数合成なし VM はコードの公開時に呼び出される正確な関数を認識している必要があるため、異なる関数を一緒に構成することは不可能です。通常のプログラミングでは非常に一般的なパターンです (OO 言語のインターフェイスや Rust のトレイトなど)。 単純な流動性プールのインセンティブを見てみましょう。 Rust であなたの貢献に 10% を追加するインセンティブを書くとしたら、次のようになります。  このようにして、私の LiquidityEnhancer は、Pool トレイトを実装する任意のプールで動作します (はい、Rust の細かい指摘をする人のために、このトレイトも静的にリンクされています。これは関数合成の一例にすぎません)。  「contribute」はすでに定義されている関数でなければならないため、これはSuiでは不可能です。代わりに、正確なプール実装にリンクする新しいパッケージを、新しいプール実装に対して公開する必要があります。  2b) 動的コールバックや関数ポインタは使用しない 関連して、汎用インターフェイスを介して任意のロジックを実行できることは、特に DeFi 設定において非常に便利な構造です。 将来の呼び出し元に何らかの任意のロジック (たとえば、支払い遅延の使用など) を呼び出すようにインセンティブを与える、インセンティブ付きの将来のエグゼキューターを想像してください。 Rust では、これは次のようになります。  ただし、Sui では動的ディスパッチがないため、これは不可能です。代わりに、そのような機能を使用するメソッドごとに、新しい IncentivizedFutureExecution パッケージを発行する必要があります。  2c) 厄介なアップグレード可能性 スイがサポートしてるのは 。残念ながら、静的なディスパッチ不変条件のため、パッケージのアップグレードの管理は予想よりも難しく、安全性が低くなります。 パッケージのアップグレードとバージョン管理 まず、シームレスで透過的なコード更新は不可能です。別のパッケージを呼び出すパッケージがあり、そのパッケージに必要なバグ修正アップデートがある場合、修正が必要な場合は自分で新しいパッケージを公開する必要があります。  パッケージの依存関係がますます増加すると、よく使用されるパッケージの単純なバグ修正であっても、パッケージのアップグレードが爆発的に増加する可能性があります。  第 2 に、このコードにバグや悪意のあるコードがある可能性がある場合でも、すべての古いコードは常に存在します (それに依存する他のコードがそれを呼び出すことができる必要があるため、これは必要です)。これに対抗するために、オブジェクトの状態で適切なバージョン管理スキーマを維持するという負担がアプリケーション層に課されます。  3. 厄介なメールボックスのパターン スイが最近リリースしたのは、 これは、他のオブジェクトに知られずにオブジェクトを別のオブジェクトに送信する方法として最もよく説明できます (以前は、これはアドレスでのみ可能でした)。そのオブジェクトにアクセスできるようにするには、この転送を認識した別のトランザクションを実行する必要があります。  オブジェクトへの転送パターン このような構成は、受信オブジェクトの状態への依存関係を削除するのに役立ちます。これは、UTXO モデルの別のアドレスに UTXO を送信することと似ています (受信部分も、UTXO 監視スクリプトを使用して所有権を証明することと似ています)。その後、Sui のコンセンサスは、この競合の欠如を利用して、そのようなトランザクションをより適切に並列化することができます。 ただし、このようなパフォーマンスの向上には、セキュリティのトレードオフがないわけではありません。受信オブジェクトに関する情報 (オブジェクトが存在するかどうかを含む) なしでオブジェクトが受信される可能性があるという事実により、送信されたオブジェクトへのアクセスが永久に失われる可能性が生じます。 これは、受信オブジェクトが送信されるオブジェクトをサポートしていない場合に可能です。このような欠陥は、ERC-20 トークンをサポートしていないスマート コントラクトに誤って ERC-20 トークンを送信することに似ています (資金損失の 一般的な原因)。 非常に さらに、親子関係には 2 つのタイプがあり、1 つは親が子のことを知っている関係、もう 1 つは子が親のことを知っている関係であるため、従来のプログラミングで一般的であるよりも複雑なモデルになります。  この厄介な構造でプログラミングを行わずにパフォーマンスの利点を維持するアプローチはあるでしょうか?あると思います。他の CRDT アプローチとともに不変ポインターを使用する必要がありますが、それについては今後の記事で説明します。  4. 厄介な共有状態プログラミング Sui の VM は、非競合状態でプログラムおよび実行できるように最適化されています。このため、実際に共有状態を処理する必要がある場合、プログラミングの仕組みがかなり厄介になってしまいます。これらのいくつかを見てみましょう。  4a) 保存された参照がない Sui の VM には保存された参照の概念がありません。存在する場合、関数の状態依存関係を静的に分析する機能が失われ、したがって並列化する機能が失われます。この結果、保存された参照を管理する負担がプログラマ/ユーザーに課されることになります。 たとえば、関数の 1 つで特定の Oracle からの価格を必要とするオブジェクトがあるとします。 Rust では、これは次のようになります。   Sui では参照を保存できないため、MyDefi と Oracle の間のこの関係をより機能的な方法で記述する必要があります。  ちょっと待って！任意のオラクルを渡すことができるようになりました。正しいオラクルが使用されていることを確認するには、 使用する必要があります:    ID ポインター パターン このパターンは、通常の参照と比較すると脆弱であるため、正しいリレーションを実装するには注意が必要です。オブジェクト間の関係グラフが成長し、より複雑になるにつれて、このプログラミングの負担がうまく拡張されることを想像するのは困難です (たとえば、Oracle の get_price 呼び出しにも独自の依存関係がある場合はどうなるでしょうか)。 さらに、トランザクション コードであれパッケージ コードであれ、呼び出し元には常に正しい参照を渡すという負担がかかります。この参照が変更される可能性がある場合、参照が最新の状態に更新されていることを確認するために、呼び出し元にさらに別の負担がかかります。  4b) 関連インスタンスの非動的タイプの安全性 従来のプログラミングとは異なり、DeFi プログラミングでは、インスタンスが別のインスタンスと同じ「インスタンス グループ」の一部であるかどうかを型チェックできることは非常に便利です。 たとえば、2 つのコインの結合が同じコイン識別子であることを確認すると便利です。  これを従来のジェネリック セマンティクスで実装する場合の問題は、ジェネリックが「関連するインスタンスのグループ」ではなく型を表すために使用されることです。 かなり賢い方法で、Sui はこの問題を回避することができました。 。このシステムでサポートされているパターンでは、関連するインスタンスの新しいグループが必要な場合は、このグループの識別子を表す特別な新しいタイプを作成する、と基本的に言われています。 ワンタイム証人パターン この大きな利点は、言語層をまったく変更する必要がなく、よく知られた汎用セマンティクスを使用するだけでこの種の安全性を実現できることです。 最大の欠点は、関連するものの新しいグループが作成されるたびに、新しいタイプ (つまり、新しいパッケージ) をデプロイする必要があることです。たとえば、新しいパッケージをデプロイせずに新しい Coin<T> を動的に作成することはできません。 結論 Sui の MoveVM は、システム エンジニアの基準に基づいて構築されています。つまり、概念的に単純な低レベルのプリミティブに基づいた、静的に適用される VM です。 残念ながら、シンプルとは簡単という意味ではなく、通常の共有オブジェクト パターンを避けることにこだわるため、アプリケーション層は非常に複雑で、プログラミングが直感的ではありません。  DeFiは乱雑な共有オブジェクトの世界です。誰でもアクセスできる大きな流動性を備えたプール、誰でも貸し借りできる融資プロトコル、誰でも呼び出せるオラクル、そして同時に起こるこれらすべてのオブジェクトの構成と相互作用です。 このようなエコシステムを並列化することは DLT の聖杯であり、Sui の試みは、煩雑さをアプリケーション層に押し付けすぎることを除けばうまくいきました。 確かに、一部の問題はより優れたツールと言語サポートで解決できる可能性がありますが (  )、大きな VM 変更なしでは修復できないものもあります (  )。 1 汎用すぎるオブジェクト プリミティブ、4 ぎこちない共有ステート プログラミング 2 動的ディスパッチがない、3 ぎこちない)メールボックスパターン

Buy XRD with card or bank transfer via Switchere.

このオーディオは、ストーリーの元の言語で制作されています。

Sui の MoveVM: 包括的なレビュー

About Author

コメント

ラベル

この記事は

Related Stories

ワークフローを10倍に向上させる方法: 必須アプリ17選

暗号通貨の成長: 効果的なユーザーペルソナの作成

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

ワークフローを10倍に向上させる方法: 必須アプリ17選

暗号通貨の成長: 効果的なユーザーペルソナの作成

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps