今週、個人的に日本でビットコインよりweb3のほうが人気がある理由を考えていて(カンファレンスでこのトピックに触れるセッションを受け持っているため)1つの仮説を思いつきました。それは日本のカストディ規制の厳しさ、つまりカストディに交換業のライセンスが必要なことが原因なのではないか、というものです。

2018年ごろまでは日本でもツイッター上に投げ銭機能をもったTipbotと呼ばれるボットが多数存在し、仮想通貨をある程度気軽に使える土壌があった気がします。しかし、2019年~2020年にかけてのカストディ規制の施行(他人のために暗号資産を管理する場合は交換業ライセンスが必要)により、国内産のものは駆逐されてしまいました。

そこでカストディ規制を受けて、Web3という名目上分散化されているプラットフォーム上のスマートコントラクトという、「カストディに限りなく近くても該当しないと主張できる」便利なものに目が向いたのではないでしょうか。例えばAdmin Keyのあるスマートコントラクトはカストディであると主張することもできそうですが、現状そういう扱いにはなっていない雰囲気があります。つまり、これまで法的にカストディに該当してしまう形でしか実現できなかったプロダクトを、法的にノンカストディアルな扱いを受けられる形で開発できる点が注目されているという説です。

強いて言えば、海外の草コインTipbotも当時と比べて大幅に減っていることはこの説の反証になっているかもしれません。

そうなると、ビジネスロジックをブロックチェーン上に書き込んでしまうわけにもいかないビットコインがWeb3に流れた開発者にとって再び魅力的になるにはカストディ同様の残高の扱い方の柔軟性を実現しつつ「カストディに該当しない」スキームが必要なのではないでしょうか。

今日はMulti-institution Custodyというスキームによって日本法におけるカストディに該当しないウォレットのスキームについて調べてみました。特に後半は考えがまとまりきっていないかもしれませんが、ご容赦ください。

・Unchained Capitalが2018年から提供しているMulti-institution Custodyとは

・日本でもαU WalletがMulti-institution Custodyモデルでユーザーのシードフレーズのバックアップを保管している

・シードフレーズの管理がセルフカストディの一番のハードルになのか?

・Multi-institution Custodyで事実上のカストディアルウォレットは作れない

Unchained Capitalが2018年から提供しているMulti-institution Custodyとは

アメリカにあるUnchained Capitalはマルチシグを専門とする会社で、ユーザーの資産のマルチシグによる管理やビットコイン担保ローンを提供しています。その彼らが2018年から行っている「Multi-institution Custody」と呼ばれるモデルはその名の通り、複数の法人(Institution)が絡むものです。

従来、一般ユーザー向けのマルチシグ署名サービスの提供は例えば2-of-3や3-of-5のうち鍵を1つだけ法人が預かり、ユーザー単独で資産を動かせるものでした。メリットとして、ユーザーは通常時はパーミッションレスに自身の資産にアクセスでき、仮に鍵を紛失した場合などにもスペアの鍵を預けた法人による署名を請求すれば資金を動かすことができます。法人が「飛んで」も、自身の鍵だけで動かせるため資金を失うことにはなりませんし、法人が勝手に送金することもできません。

Multi-institution Custodyでは、関わる法人は2社以上となります。2-of-3においても、鍵を2社+ユーザー、あるいは3社に委託することで、ユーザーが管理しなければならない鍵の数が減少します。その一方、ユーザーは資金を動かすためには必ず1社以上の協力が必要となり、法人間で共謀して自身の資金を盗まれないことを信用する必要があります。

日本のカストディの定義は「事業者が暗号資産の移転に必要な秘密鍵を保有、管理しており、利用者の協力がなくとも自ら暗号資産を移転できる状態にある」とのことですが、これはひっくり返せば事業者が自ら利用者の暗号資産を動かすことができなければカストディには該当しないのです。

