1. ネットワークへの非公開性 項目 公開チャンネル プライベートチャンネル アナウンス ネットワーク全体に配信 配信されない 発見可能性 誰でも確認可能 当事者のみ知る ネットワークグラフ 含まれる 含まれない 2. ルーティングの制限 主な制限事項 直接支払いのみ可能 - 第三者はこのチャンネルを経由できない ルーティング収益なし - 転送手数料を稼げない 受信時の例外 - インボイスにルーティングヒントを含めれば受信可能 3. プライバシーの向上 プライバシー面でのメリット ✅ チャンネル容量の秘匿 - 外部から残高が見えない ✅ 取引の秘匿性 - チャンネルの存在自体が隠される ✅ UTXOとの関連付け困難 - オンチェーン資金とノードの関連が分かりにくい プライバシーの脆弱性 ⚠️ インボイス経由の情報漏洩 - ルーティングヒントでチャンネルIDが露出 ⚠️ プロービング攻撃 - 偽の支払いハッシュで存在を探知可能 ⚠️ オンチェーン分析 - ファンディングトランザクションは見える 4. 技術的制約 GetChanInfoの失敗例 // プライベートチャンネルではグラフ情報が取得できない r, err := l.lndClient.GetChanInfo(context.Background(), &lnrpc.ChanInfoRequest{ ChanId: chanId, }) if err != nil { // Ignore err because channel graph information is not always set. return maxHtlcAmtMsat, nil } ListChannelsでの取得 // PublicOnly: false, PrivateOnly: false で両方取得 r, err := l.lndClient.ListChannels(context.Background(), &lnrpc.ListChannelsRequest{ ActiveOnly: false, InactiveOnly: false, PublicOnly: false, // プライベートチャンネルも含む PrivateOnly: false, // 公開チャンネルも含む }) 5. PeerSwapへの影響 メリット 👍 ルーティング制限の影響なし - 直接ピア間でのみ動作 高いプライバシー - スワップ操作が外部から見えない ポリシー変更不要 - チャンネル更新のアナウンス不要 課題 ⚠️ チャンネル情報の取得困難 - max_htlc等のパラメータが不明 ピア発見の困難 - PeerSwap対応ピアを見つけにくい 流動性評価不可 - ネットワーク全体の状況が把握できない 6. まとめ プライベートチャンネルは以下のトレードオフを持つ： ...

はじめに ブログ記事の作成から公開までの流れを自動化するために、便利なスクリプトを作成しました。このスクリプトを使うことで、記事の作成、編集、公開までの一連の作業を効率化できます。 内容 blogスクリプトの機能 プロジェクトのルートディレクトリにある blog スクリプトは以下の機能を提供します： 記事ファイルの自動生成 日付とタイトルから適切なファイル名を生成 Hugoのフロントマターを自動で設定 記事の基本構造（はじめに、内容、まとめ）を自動挿入 編集環境の自動起動 VSCodeで記事ファイルを自動で開く 編集完了まで待機する機能 公開プロセスの自動化 Gitへの追加・コミット リモートリポジトリへのプッシュ GitHub Actionsによる自動デプロイ 使用方法 ./blog "記事のタイトル" 例： ./blog "新しいブログ記事" スクリプトの流れ タイトルを受け取り、日付と組み合わせてファイル名を生成 hugo new コマンドで記事ファイルを作成 フロントマターのタイトルを更新 基本的な記事構造を追加 VSCodeで記事を開いて編集待機 編集完了後、公開確認 公開する場合、Git操作を実行 スクリプトコード #!/bin/bash # Blog post creation script # Usage: ./blog <title> if [ -z "$1" ]; then echo "Usage: blog <title>" echo "Example: blog 'My New Post'" exit 1 fi # Get the title and create filename TITLE="$1" DATE=$(date +%Y-%m-%d) FILENAME_TITLE=$(echo "$TITLE" | sed 's/ /-/g' | tr '[:upper:]' '[:lower:]') FILENAME="content/posts/${DATE}-${FILENAME_TITLE}.md" # Create new Hugo post echo "Creating new post: $FILENAME" hugo new "$FILENAME" if [ ! -f "$FILENAME" ]; then echo "Failed to create post file" exit 1 fi # Update the title in the frontmatter sed -i '' "s/title: .*/title: \"$TITLE\"/" "$FILENAME" # Add some initial content cat >> "$FILENAME" << 'EOF' ## はじめに ## 内容 ## まとめ EOF echo "Opening $FILENAME in VSCode..." echo "Edit your post and save. The script will wait for you to finish editing." echo "Press Ctrl+C to cancel without publishing." # Open in VSCode and wait for it to close code --wait "$FILENAME" # Check if user wants to publish echo "" read -p "Do you want to publish this post? (y/N): " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]]; then echo "Publishing post..." # Add and commit the new post git add "$FILENAME" git commit -m "Add new blog post: $TITLE" # Push to remote git push origin main echo "Post published successfully!" echo "Your blog will be updated shortly via GitHub Actions." else echo "Post saved as draft. You can publish it later with:" echo " git add $FILENAME" echo " git commit -m 'Add new blog post: $TITLE'" echo " git push origin main" fi コード解説 1. 引数チェック if [ -z "$1" ]; then echo "Usage: blog <title>" echo "Example: blog 'My New Post'" exit 1 fi タイトルが渡されているかチェックし、なければ使用方法を表示して終了。 ...

