BitVM、Hodl Contracts、UTXO Dealershipなどの生みの親で、新しいアイデアを形にすることが得意な開発者であるSuper Testnet氏が今週「Hedgehog」と命名した新しいレイヤー２プロトコルを発表しました。

2-of-2のマルチシグに入金するペイメントチャネル型のレイヤー２であるところまではライトニングに類似していますが、裏側の仕組みはよりシンプルになっています。新しい構造を可能にしたのは新しい技術というよりはビットコイントランザクションと署名の組み合わせ方の工夫です。

今日はそんなHedgehogについて簡単に紹介してみます。

・Hedgehog特有の長所を従来のライトニングチャネルと比較する

・State Channel型のレイヤー２に取り組み続ける意義

Hedgehog特有の長所を従来のライトニングチャネルと比較する

Super Testnet氏自身、解説動画においてHedgehogのライトニングに対する優位性を「非同期的（宛先がオンラインでなくてよい）」「シンプルである」ことだと考えていることを説明しています。

ライトニングチャネルと比較してシンプルな仕組み

ライトニングチャネルは2-of-2マルチシグへのファンディングトランザクションから２者間で資金を分配するコミットメントトランザクションを作成し、さらに送金ごとにHTLCを作成するトランザクションを追加・決済時にコミットメントトランザクションの更新を行うなど、かなり手の込んだプロトコルとなっています。

その反面、Hedgehogチャネルは2-of-2マルチシグに入金してからはConnector OutputsとRevocable Scriptsというものを組み合わせただけです。

Revocable Scriptsはライトニングでもおなじみの(Alice after 2016 blocks) OR (Bob && Alice_Secret)というような使用条件のスクリプトです。この例では、Aliceは2016ブロック待つことで資金を回収できますが、Alice_SecretをBobに渡すことでその権限を放棄（Revoke）することができます（＝Bobに明け渡せる）。

Connector Outputsは2021年にJeremy Rubin氏がbitcoin-devメーリングリストに投稿したコンセプトで、要するにトランザクションに別のUTXOを入力として追加することでそのUTXOを「使用条件」とみなすことができるものです。

例えば(Alice && Bob)という条件のマルチシグアドレスからの送金に、Bobが別のUTXOを入力として追加してからSIGHASH_ALLで署名した場合、そのトランザクションからBobが追加した入力を外すとBobの署名は無効となります。

これを発展させて、Hedgehogでの送金はこのように行います：

(Alice && Bob)のHedgehogチャネルにAlice側の資産が10,000 sats入ってるとします。AliceがBobに2,000 sats送りたいとき、彼女は2つのトランザクションと署名をBobに送りつけます。（総額が少し減っていくのはトランザクション手数料として確保されている分です）

トランザクション１：
　　入力：(Alice && Bob) 10,000 sats
　　出力：(Bob after 2016 blocks) OR (Alice && Bob_Secret) 330 sats (dust limit)
　　出力：(Alice && Bob) 9,500 sats
このトランザクションにおいて、１つめの出力は後にRevocable connectorとして使用し、２つめの出力はHedgehogチャネルの本体として使用し続けます。

トランザクション２：
　　入力：(Alice && Bob) 9,500 sats
　　入力：(Bob after 2016 blocks) OR (Alice && Bob_Secret) 330 sats
　　出力：Bob 2,000 sats
　　出力：Alice 7,500 sats
こちらのトランザクションが送金の本体で、先程のRevokable Connectorを使ってチェーンされていることがわかります。

Bobはチャネルを決済したいと思ったらトランザクション１を署名・配信し、その後2016ブロック経過後にトランザクション２を署名・配信することで最終的な残高2,000 satsを手に入れることができます。(そのとき、Aliceも7,500 sats入手）

もちろん決済せずに使い続けることもできます。その場合はRevocable ConnectorのSecretを開示することでトランザクション２からチャネルの状態を初期化し、新たなRevocable Connectorを作成して上の手順を繰り返します。チャネルの状態を初期化してもマルチシグからの送金には相手の署名が必要なため、勝手に全額を送金されることはありません。

逆に言えばマルチシグの相手が消えると資金がロックされてしまう仕組みになってしまいます（悪意があれば資金を人質に取れる）が、Hedgehogチャネルに寿命を設定することで問題を回避する仕組みも併せて提案されています。

受け手がオフラインでも送金自体はできる

このように、Hedgehogではやりとりされるものは新しいトランザクションや署名といった情報であり、１回のステート更新（残高分布の更新）に際して何度も情報をやりとりする必要がありません。その結果、送金相手がオンラインではないときでも送金情報を送りつけることで送金自体は可能です。

リアルタイムのやりとりが必要なわけでもないので、ややこしい通信プロトコルも必要ありません。メールやSNS、Nostr経由でも送金できます。もちろん、受け手が実際に検証可能な形で「受け取る」にはウォレットに読み込んで確認する必要がありますが。

相手のオンライン状態を気にしない完全なプッシュ型であるがゆえにマルチホップの送金をどのように実現するかに難点があるように思いますが、シンプルさを捨ててHTLCを再導入することで解決できるかもしれません。その一方でシングルホップの送金に特化した仕組みになる可能性もあります。もちろん、大して普及せずに廃れる可能性だってあります。

State Channel型のレイヤー２に取り組み続ける意義

今年に入って爆発的に増加している「ビットコインのレイヤー２」を自称するプロジェクトですが、その大半はサイドチェーンのような仕組みになっています。一方でビットコイナーが従来から取り組んでいるものの多く（ライトニングネットワークやStatechainsなど）はユーザーが直接レイヤー１に決済できるState Channel型と呼ばれる種類のものです。

自称レイヤー２の多くは実際には（サイドチェーンの運用者が消滅・敵対的などの）過酷な条件下でユーザー単独でExitできないものであり、従来のレイヤー２の定義には当てはまりませんが、State Channel型のものは非常に自己主権的なものばかりで資金を盗られてしまうリスクは低いように感じます。

どのような種類のレイヤー２でもMass Exit Problemと呼ばれる問題があり、ユーザーが一気にオンチェーンに「脱出」しようとする場合にオンチェーン手数料の高騰から不具合や逃げ切れなかったユーザーが発生してしまう可能性があり、これはState Channel型にも共通の問題ではありますが、特にサイドチェーン型のレイヤー２はオフチェーンスケーリングの競争という側面がある以上、より多くのユーザー、トランザクションを受け入れるため、Mass Exit Problemの問題も大規模化するのではないでしょうか。

特にBitVMを利用したExit方法が実装されたとして、それにどれくらいのコストがかかるのかは大きな問題となっていくでしょう。

金融系のユースケースなどがあり高額の資金を預けているユーザーが多ければ多いほどオンチェーン手数料も高騰すると考えられるため、実際にトラストレスといえる預入金額の水準がかなり高くなる可能性もあります。

State Channel型のネットワークが全体規模でクラッシュしてオンチェーン決済するならまだしも、決済するかしないかはあくまでチャネル単位の問題なので場合によってはState Channel型のほうが（通常時は高コストの可能性もありますが）逃げやすい・トラストレスと捉えやすいかもしれません。

1つ1つのペイメントチャネルを「２者間のフェデレーション」と整理して２つのアプローチを一般化しようとする流れもあり、ビットコインのレイヤー２に対する関心は今後も高い水準で継続しそうです。