LightningPeach Walletの紹介

今回はLightning Networkの研究チームであるLightningPeachがリリースしたLightningPeach Walletについてのご紹介です。本ウォレットはまだテストネット版、かつベータテスト期間中でまだまだ開発途上ですが、とてもユニークな機能があり必見です！

LightningPeach Wallet

Lightning Networkを専門で研究調査しているLightningPeachがテストネット版としてリリースしたデスクトップ型のウォレットです（ダウンロードはここから）。このウォレットはLND上で動作することが前提ですが、ウォレットに付随されているので、自前でインストールする必要はありません。ただし、ビットコイン（bitcoind）がPC上で稼動している必要があります。

新機能

LightningPeach Walletの特徴として３つの機能があります。（これらの機能はLightningPeach Wallet同士のみで可能となります）

• インボイス不要のライトニングペイ

Lightning IDを使って、ビットコインの送受金がオフチェーンで可能です。通常のライトニングペイは受取者がインボイスを発行し送金者へ送付しないと、送金できませんが、この機能は直接送金者から受取者へコインを送金できます。

• ストリームペイメント

毎秒単位でビットコインの支払いができる機能です。例えば、動画や音楽のストリーミングをしている間、支払いをすることができ、視聴をやめたところで支払いが止まるようなサービスを作ったりできるようになります。

• アドレス帳

ライトニングノード毎に名前をつけることで、支払い先相手を選択することができます。これによって、いちいちLightning IDを覚えておいたり、コピー＆ペーストする必要がなくなります。

実際に使ってみた

今回はWindows版をインストールしてテストネット上で使ってみました。

（１）プロフィール画面

セットアップが完了し、プロフィールを確認します。Lightning IDとはノードIDのことです。

（２）チャネル開設

チャネルタブからチャネルを開設します。カスタムチャネルにチェックをすると指定したLNノードとの開設ができますが、チェックなしでデフォルトでまずはチャネルを開設します。このデフォルトは、LighningPeach Walletノードとチャネルを開設してくれるので、新機能のLightnig IDを使ってインボイスなしにライトニングペイしたり、ストリームペイメントが可能になります。

（３）ライトニングペイ！

通常のライトニングペイですが、Toで送金先を選択するだけで、インボイスなしで送金できます。これはすごい！

（４）ストリームペイメント

ストリームペイメントはまず、毎秒いくらのコインを送金するかと、送金時間の上限を設定します（本例は1秒ごとに10satoshiで60秒を上限としています）。設定完了後、再生ボタンを押すことで１秒ごとにコインが送金できました。これもすごい！

所感

ライトニングの仕様上、現状は受取者がまずはinvoiceを発行し、それを送金者へ渡さないと支払いができませんが、LightningPeach Walletを使うと送金者がいきなり受取者に支払いができます（受取側のウォレットが起動している必要はありますが）。LightningPeach Walletを持っている人同士であれば、お互いがIPアドレスを公開することなくライトニングペイできるので、今後モバイルウォレット対応したりできるととても便利になると思われます。

ストリームペイメントも面白い機能ですが、現状はウォレット同士でストリームペイメントは使わないかなと思います。ただ、この機能により動画や音楽も聞いている間に支払うということができるので、今後のマイクロペイメントのあり方が大きく変ってくるかもしれません。

現状、ベータテスト期間で支払いや受取がうまくできないことも多々あります。他にも、チャネル開設時のファンディングトランザクションを作るときに手数料を指定できず、なかなかトランザクション承認が得られなかったです。今後の改善に期待したいです。

Lightning Network 2.0

はじめに

今回はAbacus社のDaniel氏によるライトニングネットワーク2.0についての見解を参考に、ライトニングネットワークが抱える問題とその解決策のダイジェストとして書いています。各解決策のコンセプトを簡潔に書いており、技術的な詳細は末尾の参考欄に日本語解説ページのリンクを載せてあるので、詳細をじっくり読みたい方はそちらを参考にしてください。

[toc]

ライトニングの問題を3つのカテゴリへ

ライトニングが抱える問題を大きく3つのカテゴリへ分けると以下のようになります。

• 限られたコイン量しか送受信できない流動性の低さ
• 限られた相手しか送受信できないルーティングの低さ
• ノードを常にオンラインに保つ必要がある難しさ

以下にそれぞれの問題と解決策について紹介していきます。

問題1 チャネル間の流動性

ライトニングは2者間で送受信できるコイン容量を決めます。例えばアリスとボブの間で以下のチャネルがあったとします。この場合、アリスはボブへ2BTC送金可能ですが、それ以上のコインの送金はできません。

• Alice 2–0 Bob

また、アリスがボブへ2BTC送金した場合（以下の図を参照）は、アリスはボブへ送金できなくなり、一度チャネルを閉じて新たらしチャネルを開く必要があります。

• Alice 0–2 Bob

このようにライトニングネットワークはコインの流動性が低いという問題を抱えています。そこで、以下に流動性の低さを解決するいくつかの案を紹介します。

AMP（エーエムピー）

複数のチャネルを一つのチャネルと見たてて相手に送金する仕組みです。例えば、アリスがボブとキャロルに対してそれぞれ0.5BTCのチャネルがあり、またボブ、キャロルはデビッドに対して0.5BTCのチャネルがあるとします。通常だとアリスがデビットへ1BTCを送金することはできません（ボブへもキャロルへも1BTCぶんのチャネルが無いため）。AMPは、アリスが持つ2つのチャネルと、デビッドが持つ2つのチャネルを、まとめて1つのチャネルとみなすことで、1BTCをデビッドへ送金することを可能にします。

Splicing（スプライシング）

ライトニングネットワークを使用するには、あらかじめ相手と資金の容量を決める必要があります。例えば、アリスがボブへ1BTCのチャネルを開設すると、アリスがボブへ最大で1BTCしか送金できません。もしアリスが1BTC送金した場合、彼女はそれ以上何もすることができません（ボブが送り返してくることを除いて）。また、アリスは残っているBTCをオンチェーン決済したい場合もあるでしょう。このような状況で、チャネルを閉鎖することなく、ライトニングの資金をチャージしたり、オンチェーン決済することを可能にするのがスプライシングです。

Submarine Swap（サブマリンスワップ）

オンチェーンとオフチェーンの資金交換の橋渡しをする仕組みです。アリスはオンチェーンのビットコインを持っており、ボブはライトニングネットワーク上（オフチェーン）にビットコインがあるとします。ここでアリスがボブの持つオンチェーンのビットコインアドレスへ送金し、ボブはアリスがもつライトニングネットワークのアドレスへ送金します。ここで暗号トリックを使うことでお互いが不正せずにそれぞれの資金を送金することができます。

Channel Factories（チャネルファクトリー）

ブロックチェーンとライトニングネットワークの間にもう1階層新たに入れようと提案しているのがこのチャネルファクトリーの面白いところです。通常のライトニングのFunding Txは1：1のマルチシグですが、チャネルファクトリーではN：Nのマルチシグを使います。例えば、アリス、ボブ、キャロル、デイビッドの4人がそれぞれ2BTCをデポジットします。

• アリス：2
• ボブ：2
• キャロル：2
• デイビッド：2

次に、アリスとキャロルの間でチャネルを開くことを決めたとします。そこで2人は2：2マルチシグのFunding Txを作り、これをボブ、デイビッドへブロードキャストします（ブロックチェーンにはブロードキャストしません！）。