Tuscany Lightning Summit 2025 目的: Tuscany Lightning Summit 2025（TLS2025）で示された Bitcoin／Lightning Network および関連 Layer2 技術の最新動向を体系的に整理し、今後の技術課題と展望を明確化する。 結論: LSP 標準化、ノンカストディ型 UX 改善、複数 Layer2（Liquid・RGB・Taproot Asset 等）のハイブリッド運用が不可欠である。一方、開発リソースは限定的であり、コミュニティ協働と提案（BOLT／BLIP）への貢献が急務である。 Day 1 概要 セッション 主題 私見 Keynote by Giacomo Zucco LN を総合送金・ルーティング基盤へ再定義。異資産スワップとセキュリティモデル統合を強調。 P2P atomic swapが鍵。Taproot Asset と RGB の共存性を注視。 1000 Shades of Trust 秘密鍵管理を二項対立ではなくスペクトルで捉えるべきと提言。 フェデレーション維持可能性が核心。中間形態への社会的理解が不足。 Bitcoin’s Fintech Revolution LN によるリアルタイム小額決済と規制対応。 Stablecoin 実装は RGB／Taproot Asset／Liquid の選択が重要。 Lightning Without the Storms Liquid（許可制フェデレーション）と LN（分散 P2P）の比較。 プロトコル選択の複雑化は必至。 Ark Lightning Gateways Ark を L2 オプションとして紹介。 プロトコル詳細は未確定で追跡必要。 Lightning and Digital Identity LN を SSI／ID 管理へ適用する PoC。 拡張可能性は高いが時期尚早。 Attributable Failures in Lightning MPP 失敗時に責任ノードを特定する BOLTs #1044。 ルート信頼性向上に必須だが合意形成が難航。 Keynote by Adam Back Compact Blocks によるブロック伝播最適化。 誤検出リスクに留意。swap 需要増加を予測。 The Bitcoin Reality Check 決済普及度の現実とマーケティング課題。 技術と社会の認知ギャップが大。 交流・開発関連 Greenlight: Christian Deckerと PR(#599) をマージ。HTTP 経由プラグイン構想が進行。 PeerSwap: Nepetとfeaturebidsによる2hop peerswapの可能性の検討。 まとめ TLS2025 は Bitcoin／Lightning の進化を俯瞰し、Liquid・RGB・Taproot Asset 等を含む多層技術併用が前提となる「複雑化時代」の到来を示した。開発リソースは限られ、BOLT／BLIP 提案への実装貢献が停滞を打破する最短経路である。ユーザーオンボーディング、LSP 標準化、カストディ形態最適化を段階的に進め、利便性と分散性を両立したエコシステムを構築すべきである。次回サミットまでに、自身もコードおよび議論へ継続的に貢献し、課題解決を加速させたい。 ...

