ロールアップ レイヤ 2 モジュラー エボリューション: 何が可能か?

この記事では、進化の観点からロールアップ レイヤー 2 の開発と進化について説明し、主に次の質問に答えます。

ロールアップのしくみ:

ロールアップのモジュール化

モジュール化が可能性を広げる

モジュール式アプリケーションの技術動向

概要

ロールアップの仕組み

ブロックチェーンの「トリレンマ」は業界にとって常に難しい問題であり、レイヤー1ブロックチェーンが最初に「分散化」と「セキュリティ」を確保すべきだと考えるなら、レイヤー1から「スケーラビリティ」ソリューションを移行することは自然な選択であり、したがってレイヤー2です。 新たな課題は、レイヤー2からレイヤー1までのセキュリティをどのように確保するかです。

当初は、レイヤー2アプリケーションのステートツリーのルートをレイヤー1に定期的に書き込み、取引プラットフォームのプルーフオブリザーブと同様に、アプリケーションの状態をプルーフオブステートで検証できるようにするというアイデアがありました。 ただし、このメソッドは、2 つの状態遷移が正しいことを公的な方法で検証するために第三者が行うことはできません。

この問題をより深く掘り下げるために、任意のプログラムの状態は状態遷移式で表現できることを抽象化しましょう。

t+1 (t, T)

この式はイーサリアムのイエローブックから来ていますが、どんなプログラムでも表現できます。 ここでは、状態を表すプログラムを表します。 状態 t+1 は、プログラム Y によって状態 t とトランザクション T から計算されます。 トランザクション T は、プログラムの入力を表します。 t が決定論的であり、プログラム Y が決定論的であり、T が決定論的である場合、t+1 は決定論的です。

したがって、公的な検証可能性を提供するには、Y が公開されていること、すべての T が歴史的に公開されており、順序どおりに公開されていること、および中間状態が Y と T によって再計算できることが鍵となります。 プログラムの公開はオープンソースで実現できますが、データ可用性(DA)の概念を導入したTの公開をいかに確保するかが鍵となります。

データの可用性には、アプリケーションのトランザクションを記録するための公開されていない不変の台帳が必要です。 当然のことながら、ブロックチェーン台帳はそのようなシステムであるため、レイヤー2のトランザクションはレイヤー1に書き戻され、データの可用性が確保されるため、ロールアップの名前の由来となっています。

したがって、レイヤー2システムには、ユーザートランザクションを収集し、ソートし、DAに書き込む役割が必要であり、この役割はシーケンサーと呼ばれます。 ここでの一連のトランザクションは、正規トランザクションチェーンと呼ばれます。

データの可用性が保証されており、誰もがプログラムを自分で実行してトランザクションを実行することで、最終的な状態を取得できます。 しかし、結局のところ、ソフトウェアまたはハードウェアの障害もデータの不整合を引き起こす可能性があるため、結果が他の人と同じかどうか誰もがわからないため、ここにはコンセンサスがありません。 したがって、トランザクションの実行後にステータスツリールートを公開し、全員がステータスを確認できるように定期的に別のロールが必要であり、このロールは提案者と呼ばれます。 ここでの各コミットの状態は、状態コミットメント チェーンと呼ばれるトランザクション シーケンスに対応する状態シーケンスも構成します。

この時点で、アプリケーションの検証可能性に到達しました。 誰かの結果が提案者の提出のステータスと一致しず、それが自分の問題ではないと判断された場合、提案者は不正行為をしているか間違っていると判断された場合、どのように他の人に知らせますか? アービターは信頼できる第三者である必要があり、オンチェーンコントラクトはこの役割を担うことができます。

仲裁には 2 つのオプションがあります。

提案者は、状態を送信するたびに、チェーン上のアービトレーションコントラクトによって検証される、以前の状態からの状態遷移の有効性証明も提供します。 有効な証明は、通常、ZK ロールアップと呼ばれるゼロ知識技術を使用して生成されます。