• アリス：1
• ボブ：2
• キャロル：1
• デイビッド：2
• アリス／キャロル：2（←ここがペイメントチャネルとなる）

この時点でアリスとキャロルは、他の誰（この場合ボブとデイビッド）とも干渉せず2BTC上で送受信することができます（これはライトニングと同じですね）。さらに、ボブとキャロル間で取引をしたい場合、先と同様に2者間で2BTCのFunding Txを作り、皆へブロードキャストします（再度、ブロックチェーンへはブロードキャストしません）。そうすると以下のような状態になります。

• アリス：1
• ボブ：1
• キャロル：０
• デイビッド：2
• アリス／キャロル：2（←ここがペイメントチャネルとなる）
• ボブ／キャロル：2（←ここもペイメントチャネルとなる）

ここでチャネルファクトリの良い所が分かります。それは、キャロルはアリスとボブに対しての2つのチャネルを開設しましたが、ブロックチェーンにブロードキャストしたのは最初の4：4マルチシグの1回だけです。このように一旦、N：Nマルチシグを挟むことで、その上にライトニングネットワークのような2者間ペイメントチャネルを開くことがコストなしで可能になります。

Duplex Micropayment Channels（デュプレックスマイクロペイメント）

DMCはChristian DeckerとRoger Wattenhoferによって提唱されたビットコインのスケーリング案の1つです。ペイメントチャネルで重要なのは、「どうやって最新状態の残高のみをブロックチェーンに書き込むか」です。ライトニングネットワークの答えは、「もし古い状態の残高をブロードキャストしたらペナルティとしてすべての残高を没収する」ことです。それと異なりDMCの答えは、「最新の残高をブロードキャストできる期間を設け、それ以外の古い残高は無効とする」ことです。

アリスとボブはそれぞれ1BTCをデポジットしてチャネルを開設したとします。ライトニングの双方向ペイメントチャネルと違い、DMCは一方向ペイメントチャネルです。2者間で2つのチャネルを持ちイメージです。アリスとボブはそれぞれのチャネルで相手に1BTC分送金が可能です。さらにこのチャネルにはタイムロックが設定してあります（本例は100日）。これは100日後にこのトランザクションは有効となり、ブロックチェーンにブロードキャストすることができます。

      1    —   0

Alice             Bob  Timelock = 100 days

      0    —   1

ここで例えば、アリスがボブへ1BTC送金し、ボブがアリスへ0.5BTC送金したとすると以下のような残高になります（アリスは0.5BTC、ボブは1.5BTC）。アリスは0.5BTC持っているのに、アリスー＞ボブのチャネルは０：1でアリスは送金できません。

      0    —   1

Alice             Bob  Timelock = 100 days

      0.5  —  0.5

そこで、お互いのチャネル残高を”リセット”して新しいチャネルを作ります。ここで重要なのがTimelockを減らし、先のチャネル状態を無効にすることです。これでアリスはボブへ0.5BTCを送金することが可能になりました。

      0.5  —   0

Alice             Bob  Timelock = 99 days

      0    —  1.5

DMCの欠点としては、リセットの回数が有限であることです。本例では100回のリセットが上限となります。リセットが上限に達した場合は、”リフレッシュ”をすることで、Timelockの上限を0日から100日へ戻すことができますが、このリフレッシュをするにはオンチェーンのトランザクションを作る必要があり、これがライトニングネットワークと比べた時の欠点です。しかし、複数人が強調する必要があるチャネルファクトリを考える際には、ペナルティーを課すライトニングより、タイムシーケンスを使って古い取引を無効にするDMCの方が有効だと思われます。

Payment Loops（ペイメントループ）

ボブは以下のようなペイメントチャネルを持っており、チャネルバランスの均衡をとりたいと思ったとします。

Alice 0–2 Bob 0–2 Carol

 |                    |

 + – – – OTHERS – – – +

そこで、ボブはBob – Alice – OTHERS – Carol – Bobという経路を取って自分自身に支払いをすることで、以下のような資金のリバランスをとることができます。これをペイメントループといい、とても簡単に、早くリバランスをすることができます。

Alice 1–1 Bob 1–1 Carol

 |                    |

 + – – – OTHERS – – – +

問題2 安定したルート状態

P2Pネットワークでのルーティングはライトニングネットワークだけの問題ではなく、一般的な問題として考えることができます。そのため、ライトニング専用のルーティングアルゴリズムを特段考える必要はないと予想されています。とは言っても、実際にライトニングのためのアルゴリズム案は発表されており、それがFlareです。

Flare（フレア）

概要としては、自ノードの近隣ノードとビーコンノードと呼ばれるランダムに選ばれたノード群の近隣ノード情報をルーティングテーブルとして持つことで、全ノード情報を保持することなく特定ノードの経路を効率的に発見できるというものです。

問題3 ノードの稼働率

ペイメントシステムは常にインターネットと繋がっている必要があります。特にライトニングネットワークにおいてのインターネット接続状態は、他ノードからの送金の中継や支払い受付、資金の安全性を保つために必要不可欠です。ここでは、「ライトニングではオンチェーンを監視しないと資金が盗まれてしまう」というセキュリティの問題に対する解決策を紹介します。

WatchTower（ウォッチタワー）

自身のライトニングノードまたはウォレットが数日間オフラインになり、チャネルの相手方が古い取引残高をブロックチェーンにブロードキャストし資金をちょろまかそうとする場合に、第3者がそれを監視、対処してれるセキュリティ対策の仕組みです。

Compact Block Filter（コンパクトブロックフィルター）

ライトニングネットワークもビットコインも一番安全な方法は、フルノードを稼動させ常にトランザクションを検証することですが、これは一般ユーザーにとっては負荷が大きすぎます。ビットコインにはホワイトペーパーでも書かれているSPVという仕組みがあり、ハッシュ木のブロックヘッダー（マークルルート）と検証するトランザクションを使うことで、そのブロックに自分の取引データが入っているかを検証する方法があります。しかし、ライトニングの場合はこの逆で、自分の取引データ（コミットメントトランザクション）が入っていないかを検証する必要があります。

そこでCompact Block Filterを使うとこの種の検証が可能になります。このコンセプトは、あるフィルターがされたブロックをノードから受信し、その中に自身に関する取引データが存在しないかを検証します。Compact Block Filterではあるパターンにマッチしているのに、マッチしていないと判断する検知漏れ（False Negative）はありませんが、あるパターンにマッチしていないのに、マッチしていると判断する誤検知（False Positive）の可能性があります。つまり、「このブロックには自分の取引データはない」という判断は確実にできますが、「このブロックには自分のデータが入っていないのに、入っている」という判断をする可能性もあります。ただ、後者の場合は、そのブロックの全データを受信し、検証すれば良いのです。Compact Block Filterを使うことで、ウォレットなど軽量クライアントでもしっかりとデータ検証をすることが可能になり、セキュリティ水準を保つことができるでしょう。

Eltoo（エルトゥー）

ライトニングネットワークは、お互い悪意ある行為（古い残高状態をブロードキャストし資金をちょろまかす）をすると、全額没収されるというペナルティを課すことで悪意ある行為を抑止しています。上記でも書いたように、もし自身が数日間オフラインになっていて、ウォッチタワーも機能していなかった場合、相手方に悪意ある行為を許してしまいます。そこで提案されたのが、古い残高のトランザクションを無効にしブロードキャストできなくするEltooです。

最後に