https://github.com/warpdotdev/Warp/discussions/400 のまとめ。 Warp のオープンソース化について 目的 Warp Discussion #400 で議論された「完全オープンソース化」対「クローズド戦略」の議論を整理する。 背景 コメント数: 120（2025 年 4 月時点） 主要アクター: Warp 開発チーム、企業ユーザ、FOSS 支持者 想定ユーザ数: 10 万以上（公式発表） メリット 監査性向上: セキュリティ脆弱性検証が可能。 長期保守性: 開発停止時にフォークで継続できる。 コミュニティ貢献: パッチと機能追加が期待できる。 デメリット コントリビューション管理コスト増。 IP 流出: 競合がフォークし商用利用する恐れ。 フォーク乱立: サポート負担が拡大。 ライセンス選択肢 類型 利点 欠点 GPL / AGPL fork 自由、利用者保護 企業採用減 MIT / Apache-2.0 導入容易 IP 複製リスク 制限付き独自 収益と自由の両立 FOSS 定義外 事例: Onivim 2 は「非商用無料＋商用有償」を採用し、3 年で 1 万ライセンスを販売。 ビジネスモデルとの整合 Warp は将来、コラボレーション機能に課金予定である。クライアント側を FOSS 化し、サーバー機能を商用に保持すれば、運用コストと収益を両立できる。 推奨戦略 コア以外（UI、テーマ、拡張 API）を Apache-2.0 で公開。 サーバー機能をクローズドにして収益源を維持。 18 か月後を目途に全面 GPL 化する「タイムディレイ方式」を検討。 まとめ Warp は「部分的オープンソース＋時間差全面公開」という段階的戦略を取るべきである。これによりコミュニティの信頼を獲得し、長期的なエコシステム拡大を実現できる。 ...

https://github.com/openai/codex は、Unix シェルならではのパイプやスクリプト管理との相性が良く、AI を活用したシームレスなコードレビューを実現できる。 一方で、自動実行に対するセキュリティリスクも存在するため、Git 管理とサンドボックス設定などで防御を固める必要がある。例えば、下記のようなgh-prs.sh のようなscriptと組み合わせたワークフローを構築し、codex -m o3 を活用した差分解析や自動レビューを行うことで、高品質な開発プロセスを確立できる。 codex -m o3 $'コードの構造を踏まえて内容をレポートし、さらに改善提案やレビューを行ってください\n\n'"$(gh-prs.sh)" #!/usr/bin/env bash # # gh-prs.sh # ------------ # GitHub CLI で Issue 一覧を取得し、peco で選択して # `gh pr view` と `gh pr diff` で詳細と差分を表示するシンプルなスクリプト。 # # 依存: # - GitHub CLI (gh) : https://cli.github.com/ # - peco : https://github.com/peco/peco # # 使い方: # ./gh-prs.sh [gh issue list のオプション] # # 例) 自分が担当で open 状態の Issue を対象にする # ./gh-prs.sh --assignee @me --state open # set -euo pipefail # 表示調整 SUMMARY_MAX=120 # peco で視認しやすいようタイトルを truncate する長さ # pr 一覧取得 (番号とタイトルのみ、タブ区切り) LIST=$(gh pr list --limit 100 "$@" \ --json number,title \ --template '{{range .}}{{printf "%.0f\t%s\n" .number .title}}{{end}}' || true) if [[ -z "${LIST}" ]]; then echo "該当する pr がありませんでした。" >&2 exit 0 fi # peco で選択 pr_NUM=$(echo "${LIST}" | awk -v max="${SUMMARY_MAX}" -F'\t' ' { title=$2; if(length(title) > max) title=substr(title,1,max)"…"; printf "%s\t%s\n",$1,title }' | peco --prompt "Select pr > " | cut -f1) if [[ -z "${pr_NUM}" ]]; then echo "pr が選択されませんでした。" >&2 exit 1 fi # 詳細表示 + diff gh pr view "${pr_NUM}" gh pr view "$pr_NUM" \ --json comments \ --jq '.comments[] | select(.authorAssociation != "NONE") | "\(.author.login)\n\(.body)\n"' gh pr diff "${pr_NUM}"

