Lightning Network は何故 invoice ベースの決済なのか (2 of 2)

普通にインターネットを利用している方には少し縁遠いかもしれない、そんな話から入ります。

よほどイケていない若干の例外はあるかもしれませんが、ほぼ全ての Web サービスは、API (Application Programming Interface) というものを提供しています。

仮想通貨に興味のある方ですと、Twitter に tipbot なるものがあるのをご存知と思います。Tipmona 辺りが有名どころですね。

あれら tipbot は Twitter が提供する API を利用して、Twitter 社とは関係ない企業や個人が管理運用しています。

市場取引にお詳しい方なら、取引 bot なるものがあって、初心者を狩りに行っていることをご存知でしょう。あれらは仮想通貨交換業者が提供している API を使っています。

Google が提供するサービスは、たいてい無料で使え、Google Maps でお金を払った記憶がある方は滅多に居ないと思います。しかし、Google は、API 経由での Google Maps の利用について、一定以上の頻度の場合は有償で提供しています。Google さんもご商売ですし。

Twitter も一部 API は課金で、その範囲を広げようとしています。今春辺りから「Tipbot らが運用継続できなくなるのでは」というツイートがしばしばみられましたが、API の変更と課金モデルの変更が背景にありました。

...

このように、インターネット上に存在するサービス群の多くは、裏側で API でつながっています。そして API の利用に際して課金したいという需要が少なからずあります。

現状、このような API 課金は 2 通りあります。

1. ポイントなどを先に購入させ、利用ごとにポイントを減少させる。
2. 呼び出し回数を記録して、周期的に(毎月とか)請求する。

余談: この他に毎月固定のお支払で使い放題というモデルもありますが、API 課金の場合は今ひとつ人気がないようです。使う側からすると、一回も使わなかった場合でもお金を払うのは嫌です。一方、API 提供側からすると「定額を払ったから」と大量のアクセスをされるとシステムが落ちかねません。

...

暗号通貨勢はトラストレス好きですので、API 課金もブロックチェーンを使ってトラストレスにしたいところです。

上記の「1. ポイントなどを先に購入させ…」は API 利用者から見ると、いわゆる GOX リスクがあり論外です。

「2. ...周期的に(毎月とか)請求する」は、API 提供者から見ると、夜逃げされるリスクがあります。

...

さて、ここで、オンチェーン決済絶対主義(いわゆるビックブロック)にとって悩ましい事実を一つ、追加しましょう。

API は常に提供可能な状態にあるとは限らないのです。

最近見かけなくなりましたが、Twitter でサービス障害が起きて、いわゆる「くじら」が表示された記憶をお持ちの方もいらっしゃるでしょう。また、国内取引所で "502 Bad Gateway" なる表示とともに取引不能になりキレた方も多いでしょう。

これらのユーザインタフェースが落ちている場合、後ろで動作している API サーバも少なからずの確率で落ちています。

そもそも多くの API サーバが基盤として依存しているクラウド事業者も、トラブルなく運用できているわけでもありません。マイクロソフトのクラウド基盤である Azure の状態の履歴をみると、意外と頻繁に何らかのトラブルを起こしています。これは Azure の品質が悪いわけではなく、他のクラウド事業者でも同じような頻度で何らかのトラブルを起こしています。

一般論として、API が常に期待通りに利用できるかどうかは、誰も保証できません。「一年のうち95%くらいの期間は正常にサービスが使える…はず」という保証の仕方をします。このような状態なのに、 API 利用者から一方的に送金されても、 API 提供者は困るわけです。場合に応じて返金対応しなければなりませんし、オンチェーンならマイナーに送金手数料を追加で払わねばなりません。秒間何千回もある API 呼び出しの、どの呼び出しと送金が結びつくのか、プロトコルレベルでは判りません。

「いやペイメントプロセッサを併用すれば可能だ」とビックブロック派が主張したとして、それもまた一つの考え方だと思います。

しかし、人間が手動でブラウザを操作するのと、計算機と計算機との間で行われる API とでは、速度も頻度も段違いです。仮想通貨交換所で API 由来の過負荷が起こることから、なんとなく想像していただけると思います。

API 利用不可だったときの返金トランザクションも含め、ブロックサイズがどれくらいに膨らむのか。ビッグブロック原理主義の方々は、慎重に計算したほうが良いでしょう。

また、現存する API サービスの殆どは、普通に Web ブラウズをするときに使っているのと同じ HTTP (HTTPs) プロトコルを使っています。そして HTTP を使った決済手段である HTTP/1.1 402 Payment Required は、(一方的に送金するのではなく)サーバ側から遅れてくる請求情報に応答するという流れで決済を完了させることを暗に想定して設計されています。

技術勢へのお知らせ: 402 Payment Required と Lightning Network を結合する仕組みは既に存在しソースコードも入手できます。https://github.com/ElementsProject/paypercall

諸々踏まえて API 課金決済を考えてみると、請求書ベースとし、返金までプロトコルでサポートするほうが合理的です。

…これ、Lightning Network の特徴そのものですね…。

...

さて、あえてしつこく Lightning Network (LN) を使った場合のデメリットを考えてみます。

オフチェーン決済の場合、オンチェーンで資金をロックされるというデメリットが API 利用者にはあります。

しかし、API 利用者側のバグにより無尽蔵に API 課金し続けた結果に起こる、いわゆる「クラウド破産」が起きないというメリットもあります。加えて、Lightning Network (LN)ではトランザクションを送金元/送金先がお互いに持って牽制し合うので、GOX リスクは極めて低くなっています。深入りしませんが、LN には万一 GOX した場合の取り返し手段も存在します。このあたりは(少なくともプロトコルのレベルでは)十分にトラストレスです。

...

実際のところ HTTP/1.1 402 Payment Required が請求書ベースであることから、API 課金に限らず、 Web で決済したければ LN のほうが合理的です。

しかし、人手でポチポチとクリックするなら、外部のペイメントプロセッサがあれば、LN でなくても十分対応できます。幾つかのユースケースでは LN であることが足かせとなる場合もあるでしょう。Twitter でもそのようなケースでの送金困難を見かけます。

(上記ツイートのような状況に陥らないための平易なテクニックはあるのですが、それが広く共有されていない現状では「LNは使い物にならない」「ヲタクのオモチャ」という声は否定しきれないでしょう。)

LN が真価を発揮するのは、高頻度 API 課金が必要になるような環境、難し目の言葉でいえば Semantic Web, IoT, M2M といったキーワードが登場するような、シリアスな自動化が行われている環境。そのように、当業者BOTの中の人は考えます。

そして、その "環境" が一部の業者やヲタク向けの "特殊な環境" と思うかどうかは、各位の想像力次第でしょう。

シェアリング経済圏が広がっていくことが確実な情勢で、宅内の自動化ができるホームスピーカーのようなガジェットが量販店で買え、自動車はクラウドとつながり、IT後進国の日本でさえ小学生のプログラミング必修化が決まりました。

日常がプログラミング可能になる世の中で、重要性を増すのは、API です。API を組み合わせることが、日常のためのプログラミングを、支えることになるでしょう。

そして API 課金と親和性の高い LN は、そのような仕様になっている合理性があります。たぶん。

…今井さんの尻馬に乗るならば、つまり、こういうことです。