Polkadot デプロイメントポータル：なぜプロジェクトは L2 になるのではなく、Polkadot へのデプロイを選ぶのか？

過去、Polkadot上でRollupをデプロイすることは決して簡単なことではありませんでした。なぜなら、システムが柔軟であればあるほど、デプロイのプロセスも複雑になるからです。SDKのアップデート、スロットオークション、ガバナンスやランタイムのアップグレードなど、どの段階もチームにとって大きな課題となり得ます。

この状況を変えるために、Parityは今年、Polkadot Deployment Portal（PDP）をリリースしました。これは構築・デプロイ・接続までを一貫して提供する「ワンストップポータル」です。その目的は明確で、参入障壁を下げ、プロセスを簡素化し、どんなチームでもPolkadot上で自分たちのRollupを迅速かつ安定して立ち上げ、運用できるようにすることです。

本記事では、Parityのプロダクト開発責任者であるSanti Balaguer氏が、ここ数年のPolkadotデプロイ体験の進化を振り返り、PDPの設計思想を解説し、このツールがどのようにRollupの立ち上げ方を変えていくのかを共有します。

Polkadotでのデプロイ体験：柔軟なシステムほど複雑になる

Jay：Space Monkeysへようこそ。本日はParityでプロダクト開発を担当しているSanti Balaguer氏をお招きしています。今日はPDPについて話しますが、PDPの正式名称は？

Santi：Polkadot Deployment Portal、つまりPolkadotデプロイメントポータルです。

Jay：PDPを始める前の4〜5年間、Parityで主にどんなことを担当していましたか？

Santi：これまでずっと開発者コミュニティと密接に関わり、主にPolkadot上でパラチェーンやRollupの立ち上げをサポートしてきました。あなたが言った通り、パラチェーンがまだローンチされていない頃からParityにいました。

Jay：よく関わってきたプロジェクトの中で、私たちがよく知っているものはありますか？

Santi：以前はSubstrate Buildersプロジェクトを担当していて、そこには多くの有名なプロジェクトがありました。特に印象に残っているのはHydrationチームです。Jakubがデモをしたとき、彼らのOmnipoolのアイデアやHydrationが解決しようとしている問題について紹介してくれました。彼は「money printer goes brrrr」（印刷機がフル稼働）の有名なミーム画像を使って、なぜ新しいソリューションを提案する必要があるのかを説明していました。今でもよくJakubとこのジョークを言い合っています。

Jay：面白いですね。多くのプロジェクトがPolkadotで成功したのを見てきたと思いますが、彼らの悩みもたくさん聞いてきたはずです。ここ数年でPolkadot上でプロジェクトをデプロイする際に最も頭を悩ませた点について教えてもらえますか？

Santi：もちろんです。Polkadot自体が非常に複雑なシステムなので、きちんと理解しないとプロジェクトがスムーズに動きません。この複雑さは実は柔軟性から来ているのです。柔軟なシステムほど複雑になりがちです。

初期の頃は、Polkadot上でパラチェーンを動かすには、まずSDKのさまざまな「破壊的アップデート」に対応しなければなりませんでした。当時はPolkadot SDKはなく、Substrateだけで、今とは違っていました。開発環境を整えた後は、コミュニティで投票を集め、スロットオークションに参加する必要がありました。オークション自体も非常にチャレンジングで、十分な支持を得る必要があり、結果は最後の瞬間まで分かりません。仮に勝てても、実際にパラチェーンがローンチするまで3ヶ月待たなければならず、スロットは2年間しか借りられません。だから当時は技術開発とコミュニティの動員の両方に全力を尽くさないと、Polkadot上で居場所を得ることはできませんでした。

Jay：そうですね。その後、ここ数年で体験はかなり改善されました。その変化の過程について話してもらえますか？

Santi：もちろんです。Parityは特にPolkadot SDKの破壊的アップデートを減らすことに大きな努力をしてきたと思います。

今でもアップデートはありますが、以前と比べてはるかに安定しており、バージョン間の互換性も良くなっています。今では開発者も自分が使っているSDKバージョンに安心して依存できます。中には古いSubstrateバージョンを使っているパラチェーンもありますが、それでもPolkadot上で正常に動作しています。

また、Cortimeの導入も（それ自体に一定の複雑さはありますが）、開発者の参入障壁を大きく下げました。これにより、より多くの人がPolkadotに挑戦しやすくなり、参入障壁が大幅に下がったと思います。この点はできるだけ活用すべきだと考えています。