以上がライトニングネットワークが抱えている問題と解決案でした。ライトニングが今後発展していくためには今回紹介したような問題を解決することはとても重要です。それと同時に、ライトニングを使えるような魅力的なサービスやウォレットも必要です。インターネットがベース技術ならびにアプリケーションの2軸で発展していったように、ライトニングもコア技術ならびにLappsの両方が今後ますます発展していくことに期待しています。

参考

[0]　Lightning Network 2.0
[1]　AMP
[2]　Splicing
[3]　Submarine Swap
[4]　Channel Factories
[5]　Duplex Micropayment Channels
[6]　Payment Loops
[7]　Flare
[8]　WatchTower
[9]　Compact Block Filters
[10]　Eltoo

【Lapps開発者が語る】LappsとDappsの違いとは

はじめに

今回は、僕自身がLappsを作り実際に感じたことを踏まえてLappsとDappsの違いや、今後のLappsについて書いています。平凡な一個人としての意見として気軽に読んでいただければ幸いです。

Lappsとは

Lightning Networkの上に乗せたアプリとよく言われますが、Lightning Networkによる「超小額決済」を活用したアプリという方がしっくりきます。オンライン上のサービス・モノを購入する場合、クレジットカードやビットコインでは決済手数料が実際のサービス利用料より高くなることがあります。例えば、１個の記事を読むのに10円だった場合、クレジットカードやビットコインの手数料の方が高くなってしまいます。ライトコインやビットコインキャッシュなどの仮想通貨は手数料が比較的低いですが、それはそのコインの価値や取引件数が少ないためです。Lightning Network上で決済をする場合、その手数料は0.001円（現時点）とかなり低く抑えることができます。これにより、10円の記事の購入によるマイクロペイメントが可能となります。

マイクロペイメントの課題

先ほどマイクロペイメントという言葉がでてきましたが、これは超少額決済と呼ばれ、

1ドルの1000分の1を意味し、ミル単位の支払いを効率的に実現する支払いシステムを意味します（Wikiより抜粋）

マイクロペイメントは、オンラインコンテンツ提供者の広告収入や購読料金などのビジネスモデルに対抗した１つの収益モデルとして注目を浴びています。しかし、ユーザーは一般に定額料金を好み、細かい金額を気にすることを嫌います。NetflixやSpotifyは定額料金で見放題聞き放題というのがウケた理由です。これがもし、1再生ごとに10円となると、ユーザーはいつも視聴回数を気にしてしまうでしょう。マイクロペイメントは注目を浴びる一方で批判的な一面もあります。ライトニングネットワークの台頭で、今後マイクロペイメントのビジネスモデルがどのように確立されるか非常に楽しみです。

個人的には、動画やイラスト、カンファレンスで発表したスライドなどを10円単位で販売したり、いいねボタンを押すのに使われたり、スパム対策などに使われるのかなと期待しています。

LappsとDappsの違い

Dappsは分散型アプリケーションのことで、Ethereumのブロックチェーン上で動くアプリなどを指します。EthereumはBitcoinよりも柔軟にスマートコントラクトを作ることができ、ブロックチェーン上に書き込めます。例えば、

「16匹いるペットに対して、もしユーザーがあるペットを飼おうとしたらそのユーザーのアドレスとそのペットIDが紐付けられる」というコントラクト（ここより抜粋）

を簡単に作り、それをブロックチェーン上に書き込むことができます。こうすることで、自動執行可能、改竄不可、透明性のあるアプリができます。ここでは16匹いるペットとしていますが、言い換えるとトークンが16個発行されたとも言えます（要はトークンを発行するアプリ）。

一方のLappsは、アプリ自体はJavaScriptやPython、Javaなどの言語で書き、サーバー上で稼動します。つまり、アプリは分散型ではなく中央集権型です。ただ、そのアプリを使用してサービスを購入するのにLightning Networkを使いビットコインで小額決済ができるのです。Lightning Network自体がビットコイン上のDappとも言えるかもしれません。

Lappsの適用アイディア

ここまででLappsは小額決済が活用できるようなサービス向けのアプリだと分かったと思いますが、ここではもう少し違う観点でLappsを考えてみましょう。Lightning決済の特徴として、

請求書（任意データの付与が可能）を支払うと、レシート（プリイメージ）がもらえる。

という仕組みを利用すると以下のようなサービスが可能になります。

Fraud Proof Swaps：取引所がライトコインを販売しており、ユーザーがライトニングで支払った後にライトコインを送金してくれなかった場合、支払い時の請求書にライトコイン送金先アドレスを載せておくことで、誰でもそのライトコインアドレスの残高が確認でき、取引所が不正していることが証明できる。（あくまでも不正を証明するだけで、支払ったビットコインは取り戻せない）

HTLC-DASH Swaps：DASHはDynamic Adaptive Streaming over HTTP の略語。DASHは様々なデバイスに最適で高品質な動画ストリーミングを配信する規格でRTSPなどを使用せずHTTPサーバで実現可能（参考サイト）。動画ストリーミングをセグメント単位で支払うことで視聴できるようにするテクニック。セグメント単位にプリイメージが埋め込まれ、インボイスを支払うごとに得るプリイメージを使ってセグメントをデコードする（参考サイト）。

当分は、デジタルコンテンツの小額決済向けプラットフォームによる、イラストや動画、音楽、記事などを国境を越えて売り買いができるようなプラットフォームが台頭してくるのではと思っています。また、ブログやオンラインサイトを運営する方々も、広告・購読収入以外にマイクロペイメントによる収益モデルが確立できるようになることも期待しています。

クロスチェーン × オフチェーン × アトミックスワップ

今回はライトニングネットワークを使ったビットコインとライトコインのクロスチェーンかつオフチェーンなアトミックスワップの概念についてのご紹介です。

マルチホップペイメント

まず最初にライトニングネットワークにおけるマルチホップペイメントについての簡単な説明です。マルチホップペイメントとは、アリスーボブ、ボブーキャロルというチャネルが存在している場合、アリスはボブを経由してキャロルへ送金するための方法です。これはちょっとした暗号トリックを使うことで、アリスがボブを信頼することなくキャロルへ送金することができます。

まず始めにキャロルが秘密鍵を生成し、その南京錠（ハッシュ値）をアリスへ渡します（１）。次にアリスは受け取った南京錠をボブへ渡します（２）。この時、アリスはボブへ南京錠に対応する秘密鍵があればBTCを送金すると伝えます。ボブはキャロルへ南京錠でロックしたBTCを送金します（３）。キャロルは秘密鍵でBTCのロックを解き、BTCをゲットします（３）。この瞬間、ボブは秘密鍵を知ることになります。そして、その秘密鍵を使ってアリスがロックしたBTCを解き、BTCをゲットします（４）。以上よりアリスはボブを経由（したように見える）し、キャロルへ送金することができました。

クロスチェーンかつオフチェーンなアトミックスワップ

では、ビットコインとライトコインをライトニングネットワークを使いオフチェーン上でアトミックスワップする方法についてです。

上記のマルチホップペイメントではアリスーボブーキャロルという経路でしたが、今回はアリスーボブーアリスという循環型経路が前提となります（ただし、アリスートムーボブ、ボブーキャロルーアリスなど中間に誰かが中継していても問題ありません）。また、アリス、ボブはそれぞれ１つのライトニングノード（例えばLND）をビットコインとライトコイン上で稼動させているものとします（要は１つのライトニングノードからビットコインとライトコインのペイメントチャネルが作れる状態）。

