Polygonが公開した内容
Polygon Labsは10月15日、Bor v2.10.3のsecurity reviewを公開しました。同社によると、BlockSTM V2が既定で有効なBor v2.10.1とv2.10.2は、中程度の深刻度のdenial-of-service問題2件の影響を受けます。いずれもPolygonのImmunefi bug bounty programを通じて報告されました。PolygonはmainnetまたはAmoyで悪用された事実を把握していないとしています。ここまではPolygonが公表した事実であり、以下はIneezaのengineering・運用分析です。
Borはblock import時にserial processorとparallel processorを競争させ、先に終わった結果を使います。問題となった投機的または重複した処理は、triggerとなるtransactionが支払ったgasより著しく高コストであり、importはその処理の終了を待つ必要がありました。EVM stateのconsensusを変える問題ではありませんが、nodeの遅延やmemory枯渇を引き起こす可能性がありました。
最初の問題に関するPolygonの試験では、約930万gasの通常transactionにより上限のない共有keccak256 cacheが約690 MiBを確保し、4-core構成で1秒超を要しました。2件目ではcode hashの反復readにより、一つの有効なtransactionをserial実行が数十millisecondで処理する一方、parallel processorは約11秒を費やしました。
Gas accountingは投機経路を制限していなかった
Polygonは共有keccak256・ecrecover cacheに上限を設け、上限後は保存せずに結果を再計算するよう修正しました。反復code hashingには、transaction・address単位でcode hashをmemoizeし、codeの変更またはrevert時にentryを無効化する修正を行いました。Polygonによると、これらの変更は実行結果を変えません。
Ineezaの分析: Protocol gasはcanonical実行を制限しても、実装上の高速化layerを制限できない場合があります。Clientはblockまたはtransactionごとに、投機処理のmemory、CPU時間、queue、保持objectへ明示的なbudgetを割り当てるべきです。Budget超過時はimportを遅らせず、高速化を無効にしてcanonical pathへfallbackする必要があります。総import latencyだけでなく、gas当たりの確保byte数や反復処理量など、投機処理の増幅率を監視すべきです。
Cancel latencyはsecurity modelの一部
Polygonの説明では、cancelが有効になるのはtransaction間だけでした。このためserial実行が競争に勝った後も、一つの長時間parallel transactionがblock importを待たせる可能性がありました。上限設定は公開されたcache経路を、memoizationは公開された反復hash経路を修正します。
Ineezaの分析: 競争型executorを安全に任意化できるのは、負けた処理が上限時間内に停止する場合だけです。Teamはtransaction間だけでなく敵対的transactionの内部でもcancelをtestし、canonical結果の準備後に許容する最大join時間を定義すべきです。Regression suiteではserialとparallelの結果比較に加え、時間、memory、cancel latencyの上限もassertする必要があります。そうでなければ、結果を破棄する高速化機能がliveness依存のまま残ります。
非公開先行patchには検証可能なrollout統制が必要
Polygonによると、10月5日にAmoyへ、10月8日からmainnet validatorと主要infrastructure providerへ非公開buildを配布し、networkの大半がupgradeした後にv2.10.3を公開しました。公開releaseはhardfork、database migration、resyncが不要で、nodeは任意の順序で個別にupgradeできます。
Ineezaの分析: 公開を遅らせれば攻撃手法を利用できる期間を短縮できますが、distribution、artifact identity、deployment evidenceが厳密に管理されている場合に限ります。運用側は署名済みまたはpin済みartifactを検証し、全validator・RPC tierの正確なbinaryとconfigurationを記録し、残存する脆弱versionの割合を監視し、公開thresholdを事前定義すべきです。「大半がupgrade済み」は復旧目標ではありません。例外を特定し、必要に応じて隔離し、期限を設定して初めてownershipが完結します。
Releaseはbinary以外も変える
Release noteによると、Borは従来無視していたHeimdall request timeout設定を適用するようになりました。Polygonはrestart前の値確認を求め、古いsample configurationの5秒に注意を促しています。現在のdefaultは30秒です。v2.10.3にはRPC batch実行slotの制限、filtered-address checkのSetCode authorizationへの拡張、並列実行のcorrectness、transaction poolのhardeningも含まれます。
Ineezaの分析: Upgrade validationはprocessのhealthやchain heightだけでなく、有効なconfigurationとworkload動作も対象にする必要があります。安全なrolloutでは、upgrade前設定を記録し、敵対的blockでimport latencyとmemoryをtestし、serial・parallel parityを確認し、RPC backpressureを検証し、canaryでHeimdall timeoutとpeer healthを観測します。Rollback判断はこれらのsignalへ結び付け、各versionのnodeがどのblockを処理したかという証跡を残すべきです。
Ineezaの見解
Bor v2.10.3が重要なのは、canonicalなblockchain実行を保護する経済的上限から、最適化処理が外れ得るという本番riskを示したためです。持続的な統制は、投機実行を信頼できないresource consumerとして扱い、独立budget、迅速なcancel、deterministic fallback、敵対的regression test、証明可能なrollout状態を持たせることです。並列化はnodeのlivenessへ無制限の権利を持たずにthroughputを改善すべきです。