https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html の意訳。 目的と結論 Taproot の BIP340 署名を用いると、従来コヴナントを阻む要素とされてきた循環問題を部分的に克服できる。したがって、CAT オペコードが再導入されれば、事実上 CHECKSIGFROMSTACK に近い仕組みを得られる可能性が高い。さらに署名アルゴリズムの数学的性質を悪用することで、introspection（トランザクションの内省）を実現する道が開ける。ただし、Taproot では出力先が楕円曲線上の公開鍵となるため、再帰的コヴナントを構築するには追加の工夫が要る。 背景 Bitcoin Script は通常、「認証データ（署名やハッシュロック等）の検証」を行うのみである。covenant（コヴナント）とは、支出時のトランザクション構造を条件により制限する概念である。しかし、Bitcoin Script はトランザクションデータ全体にアクセスできないため、トランザクション形式を強く拘束することはできない。もし CAT や CHECKSIGFROMSTACK が存在すれば、ユーザが提供するトランザクション全体のデータに対し署名をチェック可能となり、コヴナントの仕組みを実装できる。 概要 下記では、Schnorr 型署名（BIP340）が「コヴナント対策」を意図して設計されたにもかかわらず、実際には従来よりもコヴナント実装に近づける余地があることを示す。さらに CAT オペコードを組み合わせると、CHECKSIGFROMSTACK のような操作が可能になる。 covenants の定義 covenants: 特定のトランザクションのみがコインを使用可能になるよう制限・検証を行う仕組み。 従来の Bitcoin Script: 署名やハッシュロックは扱えるが、送金先や速度制限など複雑な制限は行えない。 CAT の役割: スタック上に展開した小さなデータ要素を連結し、任意の大きさのデータ検証を可能にする。 CHECKSIGFROMSTACK の役割: 任意のデータに対する署名検証を行い、ユーザが提示したトランザクションデータが正しいことを確認する。 ECDSA 署名と covenant の問題点 ECDSA は過去に Bitcoin で使われた署名方式である。 しかし ECDSA では、CHECKSIGFROMSTACK がない場合、トランザクションハッシュとの循環参照が発生して柔軟な制限がかけられない。 また、CHECKSIG が参照するトランザクションデータには前のトランザクションの情報や Script 自身が含まれ、完全な自由度が得られない。 Schnorr 署名（BIP340）の概要と誤解 Taproot における BIP340 署名は、旧来より「コヴナントを阻む署名方式」と見なされてきた。 署名ハッシュに公開鍵 $P$ が明示的に含まれ、循環を招くため、コヴナント的制約を実現しづらいと思われていた。 実際には、$R$ と $P$（一時鍵と公開鍵）を固定し、署名パラメータ $s$ を逆に操作することで、トランザクションハッシュをスタックに載せるトリックが可能である。 具象例 署名値 $s$ のみ入力としてスタックに載せる。 固定した $R$ として生成元点 $G$ を用い、DUP・SWAP・CAT などを駆使して署名チェックを行う。 その過程で $s$ が実質的にトランザクションデータのハッシュを表すように仕向ける。 ハッシュの末尾が特定バイトになるまでグラインド（複数試行）させれば、+1 の調整もクリア可能。 結果として、CHECKSIGFROMSTACK 的な振る舞いを再現し、Script 側が自由にトランザクションデータを制約できる。 さらなる応用と課題 CAT が正式に利用できれば、CAT + CHECKSIGFROMSTACK スタイルの内省が事実上可能となる。 しかし、Taproot の出力は EC 公開鍵で行われ、楕円曲線ハッシュが Script に直接提供されないため、再帰的コヴナントには追加の拡張が必要である。 SigHash モードのバリエーション（SIGHASH_NOINPUT など）をシミュレートすることで、Lightning チャネルのバックアップや Vaults など柔軟な応用が可能になると期待される。 Miniscript による発展 Script 設計の難しさがコヴナント応用を阻んできた要因である。 Miniscript は Script を安全かつ組み合わせしやすい形で記述・解析する手法であり、今後こうした高度なコヴナントの開発を加速させる見込みがある。 実際に CHECKSIGFROMSTACK を用いた高度な事例も存在し、Taproot + Miniscript との組み合わせで可能性が広がる。 結論 Taproot の BIP340 署名と CAT（もしくはそれに類する機能）の組み合わせを用いれば、トランザクション内省を実装できる可能性が高い。旧来の ECDSA より「コヴナント対策」が進んだ反面、実際には逆手を取ることで自由度が増している。一方で、再帰的コヴナントまで視野に入れる場合、楕円曲線ハッシュを Script が直接扱う必要があり追加の検討が必要である。Miniscript の応用や SIGHASH_NOINPUT 相当の仕組みを組み合わせることで、Lightning Network や Vaults の固有要件を満たす設計が可能になる。 ...

