412 測定値

Radix Engine: 「殿堂入り」のより良いモデル

に Radix Publishing10m2024/04/10

長すぎる; 読むには

より高速で、より安全で、より使いやすい DeFi プラットフォームの需要が高まるにつれて、崇拝も増えるでしょう。Radix Engine はこれを念頭に置いて設計されました。

featured image - Radix Engine: 「殿堂入り」のより良いモデル

私の前の記事では、Radix Engine が Sui の MoveVM の欠陥のいくつかをどのように回避したかについて説明しました。要約すると、次のようになります。

Sui の MoveVM は低レベルで汎用的すぎるため、扱いにくい DeFi プログラミング環境になります。
Radix Engine は高レベルで資産 + ビジネスロジック指向であり、開発者は低レベルの詳細ではなく DeFi ロジックに集中できます。

SuiのMoveVMはオリジナルのイーサリアムの哲学「クリーンでシンプル、美しい」プロトコルで、すべてをアプリケーション層に委任します。これにより、開発者は、その時点では未知のドメインも含め、あらゆるドメインを自由に探索できます。

ただし、プロトコルが単純すぎて構造化されていない場合は、重大な妥協が生じます。たとえば、認証などの一般的なシステム機能には、アプリケーション領域での複雑な実装が必要になり、標準インターフェースがさらに断片化され、パフォーマンスの最適化が困難になる可能性があります。

一方、Radix Engine は、非汎用的なシステム全体のロジックをコア技術目標として実行するように設計されており、次のことが可能になります。

システム全体の標準/実装を強制します。独自の標準により、API が断片化されていないため (例: ERC-20 と ERC-721 と ERC-404)、スタック全体の開発/保守/ツール作成が容易になり、動作を理解するためにバイトコードの解釈は不要になります (ERC-20 ラグプルは不要)。これにより、開発者とエンドユーザーはより安全で一貫性のある DeFi エクスペリエンスを得ることができます。
ロジックをハードウェアの近くで実行します。システムロジックは正確性のためにインタープリターで実行する必要がないため、そのロジックの実行はハードウェアにできるだけ近いところで実行できます。
実行を並列化します。特定のオブジェクトの動作に関する知識が手元にあると、実行前に静的分析の決定を下すことが容易になり、並列実行が可能になります。

ヴィタリックは最近この考えについて「祀り」、つまり、プロトコルで強制されるロジックの利点を得るために抽象化から選択的に脱却するという考え方です。彼の画像の 1 つを盗用して、彼は問題を抽象化と神聖化のトレードオフとして表現しています。

抽象化 (つまり、将来的/多様なユーザーニーズ) をサポートしながらパフォーマンス/セキュリティ/ユーザビリティ (つまり、エンシュリンメント) を維持するというこのバランスは、実は非常に古いコンピュータサイエンスの問題です。特にオペレーティングシステムの設計は、過去数十年間、同様の問題を解決しようとしてきました。つまり、高速で安全で使いやすいシステムを維持しながら、さまざまな抽象アプリケーションをサポートするにはどうすればよいかということです。

この記事では、Radix Engine がオペレーティングシステムモデルを使用して、プロトコルの複雑さの負荷や Vitalik が懸念する柔軟性の低下を招くことなく、あらゆる種類の「組み込み」が可能なフレームワークを作成する方法について説明します。

まず、現在の業界標準である Ethereum 仮想マシン (EVM) について見てみましょう。

VM としての EVM

EVM は、次のオペコードを使用して仮想マシン (VM) としてモデル化できるほど基本的なものです。

チューリング完全なオペコードセット
他のスマートコントラクトを呼び出すためのオペコード
現在のスマートコントラクトが所有する永続ストレージへの読み取り/書き込み用のオペコード

EVM バイトコードにコンパイルされたスマートコントラクトは、そのような VM 上で実行できます。

このモデルでは、いかなる形式の「エンシュリンメント」もEVMまたはVMハードウェアの変更を必要とします。たとえば、BLSシグネチャサポートをエンシュリンメントするには、新しいプリコンパイルを追加する必要があります。 EIP-2938新しいオペコードの追加が必要になります。規定されているものを拡張すると、必然的に VM がより大きく複雑になり、プロトコル設計者は Vitalik が説明するいずれかの決定を下す必要が生じます。

