BRC-20トークンブームの再来によりビットコインの送金手数料が再び高騰している今月、ライトニングネットワークでは送金トラブルなどによるチャネルの強制閉鎖によって大きな出費を強いられるノード運用者が目立ちました。

背景としては送金手数料の高騰以外にもライトニングウォレットのZeusがHodl Invoiceというテクニックを使ったオフライン受け取りを実装したところ、Mutinyというブラウザウォレットとの相性が悪く強制閉鎖を招きやすかったという事情があります。また、Phoenixなど必要に応じてオンチェーントランザクションでライトニングチャネルの容量を拡張するウォレットは当然手数料高騰のあおりを受けてしまいます。いずれにせよ、手数料高騰時の強制閉鎖は金額的なインパクトも大きく、話題になりやすいものです。

また、今年初めの手数料高騰時と比べてビットコインではライトニング以外のレイヤー２ソリューションが多く誕生しており、それらのプロジェクトのポジショントークとしてもライトニングの欠点を宣伝するツイートが増えた印象があります。(実際のところ、自分のライトニングノードには特になにも影響ありませんでした)

今日はその中の１つであるMercury Layerについて、どのような性質のものなのか解説します。Mercury Layerが分類されるレイヤー２の種類であるStatechainsについては過去記事でも触れていますので、ぜひそちらも合わせてご覧ください。

LNを補完するStatechains、サイドチェーンの伏兵Drivechain
最近は特にライトニングネットワークや、その上で様々なアセット・スマートコントラクトを動かせるようになるかもしれないRGBプロトコルなどについて触れてきましたが、今日はLNを「補完する」と表現されることのあるStatechainsと、なかなか議論が進みませんが有力なサイドチェーンの実現方式であるDrivechainについて紹介させていただきます。 どちらも最近あまり注目されていない気がします。 STATECHAINS ビットコインでは通常、トランザクションに秘密鍵で署名して新しい秘密鍵で使用できるアドレスに送金します。Statechainsはこれとは異なり、秘密鍵自体を渡すことでUTXOご…
ビットコイン研究所加藤 規新

・Statechainsのおさらい：UTXOのオフチェーンでの譲渡

・Mercury Layerは運営者のセキュアエレメントを利用

・プライバシーはClient Side Validationで実現

・スケーラビリティの上限は？

Statechainsのおさらい：UTXOのオフチェーンでの譲渡

上述の通り、Mercury LayerはStatechainsと呼ばれる種類のレイヤー２です。簡単に振り返ってみると、Statechainsとは「オンチェーンのUTXOを、オフチェーンで譲渡する」という性質のものです。

具体的には、オンチェーンのUTXOを使用するのに必要な秘密鍵をユーザーAとStatechainsの運営者で分割して保有します。ユーザーAはユーザーBにこのUTXOを譲渡したいとき、Statechainsの運営者と協力して誰も秘密鍵を復元することのないまま新しく分割し直したシェアをユーザーBとStatechainsの運営者で持つという状態に持っていきます。

このとき、運営者と過去の保有者が共謀することによって現在の保有者の協力なしにオンチェーンのコインを使用してしまえるという弱点があります。これは事実上のStatechainの巻き戻しで、これをどう防ぐかが工夫のしどころでした。根本的な解決はされていない問題ですが、Mercury Layerプロトコルを採用したMercury Walletではセキュアエレメントを利用してキーシェアを削除して問題を解決(軽減)していると主張しています。

Mercury Walletはセキュアエレメントを利用

これは賛否が分かれる部分ではありますが、Mercury Walletが運営するBlinded StatechainではIntel SGXというセキュアエレメントを利用して安全性を高めているとアピールしています。Intel SGXとは暗号学的に保護され外部から読み取ることのできない領域内において計算処理を実行するIntel CPUに搭載された技術で、計算内容がセンシティブで結果以外を流出させたくない、あるいは計算処理自体の改ざんを防止したい場合に使います。

Intel SGXの採用によって「Statechain運営者側ではキーシェアの生成に細工したり、古いキーシェアを保存したりしていない」ことをアピールしています。これは上述した運営者と過去のUTXO保有者が共謀して互いのキーシェアを持ち寄ることでカストディを得られてしまう問題に対するアンサーです。

しかしユーザー側から見て「本当にセキュアエレメントを利用しているのか？本当に鍵がセキュアエレメント内で削除され流出していないか？」という疑問を検証することはできない以上、結局のところ運営者に悪意がないことはトラストすることになります。

一方でこのセキュリティ上の問題を悪用するには共謀者(あるいは運営者自身が過去に当該UTXOを保有していた実績)が必要であり、攻撃によって得られる金額が大きくなりにくいため、セキュアエレメント利用の文脈で懸念されがちなバックドアや高度な脆弱性を利用した攻撃の対象にはなりにくい気がします。(より少ない条件でもっと大きな金額を狙える攻撃対象があるため)