まずアリスは秘密鍵を生成し、その南京錠（ハッシュ値）を作成します（１）。その後、アリスはビットコインのペイメントチャネルを使ってその南京錠をボブへ渡します（２）。ボブは南京錠でロックしたライトコインをライトコイン上のペイメントチャネル越しにアリスへ送金します（３）。そして、アリスが秘密鍵を使ってLTCをゲットすると（３）、ボブはその秘密鍵を使ってビットコイン上のペイメントチャネルのBTCをゲットすることができます（４）。

以上が、簡単なクロスチェーン、オフチェーンのアトミックスワップの流れです。

参考

[1]Connecting Blockchains: Instant Cross-Chain Transactions On Lightning

ライトニングネットワークのプロトコル階層とは？

ビットコインのスケーリング問題を解決するため、セカンドレイヤーとして注目を浴びているライトニングネットワークですが、今回はそのライトニングを構成する階層についての解説です。

ネットワークプロトコル

本題に入る前にまずはネットワークプロトコルについて簡単なお話を。インターネットを構成するネットワークはいくつかのプロトコル階層によって定義されています。代表的なものにOSI参照モデルとTCP/IPモデルがあります。実際、私たちがインターネットで検索したり、メールを送ったりする場合、TCP/IPモデルが使われています。OSI参照モデルとは、国際標準機構（ISO）が作った標準規格ですが、実際はTCP/IPモデルが先行し実装・普及していったためTCP/IPモデルがディファクトスタンダードとなっています。この両者のモデルをよく対応（以下の図）させる場合がありますが、これには賛否両論あります（今回はこれについては述べません）。

ライトニングのプロトコル階層

実は、ライトニングネットワークにもこれに対応するようなプロトコル階層があります。以下はBlockstream社から引用してきた図です。左側がモデル名、右側がプロトコル名です。もともとライトニングが発表された時のUpdate層はLN-Penaltyだけしか存在しませんでしたが、今回Blockstream社がeltooというプロトコルを提案しています（ここにeltooの技術詳細が日本語解説してあります）。また、最近提案されたMult-Hop LockはTransfer層に該当すると思われます（ここにMult-Hop Lockの技術詳細が日本語解説してあります）。

モデル – プロトコル – 仕様書の対応表を作ってみました。BOLTはプロトコル階層を意識して作成されていないので、章が前後したり、横断的に記載されたりしています。またEltooやMulti-Hop LockはまだBOLTには取り込まれていません。

モデル名	プロトコル	BOLT参照箇所
Payment	Invoice	BOLT11
Multihop	Sphinx	BOLT4 – Onion routing
Transfer	HTLC, Multi-Hop Lock	BOLT2, 3, 5
Update	LN-Penalty, Eltoo, Gossip	BOLT5 – LN-Penalty, BOLT7 – Routing gossip
Base	Framiing & Feature negotiation	BOLT1 – Framing, BOLT9 – Feature flags
Transport	Noise_XK	BOLT8

また、ライトニングプロトコル階層をOSI参照モデルと対応づけしたスライドなども紹介されています（引用元はここ）。

カプセル化のメリット

ここでネットワークプロトコル階層に戻りますが、プロトコルを階層化しているメリットには、各階層をカプセル化（隠蔽しお互いが中身を干渉しない）することで、論理的に独立した機能を抽象化することが挙げられます。これにより各階層は独立して設計・開発することができ、このためインターネットプロトコルは成長してきました。

BOLTにプロトコル階層の明記を！

現在、ライトニングは様々な機能が提案、設計、実装されています。仕様書BOLTにそってすべての階層を各社（Lightning Labs、Blockstream、ACINQなど）がそれぞれ個別に実装してしまっているのが現状です。ライトニングネットワークではカプセル化という概念はまだ存在しません。ここで一度仕様書BOLTへ戻り、プロトコル階層を明記し、どの機能がどの階層に属するかが明確になると開発効率も良くなるのではと思っています。今後は各階層がライブラリ化して、それぞれを組み合わせて一つのライトニングネットワーク用ソフトウェアができると良いのではないでしょうか？

*.marginmarker {
background-color: #f0e68c;
/**margin-left: 0.3em;**/
/**margin-right: 0.3em;**/
}
thead {
background: #2E86C1 !important;
color: #FFFFFF;
}
td, th {
border: 1px solid #dddddd;
text-align: left;
padding: 2px !importan;
word-break : break-all;
}

ライトニングネットワークのトランザクション構成と統計結果

div.class_yokoscroll {
overflow-x : scroll ;
position: relative;
white-space: nowrap;
}
.tx {
border-collapse: collapse;
}
.tx thead {
background: #2E86C1 !important;
color: #FFFFFF;
}
.tx td {
padding: 5px;
border: 1px solid #ccc;
}
.tx td {
white-space: nowrap;
font-family: sans-serif;
}
.tx td:last-child {
white-space: normal;
font-size: 80%;
font-family: courier;
word-break : break-all;
}
td.txindent {
padding-left: 15px;
}
td.txindent2 {
padding-left: 30px;
}
td.txindent3 {
padding-left: 45px;
}
thead {
background: #2E86C1 !important;
color: #FFFFFF;
}
td, th {
border: 1px solid #dddddd;
text-align: left;
padding: 2px !importan;
word-break : break-all;
}

ライトニングネットワークで使われるトランザクション構成について仕様書BOLTに沿って解説します。前提知識としてビットコインのトランザクション構成とライトニングネットワークの基礎が必要です。本ブログでは、アリスがチャネル開設者、ボブを受諾者として解説します。

トランザクションの種類と関連性

ライトニングネットワークには主に3種類のトランザクションがあります。また、その内の1つであるCommitment Txから資金を移動するために、さらら2種類のトランザクションがあります。

トランザクション名	解説
Funding Tx	チャネルを開設する時に作りブロードキャストするトランザクション
Commitment Tx	お互いがオフラインで資金を送金し合う時に更新していくトランザクション。どちらかが一方的にチャネルを閉鎖する時は、このトランザクションをブロードキャストする。Commitment Txのアウトプットは4種類ある。 To_local To_remote Offered HTLC Received HTLC 通常のCommitment Txのアウトプットは1と2となることが殆どである。しかし、例えば送金先のボブがpreimageをアリスへ公開しない場合は、以下に示すHTLC Timeout txまたはHTLC Success txを使い3または4のアウトプットを指定先へ送金すことができる。 HTLC Timeout tx アリスが一方的にチャネルを閉鎖後、ボブがpreimageを公開せず、一定期間経過後、アリスが3.Offered HTLCを取り戻すためのトランザクション HTLC Success tx ボブが一方的にチャネルを閉鎖後、ボブがpreimageを使い4.Received HTLCの資金を得るためのトランザクション
Closing Tx	お互いが合意してチャネルを閉鎖する時に作りブロードキャストするトランザクション

上記のトランザクションの関連性を表したのが以下の図です。

実際のデータ（Testnet）を見てみましょう。以下の表の3つのトランザクションは上記図のFunding Tx、Commitment Tx、HTLC Timeout Txを投影しています。

	Funding Tx	備考	Commitment Tx	備考	HTLC Timeout Tx	備考
