BSV Broadcaster、送信済み決済のリアルタイム受領通知を追加


BSV Broadcaster v0.20.0では、ウォレットや決済画面でトランザクション送信直後の状態表示がより迅速に。

新たに追加された「RECEIVED」通知により、ブロードキャスター(Broadcaster)がトランザクションを受け取った時点で「支払いを送信しました」といった表示が可能になった。これはTeranodeノードによる受理やブロックへの収録より前の段階を示すもの。

v0.20.0は2026年11月3日17時54分(UTC)に公開。あわせて、未確認のお釣りを使う連続決済処理や、サービス運営者向けの管理機能も改善されている。

支払いの状態を3段階で確認

ブロードキャスターは、ウォレットから受け取ったトランザクションをネットワークへ伝達、その後の状態を追跡して各アプリケーションへ通知する。v0.20.0では、新たにRECEIVED通知が追加され、ネットワークへ送る前の受信段階においても確認できるようになった。

これまでは、最初にウォレットが確認するライブ通知が「ACCEPTED_BY_NETWORK(Teranodeノード側で受理)」となることがあり、これはブロードキャスターが送ったトランザクションを1つのTeranodeノードが受け取ったことを示すにとどまるもので、この応答だけではその支払いがブロックに収録されることを保証するものではない。

次に「MINED」が通知され、トランザクションがブロックへ収録されたことを確認。

ウォレットや決済画面では次の流れを追って確認することができる。

RECEIVED: 本ブロードキャスターが受信
ACCEPTED_BY_NETWORK: Teranodeノードによる受理
MINED: ブロックに収録

RECEIVEDをリアルタイムで受け取るには、ウォレット側で支払送信以前に「ライブ更新」を受信している必要がある。

同じトランザクションを再送しても、2回目のRECEIVED通知は発生しない。

また、すでにTeranodeノードによる受理など、次の段階へ進んでいる場合は、古いRECEIVED通知を送らない仕組みとなっている。

これにより、決済が進行しているにもかかわらず、画面上ではまだ送信直後の状態にあるかのように表示されることを防いでいる。


「確証(Confirmation)前のお釣り」を使った連続決済を改善

今回のリリースでは、一つのトランザクションに含まれる「お釣り」を、まだその支払いがブロック収録(マイニング)される前に、次の支払いに使うことを可能にする工程が改善された。

ビットコインのウォレットでは、残高は未使用のトランザクション出力(UTXO)の集合として管理される。

例えば、1 BSVを5回受領し、それぞれが未使用の場合、ウォレットは合計5 BSVを5個のUTXOとして管理している。

このウォレットから1.5 BSVを支払う際、1 BSVのUTXOを2個使用すると、合計2 BSVが支払いの入力となる。そこから1.5 BSVを送金し、マイナー手数料を差し引いた約0.5 BSVが新しいUTXOとしてお釣りになる。

仮に、店舗が一つ目の取引先へ支払いに含まれるお釣りを使って別の取引先へ支払おうとする際、2番目のトランザクションは最初のトランザクションに準じて使用することで、さらなるブロック確証を必要とせずに使用することが可能な形式を取っている。

こうしたことは以前から可能であったが、ブロードキャスター内部で二つのトランザクションが別々に処理されると、2番目を扱う際に最初のトランザクションの「記録がない」状態になることがあった。ウォレットが正しい順序で送信していても起こり得る問題だった。

v0.20.0では、ブロードキャスターが最初のトランザクションをまだ処理している間に、準ずる2番目の支払いをその後ろに並べて処理する形式を取ることで、そうした問題を解決している。

試験では、プライベートなテストネットワーク上で50件の連続トランザクションを検証した。旧ビルドでは90秒後も50件中40件が再試行待ちだったが、新しい処理では、同じ90秒以内に50件すべてがACCEPTED_BY_NETWORK以上の状態へ到達した。

サービス運営者向けの管理機能も追加

サービス運営者は、クライアントごとに個別のアクセスキーを発行し、リクエスト数や一度に送信できるトランザクション数へ制限を設定できるようになった。

これらの制限は初期状態では無効で、ライブ更新に使われる別の接続には適用されない。

また、ブロックがアクティブチェーンから外れた後のトランザクション追跡についても改善されている。

報告の10月31日の事例では、元のブロックがアクティブチェーンから外れた後、約8,750件のトランザクションが再びマイニングされた。一方、あるブロードキャスター環境では、それらが以前のブロックにあるものとして記録されたままになっていた。

新しいブロードキャスターでは、ブロックの置き換わりによって収録先が変わるトランザクションについて、Merkle Serviceに追跡の継続を依頼できるようになった。これにより、対象のトランザクションが別のブロックに再収録された場合、その新しい収録先を確認できるようにする。

ただし、10月31日に報告された事例では、データベースに保存された古い収録先の情報を修正するために、Merkle Service側でも追加の改修が必要となる。この改修は11月4日時点でまだレビュー中であり、ブロードキャスターをアップグレードするだけでは、すでに保存されている誤った収録先の情報は修正されない。

編集者の見方

今回のRECEIVED通知は、ウォレットや決済画面にとって単に通知が一つ増えた以上の意味を持つ。

顧客が支払いボタンを押した直後に接続が途切れると、画面上では何も起きなかったように見える場合がある。しかし、ブロードキャスターがトランザクションを受け取った時点を別の状態として扱えることで、「送信済」表示後、Teranodeノードによる受理やブロック収録への進捗状況が確認可能となる。

ライブ通知の接続が切れた場合でも、アプリケーションはトランザクションIDを使って現在の状態を別途照会できる。

そのため、通知が届かなかったことで、顧客へもう一度支払いを求めるのではなく、まず元のトランザクションがどうなったかを確認するという流れを取りやすくなる。

実用上の変化は、支払いの状態を「送信」「ノードによる受理」「マイニング」という順序で、より明確に扱えるようになった点にある。

開発者情報

GitHubでgalt-trとして活動するDylanが、ライブ受領通知、未確認のお釣りを使う支払いの処理、クライアントごとのアクセス制限、ブロック置き換え後のトランザクション追跡に関する変更を提出。

参照リンク

BSV Broadcaster — v0.20.0 Release

BSV Broadcaster — Event Stream Guide at v0.20.0

BSV Broadcaster — Chained Submissions and the 50-Transaction Test, Pull Request #392

BSV Broadcaster — Transaction Routing Rules at v0.20.0

BSV Broadcaster — API Keys and Usage Limits at v0.20.0

BSV Broadcaster — October 31 Incident and Recovery Change, Pull Request #395

Merkle Service — Companion SQL Registration Fix, Pull Request #281

galt-tr — Developer Profile

※本記事は、原記事発行元であるBSVタイムズの使用許諾を得て、記事を要約・翻訳・編集しています。

2026年11月4日(BSVタイムズ初発行)