提案者の結果は正しいと想定されますが、矛盾が見つかった場合は、詐欺の証拠が提出され、仲裁契約が決定されます。 クォーラム契約で提案者が不正行為をしたと判断された場合、提案者は罰せられ、状態コミットメント チェーンは不正なトランザクション前の状態にロールバックされます。 もちろん、セキュリティを確保するために、オンチェーン取引決済のファイナリティを達成するために、一般的には比較的長いチャレンジ期間が設定されています。 これは、オプティミスティック ロールアップと呼ばれます。

また、レイヤー 1 とレイヤー 2 の間で資産の相互運用性を実装する必要があります。 そこで、レイヤー1とレイヤー2の間に橋を架け、国家証明によって資産決済を行います。 レイヤ1におけるレイヤ2の状態は、レイヤ1の調停契約によって保証されており、このブリッジのセキュリティも調停契約によって保証されていると想定できます。

これまでのところ、レイヤー 1 によって保証され、レイヤー 1 と相互運用できるロールアップ レイヤー 2 ソリューションがあります。

もちろん、ロールアップ ソリューションにはいくつかの妥協点があります。

レイヤ 1 にトランザクションを書き込むということは、レイヤ 2 のスケーラビリティがレイヤ 1 のブロック サイズによって制限されることを意味します。 イーサリアムを例にとると、レイヤー2はイーサリアムの全ブロックを完全に占有しており、提供できる平均TPSは数百に過ぎず、スケーラビリティはDAによって制限されます。

ガス代を節約するために、Sequencer はトランザクションをバッチで DA に書き込み、DA に書き込む前に、トランザクションの順序を調整してチートすることができます。

レイヤー 2 セキュリティとトランザクションのファイナリティの概要は次のとおりです。

ユーザがレイヤ2ノードを実行し、DAのトランザクション順序を忠実に実行した場合、ユーザの実行結果が提案者の実行結果と異なる場合、提案者がチートをしてチェーンの状態をロールバックする必要があることを意味し、その結果はユーザ自身のノードと同じになるため、ユーザーは即座にトランザクションが確認されて確定したと想定できます。 ここでの主なリスクは、データがSequencerからリアルタイムで同期されている場合、DAにまだ書き込まれていないトランザクションの順序をSequencerが調整するという前述のリスクです。

ユーザーが自分でノードを実行できない場合、RPCプロバイダーに依存する必要があり、ユーザーは特定の信頼リスクを負う必要があります。 ただし、このリスクは、レイヤー 1 の RPC ノードを信頼するユーザーによってもたらされるリスクと似ています。 ここでの追加のリスクは、Sequencer がトランザクションをドロップまたは並べ替えるリスクです。

提案者がエラーを起こしたが、どのノードもチャレンジを開始しておらず、チャレンジ期間を超えた場合、間違った状態をロールバックすることはできず、状態はソーシャルコンセンサスハードフォークによってのみ修正できます。

ロールアップのモジュール化

前の分析によると、ロールアップ ソリューションでは、チェーン上の複数のコントラクトが異なる機能を想定し、異なるモジュールを表します。 当然の考えは、モジュールを複数のチェーンに分割して、より高いスケーラビリティを実現できないかということでした。 これが、モジュール式ブロックチェーンとモジュール式ロールアップの背後にある考え方です。

モジュール性には、次の 2 つの意味があります。

モジュラー設計により、システムはプラグ可能なシステムになります。 開発者は、さまざまなアプリケーションシナリオのニーズを満たすためにモジュールを組み立てることができます。

1 によって提供される機能に基づいて、モジュール層の実装は同じ層 1 に結び付けられないため、スケーラビリティが向上します。

モジュール層は大きく分けて3つ考えられます。

データの可用性:実行レイヤーのトランザクションデータが公開されていること、および保証されたトランザクションのシーケンスが保証されていることを保証します。

