紹介

現在、私たちはすでに、プロジェクトがアプリチェーンのためにMadaraの実験を始めているのを目にしています。 Pragma、Kakarot、Mangata Finance、Dojo などは、その一例です。 マルチチェーンの未来とzkスケーリングの力を信じている限り、将来的にはこれらのプロジェクトがさらに多く見られるでしょう。 しかし、アプリチェーンの数が増えていることから、疑問も生じています

1. 地方分権化
2. コンポーザビリティ
3. 開発経験

この投稿では、多くのアプリチェーンを使用しているために発生する問題を説明し、MadaraとStarknetにとってエレガントで最適であると考える問題の可能な解決策を提示します。 すでにアプリチェーンと共有シーケンスに精通している場合は、「待ってください、それは再びPolkadotだけです」セクションにジャンプしてください。

100のアプリチェーンではどうなりますか?

例えば、100の異なるアプリチェーンがイーサリアムに落ち着く未来にいるとしましょう。 これが引き起こすすべての問題に対処しましょう。

断片化された分散化

すべてのアプリチェーンは、分散化を独自に解決する必要があります。 現在、アプリチェーンの分散化は、主にセキュリティをL1に依存しているため、L1ほど必要ではありません。 しかし、活気を確保し、検閲に抵抗し、独占的な利点(例えば、高い手数料)を避けるために、分散化は依然として必要です。 ただし、各アプリチェーンが独自の方法で分散化を解決し続けると、バリデーターセットの断片化がすぐに発生することに注意することも重要です。 各アプリチェーンは、新しいバリデーターをオンボーディングするための経済的インセンティブを開発する必要があります。 また、バリデーターは、実行に問題のないクライアントを選択する必要があります。 言うまでもなく、開発者が独自のアプリチェーンを立ち上げるための大きな参入障壁があります(単なるトランザクションであるスマートコントラクトを展開するのとは対照的です)。

コンポーザビリティ

コンポーザビリティとは、基本的にアプリ間のインタラクションを意味します。 イーサリアムやスターネットでは、これは別のコントラクトを呼び出すことを意味し、それ以外はすべてプロトコル自体によって処理されます。 ただし、アプリチェーンでは、これははるかに困難になります。 さまざまなアプリチェーンには、独自のブロックとコンセンサスメカニズムがあります。 別のアプリチェーンと対話しようとするたびに、コンセンサスアルゴリズムとファイナリティ保証を慎重に調べ、それに応じてクロスチェーンブリッジ(チェーンに直接、またはL1を介して)を設定する必要があります。 異なるデザインの 10 個のアプリ チェーンを操作する場合は、これを 10 回行います。

開発経験

分散化と橋渡しの解決は容易ではありません。 これがすべてのアプリチェーンの要件である場合、通常のスマートコントラクト開発者が独自のアプリチェーンを構築することは非常に困難になります。 さらに、すべてのアプリチェーンが独自の方法でこれらの問題を解決しようとすると、まもなく異なる標準がさまざまなチェーンによって守られ、エコシステムへの参加がさらに困難になります。

共有シーケンサーはこれを解決できます

アプリチェーンの分野をフォローしている方は、「共有シーケンサー」という言葉を聞いたことがあるかもしれません。 これは、上記の問題を解決することを目的としたすべてのチェーンに共通のバリデーターのセットを持つという考え方です。 これがその仕組みです。

共有分散化

共有シーケンサーの本質は、アプリチェーンや L2 ごとに異なるバリデーターのセットを用意する必要がないことです。 その代わり、すべてのチェーンのブロックを順番に並べる、本当に効率的で分散型のバリデーターを持つことができます。 100の異なるアプリチェーンからのトランザクションを含むブロックを想像してみてください。 これは、各アプリチェーンの実行エンジンを処理できる必要があるため、シーケンサーを本当に肥大化させると思うかもしれません。

まあ、あなたはしません!

今日では、ほとんどすべてのシーケンサーが集中化されているため、シーケンサーは、トランザクションを収集し、注文し、実行し、その結果をL1に投稿する単一のアプリケーションと見なされています。 ただし、これらのジョブは複数のモジュラーコンポーネントに分離できます。 この説明のために、それらを2つに分けます。

1. 注文エンジン: これは、特定の順序でトランザクションを順序付ける役割を担います。 この順序が注文エンジンによって決定されたら、それに従う必要があります。 これは、L1でこの注文をコミットし、トランザクションが必要な順序で実行されたかどうかをL1検証者に強制的に確認させることで実施されます。
2. ロールアップエンジン:ロールアップエンジンは、基本的にロールアップが行う他のすべてのこと(ユーザーからのトランザクションの収集、実行、配達確認の作成、L1の状態の更新)です。 理想的には、これはより多くのコンポーネントに分割できますが、この投稿ではそれを避けます。