https://github.com/EthanHeilman/bips/blob/7ad0f821ddc60366e98344a1e3019114ae46c80f/bip-0347.mediawiki の意訳。 BIP: 347 Layer: Consensus (soft fork) Title: TapscriptにおけるOP_CAT Author: Ethan Heilman ethan.r.heilman@gmail.com Armin Sabouri arminsdev@gmail.com Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347 Status: Draft Type: Standards Track Created: 2023-12-11 License: BSD-3-Clause Post-History: 2023-10-21: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [bitcoin-dev] Proposed BIP for OP_CAT 目的と結論 Bitcoin Tapscriptにスタック上の値を連結する操作(OP_CAT)を導入すべきである。これによって、スタック要素同士の結合がシンプルに行えるようになる。現在の最大スタック要素サイズは520バイトを超えないため、TapscriptでOP_CATを再度有効化してもメモリの過度な使用につながらない。結論として、OP_CATはTapscriptの表現力を強化し、より多様なスクリプト構成を行ううえで重要となる。 背景 2010年にBitcoinの初期コードからOP_CATと他のいくつかのオペコードが無効化された。理由として、スクリプト評価時に指数関数的なメモリ使用が起こり得る懸念があった。しかし最大スタック要素サイズの制限(520バイト)が設けられたTapscriptでは、この問題が発生しない。OP_CATが再び有効化されれば、マークルツリーやハッシュ化データ構造の構築など、多くのユースケースで柔軟性が向上する。 概要 このBIPは、OP_SUCCESS126(10進数126、16進数0x7e)として予約されていたオペコードをOP_CATに再定義し、Tapscriptにおいてスタック上位2つの値を連結する操作を可能にするソフトフォークを提案する。旧来のOP_CATと同じオペコード値(126/0x7e)を使用することで混乱を最小化する。 著作権 この文書はBSD-3-Clauseライセンスで公開する。 仕様 スタック上に2つ以上の値がない場合、OP_CATは失敗する。 連結後のサイズが最大スクリプト要素サイズ(520バイト)を超える場合も失敗する。 スタック[x1, x2] (x2が最上位の場合)に対して、OP_CATはx1‖x2をスタックにプッシュする。 tapscriptのOP_SUCCESS126をOP_CATに再定義するソフトフォークにより有効化する。 動機 Tapscriptにはスタック上のデータを組み合わせる汎用手段が不足している。OP_CATが追加されると次のような事例が強化される。 ビットコイン上でのアトミックスワップや分散型ファイルホスティングシステム等、Bitstreamプロトコルの簡素化 ツリーシグニチャを用いた大規模マルチシグの実装(最大4,294,967,296個の公開鍵対応) ポスト量子暗号的シグネチャ(Lamportシグネチャ)の検討 両義性契約やVaultsなどの高度な契約構造 CheckSigFromStack相当の柔軟なスクリプト支出設計 OP_CATはUnix精神に沿うシンプルでモジュール式な機能を提供し、Tapscript開発者が複雑なハッシュ化データ構造を扱いやすくする。かつてOP_CATはBitcoinに存在していたが、無効化された経歴がある。Tapscriptではスタック要素サイズで安全性が担保されるため、再度の有効化が適切と考える。 理由 tapscriptのOP_SUCCESSxオペコードを活用するアップグレード手段を用いる。かつてのOP_CATと同じ値(OP_SUCCESS126)を再定義することで、余計な混乱を防ぐ。スタック要素サイズを引き上げるかどうかは本提案の範囲外である。提案はOP_CAT単体の再有効化を目的とし、ソフトフォーク実装で行う。 下位互換性 tapscript以外のスクリプトにおいてOP_CATを利用するとSCRIPT_ERR_DISABLED_OPCODEとなる。OP_SUCCESS126をOP_CATに再定義するソフトフォークが成立した後、tapscript上だけでOP_CATが有効となる。 参照実装 case OP_CAT: { if (stack.size() < 2) return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); valtype& vch1 = stacktop(-2); valtype& vch2 = stacktop(-1); if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE) return set_error(serror, SCRIPT_ERR_PUSH_SIZE); vch1.insert(vch1.end(), vch2.begin(), vch2.end()); stack.pop_back(); } break; MAX_SCRIPT_ELEMENT_SIZE は520である。 この実装は、OP_CATが無効化される前のBitcoinコード(コミット「misc changes」4bd188c)の内容に基づく。Elements実装(13e1103a)でも類似のOP_CATが確認できる。 ...