なぜ今、プロジェクトはPolkadotにデプロイするのか？なぜEthereumのL2ではないのか？

Jay：当時は多くの課題がありましたが、今はかなり解決されています。では、なぜ今プロジェクトはPolkadotにデプロイするのでしょうか？なぜEthereumのL2や独自のL1を選ばないのでしょうか？その理由は？

Santi：とても興味深い質問ですね。まず、コミュニティとしてこの点についてもっとコミュニケーションやプロモーションを行うべきだと思います。個人的な理解と意見ですが、Polkadotは最初からRollupをネイティブにサポートするよう設計された唯一のブロックチェーンです。開発者に他の場所にはない多くのインフラを提供しています。

• 例えば、PolkadotはRollupに非常に大きなデータ可用性レイヤー（data availability）を提供していますが、Ethereum L2の場合は外部システムや「blob」に依存する必要があります。

• また、パラチェーン間のネイティブなメッセージ伝達（クロスチェーン通信）は他のRollupにはありません。この機能がないと、システムのセキュリティが損なわれます。

• パフォーマンス面でも、Spammingが検証したように、PolkadotのRollupのTPSは業界でも非常に優れています。

• さらに、弾力的なスケーリングという点でも、Polkadotは今唯一、需要に応じてインフラを随時拡張・縮小できるシステムです。例えば、Mythicalが新しいゲームをリリースし、最初の1週間でユーザーが10倍に急増する場合でも、ほとんど何も変更せずにそのトラフィックをすぐにサポートできます。

これまで「パラチェーンとRollup」について議論してきましたが、Polkadotを主役にできなかったのは少しもったいなかったと思います。でも、今ならまだ間に合います。再びPolkadotを舞台の中央に戻すチャンスがあります。

Jay：そうですね。以前あなたも言っていましたが、Polkadotは基盤アーキテクチャの設計段階からRollupのために準備されていました。ただ最初はそれをRollupとは呼んでいませんでした。

Santi：その通りです。そしてもう一つ見落としがちな点は、共有セキュリティです。ブロックチェーンの発展の流れを振り返ると、最初はbitcoin、次にEthereumが登場しました。その後、さまざまな新しい「Ethereum」が登場し、「自分のチェーンはA、B、Cの特徴があるからより優れている」と宣伝しました。しかし、新しいチェーンのセキュリティを確保するのは非常に難しいのです。十分に大きくて強力なバリデータセットが必要で、それは簡単なことではありません。

その時、Gavinは「なぜセキュリティをサービスとして提供し、基盤レイヤーに組み込まないのか？」と考えました。これがPolkadotのユニークな点です。Polkadotは共有セキュリティを提供するだけでなく、これらのRollup間で効率的な通信を実現できます。これはPolkadotが特に得意とするところです。

PDPのアイデアはどうやって生まれたのか？

Jay：素晴らしいですね。もしRollupがネイティブのデータ可用性（しかも大規模なもの）を内蔵し、他のプロジェクトを寄せ集めることなく、さらにTPSやスループットも強力で、他のRollupともシームレスに通信できるなら、Polkadotは確かに魅力的です。しかしPDPが登場する前は、パラチェーンのデプロイは非常に複雑で時間もかかりました。そもそもPDPというツールを作ろうと思ったきっかけは何だったのでしょうか？

Santi：実はこのアイデアはしばらく前から温めていましたが、本格的に動き始めたのは昨年11月です。

そして今年の3〜4月ごろからチームがフルタイムでこのプロジェクトに取り組み始め、今では急速に進展しています。このアイデアは長い間温めてきたもので、業界内にもすでに似たようなソリューションがいくつかあります。例えばEthereumエコシステムにはConduitやGelatoがありますし、Polkadot側にも以前Tanssiがありましたが、今は主にEthereumにシフトしています。考え方は似ています。

Polkadot側でなかなか実現しなかったので、自分たちでやることに決めました。Polkadotについてより深く理解しており、開発者がより簡単にプロジェクトをデプロイできるようにする方法も分かっているからです。これがPDPが解決しようとしている目標です。

開発者の代わりに決断はしない、ガイダンスと選択肢を提供する

Jay：PDPは具体的にどんな人たちを対象にしていますか？Polkadot初期には、最初からRollupを作ろうとするプロジェクトもありましたが、実際はスマートコントラクトで十分な場合もありました。どんなプロジェクトが本当に自分のRollupを持つのに適していると思いますか？