ここでは、順序付けエンジンは共有シーケンサーであり、ロールアップ エンジンは基本的にすべてのロールアップ ロジックです。 したがって、トランザクションのライフサイクルは次のようになります

共有シーケンサーは、基本的にロールアップ間でトランザクションを並べ替え、L1 にコミットします。 したがって、共有シーケンサーセットを分散化することで、基本的にそのシーケンサーセットにリンクされているすべてのロールアップを分散化します。 共有シーケンサーの動作の詳細については、Espresso の <a href="https://hackmd.io/ @EspressoSystems /EspressoSequencer>記事 17 を参照してください。

コンポーザビリティ

コンポーザビリティの大きな問題の1つは、トランザクションが他のアプリチェーンでいつ完了するかを理解し、それに応じてチェーンでアクションを実行することです。 ただし、共有シーケンサーでは、両方のコンポーザブル ロールアップがブロックを共有します。 したがって、トランザクションがロールアップ B でロールバックされると、ブロック全体がロールバックされ、ロールアップ A のトランザクションも元に戻ります。

さて、これは確かに言うは易く行うは難しに聞こえます。 こちらは。ロールアップ間の通信は、効率的かつスケーラブルである必要があります。 共有シーケンサーは、ロールアップの通信方法、クロスチェーンメッセージの外観、ロールアップのアップグレードへの対処方法などについて、適切な標準を考え出す必要があります。 これらは解決可能な問題ですが、複雑で解決するのは簡単ではありません。

開発者エクスペリエンス

共有シーケンサーは分散化の側面を抽象化し、クロスチェーンメッセージングを容易にしますが、共有シーケンサーと互換性を持たせるためにすべてのチェーンが従う必要のあるいくつかの標準がまだあります。 たとえば、すべてのロールアップ トランザクションは、シーケンサーが理解できる一般的な形式に変換する必要があります。 同様に、シーケンサーからのブロックは、関連するトランザクションをフェッチするためにフィルタリングする必要があります。 これを解決するために、共有シーケンサーは、定型コードを抽象化し、ビジネスロジック部分のみをアプリチェーン開発者に公開するロールアップフレームワークまたはSDKを考え出すと思います。

共有シーケンサーでアプリ チェーンがどのように表示されるかを示す図を次に示します

待てよ、またポルカドットだろ

Polkadotは、イーサリアムよりもずっと前にマルチチェーンの未来に取り組み始めました。 実際、彼らは5年以上前から取り組んでおり、Polkadotに精通している場合は、上記のデザインが基本的にPolkadotがすでに行ってきた多くのことを再発明していることに気付いたかもしれません。

リレーチェーン(共有分散化)

リレーチェーンは、基本的には上のシーケンス図のオーダリングエンジン+L1です。 リレーチェーン

1. すべてのパラチェーン(ロールアップ)でトランザクションを注文します
2. トランザクションが正しく実行されたことを確認します (zk 検証の代わりに、ロールアップの実行コードを実際に再実行して状態差分を検証します)

リレーは基本的に上記で説明した共有シーケンサーであることに気付いたかもしれません。 ただし、リレーチェーンも実行を検証する必要があるという事実を除いて(PolkadotはL1であるため)、イーサリアムに任せています。

XCM と XCMP

前のセクションで、すべてのチェーンが他のチェーンと相互運用するための独自の方法を構築した場合、すべてのチェーンで異なる標準とフォーマットですぐに肥大化すると述べました。 やり取りするすべてのチェーンについて、これらすべての形式を追跡する必要があります。 さらに、チェーンがアップグレードされた場合はどうなるかなどの質問にも答える必要があります。 しかし、これらの問題は、すべてのチェーンが従わなければならない基準を導入することで、エレガントに取り組むことができます。

ご想像のとおり、Polkadotはすでにこれを行っています。 XCMはメッセージング形式であり、XCMPはすべてのサブストレートが相互に通信するために使用できるメッセージングプロトコルです。 詳細は省きますが、こちらで読むことができます 5.

基板と積雲

Substrateは、Parityによって開発されたフレームワークで、ブロックチェーンの構築に使用できます。 Polkadotのすべてのパラチェーンは基質を使用していますが、基質は実際にはチェーンに依存しない方法で構築されています。 このフレームワークは、ブロックチェーンの一般的な側面をすべて抽象化するため、アプリケーションロジックに集中できます。 ご存知のように、MadaraはSubstrate上に構築されており、Polkadot、Polygon Avail、その他多くのプロジェクトも構築されています。 さらに、CumulusはSubstrateの上にあるミドルウェアであり、チェーンをPolkadotに接続できます。

