【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シャツ
短編小説(デジタル商品)

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

アトミックスワップとは

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




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



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



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

ライトニングネットワーク:ルーティングを探検

まえがき

本投稿も前回に引き続き、Lightning LabsのメンバーBryan Vu氏によるライトニングブログ(投稿日:2018-05-30)を翻訳しました。前回より少し難しい内容ですが数回読み返していただくとより理解が深まると思います。



前回私たちのヒーローキャロルとお別れした時、彼女はライトニングネットワークに見事参加し、ライトニングペイを使うようになりました。ライトニングのユーザー体験の一部に慣れてくるにつれ、ライトニングの技術面について興味を持つようになりました。BitFlixの月額料金を支払うためのルーティング手数料を稼ぐためにライトニングルーティングノードを彼女自身で立ち上げようかさえ考えるようになりました。このブログでは、キャロルのようにライトニングノードの立ち上げに興味がある、または、ライトニングネットワーク用のアプリケーションの構築や、単にライトニングに興味がある熱烈なファンのために贈るものです。この投稿では、ライトニングとペイメントチャネルの基本的な知識をすでにお持ちの方をターゲットにしています。

トピックス

  • チャネルバランス
  • ゲートウェイルーティングノード
  • 広告と非広告チャネル
  • バッファーキャピタル
  • ソースルーティングとオニオンルーティング
  • ブリッジチャネル
  • アトミックマルチパスペイメント(AMP)

このブログが読者の方により深いライトニングプロトコルの理解と、そのネットワークがどのように成長、発展するかの私たちの考えを伝えることができれば幸いです。検閲耐性・非中央集権、セキュリティ、プライバシー、ユーザビリティ、スケーラビリティ、スピード、コストを含むライトニングに対する私たちの目的にも触れます。ルーティングについては、可用性(ユーザーの資金は常時利用可能であるべき)と接続性(ネットワーク参加者はどの参加者へも送金できるべき)の2つの向上が主な目標です。


チャネルバランス

ライトニングの主要コンセプトの一つにチャネルバランスという考え方があります。ペイメントチャネルは総容量(オンチェーンでのチャネル開設時のトランザクションによって確立される)があり、そのチャネル内でお互いが送金できる容量が決まっています。エンドユーザーにとっては、ライトニングにおけるチャネルバランスは銀行口座や財布の中の現金を使うような概念に似ています。ユーザーはライトニングウォレットにビットコインを補充し、数日、数週間にわたってその残高を使い、また補充します。銀行口座が空になり何度も入金するように、ライトニングチャネルでも同様なことができます。ライトニングユーザーが数ヶ月、数年間はライトイングチャネルを開き続けることを予想しており、そうなることでチャネルを閉鎖、開設するときに必要なオンチェーンでのトランザクション手数料を最低限にすることができます。

チャネルバランスは販売者や取引所・交換所、その他のビジネスでも適用します。殆どのビジネスは、エンドユーザー(消費者)に比べ、格段にたくさんの総容量チャネルを持ちますが、これはチャネルを通して入金と出金の両方のフローが必要だからです。送金したり受け取ったりするための利用制限を増加したいユーザーやビジネスは追加でチャネル開設したり、既存のチャネルの総容量を増やしたりできます(チャネルの容量調整を「スプライシング」と呼び、今後のブログでご紹介します)。重要なことは、すべてのライトニング参加者は入金と出金のチャネルを管理します。この処理は既存金融システムがどのように機能しているかに照らし合わせることができるでしょう。

ネットワーク参加者のインバウンドとアウトバウンド資金の流れ:将来、ネットワークが進展、成長し安定した状態になると、参加者は時間に伴ってバランスの取れた入金と出金用のチャネルを持ちます(流れが一方向または他方向で不均衡になる期間もあります)。


ルーティングノード