このモデルの一般的な問題は、抽象化/エンシュリンメントの二分法がソフトウェア/ハードウェアの二分法と結びつきすぎていることです。つまり、ロジックをプロトコルにエンシュリンメントすると、VM に埋め込まれることになります。「エンシュリンメントされたソフトウェア」やシステムの一部であるソフトウェアを表現する方法はありません。

オペレーティングシステムは、「システムソフトウェア」という概念でこの二分法を解決しました。詳しく見てみましょう。

オペレーティングシステムモデル

オペレーティングシステムの主な目的の 1 つは、ソフトウェアとハードウェアの二分法、より具体的には、アプリケーションとハードウェアの二分法を管理することです。オペレーティングシステムの中核部分はカーネルです。カーネルは、ユーザー空間のアプリケーションとハードウェアへのアクセスを管理するソフトウェアです。カーネルモジュールとドライバーは、サポートされるハードウェアのセットを拡張したり、カーネルの機能を拡張したりする追加のシステムソフトウェアです。

\「神聖化」の観点から見ると、カーネルとそのモジュールはシステムの神聖化された部分ですが、ソフトウェアの柔軟性を備えています。カーネルモジュール、仮想マシン (VM)、およびユーザー空間のシステムプロセスは、カーネル自体から抽象化されているため、さらに「柔軟」です。

このモデルでは、アプリケーションとハードウェア間の間接層により、ソフトウェア/ハードウェアの二分法を抽象化/エンスリンメントの二分法から切り離すことができます。「システムソフトウェア」により、ハードウェアに過度の負担をかけずにエンスリンメントが可能になります。

オペレーティングシステムとしての Radix Engine

このオペレーティングシステムモデルを参考にして、Radix Engine には、それぞれ特定の責任と抽象化を持つ複数のレイヤーが含まれており、システムのモジュール性とプラグイン可能性を実現しています。

このようなモジュール設計により、システムロジックを強制できると同時に、次のことも可能になります。

存在するレイヤーの分離プロパティを継承します。たとえば、エンシュリンされたパッケージは、エンシュリンされていても任意の状態にアクセスできず、アプリケーションレイヤーの境界に従う必要があります。これは、ユーザー空間ドライバーやマイクロカーネル設計で見られるセキュリティと同様のタイプです。つまり、システムの各部分を分離することでリスクが軽減され、システムの更新 (エンシュリンメント) によってシステム全体がリスクにさらされることはありません。
含まれているレイヤーの機能にアクセスします。たとえば、エンシャライズされたパッケージは、システムによって提供される認証機能やアップグレード機能を継承できます。
ガバナンスを分離します。このモジュール設計により、各モジュールのイノベーションを並行して、異なるペースで実行できます。

それでは、各レイヤーを詳しく見ていき、それぞれの役割を確認してみましょう。

アプリケーション層

アプリケーション層は、高レベルのロジックを定義する役割を担います。このロジックを記述するバイトコードは、他の静的情報とともに、パッケージと呼ばれる実行可能形式でまとめられます。パッケージは台帳上に保存され、実行できるようになります。

DeFi開発用に構築したRustベースの言語であるScryptoで書かれたアプリケーションは、このレイヤーに存在します。Scryptoプログラムは、プログラムがシステム/カーネルサービスにアクセスできるようにする一連の関数エクスポートにアクセスできるWASMプログラムにコンパイルされます。システムコールAPI Linuxに似ているシステムコール、共有 I/O へのアクセスを提供します。

VM レイヤー

次の層に移ると、VM 層はアプリケーション層にコンピューティング環境を提供する役割を担います。これには、チューリング完全な VM とシステム層にアクセスするためのインターフェイスが含まれます。

Radix Engine は現在、Scrypto アプリケーションを実行するために使用される Scrypto WASM VM と、ホストの環境に合わせてコンパイルされたネイティブパッケージを実行するネイティブ VM の 2 つの VM をサポートしています。

Scrypto WASM VM を具体的に見てみると、次のようになります。

