Statechainsを実装したMercury Layerはどのようなレイヤー２なのか？

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で実現

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