したがってMulti-institution Custodyの場合も、事業者が他の法人にトランザクションに署名させることができないのであればカストディには該当しません。そして、そこを担保する方法も技術的措置に限られず、契約上の法的な拘束によるものも判断材料になるようです。

日本でもαU WalletがMulti-institution Custodyモデルでユーザーのシードフレーズのバックアップを保管している

なぜそれがわかるかというと、日本でもMulti-institution Custodyのモデルを採用しているウォレットがあるためです。それはKDDI社のαU(アルファユー)Walletです。

αU WalletはPolygonチェーンにのみ対応したウォレットで、主にNFT等を扱うことを目的として開発されている印象があります。彼らがどのようにMulti-institution Custodyのモデルを利用しているかというと「ユーザーにシードフレーズのバックアップを意識させない」ために採用しています。どういうことでしょうか。

2社に鍵を預けるので、2つの利用規約に同意が必要。この2社間では勝手に預けた秘密鍵のシェアをやり取りはできないことになっていますが、グループ会社ネーミングに複雑な気持ちです

まずウォレットをセットアップするとき、秘密鍵の生成後に「バックアップ機能」を使うかを選択できます。選択しなければ、通常通りシードフレーズが表示され、書き留めるように促されます。しかし、バックアップ機能を使用する場合はKDDI社・KDDIデジタルデザイン社の2つの利用規約に同意し、シードフレーズを秘密分散してこの2社にバックアップします。その後シードフレーズを確認しようにもアプリ内ではどこにも表示してくれません。

バックアップにアクセスする際にはOAuthによるログイン以外にも登録情報による本人確認があるようですが、ある程度セキュアな認証に使えそうなのは電話番号と住所くらいでしょうか

αU Walletがこのような設計になっている背景にはいくつかの判断がありそうです。まず、日本のマス層は英語が苦手であり、シードフレーズを表示されると混乱してしまうという問題。次にシードフレーズを安全に保管できない可能性があるという問題。最後に、KDDI社への社会的な信頼度の高さです。これらを総合すると、ユーザーにはシードフレーズに触れさせずに、万一の際のバックアップだけKDDI社と関連会社に預けるという形が確かに一つの正解になりそうです。

バックアップ機能利用時にシードフレーズをどうしても表示できないのも、おそらくはユーザーが誤って流出させてしまったりすることに対する対策かと思われます。(個人的には秘密鍵はウォレット内にあるはずなので、それをせめて注意表示の上で自分で書き留めることができないのは納得できない部分がありますが)

つまり、αU Walletの設計思想には「シードフレーズの管理がセルフカストディの障害になっている」というものがありそうなのですが、果たしてこれはどれくらいのハードル担っているのでしょうか?

シードフレーズの管理がセルフカストディの一番のハードルになのか?

残念ながらどれくらいの人がシードフレーズ絡みの問題で資金を失っているかのデータは見つけることができていません。しかし、シードフレーズを紛失した状態でデバイス上の秘密鍵にアクセスできなくなることによるセルフGOX以外にも、シードフレーズが手元にあることによってフィッシングサイトに入力してしまうようなミスも数多く発生していることはTwitterなどを見ていても想像できます。

ビットコインウォレットのデザインについてベストプラクティスを集めているBitcoin Designというサイトを見てみましょう。ウォレットのバックアップの重要性は説いていますが、金額が大きくなければシードフレーズを紙に書き留めるのではなく、クラウドへバックアップすることも検討対象になっています。

Screen prompting the user to back up after they have received a payment, with a manual backup toggle at the bottom

実際にシードフレーズにはじめて直面するユーザーの混乱について、何年も前から業界内で疑問視する意見がありました。例えばCasaのJameson Lopp氏は様々なシードレスなバックアップ方法を検討した記事を4年前に残しています。

Casaではユーザーがシードフレーズをバックアップしないで済むようにサービスが設計されています。(マルチシグのうち一部の鍵のシードフレーズが暗号化されてクラウドに保存されていたり、Casaに預けられたりしています)