Txid	344b9…	–	963df…	–	Not yet	–
block_height	1356179	–	1356183	–	Not yet	–
out[0] script	002095ac…	A & B’s MultSig	00208cda…	Offerd HTLC	0020d693…	–
out[1] script	a9146c96…	–	001433cd…	To_remote	–	–
out[2] script	–	–	0020d693…	To_local	–	–
Lock Time	–	–	543677021	–	1356614	–

上記のトランザクションのポイント

アリスがチャネル開設し、ボブと送受金をしHTLCが残ったまま、アリスが一方的（非協力的）にチャネルを閉鎖した。

• Commitment TxのアウトプットはP2WSHが2個（Offered HTLCとTo_local）とP2WPKH（To_remote）が1個ある。

よって、HTLCが残った状態でアリスが一方的にチャネルを閉鎖したことが分かります。もしClosing Tx（協力的チャネル閉鎖）の場合であれば、お互いへのアウトプットがP2WPKHとなります。

• Commitment TxのTo_localアウトプットには144ブロックのタイムロックがかかっている。

よって、To_localアウトプットが使用可能になるのは約24時間後となります。To_localを使ったトランザクションのWitnessデータを

6321026644cb387614f66421d14da3596c21cffa239011416c9adf3f351ee8551a9fc767029000b27521029654f80732769d7c435a184a3559f12178315526c53bbf003349390811c7590a68ac

ここでデコードすると、以下のようなスクリプトになっており、144ブロックであるかをOP_CHECKSEQUENCEVERIFYでチェックしていることが分かります。

OP_IF 026644cb387614f66421d14da3596c21cffa239011416c9adf3f351ee8551a9fc7 OP_ELSE 144 OP_CHECKSEQUENCEVERIFY OP_DROP 029654f80732769d7c435a184a3559f12178315526c53bbf003349390811c7590a OP_ENDIF OP_CHECKSIG

• HTLC Timeout Txはサイン済みだが、1356614ブロックまでタイムロックがかかっている。

よってHTLC Timeout txは8/1正午時点ではまだブロードキャストできず、Commitment Txが含まれた1356183ブロックから数えて431ブロック（約3日間）目の1356614ブロック以降にブロードキャスト可能になります。431ブロックという数字はcltv_expiryという変数から計算されている。この辺は今後のルーティングの解説ブログで紹介したいと思います。実際のデータは以下となり、既にサイン済みです。

02000000000101a6aff0c6b6f029adcd2b71d1c5d401bd00d66ea2af574e828c3248716ef13d9600000000000000000001be71000000000000220020d693f9aa5645d6c0935a053c458b5f792fc8bccc823f1c1223ddc06b4bce192205004830450221008b1bca92ba916a1c72ee86a560a5c6aa860533ff41217525da7d5a4b68d33b440220282c68c467f9c564767458c37004e8e23607f1fb5553ff1676cfe8099196bf6601483045022100832e9aae61a5130c6fe58060c8433d3abe404953a587a33d5932aba9b55bbb370220291f1be809f92f0829249e29677d975c66f616a9b6525ec40bca7814680dc4e601008576a91408ae0c6a9fb4b3acda162029f289ecf6ff64ebca8763ac6721023ecc0db3d1b693fca1549ef0d46ca464a28d8e73476abb5e96c826234b17752f7c820120876475527c210390719fd57dd70d3edd9a7aa6bbdf6310bf81989c777da8813637c4d9f8b68bdd52ae67a9142a27e0539cefff67396a56c519a8eb90d9427f6d88ac686846b31400

上記の生データをデコードすると、以下のようなトランザクションとなり、Lock timeが1356614であることが分かります。

{
	"result": {
		"txid": "6d58368666741e19ef7c711f43a7eb2d81fb82b7c6850f12fd11bc0bd5ed642c",
		"hash": "eeae4fad5b45d6a575ecb1073e1cb09d782a61a50ed5993357b658904d2aed93",
		"version": 2,
		"size": 379,
		"vsize": 166,
		"locktime": 1356614,
		"vin": [
			{
				"txid": "963df16e7148328c824e57afa26ed600bd01d4c5d1712bcdad29f0b6c6f0afa6",
				"vout": 0,
				"scriptSig": {
					"asm": "",
					"hex": ""
				},
				"txinwitness": [
					"",
					"30450221008b1bca92ba916a1c72ee86a560a5c6aa860533ff41217525da7d5a4b68d33b440220282c68c467f9c564767458c37004e8e23607f1fb5553ff1676cfe8099196bf6601",
					"3045022100832e9aae61a5130c6fe58060c8433d3abe404953a587a33d5932aba9b55bbb370220291f1be809f92f0829249e29677d975c66f616a9b6525ec40bca7814680dc4e601",
					"",
					"76a91408ae0c6a9fb4b3acda162029f289ecf6ff64ebca8763ac6721023ecc0db3d1b693fca1549ef0d46ca464a28d8e73476abb5e96c826234b17752f7c820120876475527c210390719fd57dd70d3edd9a7aa6bbdf6310bf81989c777da8813637c4d9f8b68bdd52ae67a9142a27e0539cefff67396a56c519a8eb90d9427f6d88ac6868"
				],
				"sequence": 0
			}
		],
		"vout": [
			{
				"value": 0.00029118,
				"n": 0,
				"scriptPubKey": {
					"asm": "0 d693f9aa5645d6c0935a053c458b5f792fc8bccc823f1c1223ddc06b4bce1922",
					"hex": "0020d693f9aa5645d6c0935a053c458b5f792fc8bccc823f1c1223ddc06b4bce1922",
					"reqSigs": 1,
					"type": "witness_v0_scripthash",
					"addresses": [
						"bc1q66fln2jkghtvpy66q57ytz6l0yhu30xvsgl3cy3rmhqxkj7wry3qdtn2kg"
					]
				}
			}
		]
	},
	"error": null,
	"id": null
}

トランザクション構成

では各トランザクションの生データを分解して重要なポイントを確認して行きましょう。

#1 Funding Tx

output[0]が資金をロックするためのスクリプト

2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG

のP2WSHです。

Funding Txのoutput[0]を使ったCommitment Txのインプット（Witnessデータ）

522102f8d3a287882446f9570f5e0e29638d46b4bf519f5628c35b30b6901311dac60821033f7837aed227d5e26c8d55672ca6cb33c4cc8aebef8fd06e6ade5c6580c153b552ae

をデコードすると、以下のようなスクリプトになっており、2-2マルチシグのチェックをしていることが分かります。

2 02f8d3a287882446f9570f5e0e29638d46b4bf519f5628c35b30b6901311dac608 033f7837aed227d5e26c8d55672ca6cb33c4cc8aebef8fd06e6ade5c6580c153b5 2 OP_CHECKMULTISIG",

version		02 00 00 00
maker		00
flag		01
input count		01
input	previous output hash (reversed)	eb4fe1372be9c2e0e6ffc423f0bde4bcfda69f185c5c1a8949ea8c6e5e4f104d
	previous output index	01 00 00 00
	script length	17
	scriptSig	16001484b12b3faf41f4a4eabdce17338ca5ec49413140
	sequence	ff ff ff ff
output count		02
output[0]	value	40420f0000000000
	script length	22
	script	002095ac86776a9be2676333e1974c23409524732db6cb13574845c217d54e256404
output[1]	value	942c590000000000
	script length	17
	script	a9146c96a72d0943be0212793177251f7feb6ec739bc87
