en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #349

Apr 11, 2025

今週のニュースレターでは、Bitcoin Coreの初期ブロックダウンロードを高速化する提案を掲載しています。概念実証の実装では、Bitcoin Coreのデフォルト設定と比較して約5倍の高速化が見られています。また、Bitcoin Core PR Review Clubミーティングの要約や、新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャプロジェクトの注目すべき変更など、恒例のセクションも含まれています。

ニュース

● SwiftSyncによる初期ブロックダウンロードの高速化: Sebastian Falbesonerが SwiftSync のサンプル実装とパフォーマンス結果をDelving Bitcoinに投稿しました。 SwiftSyncは、Ruben Somsenが最近のBitcoin Core開発者ミーティングで提案し、その後メーリングリストに投稿されたアイディアです。この記事の執筆時点で、スレッドに投稿された最新の結果では、 Bitcoin CoreのIBDのデフォルト設定（assumevalidは使用するがassumeUTXOは使用しない）と比較して、初期ブロックダウンロード（IBD）が5.28倍高速化され、初期同期時間が約41時間から約8時間に短縮されました。

SwiftSyncを使用する前に、ノードを最新のブロックまで同期済みの人が、そのブロックまでのUTXOセットに含まれるトランザクションアウトプット（つまり未使用のアウトプット）を示すヒントファイルを作成します。これは、現在のUTXOセットサイズに合わせて数百MBに効率的にエンコードできます。ヒントファイルには、どのブロックで生成されたかも記載されており、これを ターミナルSwiftSyncブロック と呼びます。

SwiftSyncを実行するユーザーはヒントファイルをダウンロードし、ターミナルSwiftSyncブロックより前の各ブロックを処理する際にそれを使用します。ヒントファイルで、ターミナルSwiftSyncブロックに到達した際にアウトプットがUTXOセットに残ることが示されている場合のみ、アウトプットをUTXOデータベースに保存します。これにより、 IBD中にUTXOデータベースに追加され、その後削除されるエントリーの数が大幅に削減されます。

ヒントファイルが正しいことを確認するために、UTXOデータベースに保存されていないすべてのアウトプットは、暗号学的アキュムレーターに追加されます。使用済みのすべてのアウトプットは、アキュムレーターから削除されます。ノードがターミナルSwiftSyncブロックに到達すると、アキュムレーターが空であることを確認します。つまり、確認したすべてのアウトプットは後で使用されたことを意味します。これが失敗した場合、ヒントファイルが正しくなかったことを意味し、 SwiftSyncを使用せずにIBDを最初からやり直す必要があります。このように、ユーザーはヒントファイルの作成者を信頼する必要はありません。悪意あるファイルによってUTXOの状態が不正確になることはなく、ユーザーのコンピューティングリソースを数時間浪費するだけで済みますね。

SwiftSyncの未実装の追加機能として、IBD中のブロックの並列検証が挙げられます。これは、assumevalidが古いブロックのスクリプトをチェックしないこと、ターミナルSwiftSyncブロックより前のエントリーがUTXOデータベースから削除されないこと、そして使用されるアキュムレーターが追加（作成）および削除（使用）されたアウトプットの最終的な結果のみを追跡することから可能です。これにより、ターミナルSwiftSyncブロックより前のブロック間の依存関係が排除されます。 IBD中の並列検証は、同様の理由からUtreexoの機能でも採用されています。

議論では提案のいくつかの側面が検討されました。Falbesonerの元の実装では、一般化された誕生日攻撃への耐性があることが示されている MuHashアキュムレーター（ニュースレター #123参照）が使用されていました。 Somsenは、より高速な代替アプローチについて説明しました。 Falbesonerは、この代替アプローチが暗号的に安全かどうか疑問視しましたが、シンプルであるため実装し、SwiftSyncの速度がさらに向上することを発見しました。

James O’Beirneは、assumeUTXOがさらに大幅な高速化をもたらすことを踏まえ、 SwiftSyncは有用かどうかを尋ねました。Somsenは、 SwiftSyncはassumeUTXOのバックグラウンド検証を高速化するため、 assumeUTXOのユーザーにとっても便利な追加機能であると返信しました。さらに、assumeUTXOに必要なデータ（特定のブロックのUTXOデータ）をダウンロードする人は、そのブロックをターミナルSwiftSyncブロックとして使用する場合、別途ヒントファイルを用意する必要がないと述べています。

Vojtěch Strnadと0xB10CおよびSomsenは、ヒントファイルのデータを圧縮することで、約75%の節約が見込まれ、（ブロック850,900の）テストヒントファイルを約88MBに縮小できると説明しました。