私たちは、インターネット接続や電源が断続的なモバイル機器やコンピュータを使って送金や受取をするライトニングユーザーが大半だろうと予想しています。このため、大多数のチャネルはエンドユーザーのノードとルーティングノード間で開設されるでしょう。ルーティングノードとは常時オンライン状態で、ライトニング決済をルーティングして手数料を稼ぐことを目的としたライトニングノードのことです。他のライトニングノードと同じように、ルーティングノードはビットコインのネットワークとのやりとりが可能でないといけません。ルーティングノードはフルノードである必要はなく、ニュートリノのような軽量クライアント用プロトコルを使って操作することもできます。しかし、より大規模なルーティングノードはビットコインノードによる検証が行われるようなセキュリティ強化されたものが好ましいでしょう。

「ゲートウェイ」ルーティングノードはエンドユーザーに直接サービスを提供します。このノードは比較的少数のユーザー(およそ100人以下)と接続し、適当なハードウェア、帯域幅、総容量で構成されます。時間が経つにつれ、ゲートウェイノードはより多くのチャネル接続ができるでしょう(以下のブリッジチャネルを参照)。私たちは現在、ルーティングノード操作者のために、そのツールとガイドを作成中で、数ヵ月後には初期バージョンをリリースできるでしょう。私たちの目的は、ライトニングに参加するための敷居を下げ、広く分散されたルーティングノードエコシステムの発展を促進し手伝うことです。


広告と非広告チャネル

顕在化されていないライトニングの一面に、多数のノードとチャネルはルーティングができず、ネットワークグラフに可視化されていないことがあります。エンドユーザーのノード(スマフォやノートパソコンなど)は初期状態ではチャネルを「広告」しません。これらの非広告チャネルはライトニングペイのリクエストに付加される「ルートヒント」または追加ルーティング情報を使うことでルーティング可能になるのです。ルートヒントは受取り側の非広告チャネルについての情報を持ち、支払い者にライトニングネットワーク内の公開、非公開ホップの組み合わせで経路(ルート)を組み立てることを可能にします。非広告チャネルがエンドユーザーのデフォルトになることで、ライトニングルーティングがより効率的になり、ルーティングテーブルが劇的に小さくなります。そしてより信頼性のあるルーティングノードが普及していくことが期待されています。

将来的には、ルートヒントはより多くの有効なルートパス情報を供給することで、たとえ送信者、受信者がネットワークグラフ上に見えない状態であっても送信者が受信者へのルートを見つけることが可能になるでしょう。

広告、非広告ペイメントチャネル:中継可能なだけのペイメントチャネルはルーティングに使われるべきではなく、広範なネットワークに広告されないでしょう(この図は簡略化してあります)。典型的なゲートウェイノードはより多くのインバウンド、アウトバウンドチャネルを持ち、エンドユーザーは一つ以上のゲートウェイと接続されます。


バッファーキャピタル

ネットワークへの連続アクセスを供給することに加えて、ルーティングノードは入金と出金を集計することで、全体の入出金の流れのバランスを保ちます。実質的には、ある一定期間に、あるルーティングノードユーザーは資金を使い、他のユーザーは資金を補充します。しかし、資金が同じ方向へ移動し始めるときがあります(例えば、送金が受取より多い場合)。これらの状況下でルーティングノードは、資金の流れが逆流しチャネルが元のバランス状態に戻るまで待つための十分な「バッファーキャピタル」を維持しないといけません。バランスが取れていない期間を対処するための十分な総容量を持っていないルーティングノードはチャネル疲弊(ノードがチャネル開設を維持するための資金がない状態)に陥り、そしてルーティングに失敗します。このようなエラーは起こるべきではありません。なぜならこのようなルーティングエラーを起こすノードは他のノードから迂回され、最終的には切断されるからです。このように、ノード操作者は、受け入れるインバウンドチャネルの本数と容量のための十分なバッファーキャピタルを供給することに強い動機が働くのです。

バッファーキャピタル:ルーティングノードはチャネル疲弊とルーティングエラーを避けるために十分なバッファーキャピタルを提供するべきです。


オートパイロットとノード可用性の尺度

