サブスクリプションモデルに適した新しいERCの提案

※この投稿はConsenSys社の同意のもと「Subscription Services on the Blockchain: ERC-948」を翻訳した記事です。

NetflixやSpotifyや漫画アプリなど、サブスクリプション型のサービスは当たり前になりつつあるビジネスです。そのビジネスモデルをイーサリアムで生かすための課題や解決策は一体なんでしょうか。

サブスクリプション経済

2008年の経済危機(リーマンショック)以降、サブスクリプションモデルの企業が続々と現れました。消費者が長い期間を掛けて少額の決済を続けることを好むと考えて、イノベーター達は、定期購入の詰め合わせボックスや、日用品、ストリーミングサービス、ソフトウェアにサブスクリプションモデルを適用し、利益を生み出しました。2017年、B2Cサブスクリプションは1100万人以上の人々を惹きつけており、2017年末の時点で、2000以上のB2Cサブスクリプションを提供する企業が存在しています。2014年から見ると、これらの企業のウェブサイトへの訪問は800%以上増加し、3700万のビジターがいます。マッキンゼーが2018年2月に行なった研究によると、オンラインで買い物をする人の15%はこの1年の間にサブスクリプションを利用したことがあります。特に、Netflixなどのメディアストリーミングサービスはオンラインで買い物をする人の46%をサブスクリプションユーザーにしています。

サブスクリプションモデル経済は衰える気配を見せません。むしろ、サービスや製品を裕福な顧客に提供する、現代的な方法として成功しています。マッキンゼーによると、平均的なサブスクリプション利用者は55,000ドルから100,000ドルの収入を得ている人たちです。ビジネスがブロックチェーンへと近づくほど、ブロックチェーン開発者やエバンジェリストはこの技術がサブスクリプションモデルをサポートできると確信できることでしょう。ERC-948はサブスクリプションベースのトランザクションを容易するために特化して作られた新しいイーサリアムのトークンプロトコルです。

Githubのスレッドで最初に提案された内容を元に、本記事ではこのERC948のメリットと実現性を検証します。

サブスクリプションプロトコルのメリット

サブスクリプション経済を容易にするトークンスタンダードの経済的利点は、過去10年の金融統計によって確立されています。しかし、ここで1つ疑問が湧き上がります。なぜ完全に新しいプロトコルが議論され開発されなければならないのか?なぜイーサやERC-20のような既存のプロトコルは使えないのか?

イーサを使ったサブスクリプションモデル

現在、イーサがサブスクリプションモデル経済のために通貨として効率よく機能する有効な手段はありません。イーサを使ったサブスクリプションモデルを運用するとなると、秘密鍵を使ってすべてのトランザクションに署名しなければなりません。規模が大きくなると、消費者はサービスや製品の毎月のトランザクションにサインすることは不可能になったり、嫌がったりします。消費者に最も寄り添った選択肢はイーサがエスクロー(第三者預託)で預かり、前払式のサブスクリプションを管理することです。そうすれば、エスクローにイーサを入金することでサブスクリプションを延長できたり、エスクローから残高を戻すことでキャンセルできたりするようになります。サービス提供者は、サブスクリプション価格×最後の引き落としからの時間に合うようにエスクローから引き落としすることができます。

このモデルの問題は利用者が最初からエスクローに多額の資金を置いておくか、または、サブスクリプションを続けるために毎月忘れずに必要な額を入金しておく必要があるということです。すなわち、選択肢は、前払式の資本コミットメントか、うんざりするような定期的な管理のどちらかです。どちらにしても顧客体験の観点から規模を拡大できそうにありません。

イーサがERC-20トークンになることを提案する議論も現れています。しかしながら、ERC-20プロトコルも、サブスクリプションモデルを簡単に容易にするようには設計されていません。

ERC-20プロトコルを使ったサブスクリプションモデル

現在のイーサリアムブロックチェーン上のERC-20プロトコルでの、本当に時間ベースのサブスクリプションを開発できる最も近いコントラクトは、サービスを再確認するために毎月メールや通知を送る必要があります。この”オプトイン”プロセスは以下のようなものです。

  • メール送信
  • メール受信
  • メールを開封
  • TXに署名
  • TXを送信

