ニュートリノ:ライトニングの明るい側面

まえがき

本投稿も前回に引き続き、Lightning LabsのメンバーBryan Vu氏によるライトニングブログ(投稿日:2018-10-17)を翻訳しました。モバイル用ビットコインアプリをより良いものにするために提案されているニュートリノの概念と技術的概略についてご紹介します。


image
本シリーズの以前の2つの投稿では、将来のライトニングユーザーを想定したキャロルが主人公でした。本投稿では、現在に時間を戻して、標準的なモバイル用ビットコインアプリを使っているアリスについてお話したいと思います。アリスが住んでいる現世界では、コンピュータプラットフォームとしてスマートフォンが大多数を占める状況になっていますが、現在のビットコインアプリは様々な問題を抱えています。それはセキュリティ、プライバシーおよび使いやすさの欠陥です。

現在のモバイル用ビットコインウォレットは中央集権サービスをベースとして作成されており、重大なセキュリティ問題を抱えています。「あなたが鍵を管理していないなら、それはあなたのビットコインではない」と幾度も言われ続けているように、中央集権サービスはユーザーのファイナンシャル情報(例えば、取引履歴)を漏洩するリスクがあります。一方で、中央集権サービスは、速く、使いやすく、少額のビットコイン保有者に対しては便利なサービスです。しかし、長くビットコインに浸かっているアリスとその友達は中央集権サービスに預けていたコインを失う経験をしており、彼女は自分で鍵管理ができるウォレットを探そうと決めました。

Goblet

そんなアリスのようなユーザーにとっての選択肢としてSPVウォレト(BIP37対応)があります。SPVウォレットは上記で述べたような中央集権サービスが抱えるリスクはありませんが、プライバシー問題のリスクを抱えています。さらに、現状のSPVウォレットは遅く、使いにくい傾向があります。アリスは遅いアプリが好きでなく、またプライバシーも重要視しているので、これらのウォレットでは満足できていません。

驚くことに、急激なビットコインの浸透とモバイルデバイスの増加にも関わらず、モバイルアプリ用の改善案が提唱されてか6年が立ちます。上記で述べた様々な問題を解決するべく、Lightning LabsのOlaoluwa Osuntokun (roasbeef) とAlex AkselrodはJim Posen (前Coinbase)と共同でニュートリノプロトコル(BIP157, BIP158)の提案をしました。


ニュートリノのメリット

分散化されたビットコイン用モバイルアプリにとっての挑戦は、全トランザクション履歴(現時点で約200GB)の中から瞬時に個々のユーザーに関係のあるトランザクションのみを取り出すことです。さらに、モバイルアプリが成功するためには、セキュリティ、プライバシーそして質の高いユーザー体験を提供する必要があります。ニュートリノプロトコルは、低電力プロセッサー、限られたストレージ容量とデータ通信量、断続的な電力および不安定なネットワーク接続性に縛られたデバイス上でこれらの必須要件を助長するためにデザインされたプロトコルです。

セキュリティ – 上記で述べたように、中央集権サービスには落とし穴(ハッキング対象箇所)が存在するため、アリスのような上級者または多くのビットコイン保有者は、通常彼ら自身で鍵管理をするのを好みます。ニュートリノは、ユーザーによる鍵管理ができるアプリをより速く、使いやすく、そして魅力的にするためにデザインされています。さらに、ニュートリノは競合したトランザクション情報*1を解決するための新しいセーフガードを含んでいます(これは特にライトニングネットワークを使うユーザーにとって役に立ちます)。

プライバシー – ファイナンシャルソフトウェアの必須要件の1つにプライバシー保護があります。ユーザーの残高や取引履歴はユーザーの同意なしで公開されてはいけません。BIP37のSPVクライアントは確率的アドレスリスト(これからおおよその取引履歴を追うことができます)を含むユーザー情報の多くを漏らしています。また、中央集権サービスもこの情報をすべて保有しておりプライバシー保護の保証はありません。ニュートリノはこれらの情報を第3者に漏らしたくないモバイルユーザーの為に改良されたプロトコルです。*2

