ソラナ、10月21日にアルペングローアップグレードを設定、150ミリ秒の最終性目標

ソラナの開発者は、アルペングローコンセンサスアップグレードを10月21日に予定しており、約150ミリ秒の最終性を目指しています。バリデーターやアプリケーションオペレーターには、メインネットの引き渡し中に変更に備えるよう求めています。

要約

• ソラナのアルペングローアップグレードは10月21日に予定されており、約150ミリ秒のトランザクション最終性を目指しています。
• Quicknodeは、引き渡し中に短時間のトランザクション停止とデータストリームの中断の可能性について警告しています。
• バリデーターは、互換性のあるソフトウェアを使用し、0.8 SOLの入場料のために投票アカウントに資金を提供する必要があります。
• 一部のRPCノードは、コンセンサスに直接参加しているバリデーターよりも遅れて最終性情報を受け取る可能性があります。

Quicknodeのメンテナンス通知では、水曜日が計画されたアクティベーション日とされていますが、最新の更新では、元の14:50 UTCの見積もりがブロック生成の進行に伴い、13:20 UTCに前倒しされる可能性があると警告しています。プロバイダーは、オペレーターに13:00 UTCから準備を整えるよう求めており、アクティベーションの約20分後にコンセンサスの引き渡しが行われる予定です。

ソラナ財団の現在のアップグレードページでは、変更がエポック1064にあり、メインネットはまだアクティブではないと記載されています。最新の見積もりでは、エポックの開始が13:20 UTC近くになるとされており、エポックの境界が固定された時計の約束ではなく、関連するトリガーとなります。

ソラナアルペングローは最終性を目指し、より速い実行ではない

アンザの設計の下で、ボトールはタワーBFTの投票と最終性のロジックを置き換えます。目標は、通常のネットワーク条件下で約150ミリ秒ですが、すべてのウォレット、取引所、または取引アプリケーションがその期間内に完了したトランザクションを表示することを保証するものではありません。

財団は、トランザクションの実行、プログラムの動作、手数料メカニズムは変更されないと述べています。一般のユーザーは、トランザクションの署名や承認方法を変更する必要はなく、別のロトールデータ配信アップグレードは後のリリースに予約されています。その文書は、コンセンサスの展開を、ネットワークがブロックを生成する頻度を管理するスロットの期間の以前の短縮から分離しています。

Quicknodeの技術概要では、同時に動作する2つの投票パスが説明されています。一方は、80%のバリデーターが参加する場合に単一のラウンドでブロックを最終化できますが、もう一方は、参加が60%に達した場合に2回目のラウンドを使用します。

プロバイダーは、そのプロセスをユーザーがすでに見る初期確認から区別しています。その概要によれば、アプリケーションは楽観的な設定の下で通常2〜3秒以内に確認を表示し、古いシステムが約13秒で完全な最終性に達する前に表示されます。

10月の展開は、アルペングローをアガベ4.3にリンクさせた以前のロードマップに続くものです。8月14日の報告では、アルペングローコードがテストのためにアガベ4.2に存在していたことが文書化されており、そのリリースでメインネットのアクティベーションを承認することはありませんでした。

9月26日までに、アップグレードは前日のテストネットの移行後にデブネットに到達しました。アプリケーションチームは、その後、ネットワークがユーザーの資金を扱う前に新しいコンセンサスの動作を確認できました。

トレーダーは引き渡し中に短時間の中断に直面

Quicknodeは、ネットワークがコンセンサスシステムを変更する間、新しいトランザクションがブロックに入るのを一時的に停止すると警告しています。その通知は、数秒間の停止が続くことを説明しており、移行に時間がかかる場合は、より長い中断が発生する可能性があります。

トランザクションの提出は、一時的に「ノードが不健康」というプレフライトエラーを返す可能性があるとプロバイダーは述べています。イエローストーンデータストリームは一度切断される可能性があり、最初に処理されたコミットメントを使用するサブスクリプションは、確認に達しないスロットを表示することがあります。

メンテナンス通知は、元に戻すことができないデータのために確認済みまたは最終化されたコミットメントを推奨しています。Quicknodeは、既存のソラナエンドポイントはそのままにしており、チームは変更全体を通じてネットワークを監視すると述べています。

プロバイダーの技術概要では、迅速な不可逆的決済が金融アプリケーション、企業の財務移転、リアルタイムサービスに関連しています。この文書では、提案されたコンセンサスアーキテクチャの機能としてこれらの使用例を示していますが、個々の取引プラットフォームが稼働日当日に新しい決済ポリシーを採用するかどうかは確立されていません。

バリデーターの準備にはソフトウェアとアカウント資金が含まれます

ソラナ財団の現在のチェックリストでは、バリデーターはエポック1064の前にAgave、Jito-Solana、またはHarmonic Salsaのバージョン4.3.2を実行するよう指示されています。同じガイダンスによれば、FiredancerとFrankendancerは移行中はサポートされていません。

オペレーターは、バリデーター入場チケットをカバーするために、投票アカウントに賃貸免除の最小額を超えて少なくとも0.8 SOLを保持する必要があります。最初の料金はエポック1065への参加に対して支払われ、未払いの料金は次のエポックでバリデーターが投票したりブロックを生成したりすることを妨げます。

ガバナンスの承認はこれらの運用要件に先立ちます。この提案は2025年9月に98.27%の支持票で通過したと、完了した投票の報道によって示されています。参加はステークの52%を表しているため、承認率は全バリデーター人口ではなく、投票された票を示しています。

その以前の投票では、コンセンサスの大規模な見直しの背後にある提案SIMD-0326が承認されました。現代の報告では、1.05%が反対、0.69%が棄権したと記録されており、発表された数字には小さな丸め誤差が保持されています。

RPC配信は150msの目標に遅れる可能性があります

Anzaのオペレーター文書では、コンセンサスメッセージが通常、承認されたバリデーター間で循環することが説明されています。デフォルトの配信パスを使用する未ステークノードは、後のブロックに運ばれる証明書から最終性を学び、通常は生成されたブロック間隔を加算します。

スキップされたり遅延したりしたブロックは、その待機時間を延ばす可能性があります。承認されたバリデーターと提携したノードは、メッセージを直接受信できますが、両者間のネットワーク遅延は配信時間の一部として残ります。

9月のdevnetの報道では、インデクサーとエクスプローラーのための別々の変更が文書化されました。候補ブロックは確認されるまで分離されている必要があり、バリデーターの参加データは通常の投票トランザクションからブロックデータに添付された証明書へと移行します。

その報告によれば、投票トランザクションを削除すると、ユーザーの支払いと取引の数が一定であってもダッシュボードの合計が変わります。両方のカテゴリをカウントするサービスは比較をリセットする必要があり、バリデーターの投票を追跡するシステムは置き換えられた証明書データを読み取る必要があります。