Santi：良い質問ですが、決まった答えはないと思います。今でも、実はコントラクトで十分なプロジェクトも見かけます。しかし、プロジェクト側が独立性を求めていたり、他のチェーンのインフラに依存したくなかったり、将来的に非常に大きなスループットを見込んでいたりする場合は、最初からRollupを選ぶこともあります。このような理由で独自チェーンやより高いインフラ独立性が必要になることがあります。

例えばHydrationのOmnipoolも、コントラクトで十分かどうか議論できますが、私はそうではなく、チェーンとして作るのが合理的だと思います。一方、EthereumのUniswapは最初はコントラクトでしたが、後に独自チェーンを作りました。今本当にチェーンが必要かどうかは分かりませんが、彼らには独自のビジネス上の考慮があります。

つまり、絶対的な答えはなく、技術とビジネスの両方が動機となっています。私にとって最も重要なのは、開発者の代わりに決断を下すのではなく、ガイダンスを提供し、彼ら自身が選択できるようにすることです。Rollupでもコントラクトでも、簡単に試せて実験できるべきです。

PDPの全プロセス体験を公開：構築・デプロイ・アクセスまで、Rollupの立ち上げがこんなに簡単に

Jay：では、チームが決断したとしましょう。自分たちで決めた場合でも、Magenta LabsやBDチームのガイダンスを受けた場合でも、最終的にPolkadot上でRollupをデプロイすることに決めたとします。PDPに入った後、どんな体験ができるのでしょうか？今のデプロイの流れはどうなっていますか？

Santi：PDPの設計では、プロセスを3つの主要な段階に分けています：Build（構築）—Deploy（デプロイ）—Access（アクセス）、この3つは相互に関連しています。

「構築」段階の核心は「どうやって始めるか」です。私たちの考えでは、最良の方法はランタイムテンプレート（runtime templates）を使うことです。現在、OpenZeppelinが関連テンプレートを開発中で、Pop CLIチームやROGチームもこの分野で取り組んでいます。Pop CLIは自分のPCで使えるツールで、Rollupのコーディングに使えます。私たちは彼らと協力し、PDPの他の2つの段階（デプロイとアクセス）とも連携させました。

例えば、Pop CLIでRollupを構築した後、直接PDPに接続してRollupをデプロイできます。私たちはこのように設計し、実装しました。これにより、開発者はCLIで全プロセスを完了でき、Web2のHerokuやVercelのようにCLIを持っています。CLIに慣れているならそのまま使えますし、完全にグラフィカルなインターフェースでも進められます。どちらでもOKです。

Jay：つまり、テンプレートで構築する以外にも、Pop CLIで構築してデプロイできるということですね。PDP自体は開発者の選択をサポートしますか？それとも単なるツールで、チーム自身が操作する必要がありますか？

Santi：両方です。PDPはセルフサービスツールとして開発者が自由に使えるようにしたいですが、重要な問題が発生した場合は私たちがサポートし、必要な助けを提供します。もちろん、誰かが自分で試したい場合はそれも全く問題ありません（笑）。

Jay：面白いですね。具体的なテンプレートの例をいくつか挙げてもらえますか？お気に入りはありますか？

Santi：例えば、ROGチームにはすぐに使えるPilot Reviveテンプレートがあります。OpenZeppelinにはFrontierテンプレートがあり、EVM機能を持つチェーンを動かしたい場合はこれが使えます。

Jay：クールですね。いくつかのスマートコントラクト関連の選択肢があるということですね。

Santi：その通りです。スマートコントラクトを持たないテンプレートもあります。例えば、資産管理専用のチェーンを作りたい場合、特に現実世界資産（RWA）関連のプロジェクトには対応するテンプレートもあります。とにかく、スタート段階では多くの選択肢があり、そこからさらに拡張できます。

Jay：テンプレートに自分で新しいPalletを追加できますか？

Santi：最初はできません。まずテンプレートからスタートし、その後ランタイムアップグレードを段階的に案内します。この方法でチームがプロダクトマーケットフィットを徐々に見つけられるようにしたいのです。この設計はとても面白く、今まさに注力している機能の一つです。現在、Puppetチームが開発した非常に面白いツールを使っていて、アップグレード予定のruntimeと現在デプロイ済みのruntimeを比較し、どこが変わったか、どこが開発者に影響するか、注意点をレポートで知らせてくれます。