この方法は中央集権的なマーケティングやサブスクリプションモデルの心理的信条を否定しています。この”オプトイン”方式は顧客との摩擦を生みます。サービスを続けるには毎月承認しなければならないからです。サブスクリプションを提供する企業は、どんなに成功していたとしても、継続的に解約率の高さに悩まされるでしょう。2017年、サブスクリプション利用者の40%が、1つ以上のサブスクリプションを解約しています。企業がユーザーに対して多くの摩擦を生むほど、ユーザーは離れていきやすくなります。ユーザーが支払いについて意識したり、サブスクリプションの再確認を求められたりするほど、払わなくなってしまいます。イーサリアムベースで顧客がたくさんのサブスクリプションを持つような将来に、この”オプトイン”方式では大きな規模に特に対応できないでしょう。

“オプトイン”方式よりも適しているのは”オプトアウト”方式です。つまり、顧客は「続ける」ということではなく「続けない」ということを決意しなければならないのです。ですが、この方法は現在のところERC-20スタンダードで一般的ではありません。”オプトアウト”方式を実現するには、コントラクトの中で企業がユーザーに対してapprove(x)関数を提示する必要があります。この時x=価格×n(価格=月額と数量、n=月数)になります。そして、企業は毎月、transfer(x/n)を呼び出します。

このモデルの問題点は二重になってしまうことです。まず、ユーザーはサブスクリプションをキャンセルするタイミングに強い保証を求めます。ユーザーはサブスクリプションをキャンセルする検証可能で即効性のあるcancel(x)関数を使って、好きな時に解約できることを望みます。インプリメンテーションによって、提供者はサブスクリプション料金が任意の期間に合わせて満たされ、トランザクションコストのオーバーヘッドを削減できるようにするために解約の過程の一部として、未払いのサブスクリプション料金が提供者に確実に支払われるようにしなければなりません。

次に、ERC-20の”オプトアウト”スタンダードでは、ユーザーは最初から、サブスクリプションをどれくらいの間続けるか、ということを決め、”n”に達した時ごとに契約を更新しなければなりません。企業が顧客にサブスクリプションの詳細について決定を強いるほど、彼らはその全過程に従いたくなくなります。ワークアラウンドとして可能性があるのは、サブスクリプションの期間を非常に長く(例えばn=1000)設定することです。しかしながら、ユーザーはサブスクリプションに1000カ月も払いたくありません。なので企業は毎月、サービスや商品のその月にかかった料金のみを請求することをユーザーに保証しなければなりません。