スケーラビリティと非中央集権 – ニュートリノプロトコルはビットコインフルノードの計算パワーが少なくて済みます。これはニュートリノクライアントに送信されるフィルターの計算は1度だけでよく、そのフィルターは全クライアントに対して同じものです。BIP37のSPVプロトコルにおいては、フルノードは各クライアントに対して異なったアウトプットを計算し送信する必要があります。もし1台のフルノードが多くのモバイルクライアントにそれぞれのデータを提供する場合、ものすごい計算パワーが必要となり重荷となるでしょう。

検閲耐性 – ニュートリノクライアントはそれ自身が鍵を保持し、自身のトランザクションをブロードキャストするので、ビットコインのパーミションレスかつ検閲耐性な特徴をさらに拡張できるでしょう。


技術的詳細

より技術的に関心のある読者のために、次の章ではニュートリノプロトコルの概要についてお話します。さらに詳細な情報はBIP157BIP158を参照してください。

GCS filters(Golomb-Coded Set filters)

大雑把に言うと、ニュートリノはビットコインブロックチェーンのそれぞれのブロックに対応する“フィルター”と言うことができるでしょう。このフィルターは1つのブロックに含まれるそれぞれのビットコインアドレスを識別するためにゴロム符号(Golomb-Rice coding)を使用しています。ニュートリノフィルター(所謂、ゴロム符号におけるGCS filters)は、1つのブロックをよりいっそう圧縮することができ、15KB以下のサイズに収めることができます。ちなみに、元の1ブロックはその250倍以上の大きさで4MB(Segwitにより実質1MBから4MBへ拡大)以下となります。

この圧縮によってネットワーク帯域幅の狭いデバイスでもブロックチェーンを確認し、新しくマイニングされたブロックがユーザーのウォレットに関係あるかを確認することができます。このプロセスに関するステップは以下の通りです。


ステップ1 フィルター作成:新しいブロックがマイニングされるごとに、フルノードはGCS filtersを作ります。このフィルターはニュートリノクライアントに提供されます。

ステップ2 フィルターの観測と比較:約10分間隔でニュートリノクライアントはこのフィルターを受信します。そして、そのフィルターからユーザーに関する新しいトランザクションデータが存在するかを確認します。

ステップ3 関係のあるブロックのダウンロード:もしフィルターがユーザーが必要とするトランザクションデータが含まれていると指し示したら、ニュートリノクライアントは「切り取った」ブロック*3をフルノードに対して要求します。このブロックは署名データ(または“witness data”とも言う)を除くすべてのトランザクションデータが含まれています。ブロックのダウンロードをし、関係あるトランザクションを取り出します。

ステップ4 ウォレットの残高の更新:取り出したトランザクションデータからウォレットの残高を更新します。

この方法では、ユーザーのアドレスを特定する情報はネットワークへいっさい送信されません。また、ユーザーのウォレットとブロックチェーンのトランザクションデータの比較検証作業はユーザーのウォレット内で行われます。これはBIP37による信頼できないリモートノードによる検証との違いです。


同期(Syncing)

ニュートリノノードの仕組みは上記で説明しましたが、アリスが彼女自身のニュートリノ搭載ウォレットを最初に立ち上げる時、最新のブロックチェーンの状態になるまで同期をする必要があります。また、ウォレットがオフライン状態で一時的にこの処理が中断していた場合も、最新のブロック状態になるためにそこまでキャッチアップする必要があります。この同期は以下の4つのステップからなります。


ステップ1 通常のビットコインクライアントやSPVクライアントのように、ニュートリノクライアントはブロックヘッダのチェーンをダウンロードし検証します。これは、ブロックチェーンの各ブロックの位置を特定し、プルーフオブワーク(PoW)を検証するためです。各ヘッダーは80バイトで、ビットコインブロックチェーンの合計ヘッダーサイズは約40MBです。

image