決済: レイヤー 1 とレイヤー 2 の間で資産と状態を決済します。 これには、State Commitment Chain と Bridge が含まれています。

仲裁: 不正の証拠を検証して裁定を下す (楽観的) か、有効な証拠を確認する (ZK)。 クォーラム レイヤーは、状態コミットメント チェーンを操作できる必要があります。

DA のモジュール性

DA機能をスタンドアロンソリューションに移行する主な利点は、レイヤー2トランザクションのガス料金が少なくとも1桁削減されることです。

セキュリティの観点からは、DAチェーンの分散化がイーサリアムよりも弱いとしても、DAレイヤーでのセキュリティの保証は、主にチャレンジ期間中のトランザクションです。

DAプライベートチェーンは、より高いストレージ帯域幅とより低いストレージコストを提供でき、複数のアプリケーションがDAを共有するために特別に設計されています。 これは、CelestiaやPolygon Availなどの現在のDAチェーンの足がかりでもあります。

DAレイヤーを分割すると、次の図のアーキテクチャが得られます。

上の図では、DA が正規トランザクション チェーンの保存を担当し、L1ToL2 トランザクション キューは Layer1 と Layer2 間のメッセージ通信を実現するために残され、ユーザーはこのキューに直接トランザクションを書き込むこともでき、Layer2 がパーミッションレスであり、Sequencer がユーザーまたはトランザクションを監査できないようにすることもできます。

1つの解決策は、DAチェーンとアービトレーションチェーンの間にクロスチェーンブリッジを設けて、DAチェーンがアービトレーション契約で提供するデータ証明を検証することです。 ただし、このソリューションは、DAと他のチェーン間のクロスチェーンブリッジの実装に依存しており、DAソリューションの選択肢は限られています。 もう一つの選択肢は、選別証明を導入することです。

シーケンスプルーフ

シーケンサーは実際には DA スキームの一部と考えることができ、次の理由により、アプリ固有の DA に相当します。

シーケンサーは、DA チェーンに一括書き込みを行う前の期間、DA を保証する必要があります。

シーケンサーは、トランザクションの検証、順序付け、および最終的なトランザクションの DA への書き込みを担当します。

トランザクションごとにシーケンス証明を生成するように Sequencer に依頼すると、次の 2 つの問題を解決できます。

DA チェーンにまだ書き込まれていないトランザクションを保証し、Sequencer がトランザクションの順序を任意に調整したり、破棄したりしないようにします。 DAチェーンとクォーラムチェーンの間にクロスチェーンブリッジがない場合、Sequence Proofのチャレンジメカニズムを通じてデータが利用可能であることを保証できます。

シーケンスプルーフには、次の機能があります。

シーケンサーの署名があり、シーケンサーによって発行されたことを証明します。 これは、トランザクションのシーケンス全体におけるトランザクションの位置を証明します。 アキュムレータプルーフの一種です。 各トランザクションは、以前のすべての履歴トランザクションと相関する新しい結果を生成するために合計されるため、改ざんが困難になります。 アキュムレータのオプションの1つはマークルアキュムレータで、マークルツリーの根の形になります。

シーケンスプルーフの仕組み:

ユーザーまたは実行ノードがトランザクションをシーケンサーに送信し、シーケンサーがシーケンス証明をユーザーに返し、他のノードに同期します。 シーケンサーがトランザクションの順序を DA に送信する前に破棄または改ざんした場合、ユーザーまたは他のノードは、シーケンス証明をクォーラム コントラクトに送信することで、シーケンサーにペナルティを科すことができます。 クォーラム コントラクトは、シーケンス証明を検証するために、状態コミットメント チェーン コントラクトからトランザクション アキュムレータのルートを読み取る必要があります。

次のシナリオについて説明しましょう。

