なぜ我々は MCP に全力投球しているのか

https://mastra.ai/blog/mastra-mcp からのllmを用いた意訳である AI エージェント向けツール統合の現状は混沌としている。「MCP Calendar integration」の検索結果からも明らかなように、どの実装が最適かを判断する統一基準がない。ツールの発見、インストール、設定は未解決の課題である。 Mastra では、この問題に取り組み、Anthropic の Model Context Protocol (MCP) が エージェントとツールの相互作用の将来 であると確信している。 競合する標準規格 現在、複数のアプローチが競合している: Agents.json (Wildcard) Agents.jsonは OpenAPI を拡張し、LLM 向けに API 相互作用を最適化する。開発者向け API と LLM 用 API の乖離に対処し、既存 API に文脈情報を補完する。 Composio Composioは独自仕様と豊富な統合ライブラリを提供している。最近はMCP サポートも追加し、選択肢を広げた。 Model Context Protocol (MCP) MCPは Anthropic 管理のオープンスタンダードであり、OSS コミュニティの協力で構築されている。AI アプリケーションの「USB-C ポート」として、LLM を外部ツールに接続する標準インターフェースを提供する。 MCP の課題 MCP エコシステムの主な課題は3つある: Discovery: ツール発見のための標準化された方法がない Quality: 集中管理されたレジストリや検証プロセスがない Configuration: 各プロバイダーが独自の設定スキーマを持つ Shopify CEO の Tobi Lütke はMCP を「LLM ツールの USB-C」と表現しつつも、まだプロトコルだけで「プラグ」が欠けていると指摘している。 コミュニティは Official Registry や .well-known/mcp.json などの規格で問題解決に取り組んでいる。 ...

March 28, 2025

Wallet Recover