ステップ2 ニュートリノクライアントは上記で述べたブロックヘッダーに対応する「フィルターヘッダー」をダウンロードします。ニュートリノプロトコルでは、各ブロックはGCSフィルターを含んでいます。フィルターヘッダーは、ニュートリノクライアントに各ブロックに対応するGCSフィルターと連動するための情報です。この詳細はBIP157に記載されています。

各フィルターヘッダーは32バイトで、このヘッダーに必要なデータ通信量の合計は約20MBです。ウォレットを初期セットアップする以前までのブロックチェーンのヘッダーは、一度検証が終わると捨てるため、ストレージ容量の節約になります。各ヘッダーのダウンロードの検証は1度限りで良いのです。

ステップ3 ウォレットのセットアップが完了して以降の処理は、各ブロックのGCSフィルターのダウンロードをします。このフィルターのダウンロード容量は月に70MBですが、このフィルターは保存する必要はありません。

ステップ4 ニュートリノクライアントは、フィルターをチェックすることで、そのウォレットに関係のあるトランザクションかを判定します。そして関係があれば、「ストリップドブロック」をダウンロードし、必要なトランザクションを抜き取ります。


初期同期のプロセスは典型的なモバイルデバイスでは数分間かかるでしょう。ニュートリノクライアントが保存する合計ブロックーチェーンデータは約数十MBです(ブロックチェーンフルノードは約200GB)。初回の同期後は、GCSフィルターのおかげで通信データ量はかなり少なくて済みます。ただし、ニュートリノクライアントはフルノードよりもデータ通信量は少ないですが、BIP37のSPVクライアントに比べると多くのデータ通信が必要になります。必要なデータ通信量は多くのモバイルデバイスにとっては許容範囲であり、プライバシーとセキュリティー向上のためのトレードオフは十分に価値あるものだと思います。さらに、ニュートリノはフィルターとブロックデータを考慮しバッチ処理と並行処理を可能とする設計になっており、たとえより多くのデータ通信が必要になったとしても、ユーザー体感はより滑らかで応答性のあるものになるでしょう。


今後の開発

処理性能

上記で述べたように、ニュートリノプロトコルは断続的なネットワークと電力に縛られたデバイス上で動くように設計されています。しかし、lndに実装されている現状のニュートリノはまだ完全に最適化がされておらず、さらなる改良が現在進行中です。

Block retrieval

ニュートリノクライアントは、ブロックやフィルターを(P2Pのビットコインネットワーク外も含め)どこからでもダウンロードするこができます。さらなるプライバシー向上が見込まれるブロック検索の方法として「プライバシー情報検索」があります。現状では、トーアがプライバシー保護として適当な手段ではあります。

Neutrino serving neutrino

(BIP37で使われるフィルターと違って)ニュートリノで使われるフィルターは全ノードに対して同じなので、ニュートリノノードは、他のニュートリノノードにそのフィルターを提供するように設定することができます。これはニュートリノクライアントがネットワークへ貢献することを可能にするでしょうし、またフルノードの処理コストを軽減できるかもしれません。

Filter commitments

ソフトフォークによって、マイナーによってGCSフィルターのハッシュ値がブロックヘッダーに直接追加されることが可能になり、これによりフィルターヘッダーのチェーンデータが不要になったり、フルノードがニュートリノクライアントに不適切なフィルターを送りつけるような悪意ある行為を除外できるようになります。また、ニュートリノフィルターはブロックチェーンのスキャンや探索を瞬時にする必要があるアプリケーションにも使用できるでしょう。

Developer tools

通常のブロックチェーンデータの検索のために、開発者がニュートリノを使えるようにするためのAPIの開発に取り掛かっています。


結論

BIP157/158に準拠したニュートリノクライアントであるlnd0.5Lightning App alphaをリリースできたことを大変光栄に思っています。これらはまだテストネット版ではありますが、メインネット版ニュートリノも開発中です。ニュートリノはbtcdにもサポートされ、またBIP158のサポートもbitcoind(BItcoin Core)にマージされました*4。長期的には、多くのノードオペレータやビットコイン開発者によってニュートリノがサポートされ、ユーザーがプライバシーの保護やセキュリティリスクを低く保ちながら、よりよりユーザー体験ができるようになることを望んでいます。ニュートリノが次世代モバイルウォレットのためにより改良された基礎技術を提供できることと信じています。