これは本質的には EVM モデルと同じように見えますが、2 つの重要な違いがあります。

ストレージへの直接アクセスの削除。各スマートコントラクトが所有するストレージにのみアクセスできるのではなく、状態の読み取り/書き込みはシステムコールを通じて行われます。この間接層により、アプリケーション間での状態共有、状態の仮想化など、システムに多くの興味深いものを実装できます。この間接層は、仮想メモリまたはLinuxのファイル記述子。
システムコールの追加。システムコールは、アプリケーション層がシステム層のサービスにアクセスするためのメカニズムであり、他のアプリケーションを呼び出したり、オブジェクトにデータを書き込んだりするために使用されます。これらのシステムコールは、実際のCPUのソフトウェア割り込み命令に似ています（例：内部(x86 の命令)

システム層

システム層は、システムの機能を拡張できるシステムモジュールまたはプラグイン可能なソフトウェアのセットを管理する役割を担っています。これらはLinuxのカーネルモジュール。

すべてのシステムコールで、システムレイヤーがカーネルレイヤーに制御を渡す前に、各システムモジュールが呼び出されます。呼び出されると、各システムモジュールは特定の状態 (たとえば、更新料金の支払など) を更新したり、パニックを起こしてトランザクションを終了したりします (たとえば、型チェッカーが失敗した場合)。

このパターンにより、システムはアプリケーション層とカーネル層の両方から分離しながら、認証、ロイヤリティ、型チェックなどの機能を実装できます。

カーネル層

カーネル層は、Radix Engine の 2 つのコア機能、つまりストレージアクセスとアプリケーション間の通信を担当します。これは、従来のオペレーティングシステムがディスクおよびネットワークアクセスを担当する役割と多少似ています。

Radix Engine の場合、これには次の低レベルの管理が含まれます。

呼び出しまたはデータ書き込み時に、移動/借用セマンティクスが維持されていることを確認します。単一所有者ルールと借用ルールはカーネルによって強制されます。これらのルールのいずれかが失敗すると、トランザクションはパニックになります。
一時オブジェクトと永続オブジェクトを管理します。オブジェクトは、いつでもグローバルスペースに存在するか、コールフレームによって所有されている可能性があります。カーネルは、実行時にこれらのオブジェクトへの参照が渡されるときに、これらのオブジェクトへの正しいポインターを維持します。
トランザクション状態の更新を管理します。カーネルは、トランザクション中に発生し、その後トランザクションの終了時にデータベースにコミットされる状態の更新を追跡します。

奉納されたソフトウェア

これらのレイヤーは、DLT プロトコルのエンシュリンメントとどのように関係しているのでしょうか? オペレーティングシステムのカーネルレイヤーと同様に、Radix Engine のこれらの中間レイヤーは、抽象化/エンシュリンメントの二分法をソフトウェア/ハードウェアの二分法から切り離し、「エンシュリンメントされたソフトウェア」という概念を作成するために必要な間接性を提供します。

エンシャライズされたソフトウェアは、システム全体のロジックを適用する機能を維持しながら、ソフトウェアの柔軟性とセキュリティ特性を備えています。

Radix ネットワーク上で現在実行されているいくつかのエンシュリンメントの例を確認し、それらがどのように実装されているかを見てみましょう。

祀られた資源

Radix DeFi/Web3 プラットフォームの中心的な差別化要因は、リソース (つまり、資産) はビジネスロジックとは別に理解されるべき基本的なプリミティブであるという考え方です。この概念を定着させることで、すべての dApp、ウォレット、ツールが資産のインターフェイスと動作がどのようなものであるかを共通に理解できるようになり、構成がはるかに容易になります。

リソースはシステムの最も根深い部分の 1 つですが、その組み込みを実装するには、次の 2 つのモジュールソフトウェアのみが必要です。

Buckets、Vaults、Proofsなどのリソースオブジェクトのロジックを処理するネイティブパッケージ
これらのオブジェクトのライフタイム不変条件（リソースの移動可能性や燃焼可能性など）を強制するシステムモジュール

Radix Engine がシステム/カーネルから抽象化されながら、標準化された移動可能なリソースの深い概念を表現できたという事実は、モジュール式システムソフトウェアフレームワークの威力を示しています。