プライバシーはClient Side Validationで実現

単純なStatechainの実装にはプライバシー面でも問題があります。なぜなら運営者が必ず送金に介在するため、運営者に送金の情報が筒抜けなためです。対策として運営者が署名する内容をユーザーがBlindingするというものがあり、Mercury LayerではこのBlinded Statechainというモデルを採用しています。

Blinded Statechainにおいて、送金を行うユーザーは運営者に提出する署名対象データを暗号学的にブラインドするため、運営者は署名対象データが何なのかわからないまま署名することになります。運営者が全く内容を検証できないため、送金の正当性を検証するのは送金を受け取るユーザーに任されます。これはRGBなどで採用されているClient Side Validationモデルそのものです。

Client Side Validationについては以下のレポートで解説しています。

RGB＆Taro ビットコイン上のトークン発行は現状どういうレベルで今後どうなるのか？
「ビットコイン上のトークン発行の概要と可能性 〜Client-Side ValidationモデルとRGB、Taro概観」というレポートをDiamond Handsとして公開しました。 日本語レポートダウンロードリンク https://docsend.com/view/6i3fvxzgzww5pujd こちらのレポートは去年から話題に度々上がるRGBやTaroなどのClient-Side Validation型と呼ばれるビットコイン上のトークンプロトコルについて概要を説明し、その仕組みや可能性、解決すべき課題について読みやすいスライド形式でまとめたものです。
Diamond Hands Magazine 💎ビットコイン＆ライトニングニュース🙌Koji Higashi

結果として、送金時に送金者から宛先ユーザーへと過去の送金記録の情報を渡す必要がありますが、運営者に対してはプライバシーが守られやすいという特徴があります。

ちなみに、送金関係が複雑になりデータが膨大になりやすいRGBとは異なり、Statechainにおける送金はUTXOをまるごと(Non-fungibleに)譲渡するので必要なデータが線形にしか増加しない特徴があるため、Client Side Validationとの相性が良い気がします。

スケーラビリティの上限は？

ライトニングのスケーラビリティは１つのチャネル上を累計で流れることのできるトランザクション数に上限がないため「理論上無限大」です。(無論、現実にはチャネル閉鎖を招いてしまうエラーの確率がゼロではなかったり、必要に応じてチャネルを閉じることがあるので無限大ではありません。) ではStatechainsのスケーラビリティ面でのメリットはどれくらいなのでしょうか？

Statechainsの特徴としてユーザーは必ずオフチェーンで「バックアップトランザクション」を保持しており、仮に運営者の協力が得られなくとも自身で保有するUTXOをオンチェーンで使用できるようになっています。しかし、すでに他のユーザーにStatechain上でそのUTXOを譲渡したユーザーがこのトランザクションを使ってしまう可能性はないのでしょうか？

実はその対策として、このバックアップトランザクションには有効化されるタイミングがあり、オフチェーン送金のたびに新しくできるバックアップトランザクションの有効化タイミングが早くなります。(つまり、最近受け取ったユーザーほど早く使えるようになる) したがってバックアップトランザクションには直前のユーザーがバックアップトランザクションを使えるようになってしまうタイミングという「賞味期限」があるのです。

したがって、Statechainのスケーラビリティは無限大とはいきません。Mercury Walletの既定値はhinit (最初の保有者がオンチェーンTXできる前に待つ必要のあるブロック数)=1000, confirmation interval (送金のたびに何ブロック早まるか)=10なので瞬間的に大量のStatechainトランザクションを行った場合の最大効率でも100トランザクションごとにオンチェーントランザクションを行う必要がありそうです。

Statechainに期待される役割の１つは「ライトニングチャネル自体の譲渡」です。StatechainではUTXOをまるごと譲渡するため金額が固定されてしまいますが、そのUTXOがライトニングチャネルであれば柔軟に金額を設定できるし、チャネルを大きくしたいときに古いチャネルを閉じずに売却できればトランザクション手数料もケチれるというわけです。ただし、上記の条件によってチャネルに「賞味期限」があるので、かなりhinitを長く取る必要があるなど少し変わった条件のあるライトニングチャネルになるでしょう。

まとめ

・Mercury LayerはUTXOの所有権をオフチェーンで譲渡するStatechainの実装

・Statechainに特有のセキュリティ上の問題を軽減する方法としてIntel SGXの利用を挙げているが、根本的な解決とはなっておらず、検証することも不可能

・RGBと似たClient Side Validationを使うBlinded Statechainという仕組みになっており、運営者に対してプライバシーも保たれやすい(ただし運営者に対して送金していた場合や後の保有者にデータを公開された場合を除く)

・スケーラビリティ面ではライトニングには劣ると考えられるが、将来的にStatechainsはライトニングチャネルと組み合わせることでさらに応用できる