脚注

*1.軽量クライアントが特定の資金(例えば、特定のUTXO)が使用されたかをフルノードへ確認した場合、フルノードは故意に間違った情報(この場合、まだ未使用であること)を返す可能性があります。この攻撃は、通常の支払い場面では、その支払いに関係する当事者は再支払いを要求するか、支払いが完了するまで商品を購入者へ渡さない、ということができるので殆どありえない攻撃です。しかし、ライトニングネットワークの場合、ノードは常に「不正なチャネル閉鎖をするトランザクション」がないか監視する必要があり、もしそのトランザクションを見つけられなかった場合、その資金を失う結果になります。

ニュートリノにおいては、異なるピアから競合するフィルターが送られてきた場合、その競合したブロックを見つけ、その1ブロック全体をダウンロードします。そのブロックからどちらのピアが正しいのかを自動的に判断することができます。BIP37のSPVクライアントではユーザーに対してこのアラートは出せますが、自動的に競合を解決することはできません。


*2.ニュートリノを実装したクライアントでもウォレットの情報の幾分かの漏洩を防ぐことはできません。これは、悪意あるノードが、モバイルウォレットがどのブロックをダウンロードし、ブロックにまたがってどのアドレスが再利用されたかを観測できるからです。これを緩和するには、上記ブログで述べた「プライベート情報検索」の活用を模索しています。それでも、ニュートリノは他のどのモバイルクライアントよりもユーザープライバシーは高いと信じています。


*3.Segwitの採用によって、ビットコインの取引署名(witnessデータ)は既存のデータ構造から分離されました。ニュートリノクライアントはこの分離されたwitnessデータは不要で、「切り取った」ブロックのみのダウンロードで済み、結果的に多くの帯域帯の節約に繋がります(潜在的に50%以上の節約)。


*4.BIP158がbitcoindにマージされましたが、一方でまだBIP157はマージされていません。そのためニュートリノのフィルターをまだbitcoindではサポートできない状況です。今後数ヶ月にわたってニュートリノの完全なサポートを追加する作業が進行中です。


LightningPeach Walletの紹介

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


LightningPeach Wallet

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


新機能

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

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

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

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


実際に使ってみた

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

(1)プロフィール画面

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


(2)チャネル開設

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


(3)ライトニングペイ!

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


(4)ストリームペイメント

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


所感

ライトニングの仕様上、現状は受取者がまずは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
  • キャロル:0
  • デイビッド: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持っているのに、アリスー>ボブのチャネルは0: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による「超小額決済」を活用したアプリという方がしっくりきます。オンライン上のサービス・モノを購入する場合、クレジットカードやビットコインでは決済手数料が実際のサービス利用料より高くなることがあります。例えば、1個の記事を読むのに10円だった場合、クレジットカードやビットコインの手数料の方が高くなってしまいます。ライトコインやビットコインキャッシュなどの仮想通貨は手数料が比較的低いですが、それはそのコインの価値や取引件数が少ないためです。Lightning Network上で決済をする場合、その手数料は0.001円(現時点)とかなり低く抑えることができます。これにより、10円の記事の購入によるマイクロペイメントが可能となります。


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

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

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

マイクロペイメントは、オンラインコンテンツ提供者の広告収入や購読料金などのビジネスモデルに対抗した1つの収益モデルとして注目を浴びています。しかし、ユーザーは一般に定額料金を好み、細かい金額を気にすることを嫌います。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サーバで実現可能(参考サイト)。動画ストリーミングをセグメント単位で支払うことで視聴できるようにするテクニック。セグメント単位にプリイメージが埋め込まれ、インボイスを支払うごとに得るプリイメージを使ってセグメントをデコードする(参考サイト)。


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

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

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


マルチホップペイメント

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


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


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

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

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

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


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


参考

[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;
}

【緊急速報】日銀の緩和策修正について