定められた認可とロイヤリティ

Radix Engine は、このロジックをビジネスロジックから分離し、これらをシステム機能として実装することで、承認とロイヤリティを標準化します。これにより、ユーザーと開発者は、台帳上の任意の機能にアクセスするための要件を理解するための組み込みの共通の方法を持つことができます。

ビジネスロジックをシステムロジックから分離するモジュール性により、通常の認証チェックなしでトランザクションをプレビューする機能など、便利な開発/デバッグオプションも可能になります (1,000 万 USDC をどこかに送信した結果をシミュレートしたいですか? 認証を無効にすると、プレビュートランザクションで鋳造を実行できます)。

認証とロイヤリティを制定するには、次の 4 つのモジュールソフトウェアが必要です。

アプリケーション層が任意のオブジェクトの認証/ロイヤリティにアクセスできるようにする認証およびロイヤリティのネイティブパッケージ (たとえば、メソッドにアクセスするための認証ルールを取得したり、ロイヤリティを請求したりする)。
Auth および Royalties システムモジュールは、オブジェクトメソッド呼び出しの前に呼び出され、呼び出し元が呼び出しを行ってロイヤルティを徴収するのに十分な権限を持っているかどうかを確認します。

奉納された取引

あらゆるシステムを使いやすくするには、ユーザーとシステム間の適切なインターフェースが最も重要です。使いやすくするには、インターフェースは使いやすさとパワー/柔軟性の間で適切なバランスを見つける必要があります。

オペレーティングシステムの世界で最も一般的なインターフェイスはターミナルです。ターミナルは、ユーザーにさまざまなシステムコールを呼び出して作成するためのコマンドラインツールを提供するユーザー空間プロセスです。

DLT の世界では、このインターフェースはトランザクションです。トランザクションの業界標準は、単一の低レベルの汎用呼び出し呼び出しを使用することです。残念ながら、これは単純すぎるため、システムと対話するときに実際に何をしているのか理解するのが難しくなります。

一方、Radix Engine は従来の OS パターンを使用し、アプリケーション言語 (bash などのターミナルスクリプト言語に類似) を組み込み、単一のトランザクションでシステムコールを呼び出し、構成します。

トランザクションのエントリポイントはアプリケーション層で動作するため、言語インタープリターはトランザクションプロセッサネイティブパッケージを追加することによって実装されます。

奉納されたBLS

BLS 署名は、しきい値署名の可能性を可能にする重要な暗号プリミティブです。残念ながら、WASM でこのようなロジックを実行すると、最大コスト単位がすぐに消費されます。最近の「Anemone」アップデートでは、BLS をネイティブに実行することで実装し、WASM と比較してパフォーマンスが 500 倍向上しました。

BLS ロジックはステートレスであるため、Scrypto WASM VM への追加のプリコンパイルとして簡単に追加できます。

結論

何を制定し、何を制定しないかは、あらゆる DLT プロトコルにとって重要です。残念ながら、業界の既存の VM モデルでは、すべての制定の決定が重大な決定となります。

Radix Engine は、オペレーティングシステムモデルを参考にして、「ソフトウェア」と「ハードウェア」の間に間接レイヤーを追加することでこの問題を解決します。これにより、Radix Engine は「エンシャリンドソフトウェア」の概念を表現できるようになり、プロトコルは、リスクの高い妥協の決定をすることなく、新しいエンシャリンドシステムを簡単に追加、変更、表現できるようになります。

もともと、オペレーティングシステムは、複数のアプリケーションの共有リソースを管理するために設計された小さなソフトウェアでした。より優れた、より高速で、より安全なプラットフォームを求めるユーザーの要求が高まるにつれて、オペレーティングシステムはますます大きなソフトウェアスイートで、より多くの責任を負うようになりました。

DeFi も例外ではありません。より高速で、より安全で、より使いやすい DeFi プラットフォームの需要が高まるにつれて、導入も増えるでしょう。Radix Engine はこれを念頭に置いて設計されており、将来に向けて導入を拡大するために必要なスケーラブルで安全なフレームワークを提供します。