witness		02 483045022100c9a818188c3a6ac8d3769094d042cba999442fdcb08488f99304f5a9ede8eef502200e944849599a94baf8950aca74120db9ce8f7ec2dbaa63262ca2fb32a7134dde01 2103ff8c135286952caa12bf4e4a307b8d94a8cd3dc701b42cf217ee9efc9b04a200
block lock time		00 00 00 00

#2 Commitment Tx

output[0]がOffered HTLCです。スクリプト自体はハッシュ化されていますが、HTLC Timeout TxのWitnessデータ

8576a91408ae0c6a9fb4b3acda162029f289ecf6ff64ebca8763ac6721023ecc0db3d1b693fca1549ef0d46ca464a28d8e73476abb5e96c826234b17752f7c820120876475527c210390719fd57dd70d3edd9a7aa6bbdf6310bf81989c777da8813637c4d9f8b68bdd52ae67a9142a27e0539cefff67396a56c519a8eb90d9427f6d88ac6868

をデコードすると、以下のとおり、BOLT仕様書どおりのスクリプトになっています。

OP_OR OP_DUP OP_HASH160 08ae0c6a9fb4b3acda162029f289ecf6ff64ebca OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE 023ecc0db3d1b693fca1549ef0d46ca464a28d8e73476abb5e96c826234b17752f OP_SWAP OP_SIZE 32 OP_EQUAL OP_NOTIF OP_DROP 2 OP_SWAP 0390719fd57dd70d3edd9a7aa6bbdf6310bf81989c777da8813637c4d9f8b68bdd 2 OP_CHECKMULTISIG OP_ELSE OP_HASH160 2a27e0539cefff67396a56c519a8eb90d9427f6d OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF OP_ENDIF

version		02 00 00 00
maker		00
flag		01
input count		01
input	previous output hash (reversed)	6e095eada577d15b30c05a77399cdc5039697072a797e6a23e13b5d9d79c4b34
	previous output index	00 00 00 00
	script length	00
	scriptSig	–
	sequence	6d2e0880
output count		03
output[0]	value	57c3000000000000
	script length	22
	script	00208cda218e1ba82f99abd5e865ba2c19cd4b0306aaecf27fba77428f4abadb77f9
output[1]	value	6aea000000000000
	script length	16
	script	001433cdbb0c88c99d11fd1b8d23b2ed0b36ff426b13
output[2]	value	38260d0000000000
	script length	22
	script	0020d693f9aa5645d6c0935a053c458b5f792fc8bccc823f1c1223ddc06b4bce1922
witness		04 00 483045022100ecefc2b781e55ba75c566bbe8a2c7c6b41a52ead675af9207a09ce934e4eaf5b022031686c216aad75fe53a2539c2af1a30ef01a492074d6b311c9b026a74519c5eb01 473044022078400de1c4d328a9f38c7e8db484c7a3e174f65efc813216d52f6867735cc31002202c9a68784efcf75d25c2988f3a0af0ff7aa585c8bb6c9e387c0db79481d027f501 47522102f8d3a287882446f9570f5e0e29638d46b4bf519f5628c35b30b6901311dac60821033f7837aed227d5e26c8d55672ca6cb33c4cc8aebef8fd06e6ade5c6580c153b552ae
block lock time		5dda6720

#3 HTLC Timeout Tx

上記のポイントでも言及しましたが、このトランザクションで注目すべきはlock timeです。その値は46b31400で、1356614ブロック目を表しています。Commitment Txがブロックに取り込まれた1356183ブロックから約3日間経過後の1356614ブロック以降にこのHTLC Timeout Txをブロードキャストすることができます。

version		02 00 00 00
maker		00
flag		01
input count		01
input	previous output hash (reversed)	a6aff0c6b6f029adcd2b71d1c5d401bd00d66ea2af574e828c3248716ef13d96
	previous output index	00 00 00 00
	script length	00
	scriptSig	–
	sequence	00 00 00 00
output count		01
output[0]	value	be71000000000000
	script length	22
	script	0020d693f9aa5645d6c0935a053c458b5f792fc8bccc823f1c1223ddc06b4bce1922
witness		05 00 4830450221008b1bca92ba916a1c72ee86a560a5c6aa860533ff41217525da7d5a4b68d33b440220282c68c467f9c564767458c37004e8e23607f1fb5553ff1676cfe8099196bf6601 483045022100832e9aae61a5130c6fe58060c8433d3abe404953a587a33d5932aba9b55bbb370220291f1be809f92f0829249e29677d975c66f616a9b6525ec40bca7814680dc4e601 00 8576a91408ae0c6a9fb4b3acda162029f289ecf6ff64ebca8763ac6721023ecc0db3d1b693fca1549ef0d46ca464a28d8e73476abb5e96c826234b17752f7c820120876475527c210390719fd57dd70d3edd9a7aa6bbdf6310bf81989c777da8813637c4d9f8b68bdd52ae67a9142a27e0539cefff67396a56c519a8eb90d9427f6d88ac6868
block lock time		46b31400

LNのトランザクション統計結果（一部抜粋）

ライトニングの主なトランザクションと各特性を理解したうえで、最後にLightningPeach（Bitfury）によるライトニングネットワークのトランザクション統計結果を一部以下に紹介します。オリジナル記事はここを参照してくだっさい。

• 一方的チャネル閉鎖の割合が多い

チャネル開設の相手側が一方的にチャネルを開設する割合が多いが、一方的に閉鎖するインセンティブはなく、少し奇妙な行動である。

• 大きなチャネルほど一方的チャネル閉鎖が起きている

これは相手がオフラインになったときにCommitment Txをブロードキャストして不正に資金を横取りしようと考えるインセンティブが働くからである。

• 一日平均、1件のペナルティー（不正行為による資金の没収）

最後に

今回はライトニングネットワークで使われる主要なトランザクションとその関連性について見てきました。仕様書BOLTだけ読んでも実感がわかなかった箇所が、実際のデータを使いブレークダウンすることでより一層理解が深まったと思います。
また、トランザクション構成や特性を理解することで、ライトニングのトランザクション統計結果も違う角度で考察することができると思います。例えば、大きなチャネルほど一方的チャネル閉鎖が起きているが、実際に資金を不正入手された件数はどのぐらいあるか、HTLC Timeout TXがブロードキャストされた件数はどのぐらいあるのか（HTLC Timeout/Success Txが存在することは稀）、などが上げられます。
AMPやルーティング最適化もライトニングの普及には欠かせませんが、上記の不正行為を防ぎ、ユーザーの資金をしっかりと守ることが優先度が高いと思うので、ウォッチタワーの設計・実装が今後ますます重要になると思っています。

参考

[1] Understanding the Lightning Network, Part 2: Creating the Network

[2] Understanding the Lightning Network, Part 3: Completing the Puzzle and Closing the Channel

[3] LightningPeachによる統計報告1

[4]Offered/Received HTLCの解説 by Nayuta

[5] NayutaによるHTLCの送金の解説 by Nayuta

[6] Lightning Networkが動作する仕組み by Nayuta

ライトニングのセキュリティ監視は必須！ウォッチタワーとは

ウォッチタワーはセキュリティ監視役

ウォッチタワーとは、スマフォなどが数日間オフラインになっている間、ペイメントチャネルの相手が悪意ある行為、例えば、古くなった取引データ（HTLC）をブロックチェーンにブロードキャストした場合に対処するセキュリティ対策のことです。ウォッチタワーは別名ブロックチェーンモニタリングとも呼ばれたりします。