シーケンサーは、ユーザー トランザクションを破棄またはリフローします。 これにより、シーケンサーは同じ場所に 2 つのシーケンス証明を生成します。 ユーザーがアービトレーション コントラクトにシーケンス証明を送信すると、Sequencer はトランザクションが最新のトランザクション アキュムレータのルートに含まれていることの証明を提供する必要があり、それができない場合、Sequencer はペナルティを受けます。

シーケンサーはDAチェーンにトランザクションを適切に書き込まず、Proposerと共謀してトランザクションを隠蔽しました。 クォーラム チェーンと DA チェーンにブリッジがある場合、ブリッジを使用して検証され、シーケンサーにペナルティが課せられます。 それ以外の場合、ユーザーは Sequencer にチャレンジして、元の情報と共に特定の場所でのトランザクションの証明を提供できます。 ただし、この場合、仲裁契約はユーザーが悪意のあるチャレンジであるかどうかを判断できないため、Sequencerがデータを提供しても、Sequencerにペナルティを課すことはありません。 ユーザーにとって、悪意のあるチャレンジは他人や自分自身を傷つけ、経済的な動機付けも欠如しています。

Sequence Proofを導入することで、レイヤー2プロトコルの安全性を高めました。

トランザクションパイプラインと並列実行

SequencerをDAに分割し、DAはトランザクションの検証と順序付けのみを担当するが、トランザクションの効率化と並列実行が容易になるというメリットもある。

取引を検証する際には、署名と十分なガス料金があるかどうかを検証する必要があり、ガス料金の検証は州に依存する必要があります。 検証トランザクションが実行トランザクションによってブロックされないようにするために、検証トランザクションが依存する状態と最新の状態の間の遅延 (秒単位) を Sequencer に許可すると、ガス検証が不正確になり、DDoS 攻撃のリスクがあります。

しかし、DA であることはシーケンサーにとって正しい方向であると考えているので、さらに検討する価値があります。 例えば、取引手数料のDA部分を分割し、Sui Move Object(UTXO)で表現することで、ガス代検知のコストを抑えることができます。

シーケンサーはトランザクションをソートしてトランザクションパイプラインに出力し、トランザクションパイプラインはProposerや他のノードに同期されます。 各ノードは、独自のサーバーの状況に応じて並列スキームを選択できます。 各ノードは、因果関係のないトランザクションのみを並列化し、因果関係のあるトランザクションをシーケンサーの順番で実行し、最終的な結果に一貫性を持たせる必要があります。

提案者は、ステートツリーのルートとアキュムレータのルートをオンチェーンのステートコミットメントチェーンコントラクトに定期的にコミットする必要があります。

そこで、ガス代が安く、TPSが高く、セキュリティが強化されたモジュラーレイヤー2、Roochを手に入れたのです。

MoveOS: MoveVM と、システムの実行および状態ストレージ エンジンである StateDB が含まれています。 StateDB は、状態の証明を提供する 2 つの層の疎なマークル ツリーから構築されています。 前の分析に基づいて、状態ツリーと状態証明はロールアップ アプリケーションの不可欠なコンポーネントであると結論付けることができます。

RPC: 外部クエリの提供、トランザクションの送信、サービスのサブスクライブを行います。 他のチェーンと互換性のあるRPCインターフェイスを仲介できます。

シーケンサー: トランザクションを検証し、トランザクションをシーケンスし、シーケンス証明を提供し、トランザクションをトランザクションパイプラインに出力します。

提案者:トランザクションパイプラインからトランザクションを取得し、バッチで実行し、定期的にオンチェーンのステートコミットメントチェーンに送信します。

チャレンジャー: トランザクション パイプラインからトランザクションを取得し、バッチで実行し、ステート コミットメント チェーンと比較して、チャレンジを開始するかどうかを決定します。

DA & Settlement & Arbitration Interface: 異なる実装間の切り替えが上位層のビジネスロジックに影響を与えないように、異なるモジュール層を抽象化およびカプセル化します。