この記事の執筆時点で、議論は進行中でした。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、重要な質問と回答のいくつかに焦点を当てます。以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Add Fee rate Forecaster Managerは、 ismaelsadeeqによるPRで、トランザクション手数料の予測（推定とも呼ばれる）ロジックをアップグレードします。このPRでは、複数のForecasterを登録できる新しい ForecasterManagerクラスが導入されます。既存のCBlockPolicyEstimator（承認済みのトランザクションのみを考慮）は、そのようなForecasterの1つとなるようにリファクタリングされました。注目すべきは新しくMemPoolForecasterが導入されたことです。MemPoolForecasterは、 mempool内の未承認トランザクションも考慮するため、手数料率の変更に迅速に対応できます。

なぜ新しいシステムは「Estimator」や「Fee Estimation Manager」ではなく、「Forecaster」と「ForecasterManager」と呼ばれるのですか？

このシステムは、現在と過去のデータに基づいて将来の結果を予測します。ある程度のランダム性をもたせて現在の状況を近似するEstimatorとは異なり、 Forecasterは将来の出来事を予測します。これは、このシステムの予測的な性質と不確実性/リスクレベルの出力と一致しています。 ➚
CBlockPolicyEstimatorが、PR #12966のアプローチと同様に、 mempoolの参照を保持するように変更されていないのはなぜですか？また、mempoolへの参照を保持するよりも現在のアプローチが優れているのはなぜですか（ヒント：PR #28368参照）？

CBlockPolicyEstimatorはCValidationInterfaceを継承し、その仮想メソッドであるTransactionAddedToMempool、TransactionRemovedFromMempool、 MempoolTransactionsRemovedForBlockを実装しています。これにより、 CBlockPolicyEstimatorは、参照を介してmempoolに不必要に密結合されることなく、必要なmempoolの情報を取得できます。 ➚
新しいアーキテクチャとCBlockPolicyEstimatorを直接変更した場合のトレードオフは何ですか？

複数のForecasterを登録できるFeeRateForecasterManagerクラスを備えた新しいアーキテクチャは、よりモジュール化されたアプローチであり、テストの効率化や、より効果的な関心事の分離を実現します。これにより、後から新しい予測戦略を簡単に追加できます。ただし、メンテナンスに必要なコードが少し増え、どの推定手法を使用すべきかユーザーが混乱する可能性があります。 ➚

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

● Core Lightning 25.02.1は、この人気のLNノードの現在のメジャーバージョンのメンテナンスリリースで、いくつかのバグ修正が含まれています。
● Core Lightning 24.11.2は、この人気のLNノードの前のメジャーバージョンのメンテナンスリリースです。いくつかのバグ修正が含まれており、そのうちのいくつかは、バージョン25.02.1でリリースされたバグ修正と同じものです。
● BTCPay Server 2.1.0は、このセルフホスト型ペイメントプロセッサソフトウェアのメジャーリリースです。いくつかのアルトコインユーザーに対する破壊的な変更と、RBFと CPFPによる手数料の引き上げの改善、すべての署名者がBTCPay Serverを使用している場合のマルチシグのより良いフローが含まれています。
● Bitcoin Core 29.0rc3は、ネットワークの主要なフルノードの次期メジャーバージョンのリリース候補です。バージョン29のテストガイドをご覧ください。
● LND 0.19.0-beta.rc2は、この人気のLNノードのリリース候補です。おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。

注目すべきコードとドキュメントの変更

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

● LDK #2256およびLDK #3709は、BOLTs #1044で定義されているように、 UpdateFailHTLC構造体にオプションのattribution_dataフィールドを追加し、 AttributionData構造体を導入することで、失敗の帰属（ニュースレター#224参照）を改善します。このプロトコルでは、各転送ノードは失敗メッセージにhop_payloadフラグ、ノードがHTLCを保持していた時間を記録するdurationフィールド、経路上の想定される位置に対応するHMACを付加します。ノードが、失敗メッセージを破損した場合、 HMACチェーンの不一致は、破損が発生したノードペアを識別するのに役立ちます。
● LND #9669は、RBF協調クローズフロー（ニュースレター#347参照）が設定されている場合でも、 Simple Taproot Channelで常に従来の協調クローズフロー使用するようダウングレードします。これまでは、両方の機能が設定されているノードは起動に失敗していました。
● Rust Bitcoin #4302は、スクリプトビルダーAPIに相対的タイムロックパラメーターを引数に取る新しいpush_relative_lock_time()メソッドを追加し、シーケンス番号をそのまま受け取るpush_sequence()が非推奨となりました。この変更により、開発者がスクリプト内で相対的タイムロックの値ではなく、シーケンス番号を誤ってプッシュしてしまう潜在的な混乱が解消されます。この値は、CHECKSEQUENCEVERIFYを使ってインプットのシーケンス番号と照合されます。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、（ニュースレターが公開された翌日の）木曜日の15:30 UTCから Riverside.fmで毎週開催されているBitcoin Optech Recapにご参加ください。この議論は録画もされ、ポッドキャストページからご覧いただけます。