mnemonic seedを保持していれば、ウォレットの残高をリカバリーできる。これは一見不思議だが、実際には無限に生成可能なアドレス(script pubkey)のうち、使用されたものだけを検出し、UTXOを取得する仕組みがあるためである。どのアドレスが使われたかを追跡できるからこそ、seedを頼りに残高を復元できる。 しかし、mnemonic seedを持っているのに残高が正しく復旧しないケースも存在する。また、レガシーSegWit(P2SHアドレス・3xxxx)の潜在的な危険性は誤解を生みやすい。これらを整理するために、btc walletの実装(https://github.com/btcsuite/btcwallet)を例にしながら、BIP0044/49/84/86が規定するHDウォレット構造と、ウォレットのリカバリー方法を示す。 BIPの概要と相互関係 BIP0044、BIP0049、BIP0084、BIP0086はいずれもHDウォレットの「目的(purpose)番号」を定義し、各アドレス形式を区別している。以下、それぞれの要点をまとめる。 BIP44 概要: m/44'/coin_type'/account'/change/address_index の構造を規定する汎用的HDウォレット標準。 用途: レガシーP2PKH(1xxxx)アドレスに広く利用されてきた。複数通貨・複数アカウント管理が可能。 他BIPとの関係: 新しいアドレス形式に対応するBIP49やBIP84などは、このBIP44をベースにpurpose番号を変えて並立利用できる。 BIP49 概要: m/49'/coin_type'/account'/change/address_index を使い、P2WPKH-in-P2SH(3xxxx)アドレスを定義。 目的: 互換性を重視しつつ部分的にSegWitの恩恵(手数料削減など)を得るためのラップドSegWit。 他BIPとの関係: レガシー形式(BIP44)を補完し、新しいネイティブSegWit(BIP84)へ移行する中継的役割を果たす。 BIP84 概要: m/84'/coin_type'/account'/change/address_index の構造を使い、ネイティブSegWit(bech32、bc1q…)アドレスを定義。 目的: SegWitの機能をフル活用し、より低い手数料やエラー検知の強化を実現。 他BIPとの関係: ラップドSegWit(BIP49)より進んだ純粋なSegWit。Taproot(BIP86)の前段階。 BIP86 概要: m/86'/coin_type'/account'/change/address_index を使い、Taproot(bech32m、bc1p…)アドレス(単独所有向け)を定義。 目的: Schnorr署名やMASTなどTaprootの恩恵(手数料削減・プライバシー向上)を得る。現時点ではシングルキー中心だが、将来的な拡張も想定。 他BIPとの関係: ネイティブSegWit(BIP84)より先進的なP2TR形態を扱う。purpose番号86を使い、既存形式と衝突しない。 BIP49が「legacy segwit」と呼ばれる理由 BIP49のP2WPKH-in-P2SHアドレス(3xxxx)は見た目が通常のP2SHと同じため、一般に「legacy segwit」とも呼ばれる。P2SHの場合、redeemScriptをユーザ側で保持する必要があるが、BIP49対応ウォレット(例: 多くのハードウェアウォレットなど)を使うなら、redeemScriptを個別にバックアップしなくても済む。 https://github.com/btcsuite/btcwallet/blob/master/waddrmgr/address.go#L554 アドレスインデックスとリカバリー アドレスインデックス(address_index)はウォレットが生成したアドレス数に応じて変化する。復旧時には何番目までアドレスを生成してスキャンするかを決める必要がある。btc walletでは以下のアルゴリズムにより、使用中のアドレスを取りこぼさずに効率的なブロックスキャンを行う。 sequenceDiagram participant RM as RecoveryManager participant RS as RecoveryState participant BRS as BranchRecoveryState participant BC as Blockchain Note over RM: (Resurrectで<br>既存のアドレス・UTXOを復元) loop until 全ブロックスキャン完了 RM->BC: 次のブロック(群)取得 BC-->RM: BlockBatch返却 RM->RS: State取得 RM->>BRS: ExtendHorizon()呼び出し alt horizonが不足 BRS->>BRS: horizonを拡張<br>(nextUnfound + recoveryWindow) note right of BRS: 無効インデックス数も考慮 end RM->BC: FilterBlocksRequest(生成済みアドレスを照合) BC-->RM: FilterBlocksResponse(発見されたaddrのindex) RM->>BRS: ReportFound(index) alt 新しい発見がありnextUnfoundが進む BRS->>BRS: horizon再チェック end end Note over RM: 発見された中で最も高いインデックス +<br>recoveryWindow + 無効インデックス数まで生成し続ける Resurrect 既知のアドレスやUTXOを RecoveryState に登録し、初期状態をセットする。 ExtendHorizon nextUnfound + recoveryWindow (+ 無効インデックス数) までアドレスを導出・監視対象に加えておき、取りこぼしを防ぐ。 FilterBlocks 実際にブロックをスキャンし、高いインデックスのアドレスが見つかったら ReportFound で更新し、さらに horizon を見直す。 最終的に 最も高いインデックス + recoveryWindow + 無効インデックス数まで検査し、使われている可能性のあるアドレスを漏れなく拾う。 注意 このアルゴリズムはbtc walletの実装に基づくものであり、他のウォレット実装には異なる部分があるかもしれない。 また、recoveryWindowは、250が設定されている。 一般的なユースケースでは考えづらいが、250以上、indexが連続していない場合は、リカバリーが不完全になる可能性がある。 ...

March 27, 2025

elip-0200

ELIP 0200の日本語訳。Elements Improvement Proposals (ELIPs) は、BitcoinのBIPに相当するElementsプロジェクトの改善提案である。 この記事はllmによる機械翻訳に基づく。誤りの可能性がある点に留意すること。 この内容はcommit hash 9f08b8168328691c1bff6e0261cebbe985f39ae4 時点のリポジトリを参照している。 ELIP: 200 Layer: Applications Title: Confidential Transactions の割引料金 Author: Byron Hambly bhambly@blockstream.com Comments-Summary: まだコメントはない Comments-URI: https://github.com/ElementsProject/elips/wiki/Comments:ELIP-0200 Status: Draft Type: Standards Track Created: 2024-06-19 License: BSD-3-Clause はじめに 概要 Confidential Transactions (CT) の取引手数料を割引する方法を提案する。これにより、ウォレットが割引手数料率を算出可能になり、ノードが割引されたCTをリレー・採掘するための要件を定義する。 Copyright 本書は3条項BSDライセンスの下で公開している。 Motivation ElementsにおけるCTは、明示的な取引よりサイズが約10倍大きい。 Pedersenコミットメントやアセットコミットメント、ECDHエフェメラルキーなどが追加され、さらにレンジプルーフとサージェクションプルーフを含むウィットネスデータが大きな要因である。 サイズが大きいほど手数料が高くなるため、ユーザがCTによるプライバシーを犠牲にし、明示的な取引を選びやすくなる可能性がある。 このELIPは、ElementsでCTを割引料金で受け入れるポリシー変更を提案し、CTと明示的な取引を同等の手数料規模に近づけ、明示的取引優先の動機を下げる。 Design Overview 新たに「discount virtual size (discountvsize)」を導入する。 明示的な取引では通常のvsizeと実質同じ値となるが、CTでは秘密出力が含まれるたびに、各出力分の重みを仮想サイズ計算の前に減少させる。 ウォレットは、この割引計算を用いて手数料を推定し、ノードはメンプールへの受け入れやピアへのメッセージングでdiscountvsizeを利用する。これによってCT取引の中継と採掘が行われる。 欠点 ディスカウントを導入すると、実際のコストは表面上の手数料率より低くなる。 既存のブロックアセンブラは先祖手数料率が高い取引から優先するため、割引CTは同じ「表面料金率」の明示的トランザクションなどより選択が遅れる。 この状態を解消するには、ブロックアセンブラ側で割引された仮想サイズを基準に手数料率を扱うよう変更が必要だが、最大料金追求よりCTのプライバシー優先を許容するというトレードオフとなる。 仕様 ウォレット ウォレットは通常の手順で取引を作成し、まずプレースホルダーの手数料出力を含める。 ダミー署名を埋め込んだ後、BIP-01411 に従い以下の式で重みを算出する: Weight = (Base transaction size * 3) + Total transaction size ...

March 24, 2025

[podcast]OP_CTV

https://d-central.tech/understanding-op_ctv-bip-119-in-bitcoin/ をinputとし、podcastfyを用いて作成したもの。 「次世代ビットコインへの扉:OP_CTVがもたらす革新とは?」 今回のポッドキャストでは、ビットコインの新提案「OP_CTV (BIP 119)」を切り口に、ビットコインがどんな未来を描こうとしているのかを探ります。秘密鍵を盗まれても即時に資金を抜かれない「ボルト(Vault)」機能や、複数人で1つのUTXOを共有できるShared UTXOによるスケーラビリティ改善など、セキュリティ・プライバシー・効率性を大幅にアップさせる可能性が語られました。 一方で、政府の“ホワイトリスト”強制への懸念や、新機能導入による複雑化・セキュリティリスクも話題に。ビットコインが一貫して大切にしてきた「慎重で分散的な進化」は、OP_CTVにも当てはまります。ソフトフォークを経たコミュニティ合意が必要なことや、新機能の意義が正しく理解されるかが鍵。ビットコインの「堅牢さ」と「革新」がどう共存していくのか、目が離せない展開です。

March 24, 2025

CTV Template Hash詳細

templateはなにが可変であり、なにが固定なのか、を整理する。 様々な場所に情報があるが、BIPに記されたpython codeを見るのが一番良い。 def ser_compact_size(l): r = b"" if l < 253: # Serialize as unsigned char r = struct.pack("B", l) elif l < 0x10000: # Serialize as unsigned char 253 followed by unsigned 2 byte integer (little endian) r = struct.pack("<BH", 253, l) elif l < 0x100000000: # Serialize as unsigned char 254 followed by unsigned 4 byte integer (little endian) r = struct.pack("<BI", 254, l) else: # Serialize as unsigned char 255 followed by unsigned 8 byte integer (little endian) r = struct.pack("<BQ", 255, l) return r def ser_string(s): return ser_compact_size(len(s)) + s class CTxOut: def serialize(self): r = b"" # serialize as signed 8 byte integer (little endian) r += struct.pack("<q", self.nValue) r += ser_string(self.scriptPubKey) return r def get_default_check_template_precomputed_data(self): result = {} # If there are no scriptSigs we do not need to precompute a hash if any(inp.scriptSig for inp in self.vin): result["scriptSigs"] = sha256(b"".join(ser_string(inp.scriptSig) for inp in self.vin)) # The same value is also pre-computed for and defined in BIP-341 and can be shared. # each nSequence is packed as 4 byte unsigned integer (little endian) result["sequences"] = sha256(b"".join(struct.pack("<I", inp.nSequence) for inp in self.vin)) # The same value is also pre-computed for and defined in BIP-341 and can be shared # See class CTxOut above for details. result["outputs"] = sha256(b"".join(out.serialize() for out in self.vout)) return result parameter precomputed must be passed in for DoS resistance def get_default_check_template_hash(self, nIn, precomputed = None): if precomputed == None: precomputed = self.get_default_check_template_precomputed_data() r = b"" # Serialize as 4 byte signed integer (little endian) r += struct.pack("<i", self.nVersion) # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", self.nLockTime) # we do not include the hash in the case where there is no # scriptSigs if "scriptSigs" in precomputed: r += precomputed["scriptSigs"] # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", len(self.vin)) r += precomputed["sequences"] # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", len(self.vout)) r += precomputed["outputs"] # Serialize as 4 byte unsigned integer (little endian) r += struct.pack("<I", nIn) return sha256(r) OP_CHECKTEMPLATEVERIFY(OP_CTV)は「将来使われるトランザクションの形をあらかじめ決めておき、そこから外れる支払いを無効とする」仕組みを提供する。したがって、意図しない送金や改ざんを防ぎながら、VaultやChannel Factoryのような特定用途の“Covenant”機能をシンプルかつ安全に実装できる。 ...

March 24, 2025

bip-0119

BIP 119の日本語訳をおいておく。 この記事は、llmにより翻訳されたものであり、内容に誤りがある可能性はある。 BIP 119は、新しいオペコード OP_CHECKTEMPLATEVERIFY を有効化することを提案しており、このブログを書いた段階で、有力な選択肢となっている。 Developer Consensus May Be Converging on a Bitcoin Soft Fork Proposal: Blockspace なお、この記事は、commit hash88c0fb9b5b7c3ed73386224c8c4ae0fd4fc3537f 時点のものとなっている。 Abstract Summary Motivation Detailed Specification デプロイ 参考実装 根拠 The DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stack Committing to the version and locktime Committing to the ScriptSigs Hash インプット数へのコミット シーケンスハッシュへのコミット アウトプット数へのコミット アウトプットハッシュへのコミット 現在のインプットのインデックスへのコミット Committing to Values by Hash Using SHA256 Using Non-Tagged Hashes The Ordering of Fields 設計上のトレードオフとリスク Denial of Service and Validation Costs 永久に使用できない出力 転送アドレス NOP-Default and Recommended Standardness Rules 機能の冗長性 将来的なアップグレード CHECKTEMPLATEVERIFY バージョン OP_CHECKSIGFROMSTACKVERIFY OP_AMOUNTVERIFY OP_CAT/OP_SHA256STREAM Backwards Compatibility スクリプト互換性 References 類似した代替案について 著作権 BIP: 119 Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY Author: Jeremy Rubin j@rubin.io Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119 Status: Draft Type: Standards Track Created: 2020-01-06 License: BSD-3-Clause ...

March 22, 2025

[podcast]Covenants Everything

https://www.adoptblock.com/covenants-op-cat-op-ctv-english をinputとし、podcastfyを用いて作成したもの。 gpt-4o-mini-ttsを使うことで実用に耐える音声品質になった。 ビットコインのスケーラビリティ課題とKaspaとの比較 ビットコインのSidechainやLightningなどの拡張方法 Kaspaは高速だが、フルノードでない点がセキュリティ上の妥協になる ビットコインScriptとコヴナンツ入門 UTXOモデルとスタックベースの簡素な言語設計 コヴナンツ(Covenants)で“UTXOの使い方”を厳しく制限・管理できるアイデア 主なコヴナンツの種類と特徴 トランザクションのハッシュ検証型、トランザクション内容検証型など 再帰的に制限をかけることで、予期せぬ流動性の低下やファンジビリティ低下リスクがある OPコード(オペコード)の拡張 過去に無効化されたOP_CAT再導入と、そのメリット・懸念 OP_CHECKTEMPLATEVERIFY (OP_CTV) などのシンプルなコヴナンツ実装案 それぞれのアプローチのトレードオフ(柔軟性と安全性のバランス) ライトニングネットワークやEltooとの関係 ANYPREVOUT (BIP-118) でチャネル管理をシンプル化 Vaultのアイデアなど、資金盗難への対抗策も議論される ビットコイン開発の進め方 SegWitやTaprootの導入にも長いテストと合意形成が必要だった 大規模変更ほど、実装リスクとコミュニティの議論に時間を要する 今後の展望と注意点 コヴナンツ導入でDeFi的な活用も見据えられる ただし、BTCのファンジビリティや可用性を損なう恐れもあり、慎重な検証が必須

March 21, 2025

Github Copilot Chat Commit Message Rules

コミットメッセージを標準化するには、github.copilot.chat.commitMessageGeneration.instructionsを設定し、Copilot Chatが常に所定のルールに従うよう誘導するのが効果的である。たとえば、以下のように.vscode/settings.jsonに記述する。 他にも多様な方法があるが、ボタンをクリックするだけで設定できるため、結局これが使われていることが多いように思われる。 { "github.copilot.chat.commitMessageGeneration.instructions": [ { "text": "以下のルールに従ってコミットメッセージを生成:\n"+ "1) 1行目は50文字以内\n"+ "2) 本文が必要なら72文字幅で改行し、1行目と本文の間に空行\n"+ "3) 現在形で書く (例: 'Fix bug', 'Add feature')\n"+ "4) サブシステムやパッケージ名を先頭に (例: 'wallet: ')\n"+ "5) 箇条書きはハイフン(-)またはアスタリスク(*)で始める\n"+ "6) 最後に 'Generated by Copilot' と記載" } ] } Copilot Chatは、この設定を参照してコミットメッセージを提案する。結果として、コミットメッセージの書式を一貫させ、読みやすい履歴管理を実現できる。commitlintなどと併用すれば、さらに厳格なバリデーションを行うことが可能である。

March 21, 2025

Wifi Off

Wi-Fiを強制的にオフにすべきである。ネットからの通知やチャットへの意識を一掃し、思考を乱す要因を遮断できるからである。プログラミングや文章作成など、深い集中が必要な作業では特に有効である。 Wi-Fiを切る前に必要資料をあらかじめ開いておくことが望ましい。ネット接続が必要な箇所は作業後にまとめて調べるべきである。スクリプトを用いれば、一定時間オフにしたまま強制的に待機できる。たとえばmacOSでは、以下のワンライナーが使える。 networksetup -setairportpower en0 off && sleep 1800 && \ networksetup -setairportpower en0 on && \ osascript -e 'display notification "WiFiが復活しました" with title "通知"' 資料を読み込み、作業に没頭し、後で必要部分のみ確認すればよい。緊急の連絡が想定される場合は注意が必要だが、そうでないならオフラインで集中すべきである。この手法によってフロー状態を維持しやすくなり、結果的に作業効率が上がると断言できる。 または、私の実装したcliを使えば、より高度に設定することができる https://github.com/YusukeShimizu/rust-pomo rust-pomo --focus 1200 --break-time 600 --cycles 2 === Cycle 1/2: Focus time === Setting WiFi off Starting timer for 1200 seconds... [####################--------------------] 594s / 1200s

March 21, 2025

Greenlight における Scheduler と Signer/HSM のアーキテクチャ

greenlight proto をベースにした解説。 greenlightはLightning Network(LN)の運用を簡易化するためのサービスである。しかし、どこが自己ホスト(self host)で、どこに信頼を置く必要があるのかが分かりにくい。SchedulerはLNノードの管理やスケジューリング機能を担うが、これは非公開のコードで動作し、ユーザーはその内部を直接検証できない。一方、Signerはトランザクション署名を行う重要なコンポーネントであり、cln(Core Lightning)はLightning Networkの実装である。これらは公開リポジトリとして誰でも参照できる。 目的と結論 Greenlight では、Scheduler (Closed Source) が Node 管理の中心にあり、UserClient (with integrated Signer/HSM) が Self-Hosted 環境で秘密鍵を保持する構造をとる。結論として、UserClient 側が鍵操作を制御しつつ、Greenlight 側の Scheduler が Node (CLN) を起動・管理する。これにより、秘密鍵をローカルで保持したまま Node をリモートで稼働させる運用が可能となる。 全体構造 以下の図に示すように、UserClient (with integrated Signer/HSM) は自前の環境 (Self-Hosted) で動作する。一方、Scheduler は Greenlight が管理し、CLN (c-lightning+plugin) も Greenlight Hosted 環境で稼働する。UserClient は Scheduler に対して Manage API call を行い、Node に対する操作は Scheduler が CLN を経由して実行する。Signer/HSM は秘密鍵をローカルで保持し、署名要求のみを受け付ける。 (Self-Hosted) (Greenlight Hosted) +-----------------------------------+ (Manage API call) +----------------------------+ | UserClient (with integrated | --------------------> | Scheduler (Closed Source) | | Signer / HSM) | +-------------+--------------+ +-----------------------------------+ | | (Node management) | v | +------------------------+ |-----------------------> |CLN (c-lightning+plugin)| +-----------+------------+ ノード登録とスケジューリングフロー チャレンジ発行 (GetChallenge) スコープ (REGISTER や RECOVER) と node_id を指定し、Scheduler に GetChallenge をコールする。 Scheduler は一度きり有効な challenge を生成し、ChallengeResponse に含めて返す。 Register / Recover クライアントは challenge を秘密鍵で署名し、node_id、network、CSR などと共に送信する。 Scheduler は署名検証後にノード所有権を確認し、mTLS のための device_cert と device_key を発行する。 Register は新規発行、Recover は既存ノードの証明書再発行となる。 Schedule / GetNodeInfo クライアントは Schedule を呼び出し、ノード起動をリクエストする。 Scheduler は CLN を割り当て、grpc_uri など接続情報を返す。 すでに起動済みの場合、GetNodeInfo で接続情報を取得可能である。 接続・操作 クライアントは取得した device_cert と device_key を用い、mTLS で CLN (node) に接続する。 支払いやチャネル操作などの RPC 呼び出しを行う。 署名が必要な場合、CLN は Signer (HSM) へ HsmRequest を送信し、秘密鍵を外部に渡さずに署名のみを実行する。 Signer フロー (HSMRequest / HsmService) CLN は秘密鍵が必要なとき、Node Service の StreamHsmRequests を用いて外部サイナー (Signer/HSM) へ HsmRequest を通知する。Signer はローカルで署名を実施し、HsmResponse で返す。具体的な流れは以下の通りである。 ...

March 19, 2025