UseBitcoinを支える技術 - 普通のWebに、何を⾜すとBitcoin決済サイトになるのか

UseBitcoinを支える技術
普通のWebに、何を⾜すとBitcoin決済サイトになるのか

Transcript

1. UseBitcoinを⽀える技術 普通のWebに、何を⾜すとBitcoin決済サイトになるのか 2026.04.25 @mot_xx 10 min
2. このLTは ”久しぶりに会ったWebエン ジニアの友⼈” に説明するつもりで話 します 実装イメージと判断材料を最短で伝える。技術選定の理由やハマりどころを、 リアルな経験として共有します。
3. このLTのゴール UseBitcoin.jpの技術スタックを理解し、BTC決済のWebサービ スの実装をはじめることができる 01 UseBitcoinを⽀える 技術の基本 UseBitcoinを⽀える技 術の全体像を掴む 02 Bitcoin特有の 技術スタックを知る ⾃分でBTC決済Web サービスを実装する⾜ がかりとする 03 ビットコイン決済サービスの リアルを共有 実際の経験とハマりど ころを話す
4. moti
5. UseBitcoin.jp とは？ サービス概要 ‧Bitcoin決済対応ECサイト ‧ユーザーアカウントなし ‧商品：プリペイドカード
6. 全体ざっくりアーキ図 WebアプリとBTCPay は⾃社運⽤環境で管理 ユーザー Webブラウザ Webアプリ ビットコインEC BTCPay Server 決済管理 Bitcoin 決済インフラ AWS BTCノード LNノード グローバルインフラ BTCノード LNノード React Rust PostgreSQL
7. UseBitcoin.jp の技術スタック フロントエンド React + TypeScript React TypeScript Tailwind バックエンド Rust Rust axum データ管理 データ永続化 PostgreSQL bitcoind LND インフラ/構成管理 AWS + Cloudflare AWS Cloudflare Workers Nix (devenv) S3 sqlx Bitcoin決済 Bitcoin + Lightning bitcoind LND BTCPay Server
8. 普通のWeb技術に"これ"を⾜しただけ 普通のWeb構成 既存のECサイト技術 React + TypeScript / Rust PostgreSQL AWS (ECS Fargate/EC2/RDS), Cloudflare 追加したもの Bitcoin決済レイヤー BTCPay Server（⾃社サーバー内） Bitcoin / Lightning ノード RTL（ノード管理ソフトウェア） ⾜したのは"Bitcoin決済レイヤー"だけ。Webアプリの8割は既存技術で構築可能
9. BTCPay Serverとは 決済UI‧Webhook通知‧ウォレット管理を担う セルフホスト型のBitcoin/Lightning Network決済サーバー
10. アーキテクチャ概要 ECサイトとBTCPayServerスタックの連携構成 BTCPayServer管理領域 顧客 購入者 マーチャント 店舗管理者 ECサイト プラグイン / API連携 BTCPayServer 決済エンジン PostgreSQL 設定・請求DB NBXplorer ブロックチェーン監視 Lightning Node ライトニング決済 Bitcoin Core フルノード Bitcoin ネットワーク (P2P) ECサイト BTCPayスタック ビットコイン層 BTCPay Serverとは
11. なぜBTCPay Serverを選んだか • 仮説検証用のプロダクトを素早く完成させるため ◦ サービス管理画面・WebAPIの両対応で、用途に応じて使い分け可能 ◦ セルフカストディで、セキュリティを自分でコントロールできる （OpenNodeなどカストディ型サービスとの比較） ◦ 最小コストでビットコイン環境が構築でき、仮説検証に応じてpivotしやすい
12. ハマりどころ1： 売上を得るためにLNノード運⽤が常に必要 - チャネルリバランス - まず、チャネルの説明
13. ・EC売上分のビットコインを受け取り続けると残高が増え、チャネルバランスが偏り、最終的にEC売 上を受け取ることができなくなる。リバランスが必要 ・チャネル開設時、最初にリバランスしないと、EC売上を受け取ることができない - Inbound Capacityはチャネル上の相手の残高 - Outbound Capcityはチャネル上の自分の残高 参考：LNにおけるInbound Capacityの獲得方法8選 https://bitcoin-research.jp/ln-inbound-capacity-8-methods/ ハマりどころ1： 売上を得るためにLNノード運⽤が常に必要 - チャネルリバランス -
14. ハマりどころ２： LNノードのバックアップが難しい ウォレットのシードをバックアップ LNウォレットのシードをバックアップ Static Channel Backup (SCB) の取得‧外部保管 ノードとチャネルの情報を持つデータを取得、別の場所にバックアップしておく 同期的なレプリケーション 可⽤性を⾼める場合は必要。⾮同期レプリケーションは避ける。
15. まとめ 01 普通のWeb + BTCPay Server + Bitcoin/Ligntning ノードで作れる 既存のWeb技術スタックにBitcoin決済レイヤーを追加 02 ハマりどころはLNの残⾼リバランス運⽤ Lightning NetworkのInbound Capacity管理が課題 03 8割はWeb開発のベーシックな技術 2割がビットコイン固有 ⼤半は⼀般的なWeb開発スキルで対応可能 意外と普通のWebエンジニアの延⻑で作れる 既存のWeb開発スキルにBitcoinの知識を⾜すだけで実現可能
16. Thank you for your attention! Q&A - ご質問があればお気軽にどうぞ usebitcoin.jp https://usebitcoin.jp BTCPay Server Docs docs.btcpayserver.org
17. Appendix: オンチェーン vs Lightning ⽐較 評価軸 オンチェーン (On-chain) Lightning Network 速度 遅い (10分〜1時間) 即時 (秒単位) ⼿数料 ⾼い (数百 sats) 安い (1〜 sat) 確実性 確実（ブロック確認後） ルートが無かったら失敗 運⽤難易度 シンプル 複雑（LNノード管理必要） ユースケース ⼤額決済‧保存 ⾼頻度‧⼩額決済