Jay：そうそう、最近その機能を統合したのを見ました。素晴らしいですね。

Santi：はい、今週やっと完成しました。これでランタイムアップグレードのレポートが得られ、プッシュする内容が期待通りか確認できます。今後はさらに、バックグラウンドでいくつかのブロックをシミュレーション実行し、新しいruntimeをテストする機能も追加したいと考えています。すべて正常なら「リリース可能」と表示し、問題があれば「テストに失敗したので再確認を」と知らせます。これでアップグレード時のミスを防げます。Polkadotの強みの一つは柔軟なランタイムアップグレードをサポートする点なので、チームはこれを活用して素早く反復し、プロダクトマーケットフィットを見つけられます。

Jay：ちょっと待ってください。この部分はもう「デプロイ」段階に入っていますか？構築からランタイムまでの話はデプロイに含まれますか？

Santi：そうですね、ここは少し重なっています。構築は主にテンプレートから始める部分、デプロイは基盤インフラに関わる部分です。以前は自分たちでDevOpsチームを組んでcollatorノードを立てたり運用したりする必要がありましたが、今は最初の段階ではそれを気にしなくていいです。プロジェクトが成長し資金やリソースができたら、自分たちで運用チームを作って移行もできますし、その際も私たちがサポートします。でも最初はこれらを私たちが引き受けます。

Jay：今は誰がそれをやっているのですか？

Santi：現在はParityが提供しています。ただし、将来的には開発者がどのクラウドプラットフォームにデプロイするか自由に選べるようにしたいと考えています。IBP（インフラプロバイダー）も選択肢になるかもしれませんが、この抽象化には少し時間がかかります。今は体験を確保するためにParity自身のインフラで提供していますが、最終的にはより多くの選択肢を開放します。

さらに、BDU（Basic Deployment Unit、基礎デプロイメントユニット）というコンセプトも導入しました。プロダクションネットワークにRollupをデプロイする場合、標準化されたインフラを一式デプロイします。これには3つのcollatorノードが含まれ、そのうち1つはRPCエンドポイントとして利用でき、さらにindexerも提供します。

現在、Subscanと協力しており、彼らのオープンソースソリューションをPDPに統合する予定です。これにより、indexerだけでなくブロックエクスプローラーも利用でき、これまでチームが時間をかけて構築していたものをワンストップで提供できるようになります。この設計はとても良いと思います。

Jay：すごいですね。これは構築に含まれますか？

Santi：これはデプロイです。

Jay：分かりました。この段階でRollupはすでに稼働し、ブロック生成も始まっているのですね？チームもランタイムアップグレードで試行錯誤しながらプロダクトマーケットフィットを見つけられる？次は最後の「アクセス（Access）」ですね？これは何ですか？

Santi：はい！AccessこそがPolkadotのハイライトであり、Rollupチームに独自の価値をもたらす部分だと思います。構築とデプロイはランタイムやインフラに関わる部分で、皆ある程度すぐに慣れることができますが、Polkadotの特徴を本当に活用することで差別化が生まれます。例えばCoretimeはAccessの一部で、PDPは事前にCoretimeを購入しておき、開発者がRollupをデプロイする際にすぐ使えるようにしています。これにより、28日間待たずにすぐにブロック生成を開始でき、ユーザー体験が大幅に向上します。

Jay：もし私がデプロイしたい場合、自分でPDPでCoretimeを購入する必要がありますか？

Santi：私たちが代わりに購入し、その後費用を請求します。実際、Coretimeにはさまざまな選択肢を用意しています。最初から全力で行きたい場合はフルコアを使えますし、「スライスコア」というコアの一部だけを使うこともできます。まずは少額で試してみたい場合は一部だけ使うことも可能です。

Jay：この機能はすでに使えますか？

Santi：PDP上ですでに利用可能です。現在、WestendとPaseoネットワークで稼働しています。Paseoは最近スライスコアを導入しましたし、Westendではコアの一部を直接取引できます。デメリットはブロック生成時間が長くなることですが、メリットは参入障壁が大幅に下がり、ほぼ低コストで試せることです。効果が良ければフルコアにアップグレードし、6秒ごとにブロック生成が可能です。これらはすべてPDP上で完結します。ただし、接続メカニズムについてはPolkadotの有効活用方法を引き続き解決する必要があります。現在、Polkadot Hubが重要な機能モジュールとしてまもなくリリースされる予定で、私たちはこれに大きな期待を寄せています。