マイクロペイメントと分散システムの未来

2020-04-06 00:56:19

今回はタイトルにあるような抽象的で壮大なお話ではなく、LSAT(Lightning Service Authentication Token)と言われるLightning Networkを活用した認証技術について書きたいと思います。ではなぜタイトルを小難しくしたかと言うと、これまでのインターネットとセキュリティの歴史が、LSATのコンセプトと深く関係しているためです。タイトルにある分散システムは、複数のコンピュータが連携し、あたかも一つのサービスを提供しているようなシステムのことです。例えば、オンラインバンキングはオンライン上で処理を受け付けるWebサーバーと実際の勘定をするホストが存在し、それらが組み合わさって一つのサービスを提供しています。その他にも航空券予約システムやウェブメール、また、インターネット自体が分散システムとも呼べると思います。情報技術が進化するにつれて、様々なサービスが連携するようになり、もはや分散システムでないサービスを見つけるほうが難しいのではないでしょうか。

分散システムで大切なのが、各リソースに対するアクセス制御です。これまでは（分散システムに限らず）アクセス制御リストと呼ばれる方法でアクセス制御を行ってきました。しかし、連携するシステムが増えることで、アクセス主体を全て把握することが困難になってきて、Confused Deputy Problem（詳細はこちら）と言われるアクセス制御の問題が出てきました。そこで、Capabilityと呼ばれるチケットを持っていればアクセス権があるとみなすアクセス制御方法が提案されますが、この方式が実装されている例は少ないのが現状です。

とここまで分散システムとアクセス権の現状を超ざっくり紹介してみました。が、なんのこっちゃ？だと思います。上記の話がどのようにLSATと結びつくのかは後述しますので、とりあえず先へ読み進めてみてください。

LSATについて
LSATとは、認証と課金APIの為の標準プロトコルで、クッキーやBearerトークンのように動作します。Lightning Labによってプロトコル及びデモが実装されており、ここから仕様などを確認することができます。LSATの仕組みの解説の前に、まずはクッキーとBearerトークン、Macaroonsについて簡単に説明します。

クッキー
WebサーバーとWebブラウザ間で一時的にやりとりされるファイルのことで、あるサイトが発行したクッキーをブラウザが保持することで、そのサイトを再訪すると、以前のユーザー情報を特定することができます。

Bearerトークン
Bearerトークンは、ある対象へのアクセス制御を、その「トークンの所有」のみで決定される仕組みです。Bearerトークンを持っていればあるサービスへアクセスができ、その所有者が誰であるかは関係ないので、そのトークンを誰かに渡すことで、第三者でもアクセスができてしまいます。これをCapability-based authenticationとよび、「トークンを持っていること」＝「Capabilitiyがある」という意味からの由来です。

Bearerトークンを用いたWeb認証はBearer認証またはトークン認証とよばれ、OAuth2.0*1でサポートされています。
*1 OAuthとはあるサービスへの権限を認可するためのプロトコルで、Twitterログインなどのソーシャルログインで使われる仕組みです。

クッキーはBearerトークンのような使い方が広くされており、両者を明確に区別することは難しいです（僕自身、明確な違いがあるのか分かっていません）。参考までにこのサイトでは、「ブラウザはクッキーは自動的に送信するが、Bearerトークンはしない」という違いがあると解説されていました。ただ、クッキーもトークンもサーバー／ブラウザ間でのアクセス制御を行うために送受信されるチケットであると認識すれば、ここでは問題ないと思います。

Macaroons
Macaroonsは（以前の記事で紹介しましたが）、クッキーとほぼ同じようなものですが、アクセス権限を付与することができ、かつそのMacaroonを第三者へ渡すことで権限委譲することができるチケットです。実はこのマカロンが今回の話のコアとなっており、分散システム上でのCapability-based authenticationのためにGoogleによって提案・開発されました。

Lightning Networkによるビットコイン決済
ここで認証の話から少し離れて、ビットコイン決済についてです。LNでのビットコイン決済ではインボイス方式をとっており、インボイスの支払いとレシートの受取りをもって決済が行われます。以下がLN決済の簡易的なフローとなります。

支払人は、受取人へインボイスを請求
受取人は、インボイスを送付
支払人は、インボイス情報をもとに支払い
受取人は、支払いを確認後、レシートを支払人へ送付

この時、このレシートがProof of Paymentと呼ばれる支払い証明書となります。このレシートを所有していることで、対象のインボイスの支払いが完了したことの証明になります。

例えば、スポットライトではログインなしで記事の購入が可能ですが、記事を購入後ページを更新すると有料コンテンツの閲覧ができなくなります。これを解決するためには、購入時のレシートを見せることで、記事の再閲覧が可能になります（現時点でスポットライトにこの機能は実装されていません）。レシートがチケットの代わりとなり、記事の閲覧のCapabilitiyがあるということになります。

このようにあるサービスやコンテンツに対して支払った際に受け取るレシートを活用することで、そのリソースへのアクセス制御をすることができ、そのための認証方式がLSATなのです。

普段僕達が使うシステムで似たような仕組みがあります。例えば、オンラインで航空券を購入する場合、アカウントなしでも購入することができ、その際に登録したメールアドレス宛に予約番号が送られてきます。その番号を入力することで、フライト情報の確認や変更ができるのですが、上記でみたProof of Paymentはこのような仕組みに近いです。

LSAT = Macaroons + Lightning
LSATでは、チケットであるMacaroonsとインボイス情報を組み合わせた認証方法で、言い換えれば、LSATは次の二つのデータを含めたチケットになります。