マルチチェーンサポートによるインタラクティブな不正防止

楽観的ロールアップ方式では、オンチェーンの仲裁契約がオフチェーンのトランザクション実行エラーをどのように判断するかは、常に難しい問題でした。 当初のアイデアは、レイヤ 1 でレイヤ 2 トランザクションを再実行することでしたが、このソリューションの問題は、レイヤ 1 コントラクトがレイヤ 2 トランザクションの実行をシミュレートする必要があるため、非常にコストがかかり、レイヤ 2 トランザクションの複雑さが制限されることです。

最後に、業界はインタラクティブな証明スキームを模索しています。 複雑なトランザクションは最終的にマシンインストラクションの実行に変換されるため、ダイバージェンスを生成する命令が見つかった場合は、チェーン上の命令の実行をシミュレートするだけで済みます。

また、上記の状態遷移式も使用します。

t+1 (t, T)

ここで、Tは命令を表し、Tは命令入力を表し、命令が依存するメモリの状態を表します。 実行中に、それぞれのステータス証明書を生成します。 検察側と弁護側は、対話を通じて、両当事者間の意見の相違点mを見つけ出し、m-1の状況と指示mをオンチェーン仲裁契約に提出して模擬執行を行い、執行後に仲裁契約を決定することができます。

したがって、残りの問題は証明を生成する方法であり、主に2つのオプションがあります。

これは、ArbitrumのAVMやFuelのFuelVMなどのコントラクト言語仮想マシンに直接実装されています。

既存の命令セットに基づいてシミュレータを実装し、シミュレータで証明機能を提供します。 例としては、Optimism の MIPS ベースの大砲、Arbitrum の新しい WASM ベースの Nitro、Rooch の MIPS ベースの OMO などがあります。

OMOは、シングルステップのプルーフ・オブ・ステート機能を備えた汎用バイトコードシミュレータで、マルチチェーン実行環境向けに設計されています。 OMOのサポートにより、クォーラムレイヤーのモジュール性を実現できます。 チューリング完全コントラクトをサポートするチェーンは、コントラクト内のOMOの命令をクォーラムレイヤーとしてエミュレートできます。

ZK + 楽観的コンボスキーム

オプティミスティックロールアップとZKロールアップのメリットについては、業界で多くの議論が交わされてきましたが、この2つを組み合わせることで、両方の長所を活かすことができると信じています。

以前の楽観的な解決策に基づいて、新しいキャラクターであるZKプローバーを紹介します。 提案者によって提出された取引状況の有効な証拠をバッチで生成し、仲裁契約に提出します。 仲裁契約が検証された後、取引がレイヤー1でファイナリティに達したと判断でき、レイヤー2からレイヤー1への引き出しトランザクションを決済することができます。

このアプローチの利点:

ZK のパフォーマンスの問題は、レイヤ 2 の全体的なスループットを制限しません。 ZKは、オプティミスティックのチャレンジサイクルを短縮し、ユーザーエクスペリエンスを向上させることができます。

ZKのソリューションとハードウェアアクセラレーションが成熟する前に、Optimisticを通じてエコシステムを構築することができ、モジュラーソリューションによりZKを最終的にシームレスに統合することができます。

マルチチェーン決済

モジュール化の傾向をさらに考えると、DAは他のチェーンに移行できるのだから、決済層も他のチェーンに展開できるのではないかと考えるのが自然です。

レイヤー 1 とレイヤー 2 の間の資産の決済は、主に 2 つのコンポーネントに依存し、1 つはブリッジ、もう 1 つはステート コミットメント チェーンです。 もちろん、ブリッジは複数のチェーンにデプロイできますが、ステート コミットメント チェーンは、クォーラム コントラクトによって保護された 1 つの権限のあるバージョンのみを持つことができます。