https://www.okx.com/learn/what-is-opcat をinputとし、podcastfyを用いて作成したもの。 BIPの歴史と現在：ビットコイン改良提案の本質に迫る 2011年に導入されたBIPの背景と、その民主的なプロセス 初期の頃の非公式なやり取りと、コードレビュー文化の変化 OP_CAT復活への道：BIP 347がもたらす新たな可能性 削除されていたOP_CATが、なぜいま再注目されているのか スクリプトの表現力拡大によるスマートコントラクトの将来像 ビットコインコミュニティの慎重姿勢：合意形成とレビューの意義 BIP承認プロセスのステップと、コミュニティ全体での厳格なレビュー 「Speedy Trial」など過去の合意形成手法からみるアップグレードの難しさ コベナント機能とボールト構想：OP_CATが切り拓く高度なユースケース 資金の使い道を制限する「コベナント」の具体例と利便性 タイムロックで不正送金を阻止するボールト機能の仕組み 対抗するのか、共存するのか：Ethereum的拡張VSビットコインのシンプルさ 複雑化によるセキュリティリスクへの懸念と、拡張機能を求める声のせめぎ合い OPCTVやOrdinalsとの比較から見えるビットコインの今後の方向性 未来のビットコイン：機能性と安定性のバランスをどう保つか スクリプトの拡張で生まれる新たなアプリケーションの可能性 開発者・ユーザー双方にとってのメリットと、コミュニティにおける議論の焦点

『Nexus 情報の人類史 第三章：文書』を読み、編纂プロセスと現代のBitcoinプロトコル開発における類似性を感じた。 以下の記述を分析の出発点とする： 「ラビ」と呼ばれる学識あるユダヤ教徒の賢たちの間で、正典のデータベースが整理され、出回っている多くの巻のうちのどれをヤハウェの公式の言葉として聖書に含めようやく、何世紀も重ねて議論が行われていた。 編纂過程とBitcoinプロトコルの開発には、分散型の合意形成メカニズムという共通点がある。まず、古代のユダヤ教徒の学者集団（ラビ）は地理的に分散しつつ、聖典に採用すべき文書を長期的に検討した。この枠組みは、現代のBitcoinプロトコル開発における開発者コミュニティの意思決定構造と類似する。すなわち、Bitcoin Improvement Proposal（BIP）は多様な専門家らによって提案・議論され、最終的な変更点が合意に至るまでに十分な時間をかける。両者は時間を要する合意形成を重視している点が共通する。ときには数世紀に及ぶのかもしれない。 次に、古代の編纂プロセスでは文書の正統性を議論する際、複数の視点から検証する手法が採用された。Bitcoinにおいても、暗号学的な安全性やネットワーク全体の整合性を多面的に精査する。したがって、多層的な検証システムが両者の決定を堅牢にしている。研究者、開発者、ユーザーなど多彩な立場の検証がなければ、変更提案は合意に至らない。