*.marginmarker {
background-color: #f0e68c;
/**margin-left: 0.3em;**/
/**margin-right: 0.3em;**/
}

普段とは違い今回は日銀の緩和策修正についてのメディアの報道と僕の意見についてお話したいと思います。2018年7月31の金融政策決定会合でついに黒田さん率いる日銀が緩和策の修正を決定しました。その理由は異次元緩和の副作用が目立つようになってきたからです。

主な副作用には、以下があると言われています。

  • 銀行経営の悪化
  • 年金や保険の運用難
  • 金融市場のゆがみ

では、上記の副作用について一つずつ見ていきましょう。


銀行経営の悪化

地銀の本業である貸し出しによる儲けは実は増加しているんです!全国地銀協会との決算を確認してみましょう。出典はこちら


コア業務純益:+2.1%(+227億円)の1兆887億円

業務純益  :▲8.5%(▲884億円)の9,463億円

経常利益  :▲2.7%(▲301億円)の1兆1,015億円

当期純利益 :7,838億円(▲1.5%[▲115億円])


貸し出しなどの本業であるコア業務純益は黒字であり、貸出金も増加していることから融資は頑張っています。一方で、国債・外債などの損益を表す業務純益がマイナスとなっています。これは銀行は、マイナス金利によって国債からの収益が見込めないことから外債を購入していましたが、アメリカやヨーロッパでは金利が上昇し、外債価格が下落したため損をしたのです。要は、外債を運用して失敗したわけです。それで、経営難だとか言っているのはちょっとおかしいと思いますが。

一方で、フィンテックやブロックチェーンなどで銀行が不要になるとか、融資はソーシャルファンディングやクラウドファンディングにとって替わるとか言われていますが、僕はそんなことは無いと思います。会社を運営するのは人です。人と人とのつながりは「信頼」によって成り立っています。いくらブロックチェーンでトラストレスなシステムが作れたとしても、取って代わる箇所は限定的で、むしろ共存していくものだと思っています。社会は人との繋がりで成り立っていますので、今後も銀行マン・ウーマンによる融資を期待しています。


年金・保険の運用難

年金を運用している年金積立金管理運用独立行政法人(GPIF)の2017年度の運用実績は、10兆810億円(収益率6.9%)の黒字と、2期連続で運用益を確保しています。え?運用難では?と思いますが、実際は着実に積立額を伸ばしているんです。出典はこちら


金融市場のゆがみ

これは銀行経営の悪化が起因して、金融仲介機能の低下をもたらすことを意味しています。しかし先に見たように銀行による貸出し金は増加傾向にあることから金融市場にゆがみはないと思います。


ばらまいたお金はどこへ

副作用があるからといっても、お金を市場にばら撒き、円安ドル高、日経平均株価高などの恩恵を受けている企業や団体は存在します。その証拠に企業の内部留保は上昇(400兆円以上)しています。要は企業が儲けたお金は設備投資、配当、賃上げには投下されず、タンス預金みたく蓄えているというわけです。これでは、個人消費が伸び悩むわけですね。


最後に

皆さん消費しましょう!モノやサービスをです!でも何を買おうか迷っている人のために、今回はイギリスブランドで日本未上陸のジャックウィルスの洋服が買える本サイトYYBazaarをご紹介します。本サイトではクレジットカードは勿論、ビットコインやライトコイン、さらにはライトニングペイ決済にも対応しています。おくりびと行きなった方はぜひ仮想通貨での購入を!

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

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種類ある。

  1. To_local
  2. To_remote
  3. Offered HTLC
  4. 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対応ウォレットは、数日間アプリを起動しない場合、悪意あるノードにコインを盗まれてしまう可能性があるので、大金をライトニングネットワーク対応ウォレットに保管しないほうが良いと思います。



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

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

サンドルフォードTシャツ
クロムフォードノットTシャツ
短編小説(デジタル商品)

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

ライトニングノードを立ち上げてから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円

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

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

サンドルフォードTシャツ
クロムフォードノットTシャツ
短編小説(デジタル商品)