この方向性はまだ深く研究する必要がありますが、予備的な計画があります。 他のチェーンのステートコミットメントチェーンは、イーサリアムの鏡像です。 このイメージは、すべてのLayer2 State Rootを他のチェーンに同期させる必要はなく、イーサリアムのプルーフ・オブ・ステート・オン・デマンドを介してユーザーによってマッピングされます。

もちろん、他のチェーンもイーサリアム上のプルーフ・オブ・ステートを検証できる必要があるため、イーサリアム上のルート・オブ・ステートを知る必要があります。 現在、イーサリアム上の状態のルートを他のノードに同期させるシナリオは2つあります:1。 オラクルにお任せください。 2. イーサリアムライトノードを埋め込み、イーサリアムのブロックヘッダーを確認します。

このようにして、マルチチェーン決済をサポートするレイヤー2ソリューションを得ることができますが、セキュリティはイーサリアムによって保証されています。

このソリューションとクロスチェーンの違い:

リレーチェーンに依存するクロスチェーンソリューションであれば、レイヤー2がリレーチェーンに置き換わり、アービトレーションコントラクトによってセキュリティが保証されているリレーレイヤーであると考えることができます。

チェーン間の状態証明を検証するクロスチェーンスキームの場合、マルチチェーン決済スキームは状態ルート同期の技術的スキームを共有しますが、はるかに単純化されています。 マルチチェーン決済スキームでは、状態ルートの同期要件は一方向であり、クォーラムチェーンから他のチェーンに同期するだけでよく、2つずつ同期する必要があるわけではありません。

モジュール化が可能性を広げる

モジュール化により、開発者はさまざまなアプリケーションをRoochと組み合わせることができます。

Rooch Ethereum Layer2 = Rooch + Ethereum(Settlement+Arbitration) + DA。 これは、Roochが最初に実行するネットワークです。 イーサリアムのセキュリティによって保証され、イーサリアム上の資産と相互運用できるMoveランタイムプラットフォームを提供します。 将来的には、マルチチェーン決済に拡張できます。

Rooch Layer3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer2 (Settlement + Arbitration) + DA アプリケーションが独自の決済とアービトレーションをRoochレイヤー2にデプロイする場合、それはRoochレイヤー3アプリケーションです。

XChain Rollup DApp = Rooch + DApp Move Contract + XChain(Settlement + Arbitration) + DA どのチェーンも、Roochを介してMove言語に基づくRollup DAppツールキットのセットを開発者に提供できます。 開発者は、XChainによって安全で保護された独立した環境でロールアップアプリケーションを実行するために、Move言語を使用して独自のアプリケーションロジックを記述するだけでよく、アセットはXChainと相互運用可能です。 もちろん、これは各パブリックチェーンの開発者と共同で開発する必要があります。

ソブリン・ロールアップDApp = Rooch + DApp Move Contract + DAアプリケーションは、ブリッジ契約や仲裁契約を展開することなく、Roochをソブリン・ロールアップSDKとして使用することもでき、ステート・コミットメント・チェーンもDAに保存され、社会的コンセンサスによる検証可能性とセキュリティを確保します。

Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave)SCPは、アプリケーションのコードもDAに保存する必要があるという点で、Sovereign Rollupに似ています。 Roochでは、コントラクトのデプロイとアップグレードはすべてトランザクションであり、トランザクションでコントラクトコードがDAレイヤーに書き込まれるため、SCPの基準を満たしていると考えています。

Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract MoveOSは、独立したMoveランタイム環境として任意のチェーンのランタイム環境に埋め込むことで、アプリチェーンや新しいパブリックチェーンを構築することができます。

非ブロックチェーンプロジェクト 非ブロックチェーンプロジェクトでは、データ検証機能とストレージプルーフ機能を備えたデータベースとしてMoveOSを使用できます。 例えば、ローカルのブログシステムを作るのに使い、データ構造やビジネスロジックをMoveで表現します。 将来、インフラが成熟すれば、ブロックチェーンのエコシステムと直接接続することができます。 別の例としては、クラウドコンピューティングのFaaSサービスとして使用でき、開発者はMoveを介してFaaSでFunctionsを記述でき、プラットフォームが状態をホストし、ユーザー間の関数を組み合わせて呼び出すこともできます。 探索する可能性はまだまだあります。