https://github.com/Blockstream/greenlight/blob/main/docs/src/tutorials/testing.md の翻訳。 このチュートリアルの学習内容 テストの必要性と対象範囲 gl-testingテストフレームワークの概要 gl-testingとプロダクション環境の挙動の差異 前提条件 Git protoc Docker Dockerイメージの使用 環境構築 内部テスト 最初のテスト実装 IDEのオートコンプリーション活用 モックネットワークに対する手動テスト ランダムなポートとディレクトリを使用する理由 The gl-testserver How to use gl-testserver Running multiple tests in parallel このチュートリアルの学習内容 テスト用Dockerイメージの構築と活用方法 Core Lightningノードによるテストネットワークの構築技術 Greenlightテストフレームワークgl-testingの実践的活用法 Greenlightノードを用いた効率的なテスト実装 gl-testing環境でのPython REPL活用技術 テストの必要性と対象範囲 Greenlightを基盤とするアプリケーションを開発した場合、以下の検証が必須である： 現時点での動作確認 将来的な動作の継続性確保 プロダクション環境でのテストは可能だが、次の制約がある： ローカル環境と比較して実行速度が遅い Greenlightサービスのリソースを消費し、コストが発生する ローカル環境で再現性の高いテストを実行できれば、開発効率は大幅に向上する。Greenlightはこの目的に特化したテストフレームワークを提供している。 gl-testingテストフレームワークの概要 Greenlight リポジトリには、完全な機能を備えた（「バッテリー同梱」の）テストフレームワークが含まれている。このフレームワークは、Core Lightning開発にも使用されているpyln-testingをベースとしている。 gl-testingは以下の機能を提供する： 任意の複雑さを持つLightningノードネットワークの構築 Greenlightサービスのローカルモック環境の構築 pyln-fixturesを活用した高度なテスト環境の実現 再現性の高いアプリケーションテスト手法 開発依存関係の隔離 gl-testingとプロダクション環境の挙動の差異 gl-testingとプロダクションシステムの挙動における相違点はgl-testing readmeに記録されている。 このチュートリアルでは、gl-testingを使用して新規Greenlightクライアントの登録からノードでの請求書発行までのテスト実装方法を解説する。また、テストフレームワークやアプリケーションに対して手動コマンドを実行できるREPLの起動方法も説明する。 前提条件 Git gl-testingテストフレームワークはGreenlight Githubリポジトリに含まれている。作業コピーを取得するには、システムにgitのインストールが必要である。インストール方法の詳細はgit-guidesを参照のこと。 protoc 「モックネットワークに対する手動テスト」セクションではホストシステム上でgl-clientをビルドする必要がある。Greenlightはクライアント・ノード間通信にgrpcを使用するため、Protobufコンパイラprotocが必要となる。protocからインストール手順を確認すること。 Docker Greenlightアプリケーションのテストには多数の依存関係（複数のCore Lightningバージョン、多数のPythonパッケージ、rustとcargo、protoファイルコンパイラなど）が必要である。開発環境の整理のため、gl-testingテストフレームワークには必要な依存関係をすべて含む__Dockerfile__が同梱されており、ビルドされたDockerイメージ内でテストを実行できる。 Dockerイメージのビルドと使用には、動作するDockerのインストールが必要である。オペレーティングシステムへのDockerセットアップ方法はDocker manualを参照のこと。 Dockerイメージの使用 Linuxホストでは依存関係の数が多いためDockerイメージの使用を強く推奨する。WindowsおよびMacOSでは、Core LightningがLinux向けx86_64の事前コンパイル版のみを提供しているため、現時点ではDockerイメージによるテストのみがサポートされている。 ...