L402：有料コンテンツやAPIの認証におけるスタンダードを目指す野心的なプロトコル

加藤規新 • 2023年07月14日

概要

・L402 (旧LSATs)はウェブ上で有料のリソースへのアクセス認証をライトニング払いで入手できるトークンで行うための規格である。

・ユーザー情報の登録やクレジットカード決済の必要なしに有料リソースに対して少額従量課金やサブスクリプションのような決済方法を提供する。例えば有料APIの提供時にユーザー情報や支払い情報を管理することなくステートレスにアクセスを制御できる。

・L402/LSATsを提唱したLightning Labs自身が提供するLightning Loop・Lightning Poolサービスにすでに利用されているが、規格化によって他のサービスでの利用やLnd以外のノード実装で利用できるインターフェースが用意されやすくなる。

・L402という名称はこれまで一般的に使われてこなかったHTTPレスポンスコード402 PAYMENT REQUIREDに由来する。

Lightning Labsが提案しているL402という認証プロトコルとAIエージェントの相性についての話題が盛り上がっています。私はAIについては詳しくないのでその相性の話は割愛しますが、広い話をすればウェブ上の支払い方法が共通規格化されていないこと、支払手段自体も人間の介在を前提とするものが多いことに端を発していると解釈できるでしょう。確かにサービスによって支払いのフローは微妙に異なりますし、同じクレジットカード決済でも3Dセキュアが要求されたりされなかったりします。

果たしてAIエージェントにライトニング支払いを任せて安全なのか？などといった疑問はどうしても出てきてしまいます。これが安全にできるという根拠があれば教えてほしいです。

したがって今日はこのトピックのうちペイメント規格の部分にのみ注目し、L402というプロトコルがどのように機能し、ウェブサービスやAPIにどのようなメリットをもたらすかについて解説します。

過去にLSATsとして解説した際の記事もご参考にしてください。

HTTPレスポンスコードの由来

HTTPレスポンスコードは非常に技術的な内容ながらもエンドユーザーが目にすることの多い、珍しい性質のものかもしれません。読者の皆さんも調べごとをしている際などに404 NOT FOUNDや403 FORBIDDEN、500 INTERNAL SERVER ERRORなどがウェブページに表示された経験をお持ちでしょう。

現代のウェブはHTTP通信の上に成り立っており、クライアント(ブラウザ)がサーバーへと送信したHTTPリクエストには必ずHTTPレスポンスが返ってきます。(返ってこないとリクエストがタイムアウトし、Chromeなら恐竜が表示されます。)

このHTTPレスポンスコードは非常に多くあり、200番代は成功、500番台はサーバーエラーなどと大まかな意味によってグループ分けされています。ジョークのようなコードもあるので、興味が湧いた方はぜひ一覧で見てみてください。

さて、クライアント側に起因するエラーを意味する400番台のコードの中には402 PAYMENT REQUIREDというものがあります。その名の通り、この有料コンテンツにアクセスするには支払いが必要だよ、という内容のレスポンスコードです。ところが、1997年にHTTP/1.1の策定とともにこのコードが追加されてから今に至るまでこのレスポンスコードが返ってきたときにブラウザなどのクライアントがどのような挙動をすればよいのかが定められてきませんでした。(個別のアプリケーションでこのステータスコードを返すものはあります)

L402はオープンソースでパーミッションレスなライトニングネットワークを通したビットコイン支払いでHTTP 402レスポンスをハンドリングしようという試みなのです。

ステートレスな有料サービス提供が強み

ところが、鋭い読者の皆様ならいきなりLightning Labsがこんな規格を提案したからといって世界のデファクトスタンダードが取れるわけではないと認識していることでしょう。私もその通りだと思います。マスアダプションには既存のアプローチに対してそれなりの優位性を発揮することが求められます。

そこでL402が前面に押し出しているのが認証トークンの発行と支払い、検証を独立して行えることです。認証トークンの発行や検証にライトニングノードが絡む必要がないため、この認証機構は支払いの決済に影響することなく簡単にスケールさせることができます。

つまり、L402/LSATsはリクエストの都度支払いを確認しなくて良いベアラー型のトークンであることに加えて、そもそも支払い自体もウェブアプリを経由せずライトニングネットワークで完結します。もちろん支払いを受け取った記録はライトニングノードに残りますが、クライアントにトークンとプリイメージを提出してもらうので参照せずに支払いの事実を検証できます。

またこのトークンには必ずしもLightning Labsが推しているMacaroonを使う必要はなく、その他のトークン形式を用いたり従来のようにデータベース管理することもできます。ただサービス側によるインボイスや利用条件への署名とユーザーが持つ領収書であるプリイメージを組み合わせたトークンスキームを使うことでパフォーマンス面や設計・運用面でステートレスに有料サービスへのアクセスを管理できることは大きな強みだと言えるでしょう。

つまるところ、L402を使うことでAPI提供者はユーザーデータを保管することなく、シンプルなアーキテクチャでサービスを提供できます。

L402の仕組み

クライアントがHTTP 402によってブロックされているリソースにアクセスするとき、可能であればそのリソースに対して有効なアクセストークンを送信するとそのリソースを参照できます。もしトークンがなければサーバー側にあるApertureというリバースプロキシがサービス側のライトニングノードにインボイスを要求し、インボイスとアクセストークンをクライアントに返します。

前述の通り、アクセストークンの生成自体と検証はApertureが行い、ライトニングノードはインボイスの生成と支払いの決済のみを行います。

インボイスを受け取ったクライアントはライトニングネットワークで支払いを行い、その結果得られるプリイメージをアクセストークンに加えてから再び有料リソースへのリクエストを送信します。

サービス側ではトークンの内容にあるインボイスに対して有効なプリイメージがあれば支払いが確認できるため、有料リソースへのアクセスを許可します。トークン自体に有効期限や残存クレジット数、有効範囲などの条件を付加することもできます。

利用例

Lightning Loop、Lightning Pool…軽量なユーザー認証として使用している。

また、アクセス権のプライシングや消費ペースを事後的に(トークンの発行後に)調整することも可能なので、需給に応じたロードプライシングが必要なユースケースなどにも応用できるようです。(Macaroonなど、そのような情報を付加できるトークン形式を利用した場合)

このように、L402は有料サービスの認証・利用方法としてかなり汎用性が高いと言えるでしょう。

展望

今後L402の仕様がはっきり固まればまずはライトニング関連で提供されている有料APIが対応していくと予想されます。なぜならばライトニング関連のAPIを提供している事業者はライトニング支払いを受け付ける能力があるためです。

実際にアダプションが難しいのはより一般的なAPIにおいてでしょう。他の支払い方法にライトニングを追加するにしろ、そのためにはAPI提供者によるある程度の努力が必要なほか、L402と他の支払方法をどのように両立して提供するかという面で検討が必要な事項、そしてある程度のソフトウェア開発が必要になる可能性があります。

少なくともライトニング関連では今後１〜２年で普及が進む可能性は低くなさそうですが、問題はその後も利用を拡大できるかという部分にあるように思います。

加藤規新

1994年生まれ、シカゴ大学でGISやコンピューターサイエンスを学び学士号取得。2016年末よりビットコインに関するリサーチや実験的な開発をしており、今までにいくつかのブログやサロンで解説を担当。ビットコインについて一番好きなところはパーミッションレスに誰でも使うことができること。 2024年11月より日本ビットコイン産業株式会社取締役。