Minaプロトコルのアップグレードプロセスについて
この記事は「Mina’s Berkeley Upgrade – What to Expect」を日本語訳したものです。
Minaプロトコルについて
Mina は参加者によって動かされる世界最軽量のブロックチェーンです。Minaは、ブルート コンピューティングの力を適用するのではなく、高度な暗号化と再帰的な zk-SNARK を使用して、ツイート数個分のサイズである約 22 kb のブロックチェーン全体を設計します。これはゼロ知識スマート コントラクト (zkApps )の効率的な実装と簡単なプログラム可能性を可能にする最初のレイヤー 1 です。独自のプライバシー機能とあらゆる Web サイトに接続できる機能を備えたMinaは、現実世界と仮想通貨、そして私たち全員が値する安全で民主的な未来の間にプライベート ゲートウェイを構築しています。
Minaの主要なメインネット アップグレードへのカウントダウンは順調に進んでおり、コミュニティの投票により、プロトコルに 3 つの重要な機能が導入されます。
Minaの主要なメインネット アップグレードへのカウントダウンは順調に進んでおり、コミュニティの投票により、プロトコルに 3 つの重要な機能が追加されます。
エコシステムの貢献者は広範なテストに参加し、ネットワークを限界まで押し上げて、ここまで到達しました。テストの最終段階であるアップグレード メカニズム テスト (UMT)が完了し、チームはMinaプロトコルのメインネットにアップグレードを展開する前に、テストと実験用に設計された環境である Devnet をアップグレードする準備を進めています。
このプロセスには多くの変動要素があり、多くのエコシステム貢献者間での高度な調整が必要です。以下に、Devnet 環境とMinaプロトコルのメインネットの両方で、アップグレード プロセス全体で予想されることの概要を示します。
アップグレード プロセスは、アップグレード前、アップグレード、アップグレード後の 3 つのフェーズに分類できます。
アップグレード前:
アップグレード前リリース: ノード オペレーターと取引所は、o1Labs によって公開されたアップグレード前ビルドに更新する必要があります。このビルドには、アップグレードを開始するために必要な、事前に決定された停止スロット (ネットワークが新しいトランザクションの受け入れを停止する時期と、ネットワークがブロックの生成を停止する時期の両方) が含まれています。フォークが成功するには、ステークの大部分 (アクティブ ステーク* の約 75%) をアップグレード前のビルドにアップグレードする必要があります。
注: このリリースには、アップグレードの準備状況の重要な指標であるアップグレードされたステークに関するレポートをサポートするために、NodeStats の軽量バージョンがデフォルトで組み込まれます。GitHubでリリース ノートが公開されたら、これと収集されるデータの詳細を読むことができます。
アーカイブ ノードの移行: 並行して、アーカイブ ノードのオペレーターは移行プロセスを開始する必要があり、停止ネットワーク スロットに達するまでこれを段階的に続行します。この時点でコミュニティ アーカイブ ノード オペレーターが移行を開始できるようにドキュメントがリリースされます。
*ネットワークアクティブステークは、過去10,000ブロックのうち少なくとも1ブロックを生成したMinaブロックプロデューサーに委任されたステークの合計です。
アップグレード中 (12 時間のダウンタイムウィンドウ):
アップグレード プロセス中に、ネットワークのダウンタイムが 12 時間発生します。
0 時間目: 過半数のステークがアップグレードされると、所定の時点でトランザクション停止スロットに到達します。このスロットから開始すると、アップグレードされたステークによって生成されるすべてのブロックは空になり、トランザクション (支払い、委任、コインベースなど) は含まれず、トランザクションを含むブロックは受け入れられなくなり、動作が期待どおりであることが確認されます。
ブロックプロデューサーにとって、停止ネットワークスロットに到達するまで少なくとも 1 つのノードを実行し続け、どのブロックからアップグレードするかについてネットワークが合意に達することが重要です。 o1Labs のチームは、アップグレード後のリリース ビルドのためにこれらのノードからネットワーク データも収集します。注: この期間中のブロックは空になるため、予定されたネットワークのダウンタイム中はブロック報酬は生成されません。
5 時間目: トランザクション停止スロット (100 スロットに相当) から 5 時間後に、ネットワーク停止スロットに到達します。この時点で、アップグレードしたブロックプロデューサーは新しいブロックを生成しなくなり、新しいブロックは受け入れられなくなり、チェーン密度が低下すると予想されます。
注: ノードをアップグレードしていないブロックプロデューサーには停止スロットが設定されていないため、ネットワークによって拒否されるブロックを生成する可能性があります。このため、アップグレード プロセスが開始される前に過半数のステークがアップグレードされていることを確認することが重要です。
5 ～ 11 時間目: この期間中、o1Labs は、フォーク ブロックで状態をエクスポートすることにより、アップグレード後のパッケージ、つまりフォーク後に実行する予定のビルドを公開します。この状態は、ビルドのリリースの準備が整う前に、台帳の状態および移行されたアーカイブ ノードとともに検証されます。並行して、チームはネットワークの立ち上げの準備を進め、シード、アーカイブ ノード、および cron ジョブをデプロイして、ノードとネットワークの健全性を検証します。
注:新しいバークレー互換台帳をフォーク ブロックの台帳と照合して検証したいノード オペレーターは、検証ツールを利用できます。
11 時間目: アップグレード後のリリースにはタグが付けられ、ブロックの実稼働が再開される前にアップグレードを開始するためのメモがコミュニティと共有されます。リリース ノートはGitHubで入手できるようになります。
アップグレード後:
12 時間目: アップグレード後のリリースが利用可能になってから 1 時間後、最初の バークレー ブロックが生成される予定です。
ネットワーク監視:アップグレードが完了し、最初のバークレー ブロックが生成されると、チームは広範なネットワーク監視を実施して、チェーンの品質が期待通りであることを確認し、過半数のステークがバークレー後のビルドにアップグレードされていることを確認します。
主な役割
Exchange：
サービスの中断を最小限に抑えるために、Exchange は要求に応じて、Mina ノードをアップグレード前のバージョンにアップグレードする必要があります (事前定義されたスロットで空のブロックの生成が開始されます)。ダウンタイム期間中 (トランザクション スロットの停止後) に送信されたトランザクションは、アップグレード後のチェーンには存在しません。ダウンタイム期間中はMINAの入金および/または出金を停止することをお勧めします。
トランザクションに署名するために非推奨の o1labs/client-sdk ライブラリに依存する取引所は、メインネットのアップグレード前に新しいライブラリmina-signerにアップグレードする必要があります。
アーカイブ ノード データベースに直接依存する交換は、その統合がデータベース スキーマの変更によって影響を受けるかどうかも評価する必要があります。
アップグレード後に O(1)Labs によって提供されるアーカイブ ノード データベースのエクスポートに依存したくない取引所は、ここにあるアーカイブ ノード移行プロセスを実行する必要があります。
ご質問やサポートが必要な場合は、専用の Telegram または Discord チャネルを通じてMina財団にご連絡ください。
ノードオペレーター:
ノード オペレーターは、最新情報についてメールと #mainnet-updates Discordチャネルを注意深く監視する必要があります。電子メールの受信に登録したい場合は、次のフォームに記入してください: https://forms.gle/sBPNp7hgrZEghdvNA
ノードのリリースに関する最新情報については、こちらのGitHub ページをご覧ください。
アップグレード プロセスのタイムラインをよく理解し、いつアップグレードが必要になるかを理解してください。
アップグレード プロセス中、ブロック プロデューサーは、stop-network-slot に達するまで少なくとも 1 つのノードをオンラインに保つ必要があります。注意してください: この期間中のブロックは空になるため、予定されたネットワークのダウンタイム中はブロック報酬は生成されません。
主要チャネル
最新のステータスとタイムラインの更新については、主要なチャンネルに注目してください。実行中の異常な動作を報告するには、GitHub: https://github.com/MinaProtocol/mina/releasesで報告してください。
ご質問やその他の問題については、Mina のDiscordサーバーのチームにお問い合わせください。