他にもWeb3業界では2021-22年頃からMPCを使ったソーシャルリカバリー機能付きのウォレットなどが試されているなど、ウォレット業界ではユーザーがシードフレーズを取り扱うのは難しいと認識されていることがわかります。

そしてMulti-institution Custodyを上手に使えばユーザーにとってシードレスなウォレット体験を提供できることもわかりました。

Multi-institution Custodyで事実上のカストディアルウォレットは作れない

では、Multi-institution Custodyを使って「カストディ型のウォレットと大差のないユーザー体験」は実現できるのでしょうか?​まずはカストディアルウォレットの何を再現しようとしているか洗い出す必要があります。

冒頭で述べた中でカストディ型のサービスの強みはその「簡単さ」です。ユーザーの代理で送金したり、受け取ったりといった処理ができることで非常に簡単にサービスを立ち上げることができます。また、サービス内部での送金をデータベースの書き換えで済ませることができるため経済的です。

しかし、ユーザーの代理で送金する場合にはユーザーの指示でしか送金できないような仕組みが必要です。例えば一般的なTipbotはツイートで送金の指示を受け付けますが、これは例えば@botAのアカウントに送金指示を飛ばし、PSBTが返ってきたら@botBのアカウントにも送金指示を飛ばす、というような運用なら実現できそうです。ただし、それではただの公開マルチシグウォレットでUXも非常に悪く、データベースの書き換えではないため送金手数料なども毎回かかってしまいます。

また、未登録ユーザーの代理で受け取ってOAuthログインで出金できる機能は(未登録ユーザーの鍵が存在しないので)カストディに該当しない形で行えません。したがってMulti-institution Custodyを使っていようがいまいがTipbotのアカウントをセットアップしていない人にビットコインを送りつけることができません。

投げ銭を受け取ったことがきっかけで仮想通貨に興味を持った人も少なくなかったと思うので、不特定多数にビットコインを送りつけることが難しいのは残念です。

ライトニングに関してはノードの管理なども絡むため、更に難しそうな印象があります。

レイヤー2系の技術で1つ親和性の高いものがあるとしたらArkやTaproot Assetsのように、トランザクションのツリーやスクリプトのツリーに「ユーザーの秘密鍵を使ってしか動かせない形で」残高を管理する技術でしょうか。これらは運用上は事実上のデータベースとそれほど変わらず、内部的な送金についてコスト削減にはつながるかもしれません。しかし、カストディ型のサービスやスマートコントラクトの特徴である「ユーザーの代理で送金や受取といった何らかの処理を走らせる」という機能がやはりスムーズに再現できない以上、代わりにはなれない気がします。

いっそ規制対応に必要な最低限のスマートコントラクトチェーンを併用するアプローチを取るのも手段なのかもしれません。以前紹介したFuji MoneyやLava Loansのように。。。

スマートコントラクトでビットコインを担保に借金する2つのアプローチ:Lava Loans ProtocolとFuji Money
本稿で何度か取り上げている通り、今年はビットコイン上でDLCやコベナンツなど、スクリプト機能を活用したプロトコルへの関心が高まっています。今月ローンチしたFuji MoneyとLava Loans ProtocolはそれぞれLiquid NetworkのスマートコントラクトとビットコインのDLCを用いてビットコインを担保にステーブルコインなどを借りられるようにするプロダクトです。 各プロジェクトのホワイトペーパーはここにリンクするので、興味のある方はぜひ原文を当たってください。 https://vulpem.com/synthetic-asset-smart-contract.pdf loans-spec/loans_spec.pdf at main · lava-xyz/loans-specContribute to lava-xyz/loans-spec development by creating an account on GitHub.GitHublava-xyz 今日はこれらのプロトコルの概要を見ていきます。 Fuji MoneyはLiquidのトークン発行機
(それでもカストディに該当しないと主張できる方法でTipbotが実現できるかは知りませんが)