はじめに
今回の内容
本稿では、サブスクリプション型のスマートコントラクトプロトコルの標準規格提案であるERC-948について解説します。
本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
ERC-948は、2018年3月から活発に議論されており、具体的な実装も行われつつあります。標準化により、多くのDAppsがサブスクリプションモデルによるマネタイズを実現しやすくなる可能性があり、注目される議論といえるでしょう。
第1章 サブスクリプションモデル概要
サブスクリプションモデルとは、商品の購入ごとに課金をするのではなく、一定期間にサービスを利用する権利を販売する、継続課金型のビジネスモデルです。
サブスクリプションモデルでは、顧客は最初の加入契約さえ行ってしまえば、サービスの利用やその後の課金タイミングに支払いを意識する必要がなく、スムーズにサービスを利用することができます。
サービスを提供する企業にとっても、毎月の売上を安定させやすく、サブスクリプション型のサービスを展開する企業が増えつつあります。
主なサブスクリプション型のサービスとして、月額の音楽配信サービスや動画配信サービスなどのデジタルコンテンツはもちろん、衣服や自動車のレンタル、飲食店での食べ放題など、さまざまな業態でサービスが提供されています。
一般的なサブスクリプションモデルでは、顧客のクレジットカード情報を預かったり、銀行を介して定期引き落としを契約することで実現されます。
しかし、DAppsにおけるサブスクリプションモデルでは、信頼できる運営主体を置かないため、支払いのたびにユーザーによる署名が必要であり、簡単には継続課金を実現できません。
そこで、定期的な課金をイーサリアム上のスマートコントラクトで実現するための標準規格として、ERC-948が提案されました。
第2章 ERC20によるサブスクリプションの限界
現在のスマートコントラクトやERC20トークンを用いた単純なサブスクリプションモデルの限界を考えてみましょう。
定期的な通知
サブスクリプションモデルを実装する単純な方法として、課金タイミングが来たらユーザに通知を行い、毎回トランザクションに署名をしてもらう方法です。
この方法では、最初の契約以降の手続きが自動化されるというサブスクリプションモデルのメリットを提供できないため、ユーザ側の利便性を損ねたり、継続的な課金につながらないなどの問題が発生する可能性が高いでしょう。
デポジットからの引き落とし
また、毎回トランザクションの署名をさせない実装方法として、一定額のトークンをエスクローコントラクトにデポジットしておき、毎月サービス提供者側に送金される、というアイデアが考えられます。
この場合の問題点は、継続期間が未定であっても、デポジット額をいくらに設定すべきかをユーザ側が判断しなければならない手間が必要な点です。
デポジットされたトークンは、まだサービス提供者側には支払われていないものの、ユーザ側で利用できないようロックされてしまうため、あまり多額のデポジットをするのは現実的ではありません。一方、デポジット額を少なくしてしまうと、不足する前にチャージする手間が増えてしまいます。
さらに、サブスクリプションの契約を終えたタイミングで、残りのデポジット額が返金されるという保証が必要であり、サービス提供側の実装コストもかかります。
第3章 サブスクリプションプロトコルの提案
ERC-948は、ユーザがデポジットをせずに直接ウォレットから継続的に決済を行い、いつでもその契約の停止やキャンセルが可能なプロトコルを標準化することで、スマートコントラクトによるサブスクリプションモデルの実現化を容易にしようとする提案です。
まだ多くの仕様や実装方式が検討中の段階ですが、現在提案されている規格の例を下記に紹介します。
メソッド案
createSubscription | ユーザが自身のウォレットに対してサブスクリプションを作成する。支払いのトークン種類や1回に支払う数量、支払いの間隔などを定義する。 |
updateSubscription | ユーザが、作成したサブスクリプションの内容を更新する。 |
updateSubscriptionAddress | サービス提供者が、サブスクリプションの支払い先アドレスを更新する。 |
processSubscription | サブスクリプションの実行を開始する。 |
pauseSubscription | 実行中のサブスクリプションを一時停止する。 |
cancelSubscription | 実行中のサブスクリプションをキャンセルする。 |
description | サブスクリプションの概要を返却する。 |
amountUnclaimed | サービス利用料に応じて課金額が決まる場合に、支払いは承認されたがまだ支払いはされていない残額を返却する。 |
nextPeriod | 次の支払いのタイムスタンプを返却する。 |
イベント案
NewSubscription | createSubscriptionメソッドが成功したときに発生する。 |
UpdateSubscription | updateSubscriptionメソッドが成功したときに発生する。 |
UpdateSubscriptionAddress | updateSubscriptionAddressメソッドが成功したときに発生する。 |
PauseSubscription | pauseSubscriptionメソッドが成功したときに発生する。 |
CancelSubscription | cancelSubscriptionメソッドが成功したときに発生する。 |
Payment | processPaymentメソッドが成功したときに発生する。 |
上記のメソッドやイベント案をもとに、Solidityによる実装案も開発が進められており、実装をもとに標準規格のブラッシュアップが議論されています。
第4章 応用可能性と課題点
最後に、ERC-948によるサブスクリプションモデルの標準化による応用可能性と課題点について考察してみましょう。
応用可能性
ERC-948の応用可能性として、一度作成したサブスクリプションコントラクトを、複数のサービスでシェアリングできる可能性があります。
現在のサブスクリプション契約の多くは、各サービスで個別に契約を行う必要がありました。
サブスクリプションコントラクトのシェアリングにより、一つのコントラクトを作成しておくだけで、複数のサービスを横断的に利用することができ、ユーザにとっての利便性が向上するとともに、コントラクトを作成するガスコストの削減にも繋がります。
サービス提供側にとっても、自身のサービスで独自のサブスクリプション契約のシステムを実装することは高いコストになるため、ERC-948による標準化や、シェアリングコントラクトによる手続きの簡略化は大きなメリットとなるでしょう。
課題点
一方で、トークンを用いたサブスクリプションでは、トークンのボラティリティがネックとなる可能性があります。トークンベースで毎月の定額支払いを契約していたとしても、それが円やドルなどの法定通貨ベースで何十倍や十分の一の価値に変動する可能性はあります。
直近の対応策として、課金額は法定通貨ベースで契約を行い、毎回の支払いのタイミングでのレートに従ってトークン量を決定するか、Stablecoinの利用などが必要となるでしょう。
また、パブリックなチェーンで定期支払を実現するためには、ガスコストの考慮も必要です。一般的にガスコストは支払いのトランザクションを発行するユーザが負担しますが、サブスクリプションモデルの場合はユーザ側の利便性を損ねないために、サービス提供側がトランザクションを発行することになるでしょう。
しかし、トランザクションの発行に必要なガスコストを合算してユーザに請求すれば、ユーザにとっては当初契約した以上の金額を支払うことになります。また、ガスコストはネットワークの混み具合などによっても変動するため、思わぬ高額の請求となる可能性もあります。
現状では、あらかじめガスコストを考慮した課金額の設定や、ガスコストの変動に対応するための契約を結んでおく必要があるでしょう。
まとめ
上記のような課題はあるものの、ERC-948によるサブスクリプションモデルの標準化は多くの人の賛同により検討が進められており、比較的早い段階で実現できる可能性があります。
サブスクリプションモデルによるDAppsのマネタイズが容易になれば、これまで参入してこなかった多くの企業がDAppsとしてサービスを提供できる可能性も高まるでしょう。
ERC-948の提案はまだ草案状態であり、実装も多くの部分が未着手ですので、ディスカッションへの参加や実装などに取り組みたい人には良いタイミングかもしれません。
参考文献:
- Recurring Subscription Models are a Good Thing and should be viable on Ethereum (Merit + Architecture ERC)
https://github.com/ethereum/EIPs/issues/948 - Subscription Services on the Blockchain: ERC-948
https://media.consensys.net/subscription-services-on-the-blockchain-erc-948-6ef64b083a36 - ERC: Recurring payments
https://github.com/sb777/erc-948-draft/issues/1