ライトニングネットワークでは、双方でビットコインの残高を取引ごとに更新していきます。但し、ブロックチェーンへは発信せず、お互いのウォレットにその更新データを保存するだけです。古くなった取引データは無効となりますが、技術的にはこの無効な取引データをブロックチェーンへ発信することが可能です。

しかし、この無効な取引データがブロックに取り込まれ、悪者がコインを盗むためには一定時間の経過後になります。この期間内であれば、自身は有効な取引データをブロックチェーンに発信することで防ぐことができ、相手方にペナルティーを科すこと（ビットコインの没収）ができます。しかし、スマフォなどのデバイスは電源が切れていたり、オフラインになることがよくあります。知らない間に一定期間が過ぎてしまい、悪意ある取引データがブロックチェーンに取り込まれコインを盗まれてしまう可能性があるのです。

そこで、ウォッチタワーが、この悪意あるデータがブロックチェーンに発信されていないか逐次監視し、発信されていればそれを対処してくれます。

ウォッチタワーの特徴

• 常時稼動している必要があり、サーバ的な存在。
• スマフォなどのデバイスからHTLCsを受信・保管する。
• ブロックチェーンでブロックが発掘される度にそのブロックに悪意あるデータがあるかチェックする。発見した場合は、保管してたデータを使いブロックチェーンへ発信しコインを取り戻す。

ウォッチタワーの実装状況

各ライトニングノート開発団体によるウォッチタワーの実装は以下の通りです（2018-07-20時点）。ウォッチタワーの詳細仕様は追って解説したいと思います。

thead{
background: #2E86C1 !important;
color: #FFFFFF;
}
td, th {
border: 1px solid #dddddd;
text-align: left;
padding: 8px;
}

アプリ名	状況
c-lightning	未実装/議論済
lnd	実装中
lit	実装済み
eclare	未実装

ウォッチタワーの仕様は様々な場所で討論されており、現状は実装・実験中です。BOLTにもまだ提案されていません。

スマフォ用ライトニングウォレットは危険！？

現時点でウォッチタワーは実験段階であり、litのみ実装済みですが、ウォッチタワーを使用するには、ユーザーのウォレット側も対応する必要があります。Eclare Walletは現状受取ができないため、相手方が不正をすることはできません（というか不正する意味がありません）。受取ができるLN対応ウォレットは、数日間アプリを起動しない場合、悪意あるノードにコインを盗まれてしまう可能性があるので、大金をライトニングネットワーク対応ウォレットに保管しないほうが良いと思います。

ライトニングペイを体感してみよう！

本サイトでは英国ブランドのジャックウィルスをライトニングペイで購入いただけます。その他通常のビットコインやライトコインにも対応しています。以下の写真をクリックし商品ページより購入できます。

サンドルフォードＴシャツ

クロムフォードノットＴシャツ

短編小説（デジタル商品）

ライトニングで手数料は稼げるのか

ライトニングノードを立ち上げてから1ヶ月以上が経ち、安定してきたので、そろそろルーティングで手数料を稼ぐための計画を立ててみました。本ブログはライトニングネットワークの仕様BOLTとc-lightning(v0.5.2-2016-11-21-2716-g1125682)を元にしています。

ルーティング手数料の確認

ルーティング手数料を決めるには2つの定数base_feeとfee_rateを使い、以下の計算式となります。

手数料 = base_fee + ( 送金量 * fee_rate )

base_feeは基本料金みたいなもので、ルーティンごとに固定の値です。c-lightningではデフォルトが1000 msatoshi*1 となっています（以降msatと表記する）。fee_rateはルーティングする送金量に対する割り増し比率です。デフォルトは10 millionths/sat*2 となっています。例えば、100 satoshiをルーティングする場合の手数料は以下となります（単位はmsat）。

1000 + ( 100000 * 10 / 1000000 ) = 1001 msat

*1 1000 msatoshi = 1 satoshi

*2 millionths：100万分の1のこと

thead{
background: #2E86C1 !important;
color: #FFFFFF;
}
td, th {
border: 1px solid #dddddd;
text-align: left;
padding: 8px;
}

c-lightning表記	BOLT表記	デフォルト値
base_fee	fee_base_msat*2	1000 msat
fee_rate	fee_proportional_millionths	10 msat

ここで、アリスがボブ経由でキャロルへ1000000 msatを送付する場合について考えています。ボブのルーティング手数料はデフォルト値（上記表参照）とします。アリスは上記の計算式の結果、1001 msatを手数料として支払う必要があるため、合計で1001001 msat支払うことになります。手数料は約0.008円です。安い！

ルーティング実績の確認

今回は私のライトニングノードがどれだけルーティング手数料を稼いだのか確認してみました。が、LNDにはfeereportというコマンドで手数料を確認できるのですが、c-lightningにはそのようなコマンドがなく、手数料の確認ができませんでした（確認方法があれば教えてください）。

（2018-07-24更新）ルーティング手数料を確認するc-lightning用SQLを考えてみました。たぶんこれでいいはずです（間違っていたら教えてください）。

https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js

sqlite3 $HOME/.lightning/lightningd.sqlite3 "select sum(a.msatoshi - b.msatoshi) from channel_htlcs a inner join channel_htlcs b on a.id = b.origin_htlc"

実行結果は 11098 msatoshiでした。なので約11satoshi分しかルーティング手数料は稼いでいませんでした。笑

ルーティング手数料はどれぐらい稼げるのか？

では、ルーティング手数料はどのくらい稼げるのか1ルーティング：1 satoshiを手数料として計算してみました。結果、1ヶ月に1000回ルーティングしても100円弱程度しか稼げません。mainnet.yalls.orgなどの有名サイトでも月1000回程度のルーティングなので、ライトニングノードで手数料を稼ぐのは厳しいかなと思います。

ルーティング回数	手数料(単位:satoshi)	円換算
1000回	1000 satoshi	83円

ライトニングペイを体感してみよう！

本サイトでは英国ブランドのジャックウィルスをライトニングペイで購入いただけます。その他通常のビットコインやライトコインにも対応しています。以下の写真をクリックし商品ページより購入できます。

サンドルフォードＴシャツ

クロムフォードノットＴシャツ

短編小説（デジタル商品）

ライトニングが使いやすくなる！？サブマリンスワップとは

アトミックスワップとは

コインの交換を2者間で行うことです。通常は、株式の売買でも仮想通貨の売買でも取引所が売り手と買い手の仲介役となり取引を行うことが一般的です。仲介役の役割は、売買相手をマッチングさせたり、取引の執行を確実に行うことです。例えば、アリスがビットコインを売って、ライトコインを買いたい場合を想定してみましょう。まずは、取引所がライトコインを売ってビットコインを買いたい相手ボブを見つけてくれます。そして双方がそれぞれのコインを取引所に預けます。双方がコインを送金したことを確認後、取引所はアリスへライトコインを、ボブへビットコインを送金します。これがザックリとしたコイン交換の1つの方法です。しかし、もし取引所なしでこの取引を実行しようとする場合、相手を信用する必要があります。例えば、アリスがボブへビットコインを送金したのにボブがライトコインを送金してくれない場合やその逆も然り。そのリスクを回避するために第3者として取引所が仲介してくれます。

しかし、取引所はその仲介役を買って出てくれる一方で、取引の数パーセントを手数料として取ることがあります。そこで、アリスとボブの2者間で取引をする場合、相手を信頼することなく完全に取引を実行するための方法をアトミックスワップと呼び、スマートコントラクトを使うことで可能になります。