エンドユーザーのために、lndにはゲートウェイルーティングノードを見つけてチャネル開設する処理を自動的に行うオートパイロット機能があります。今後予定のオートパイロットのイテレーション(繰り返すこと)には、どのノードと接続するべきかの決定時にネットワークチャネルグラフから算出される尺度を使います。主要な尺度には、稼働時間、アウトバウンドチャネル容量、チャネル接続性の幅(インターネットでいう帯域幅のこと)、特定の目的地への接近性があります。これらの情報は、初期チャネル開設および開設済みチャネルの最適化を促進するために、ルーティングノードによって集計されます。最終的には、オートパイロットは、信頼性が高く安価な支払いを促進できるゲートウェイノードに対してチャネルを開設するでしょう。大半のユーザーにとって、オートパイロットはバックグラウンドで行われますが、上級者のためには、オートパイロットヒューリスティックという機能が設計されています。ライトニングコミュニティのメンバーは、特定のユースケースや完全に新しいアルゴリズムをデフォルトとして置き換えるためのノード選択パラメーターの最適化をすることが可能になるでしょう。

もう一つオートパイロットで重要なのが、エンドユーザーは関連性が全くない複数のルーティングノード(現時デフォルトは五つ)とチャネルを開設をすることです。これは、エンドユーザーにライトニングネットワークへ複数の異なる入り口を持たせ、ルーティングノードがオフラインになる場合に備え、信頼性の向上に役立ちます。これはインターネットのルーティングとは対照的です。なぜなら、ISPは物理的なインフラ(ファイバーと無線送信機)を建設するための費用による制限があるからです。ライトニングでは、他のノードと接続するためのインフラ構築のコストは単にオンチェーンのビットコイントランザクションのコストと同じです。

ネットワーク接続性、ライトニングネットワークvsインターネット:ライトニングネットワーク内のユーザーは、同じコストで物理的な制限に関わらず、そのネットワーク内ではどこにでもチャネルを開設できます。インターネットのルーティングは物理的なインフラコストによる制約があり、「ハブースポークト」ポロジーの形になってしまいます。


ソースルーティングとオニオンルーティング

ライトニングペイのルーティングとインターネットのルーティングの違いの一つに、ライトニングの場合、経路に沿ったそれぞれのルーターによって決定(通常のインターネットルーティング)されず、支払い者(ソースルーティング)によってルートが決定・確定されます。さらに、ライトニングはマルチホップペイメントのためにオニオンルーティングを採用しています。これは支払い経路内の中継ノード��は、それぞれのノードの前方と後方の情報しか知らないことを意味します。重要なことは、ソースルーティングとオニオンルーティングを組み合わせることで決済の送信者と受信者の情報を保護し、プライバシーと検閲耐性を強化できることです。

また、ライトニングネットワークのプロトコルはTorをサポートしており、将来のlndリリースではTorをサポートする予定です。エンドユーザーlndノードとゲートウェイルーティングノードとのやりとりは最終的にはTorがデフォルトになり、さらなるプライバシー保護をサポートすることが期待されます。


ブリッジチャネルとネットワーク接続性

これまで、ゲートウェイルーティングノード(エンドユーザーにライトニングネットワークへの接続するための方法を提供するノード)についてお話してきました。しかし、ライトニングユーザーがよく抱く懸念に、(1)接続性と(2)可用性(ライトニングネットワーク内のどこにいる参加者に対しても、速く信頼できる支払いができるか)があります。資本効率の良い(かつ安価な手数料)方法でこの接続性を向上させるためには、十分な総容量でより信頼性のあるノードが、他のルーティングノード間を「橋渡し」することです。これをブリッジノードと呼び、他のルーティングノードからのインバウンド広告チャネルを受け入れ、そして他のブリッジノードとゲートウェイノードに対して大きなアウトバウンドチャネルをつなげます。ゲートウェイノードとブリッジノードとの間に明確な区別があるわけではありません。あるノードは比較的多くのゲートウェイチャネルを持つかもしれませんし、あるノードはブリッジノードに重点を置くかもしれません。