EF developer Piper Merriamによって提案された、最小限のERC-20プロトコルへのオプトアウト・インプリメンテーションには、以下のようなフィールドを必要とします。

  • address token: 支払いが支払われるトークンコントラクトを指定する。
  • address provider: プロバイダのアドレス。
  • uint256 time_unit: 時間単位あたりの秒数。
  • uint256 tokens_per_time_unit: time_unitあたりの支払われるべきサブスクリプションのトークンの数。
  • uint256 last_payment_at: 支払いが行われた時刻のタイムスタンプ。triggerPaymentはこれを呼び出します。token.transfer(provider, (now — last_payment_at) * tokens_per_time_unit / time_unit)`.

ERC-20プロトコルはサブスクリプションモデルの初期の実装は可能ですが、UX上の問題故に、”オプトイン”と”オプトアウト”の選択肢のいずれにしても顧客の高い解約率を招く可能性があります。

ERC-948プロトコルの提案の実現可能性

サブスクリプションが可能なトークンの経済的インセンティブやそのようなトークンを発行できるプロトコルが今のところ不在であることが検証できたので、次にERC-948プロトコルがどのようなものなのかを見ていきましょう。

“オプトアウト”方式は、顧客と提供者のインセンティブを調整するものであるため、経済的な観点からは最も成功するものになるでしょう。オプトアウトプロトコルは以下のようなものです。

  • ユーザーはユーザーのウォレットから”x”トークンを”y”期間ごとに”z”企業が引き出すことを許可します。
  • ユーザーはいつでも同意を取り消すことができます。
  • “z”企業のオーナーはユーザーのウォレットから”x”トークンを”y”期間ごとに取り出すことができます。
  • トランザクションは”x”トークンが利用可能で、ユーザーの同意が有効で、最後の引き出しから”y”期間が過ぎているという条件を満たさなければ、throw()になります。

イーサリアムブロックチェーン上でスマートコントラクトの力を借りれば、サブスクリプションサービスのためのオプトアウトスマートコントラクトをERC-948で作るとこのようになります。

  • サービスは、ユーザーから引き出すことの出来るスマートコントラクトをデプロイします。
  • ユーザーは無制限の引き出しと無制限の時間を承認します。
  • ユーザーはcreateSubscription()関数を呼び出し、ユーザーが解約するまで”x”トークンをそのウォレットから”y”期間ごとに”z”サービスが引き出すことを許可します。
  • “y”期間ごとに、サービスはwithdrawSubscription()関数を呼び出します。資金が利用可能で、ユーザーの同意が有効であれば、その関数はtransferFrom()を使用してその支払期間に認められた分の”x”トークンを集金します。

ERC-948プロトコルの実現可能性は以下の条件に依存しています。

プロトコルは共有されている契約やサブスクリプションごとの契約をサポートして作られるべきです。共有されている契約ならば、ユーザーはサブスクリプションをいちいち監査する必要はなくなります。新しいサブスクリプションに契約する時も、契約をデプロイしなくても、1つのcreateSubscription()関数を設定するだけでよいのです。顧客体験の観点から、このモデルは見込みがあり、好ましいでしょう。35%の顧客が3つ以上のサブスクリプションを契約するような経済では、一つ一つのサブスクリプションを別々に管理するよりも、1箇所で管理できたほうがユーザーフレンドリーです。共有されている契約を作るほうがGASの節約になるということも考慮されています。しかしながら、集中させることによって、脆弱性の穴を作り出してしまうことも考えられます。サブスクリプションごとの契約のモデルの場合は、ユーザーは新しいサブスクリプションに参加するたびに新しいcreateSubscription()関数をデプロイする必要があります。契約を広げることで、攻撃の対象となるエリアを減らすことが出来ますが、すべてのサブスクリプションを別々に管理する手間をユーザーに強いてしまうので、ユーザー体験を落としてしまうでしょう。

トークン価格のボラティリティによって、企業が顧客に対して長い間に渡って”x”トークンを”y”期間ごとに引き出す許可を尋ねる際の難易度が上がってしまいます。例えば、あるトークンの月々の変化が積み重なれば、6ヶ月後には大きく異なる量の米ドルになっているかも知れません。これは単に引き落としがどの日に行われるかという、ユーザーが不運か幸運かという意味になります。イノベーションはトークンの価値が安定化するのを待ってはくれません。短期的な対処法としては、サブスクリプション価格を法定通貨で設定し、支払い時にトランザクションのレートに合わせて顧客に請求する方法です。他の方法としては、ERC-948で、最近リリースされた”Dai”のようなステーブルコインをサポートすることです。

サービス提供者にとっては、個人のサブスクリプション利用者のウォレットに対して新しい契約を発行することは時間もGASもかかり、うんざりするような作業であるので、サブスクリプション利用者の高い解約率を考慮すると、経済的に継続できない可能性があります。”共有されている契約”の考え方を真似た解決策では、企業はすべてのユーザーからトークンを引き落とせる1つのスマートコントラクトをデプロイします。この方法は、企業がメンバーシップやB2CまたはB2Bサブスクリプションモデルの異なる階層を持っている場合、少し複雑化するでしょう。

GAS―イーサリアムブロックチェーン上の契約に含まれるそれぞれのオペレーションを実行するのに必要な費用―は、将来のブロックチェーンベースのサブスクリプション企業が直面するであろう、もう一つのハードルです。現在のサブスクリプションモデルは価格の透明性に成功しています。顧客は期間あたりの支払額が伝えられ、往々にして追加や隠れた費用が請求されないことを約束されています。多くの人にとって、月々のサブスクリプションの費用に加えて、支払い期日が来るたびにサブスクリプションの関数の実行のGASの支払いが必要になるならば(特にそのGAS手数料が変わる可能性があるならば)、GASが隠れた費用のように感じてしまうかも知れません。サブスクリプション企業はこのGASの料金を顧客体験を向上させる機会として捉えるべきです。おそらく、もし企業がGAS手数料を見積もることができれば、これらの手数料を製品のトータルのコストに含めることができ、それによって売り込まれているサブスクリプション価格は最終的なものである、という顧客の期待に添うことができます。(現在のクレジットカードの支払い手数料は多くの場合、企業側が負担しているのと同じ考え方)

ERC-948プロトコルの提案はデベロッパーがプラットフォームを開発する機会を与えます。そのプラットフォーム上で企業は、この10年間小売やソフトウェア経済で価値があると証明してきた、新しい経済のモデルの力を借りることができます。サブスクリプションの共通基準ができれば、より多くの顧客に対する企業をブロックチェーン技術に惹きつけることが出来るでしょう。そして、多くのブロックチェーンのレトリックを語る者は古いものを攻撃し、新しいものを称賛するでしょうが、私達の現在の経済で成功していることが証明されてきた、インセンティブの構造から目を離してはいけません。サブスクリプション経済はその中のひとつなのです。

オリジナル記事

おすすめの記事