サブマリンスワップとは

では、本ブログの本題のサブマリンスワップについてです。サブマリンスワップとは、オンチェーンの資金とオフチェーンの資金を交換する方法で、Alex Bosworthによってプロトタイプが開発されました。

アリスはライトニングネットワークを使いたいと考えますが、ライトコインしか持っていません。こんな時はサブマリンスワップの出番です。アリスがライトコインを資金としてライトニングネットワークへチャージすることはできませんが、ここでサブマリンスワップを提供してくれるボブがいたとします。まず、アリスは自身のライトニングネットワーク対応ウォレットから請求書（インボイス）を作成し、ボブへ渡します。次にボブはその請求書からあるスマートコントラクトを作成し、特別なライトコインアドレスを生成し、アリスへ渡します。アリスは、その特別なライトコインアドレスへコインを入金します。ボブは、その入金を確認後（この時点ではまだライトコインはまだボブのものではありません）、アリスからもらった請求書に対しライトニングペイで支払いをします（この時点でアリスの目的は達成されました：ライトニングに資金がチャージされました）。支払いが完了するとレシートが受理できます。このレシートが重要で、これを使うことで先に生成した特別なライトコインアドレスからコインを取り出すことができるのです。これでボブもライトコインを受け取ることができ、コインの交換が完了しました。

背面下では

ボブが作成したスマートコントラクトは下記のようになります。

https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js

if(hash(preimage) == invoiceId){
    checkSig(presentedSig, sendtoPubkey)
}else if(height > refundHeight){
    checkSig(presentedSig, refundPubkey)
}

ここで重要なのがpreimageです。これはアリスが発行した請求書と関連付けされており、請求書の支払いが完了すると支払い者にレシートとして渡されます。このpreimageのハッシュ値を取るとinvoiceIdとなります。なので、ボブが作ったこの契約の1行目は、請求書の支払い後に受理するレシートを使うとコインをボブのライトコインアドレスへ移動できるこをと表しています。また、3行目については、ボブが請求書を支払わずにある一定時間が過ぎると、アリスのライトコインアドレスへ移動できるというものです。

ユーザーのメリット

どれほど需要があるか分かりませんが、現状ではライトコインしか保有しておらず、ライトニングを使おうと思う場合、一度shapeshiftなどでライトコインからビットコインへ交換してからライトニングへチャージするという流れになります。それが直接ライトコインからライトニングへチャージができるので簡単になりますね。

また、ユーザーが、取引所に預けたコインを使ってライトイングネットワークを始める時、もし取引所がまだライトニングに未対応であった場合でも、取引所はスワップ提供者を探しだし、その人にユーザーの請求書を渡します。スワップ提供者は特別なアドレスを生成し取引所に送付します。取引所がユーザーのコインをその特別なアドレスに送金した後、スワップ提供者はライトイングペイでユーザーの請求書の支払いをします。これでユーザーは取引所に保管してあったコインを使ってライトイングネットワークに資金をチャージすることができます。

スワップの応用～エコシステム構築～

販売者にとってライトニングでの一番の問題は受取が難しいことです。ユーザーが販売者と直でペイメントチャネルを開いていれば問題ないのですが、そうでない場合、販売者とチャネルを開設している相手とのチャネルバランスにおいて、相手側にある程度の資金がないといけません。そこで上記のスワップを応用します。

販売者であるトムはキャロルとペイメントチャネルを開設しおり、アリスもキャロルとチャネルは開設済みだとします（各チャネルバランスは以下の通り）。この状況でアリスはトムへ支払いをすることはできません。トムとキャロルとのチャネルバランスが2:0であるため、キャロルからトムへ送金する残高がないからです。トムが支払いを受け取るためにはトムとキャロルのチャネルバランスを2:0から1:1などにする必要があります。

Tom 2 -- 0 Carol 0 -- 2 Alice

そこでトムはキャロルに1BTCの請求書を要求します。トムは受け取った請求書からスワップ用の特別な（ここでは例として）ビットコインアドレスを生成し、キャロルへ入金依頼を出します。キャロルがオンチェーンのビットコインアドレスへ入金後、トムはキャロルへ1BTCライトニングペイをする。支払い後レシートを受理し、それを使い特別なビットコインアドレスからトムのオンチェーンアドレスへ移動させる。この時点でチャネルバランスが2:0から1:1へなりました。これでチャネルのリバランスが完了し、アリスから支払いを受け取れる状態になりました。

Tom 1 -- 1 Carol 0 -- 2 Alice

トムはキャロル経由でアリスからの1BTCの支払いを受け取ることができたました。

Tom 2 -- 0 Carol 1 -- 1 Alice

疑問点

キャロルがオンチェーンのビットコインを持っている必要があり、そのビットコインをオンチェーンからオフチェーンへ移動させることの動機がないと、上記取引は成立しないと思います。

最後に

Alexのプレゼンの最後の言葉が印象的でした。彼は「おそれないで」と言及しており、よくライトニングネットワークやLappの開発において諦める方がよくいます。良いアイディアを出したり、開発などに貢献する方々は、それぞれ努力をしています。コミュニティに貢献するのに、あなたが秀才である必要はなく、それぞれができる限りにのことを精一杯し、その積み重ねによって技術が開発、浸透してくるのです。

参考

Alex BosworthによるScaling Bitcoinのプレゼン

上記プレゼンの要約はここ

ライトニングネットワーク決済体験記

今回は、私が実際にライトニングネットワーク決済（以降、ライトニングペイ）をしたお話をしたいと思います。

ライトニングネットワークとは、ビットコインのスケーリング問題（1秒間に約7件しか処理できない問題）を解決する手段として開発されたレイヤー2の技術です。ライトニングペイをするということは、ビットコインで支払いをするのに変りは無いですが、支払いごとにブロックチェーンへの書き込みをしないという違いがあります。例えば、スターバックスカードやスイカに現金をチャージしてそのカードを使ってコーヒーを買ったり食品を買ったりするのと似ています。

私が最初にライトニングペイで商品を購入したのは、Blockstreamのショップでした。Ｔシャツが買いたかったのですが売り切れだったので、ステッカーを購入しました。購入当時の金額で約550円（送料込み）で購入しました。この時の送金手数料は0.1円以下でした。もしライトニングペイではなく通常のビットコインで支払うと送金手数料は約20円もかかってしまいます。これが初めてのライトニングペイだったので、ビットコインをライトニングペイ用にチャージする必要があり、そのチャージ手数料に約20円ほどかかりました。この時は5000円ほどのチャージしました。ウォレットの設定方法などはこのブログを読んでみてださい。

次に、Hodl MonkeyというサイトでビットコインＴシャツを約2000円で購入しました。今回は前回のチャージした分の残高4500円があったので、送金手数料0.1円のみでした。実際に商品が届き、かなりいい感じのＴシャツでした。右の写真が購入したＴシャツです。JPモルガン社長のあの有名な言葉「ビットコインは詐欺だ」のセリフがプリントされたＴシャツです笑

ライトニングネットワークはまだまだ発展途上の技術ですが、だから面白いですよね。ぜひこの体験を皆さんにもしていただきたい、そう思いで本ショップでもライトニングペイ対応をしました。皆さんもぜひ一度ライトニングペイを体験してみてください！

iPhoneケースをライトニングペイで購入してみる↓クリック↓