Roochのモジュラーアプローチは、さまざまなタイプや段階のアプリケーションに適合させることができます。 たとえば、開発者はまず Rooch イーサリアム レイヤー 2 でコントラクトを展開してアイデアを検証し、成長した後に Rooch 上に構築された独立したアプリ固有のロールアップにアプリケーションを移行できます。

または、アプリケーションの初期段階では高いセキュリティ要件がなく、他のチェーンと資産を交換する必要がないため、開発者はソブリンロールアップ方式でアプリケーションを直接起動できるため、最初に検証できます。 アプリケーションが成長し、資産を相互接続する需要が高まると、セキュリティ要件が高くなり、決済モジュールと仲裁モジュールを有効にして資産のセキュリティを確保できます。

モジュラーアプリケーションの技術動向

DA層のポテンシャルはまだ開拓されていない

前の分析からわかるように、DAは組み合わせに関係なく信頼されます。 DAは、監査、ビッグデータ分析、AIトレーニングなどに使用できるWeb2システムのロギングプラットフォームとして、分散型アプリケーションで同様の役割を果たします。 将来的には、DAを中心に構築されたアプリやサービスがたくさんあるでしょう。 現在、Celestia、Polygoinが利用しており、将来的にはEigenLayer、Ethereumダンクシャーディングなどがあります。

これまでの分析に基づいて、シーケンサーの役割はDAの一部であるべきであり、DAレイヤーがアプリケーションにトランザクション検証機能を提供でき、十分なパフォーマンスを備えている場合、実際にはDAがシーケンサーの責任を引き受けることができ、ユーザーはトランザクションをDAに直接書き込みます。 もちろん、アプリケーションのトークンを使用してDAのガス料金を支払うことができるかどうかは、解決する必要がある別の問題です。

DAppプログラミング言語が爆発的に普及

新しいアプリケーションの形は、Web2の時代に証明された新しいプログラミング言語の爆発的な増加につながります。 Moveは、Web3 DAppsを構築するための最良の言語となるでしょう。 Move自体の言語的な性質に加えて、次の理由があります。

DAppsは、同じ言語でのアプリケーションに必要な基本的なライブラリを迅速に蓄積することができ、生態学的集積効果を形成します。 そのため、複数の言語をサポートすることは、最初は良い戦略ではありません。

少なくとも、分散型アプリケーションは検証可能である必要があり、スマートコントラクト言語は、検証可能性を確保するという点で、開発者の精神的負担を大幅に軽減することができます。

Moveはプラットフォームに依存しないため、さまざまなプラットフォームやアプリケーションに簡単に適応できます。

移動の状態は構造化されているため、DAppのデータ構造の表現やストレージの取得が容易になります。

まとめ

私がブロックチェーンに足を踏み入れたのは17年末で、当時は業界に多くのチームがブロックチェーン分野でアプリケーションを構築しようとしていました。 残念ながら、インフラストラクチャはまだ完成しておらず、業界はアプリケーションを構築するための複製可能なモデルをまだ考え出していなかったため、ほとんどのアプリケーションプロジェクトは失敗に終わり、開発者と投資家の両方に打撃を与えました。 ブロックチェーン上でアプリケーションを構築するにはどうすればよいでしょうか? この質問は5年間私のことを考えてきました。

現在、レイヤー1、レイヤー2、スマートコントラクト、モジュラーインフラストラクチャの成熟により、この質問に対する答えは徐々に明らかになっています。

Web3 DAppsの爆発的な普及が進む中、Roochが開発者がアプリケーションをより速く構築し、実際に着地するのを支援できることを願っています。