ブリッジチャネルは、一般的にゲートウェイチャネルよりも速く支払い処理をし、また、ブリッジチャネルはエンドユーザーの中から引き抜かれるため、自然にバランスの取れたフローを持つでしょう。この二つの要因により、ブリッジチャネルはゲートウェイチャネルよりも多いバッファーキャピタルを持ち、その資本でたくさんの取引を処理することが期待されます。この資本効率はゲートウェイホップよりもブリッジホップの方がより安価な手数料になります。ゲートウェイノード単独で構成されるよりも、ブリッジチャネルがライトニングネットワークのユーザーに安価なコストで多くの接続性を与えるでしょう。

ネットワークが成長するにつれ、より多くのホップとブリッジチャネルが増えていき、指数関数的に多くのユーザーがネットワークを形成していくことが期待されます。私たちの暫定的なモデル予想では、直径10~15ホップのネットワーク内において、基本的な取引量と1円/取引以下相当の手数料で数十億ユーザーまでは対応可能です。また、上記で述べた資本効率性の理由により、ゲートウェイルーティングノードは、一般的な入出のバランスを取るために必要なだけ多くのユーザー(概算で数百ユーザー)にサービスを提供し、そしてブリッジチャネルを活用しより広範な接続性を提供することが期待されます。エンドユーザー視点では、ウォレットはより安価な手数料になるルートを選択(これは資本効率のよいブリッジチャネルを選択する傾向があるということ)するでしょう。

もう一つ注目すべきことは、エンドユーザーは複数のポイントでネットワークに接続され、またそれぞれのルーティングノードは他のルーティングノードとも接続されるので、特定のブリッジまたはゲートウェイノードによる取引の検閲はうまくはいかないでしょう。取引を検閲しようとするノードは迂回され、もし検閲しているノードが異常な数のルーティングエラーを出せば、他のノード達はその検閲ノードから切断するでしょう。また、オニオン暗号は送信者と受信者の情報をブリッジノードから見えなくするので、よりいっそう検閲が難しくなります。

マルチホップ支払い経路:ネットワークが拡大すると、始点と終点の経路の両方において非公告チャネルを二つ以上のゲートウェイノードとブリッジノードを越えることがでてきます。ライトニングが搭載されたソフトウェアはプライバシー向上のためにホップを追加しランダムにすることができます。


アトミックマルチパスペイメント(AMP: Atomic multi-path payments)

ライトニングルーティングに関する最後のトピックはAMP(アトミックマルチパスペイメント)で、これは送金者によって高額支払いを複数の小額支払いに分割することを可能にします。分割された支払いはライトニングネットワーク上の異なる経路を通って送信され、受取人がそれらを結合し、あたかも一つの取引であったかの様に見立て、その支払いを受理または拒否することができます。ユーザーにしてみれば、AMPプロセスは自動的に行われます。AMPはさらなるルーティングの柔軟性を可能にし、また複数の小さいチェネル群を1つの結合されたチャネルのように振舞うことができます。今後のブログではこのAMPの詳細について述べたいと思います。


結論

このブログでは、ライトニングルーティングに関わるいくつかの基本的なコンセプトについてお話しました。私たちLightning Labsでは、現在のプロトコルで、プライバシーの強化、ビットコインの非中央集権化および検閲耐性の向上をしながら、最低でも数百万のユーザーまで安価で信頼のある取引がスケールアップできると信じています。このブログはルーティングに関する私たちの考えについてお話しましたが、その他のライトニング実装をしている方々やライトニングコミュニティは他の考えを持っているかもしれません。ライトニングはオープンソースで協力しあうコミュニティであり、様々なアイディアについて討論することを楽しみにしています。

ライトニング革命は黎明期であり、今私たちが予測できないような様々な方法によって、プロトコル、アルゴリズム、ハードウェアの向上が効率性、プライバシー、スケーラビリティを改善することもあり得るでしょう。私たち(とライトニングのその他の実装者たち)は、将来版ライトニングネットワーク仕様書のためのプロトコル改善をすでにもっています。しかし、今後数ヶ月、数年にわたって、より多くの新しく、面白く、予想できないようなアイディアがライトニングネットワークのコミュニティおよびエコシステムから来ることを期待しています。