著者: ゴールデン ファイナンス ジェイソン**Jinjin Finance Blockchain、6 月 10 日** 今週、Arbitrum のソーター コードのバグにより、トランザクションをバッチで送信するネットワークの機能が短時間中断され、メイン チェーンでトランザクションを確認できなくなりました。その後、この脆弱性は修正され、トランザクションのバッチ送信機能が復旧しました。 6 月 10 日、Arbitrum Foundation は Arbitrum sorter のバグに関する事後分析レポートをリリースしました。次に、このバグ イベントによってユーザーの資金が失われない理由を確認してみましょう。**アービタラムソーターのバグイベントタイムライン**1. 2023 年 6 月 7 日の 06:04:53、Arbitrum Collator L1 ノードの一時的な問題のため、バッチ発行者は L1 状態ビューを更新できませんでした。根本原因の問題により、Arbitrum ソーターは以前の L1 ビュー ブロック番号の状態のクエリを試行し続けました。これは、一時的な L1 ノードの問題が自動的に解決した後でも、バッチ パブリッシャーは古い L1 ブロック番号の状態のクエリを試行し続け、L1 ノードはアーカイブ ノードではないためその状態を持たなくなることを意味します。2. 2023 年 6 月 7 日の 09:38:28 に、Arbitrum のバッチ ポスターは、設定された最大キュー トランザクション制限 (256) (メモリプール制限と同じ) に達したため、トランザクションの公開を停止しました。この制限に達しない場合、一括投稿は通常どおり続行されます。3. 2023 年 6 月 7 日午前 11 時 09 分、未公開のバッチが原因で、新しいバッチを確認するために Sequencer Inbox スマート コントラクトでアラートがトリガーされ、警告が Slack チャネルに送信されました。4. 午前 11 時 10 分、最近のバッチ リリースがなかったため、ログベースのアラートがトリガーされ、重大レベルのアラートが Slack チャネルに送信されました。5. 午前 11 時 13 分、コミュニティ チームのメンバーが SRE チームのメンバーとともに PagerDuty を開始しました。SRE チームは直ちにインシデントを認識し、対応を開始しました。6. 午前 11:19:02 に、SRE チームはバッチ ポスターを再起動しましたが、前述のキューに入れられるトランザクションの最大制限により、バッチ ポスターはトランザクションを公開できませんでした。 SRE チームはこの問題に気づき、問題を軽減するためにサードパーティの L1 RPC プロバイダーへの切り替えを開始しました。7. バッチ ポスターの開始から 5 分後の午前 11:24:16 に、L1 状態ビューが更新され、トランザクションの最初のバッチが公開されました。8. 午前 11:25:09 に、SRE チームが既にこの変更を開始していてバッチ処理に気付かなかったため、バッチ ポスター構成がサードパーティの L1 RPC プロバイダーを使用するように変更され、再起動されました。再起動後も、バッチ トランザクションは引き続き発生します。9. バッチ ポスターの開始から 5 分後の午前 11:30:21 に、L1 状態ビューが更新されました。これにより、L1 状態が同期されなくなりました。これが問題の根本原因でもありました。 L1 状態は最終ブロック番号 17428199 に更新されましたが、その状態に保存されている最終ブロックではなく、その時点での最新ブロックに対応する最新のノンス 178078 が使用されたため、Redis 内のキューに入れられたすべてのトランザクションがワイプされました。 、Redis はこれらのトランザクションを確認済みであると見なすためです。10. 午前 11:30:26 に、バッチ投稿者が新しいバッチを投稿しました。 Redis は、何を公開するかを決定するために L1 状態ビューに依存しますが、前述したように、この時点では Redis キューは空であり、L1 状態は正しくなく、バッチは状態 178078 の乱数で公開されましたが、無関係なブロック番号 17428199 を使用して発行されるバッチにより、シリアル番号 229209 の古いバッチが発行されます。このバッチは実際には以前 11:24:16 に発行され、その後、バッチ ポスターが起動を再開しました。 229209 の古いバッチはすでに公開されているため、バッチによって送信された L1 トランザクションはロールバックされました。11. 午前 11:36:35 に、ガス料金を返金しなかったため、バッチ ポスター アドレスのイーサが不足し、発行が停止されました。これは、バッチ ポスターがアドレスに保存されているすべてのガスを消費するのを防ぐための意図的なメカニズムです。回復バッチのコスト。12. 午前 11 時 46 分に、Nitro チームのメンバーがバッチ リカバリに関するソフトウェアの問題を解決するための電話を受けました。13. 午前 11 時 58 分頃、Arbitrum は、ソーター (新しくソートされたトランザクションを RPC ノードにブロードキャストする) に問題があることを一部のユーザーが発見したというレポートを受け取り始めました。これは、注文されたトランザクションが投稿ではなくバッチ ポスターの問題に起因するものが増えたためです。チェーンにとって、この問題は主に、インターネット接続が不十分であるか、メモリ割り当てが不十分なフィード クライアントに影響します。フィード クライアントはドロップされたり、再接続の問題が発生したりする可能性が高くなります。 Arbitrum では、複数の RPC ノードを実行しているユーザーはローカル フィード リレーを実行して、必要な外部帯域幅を削減することをお勧めします。午後 12 時 03 分、Arbitrum は Cloudflare のフィード レート制限を削除し、インターネット接続が原因で切断された後にクライアントが再接続しようとするとレート制限に達してしまう問題を軽減しました。午後 12 時 05 分に、Arbitrum は Cloudflare のレート制限をすべて削除し、フィードへの接続を維持するのに問題があったノードのパブリック RPC 使用率を増加できるようにしました。14. 午後 12:12:09 に、障害のあるバッチ ポスターがシャットダウンされ、Redis キュー ストアがクリアされて不良状態が解消されました。15. 午後 12:12:40 に、バッチ ポスターが古いバージョン v2.0.14 で開始されましたが、ルートの問題はありませんでした。16. 午後 12:21:56 に、新しく開かれたバッチ ポスターの最初のバッチが成功し、それ以来継続的に実行されています。**アービトラムソーターのバグイベントから学んだ教訓**この障害は、バッチ ポスターのバグが原因で発生しました。シーケンサー自体は影響を受けず、中断もされず、プロセス全体を通じてトランザクションの処理を継続しました。シーケンサーの資金が不足したというレポートは誤りです。 Arbitrum の資金調達メカニズムは、「シーケンサー」ウォレットと「ガス返金」ウォレットの 2 つのウォレットで構成されています。シーケンサーがバッチを正常にリリースできた場合にのみ返金されます。アービトラム ネットワークは、この件に関してシーケンサーに返金していません。資金不足、および関連する問題はシーケンサーの資金不足によって引き起こされたものではないため、ユーザーの資金が危険にさらされることはありませんでした。Arbitrum は、一時的なソリューションに追加された構成オプションをクリーンアップします。その後、トランザクション バックログの場合のネットワークの信頼性を向上させるために、シーケンサーのクライアントとサーバーのタイムアウトの問題を再評価する予定です。新しい「v2.1.0-ベータ版」 .2」のベータ版です。さらに、Arbitrum は、サービスに問題が発生した場合の混乱を軽減するために、パブリック ネットワーク ステータス ページを作成します。この記事はアービトラム財団の公式ウェブサイトから引用されています。
Golden Observation | Arbitrum sorter バグイベントのレビュー
著者: ゴールデン ファイナンス ジェイソン
Jinjin Finance Blockchain、6 月 10 日 今週、Arbitrum のソーター コードのバグにより、トランザクションをバッチで送信するネットワークの機能が短時間中断され、メイン チェーンでトランザクションを確認できなくなりました。その後、この脆弱性は修正され、トランザクションのバッチ送信機能が復旧しました。 6 月 10 日、Arbitrum Foundation は Arbitrum sorter のバグに関する事後分析レポートをリリースしました。次に、このバグ イベントによってユーザーの資金が失われない理由を確認してみましょう。
アービタラムソーターのバグイベントタイムライン
2023 年 6 月 7 日の 06:04:53、Arbitrum Collator L1 ノードの一時的な問題のため、バッチ発行者は L1 状態ビューを更新できませんでした。根本原因の問題により、Arbitrum ソーターは以前の L1 ビュー ブロック番号の状態のクエリを試行し続けました。これは、一時的な L1 ノードの問題が自動的に解決した後でも、バッチ パブリッシャーは古い L1 ブロック番号の状態のクエリを試行し続け、L1 ノードはアーカイブ ノードではないためその状態を持たなくなることを意味します。
2023 年 6 月 7 日の 09:38:28 に、Arbitrum のバッチ ポスターは、設定された最大キュー トランザクション制限 (256) (メモリプール制限と同じ) に達したため、トランザクションの公開を停止しました。この制限に達しない場合、一括投稿は通常どおり続行されます。
2023 年 6 月 7 日午前 11 時 09 分、未公開のバッチが原因で、新しいバッチを確認するために Sequencer Inbox スマート コントラクトでアラートがトリガーされ、警告が Slack チャネルに送信されました。
午前 11 時 10 分、最近のバッチ リリースがなかったため、ログベースのアラートがトリガーされ、重大レベルのアラートが Slack チャネルに送信されました。
午前 11 時 13 分、コミュニティ チームのメンバーが SRE チームのメンバーとともに PagerDuty を開始しました。SRE チームは直ちにインシデントを認識し、対応を開始しました。
午前 11:19:02 に、SRE チームはバッチ ポスターを再起動しましたが、前述のキューに入れられるトランザクションの最大制限により、バッチ ポスターはトランザクションを公開できませんでした。 SRE チームはこの問題に気づき、問題を軽減するためにサードパーティの L1 RPC プロバイダーへの切り替えを開始しました。
バッチ ポスターの開始から 5 分後の午前 11:24:16 に、L1 状態ビューが更新され、トランザクションの最初のバッチが公開されました。
午前 11:25:09 に、SRE チームが既にこの変更を開始していてバッチ処理に気付かなかったため、バッチ ポスター構成がサードパーティの L1 RPC プロバイダーを使用するように変更され、再起動されました。再起動後も、バッチ トランザクションは引き続き発生します。
バッチ ポスターの開始から 5 分後の午前 11:30:21 に、L1 状態ビューが更新されました。これにより、L1 状態が同期されなくなりました。これが問題の根本原因でもありました。 L1 状態は最終ブロック番号 17428199 に更新されましたが、その状態に保存されている最終ブロックではなく、その時点での最新ブロックに対応する最新のノンス 178078 が使用されたため、Redis 内のキューに入れられたすべてのトランザクションがワイプされました。 、Redis はこれらのトランザクションを確認済みであると見なすためです。
午前 11:30:26 に、バッチ投稿者が新しいバッチを投稿しました。 Redis は、何を公開するかを決定するために L1 状態ビューに依存しますが、前述したように、この時点では Redis キューは空であり、L1 状態は正しくなく、バッチは状態 178078 の乱数で公開されましたが、無関係なブロック番号 17428199 を使用して発行されるバッチにより、シリアル番号 229209 の古いバッチが発行されます。このバッチは実際には以前 11:24:16 に発行され、その後、バッチ ポスターが起動を再開しました。 229209 の古いバッチはすでに公開されているため、バッチによって送信された L1 トランザクションはロールバックされました。
午前 11:36:35 に、ガス料金を返金しなかったため、バッチ ポスター アドレスのイーサが不足し、発行が停止されました。これは、バッチ ポスターがアドレスに保存されているすべてのガスを消費するのを防ぐための意図的なメカニズムです。回復バッチのコスト。
午前 11 時 46 分に、Nitro チームのメンバーがバッチ リカバリに関するソフトウェアの問題を解決するための電話を受けました。
午前 11 時 58 分頃、Arbitrum は、ソーター (新しくソートされたトランザクションを RPC ノードにブロードキャストする) に問題があることを一部のユーザーが発見したというレポートを受け取り始めました。これは、注文されたトランザクションが投稿ではなくバッチ ポスターの問題に起因するものが増えたためです。チェーンにとって、この問題は主に、インターネット接続が不十分であるか、メモリ割り当てが不十分なフィード クライアントに影響します。フィード クライアントはドロップされたり、再接続の問題が発生したりする可能性が高くなります。 Arbitrum では、複数の RPC ノードを実行しているユーザーはローカル フィード リレーを実行して、必要な外部帯域幅を削減することをお勧めします。
午後 12 時 03 分、Arbitrum は Cloudflare のフィード レート制限を削除し、インターネット接続が原因で切断された後にクライアントが再接続しようとするとレート制限に達してしまう問題を軽減しました。
午後 12 時 05 分に、Arbitrum は Cloudflare のレート制限をすべて削除し、フィードへの接続を維持するのに問題があったノードのパブリック RPC 使用率を増加できるようにしました。
午後 12:12:09 に、障害のあるバッチ ポスターがシャットダウンされ、Redis キュー ストアがクリアされて不良状態が解消されました。
午後 12:12:40 に、バッチ ポスターが古いバージョン v2.0.14 で開始されましたが、ルートの問題はありませんでした。
午後 12:21:56 に、新しく開かれたバッチ ポスターの最初のバッチが成功し、それ以来継続的に実行されています。
アービトラムソーターのバグイベントから学んだ教訓
この障害は、バッチ ポスターのバグが原因で発生しました。シーケンサー自体は影響を受けず、中断もされず、プロセス全体を通じてトランザクションの処理を継続しました。シーケンサーの資金が不足したというレポートは誤りです。 Arbitrum の資金調達メカニズムは、「シーケンサー」ウォレットと「ガス返金」ウォレットの 2 つのウォレットで構成されています。シーケンサーがバッチを正常にリリースできた場合にのみ返金されます。アービトラム ネットワークは、この件に関してシーケンサーに返金していません。資金不足、および関連する問題はシーケンサーの資金不足によって引き起こされたものではないため、ユーザーの資金が危険にさらされることはありませんでした。
Arbitrum は、一時的なソリューションに追加された構成オプションをクリーンアップします。その後、トランザクション バックログの場合のネットワークの信頼性を向上させるために、シーケンサーのクライアントとサーバーのタイムアウトの問題を再評価する予定です。新しい「v2.1.0-ベータ版」 .2」のベータ版です。さらに、Arbitrum は、サービスに問題が発生した場合の混乱を軽減するために、パブリック ネットワーク ステータス ページを作成します。
この記事はアービトラム財団の公式ウェブサイトから引用されています。