先ほどと同じように、Substrate と Cumulus は、アプリケーションチェーンを構築して共有シーケンサーに接続できるロールアップフレームワークの代替と考えることができます。

リレーチェーン→共有シーケンサ
XCMおよびXCMP→コンポーザビリティ
ロールアップフレームワーク/スタック → Substrate と Cumulus

そう、またポルカドットの繰り返しです! これとは別に、PolkadotとParityには、SubstrateとPolkadotを構築して機能を追加し、よりスケーラブルにするための最も経験豊富で資金力のあるチームがいくつかあります。 このテクノロジーは、すでに何年も前から実戦でテストされており、箱から出してすぐに使える開発ツールが大量にあります。

イーサリアムにポルカドットを決済しますか?

ポルカドットがイーサリアムのずっと前にマルチチェーンの未来を構築し始めたのは事実ですが、今日の時点で、イーサリアムが最も分散化されたブロックチェーンであり、ほとんどのアプリと流動性が置かれている場所であることは否定できません。 しかし、すべてのPolkadot技術をイーサリアムのエコシステムに持ち込む方法があるとしたらどうでしょうか?

あるんだ！ 実際、私たちはすでにMadaraでこれを開始しています。 MadaraはSubstrateフレームワークを使用して、誰でもイーサリアム上に独自のzkを利用したL2/L3ソリューションを構築できるようにしています。 次に必要なのは、共有シーケンサーの形をしたPolkadotリレーチェーンです。 したがって、基本的には、Polkadotリレーチェーンを再利用できる場合ですが、

1. zkプルーフを介してL1で発生する検証部分を削除します
2. トランザクションの順序を L1 にコミットします。
3. ノードとコンセンサスアルゴリズムを最適化してTendermint/HotStuffをサポートする

前述したように、共有シーケンサーを取得できます。 明らかに、これは言うは易く行うは難しです。 しかし、この道は、シーケンサー、標準、フレームワークをゼロから再構築するよりも実用的であると考えています。 Polkadotは、チェーンにとらわれない方法ですでに多くの問題を解決しており、イーサリアムに借りることができます。 副産物として、

1. Substrateの構築と教育を世界に広め続ける活発な開発者集団
2. 活発な開発者ツールセットと強力なコミュニティ
3. 多くのアクティブなパラチェーンは、希望すればイーサリアムに落ち着くこともできます(最近、AstarがPolygon CDKで同じことをしているのを見ました)

結論

この記事を書いた主な目的は、StarknetとEthereumのより広範なエコシステムの中で議論を開くことです。 共有シーケンシングモデルは、Starknetだけでなく、その上に構築することを検討しているすべてのアプリチェーンの分散化において重要な役割を果たすと感じています。 アプリチェーンのテーゼとzkスケーリングに自信がある限り、共有シーケンシングモデルの徹底的な分析は避けられません。 さらに、Madaraが生産に向けて動き出し、Starknetが分散化に取り組み始めた今、このトピックに取り組むことが重要だと感じています。 したがって、これを読んでいるすべての人に、このトピックに関するフィードバック/提案を残してください。 あなたの考えを読むのを楽しみにしています!

虫垂

ポルカドット vs コスモス

Cosmosは、Polkadotと同様に、長年にわたってマルチチェーンの未来を解決してきました。 その結果、Cosmos SDKとIBCで多くの開発が行われ、Cosmosエコシステムの上に構築される多くのアプリチェーンも見られます。 したがって、このアプローチにはCosmosも考慮するのが妥当です。 このトピックに関する私の個人的な見解は、Polkadotは共有シーケンサーの問題を解決するため、より関連性が高いのに対し、Cosmosは各アプリチェーンが独自のバリデーターセットを構築する必要があるということです。 さらに、Substrateは常にチェーンにとらわれない方法で構築されており、開発者はコンセンサスアルゴリズムやPolkadotエコシステムを前提とせずにブロックチェーンを構築できます。 これが、MadaraにSubstrateを選んだ理由でもあります。 しかし、そうは言っても、コスモスでの私の経験は限られているので、より経験豊富な人々からこれについてもっと聞いてみたいです! また、2 つのネットワークの比較の詳細については 、こちらをご覧ください

免責事項：

1. この記事は[starknet]からの転載です。 すべての著作権は原作者[apoorvsadana]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。