セキュリティトークンの標準化について

13 min readDec 5, 2018

はじめに

こんにちは。Tomo( HAIL ) です。
この記事は、Qiita Ethereum Advent Calendar 2018 5日目の記事です。
今回は、セキュリティトークン、と呼ばれるものについて書きます。

セキュリティトークンとは

ここで言うセキュリティは、普段皆さんが使っているそれとはちょっと違う言葉で、「証券」を指します。違うとはいえ、何故証券がセキュリティと呼ばれるかという語源としては、普段使っている意味である「保護」から来ているようです。証券は何を保護するのか？というと、証券を発行して出資を募る資金調達者と、その証券を購入して将来的な投資リターンを狙う投資家を保護します。

証券トークン(以後セキュリティトークン)による資金調達は、Security Token Offering、略してSTOと呼ばれます。2017年から2018年の初頭にInitial Coin Offering(ICO)が流行しましたね。STOもEthereumに代表されるブロックチェーン上で発行されるトークンによるICOの一種ですが、違いは、発行されるのは投資家や発行体を保護するための体制・法規制が整備されているトークンである、ということです。ICOには詐欺も多かったため、仮想通貨怖い怖いみたいな風潮になってしまいましたが、ブロックチェーンや、その上で実行されるスマートコントラクトが悪いわけではありません。どちらかというと技術が先んじてしまい、世の中の仕組みがついてきていなかったのが反省点です。
STO自体の詳細は、またの機会に解説するとして、この記事ではそろそろ具体的な技術的な内容について入っていきましょう。

セキュリティトークンの実装

STOにおいても、最も良く使われているブロックチェーンはEthereumです。必ずしもEthereumである必要はありませんが、リッチなスマートコントラクトプラットフォームであることが望ましいかと思います。何故かと言うと、セキュリティトークンで最も大事なことは、法規制(各国の証券法など)に則ることです。それはERC20の実装レベルで言うとtransfer関数の成功可否を法規制に従って判断することで、それがオンチェーンで透明に行われている方が効率的だからです。
正直、トークンのインタフェースはERC777で殆ど事足りますが、その関数の中身が、法規制やその他の投資契約まわりを実装することになるのでかなり複雑になりうる、というところが大変です。なので、EIPのようにトークン本体のインタフェースを設計するだけではなく、周辺のコントラクトも含めたアーキテクチャ、フレームワーク、デザインパターンといったものを設計することが重要になってきます。
ちなみに、トークンのインターフェースにおいて、ERC20でなくてERC777をベースとして採用する理由は、証券の世界では、投資家本人以外が transfer(or send) を実行することが多く考えられるためです。それは、発行体による強制transfer(force transfer)であったり、証券を投資家に代わって管理するカストディアン(custodian)であったりします。それらのエンティティを Operatorとして定義しているERC777は、セキュリティトークンスタンダードのベースとしてとても使いやすいと言えます。

セキュリティトークンが目指すものと標準化の重要性

セキュリティトークンで大事なのは、transfer 関数の成功可否判定において、法律などを加味すること、というところまで書きました。さて、既存の証券システムよりもブロックチェーン上のセキュリティトークンが優秀であるためには、その仕組が効率化されていることが重要です。ここで、実際に transfer 実行時にトークン送付先の投資家に対してチェックされる項目にはどのようなものがあるのかというと、

Know Your Customer(KYC)が済んでいるか。居住国はどこか(例: US在住であるか)
Anti-Money Laundering(AML)チェックが済んでいるか
適格投資家( Accredited Investor(US), Qualified Investor(Singapore) )であるか。非上場会社への投資などはハイリスクであり、それへの投資には高度な知識と一定の資金力が必要と考えられており、そのチェックの仕組みが各国にある
投資契約書へのサインが済んでいるか

などがあります。ここで注目したいのは、各項目をチェックするエンティティ(プレイヤー)は違いうる、というところです。一部の項目はBroker-Dealerと呼ばれる代理人が実行するかもしれませんし、各項目用のサービスを提供する事業者に任せるかもしれません。KYCならOnfidoかもしれないし、投資契約ならDocusignかもしれません。各プレイヤーが、それぞれの秘密鍵を使って、チェックした項目の情報をスマートコントラクトに書き込んでおける、その仕組が大事なのではないかと僕は思っています。実際にDocusignなどは、Ethereumを筆頭に、ブロックチェーンへのデータ書き込みを積極的にサポートしようとしています。そこでこの前、Cryalize Frameworkという、フレームワークというか、デザインパターンというか、を設計してこの前NYで行われたカンファレンスでも発表してきました。このパターンでは、4種類コントラクトが登場します。

Token。シンプルなERC777に少し毛が生えたもの(Polymathが率いているERC1400/1411と同様、 canSend(from, to, amount) を追加しているぐらい)
Token Implementation。こちらは単純に、実装を容易にアップデートできるように、Tokenのコントラクトでは単純に impl.transfer(...)するよう実装を委譲する先のコントラクト
Regulator Service。各証券のタイプによって求められる法規制等を実装するロジックコントラクト。Token Implementationは複数のRegulator Serviceを参照して transfer の成功可否を判断する
Registry。投資家の情報が書かれるデータ層のコントラクト。以下のように、投資家や各サービス事業者のETHアドレスと、各項目についての情報や証拠情報のURI、ハッシュ(例: 0x12… さんの “residency”(居住国)は “Japan”で、証拠としてパスポート情報が https://~~~ に上がっていてそのファイルのMD5ハッシュは 7dbd0c39… です)の mapping を持ち、各項目(例: “residency”, “aml_checked”, “is_accredited_investor”, “is_investment_contract_signed”)ごとにread, writeの権限管理も行われている。Regulator ServiceはRegistryへの参照を持ち、Registryに書かれている様々な投資家情報を参照して transfer の可否を算出する

Registryの一部をgithubより抜粋。

struct attributeValue {
        bytes32 value;
        string uri; // optional in some cases
        bytes32 documentHash; // optional in some cases
}/*
 * @dev: Example:
 * @dev: 0x12.. => ["residency" => attributeValue("Japan", "https://...." (where KYC document is stored), "7dbd0c39...")]
 */
mapping(address => mapping(bytes32 => attributeValue)) attributes;mapping(bytes32 => bool) availableAttributes;
mapping(address => mapping(bytes32 => bool)) authorizedAttributes;// getAttributeも当然書かれていて、Regulator Serviceはそれを使って判定を行うfunction setAttribute(address _address, bytes32 _attribute, bytes32 _value, string _uri, bytes32 _documentHash) public isAuthorized(_attribute) returns (bool) {
   attributes[_address][_attribute] = attributeValue(_value, _uri, _documentHash);
   return true;
}

(上記、まだコンセプト段階で未実装なので細かい間違いご容赦を……mm)

できれば、上にもある githubのリンクからたどってRegulator Serviceのサンプルコードをご覧になっていただけると次の説明が読みやすくなるかと思うのですが、このデザインパターンで目指していることは

Registry層に、各プレイヤー(発行体、Broker-Dealer、サービスベンダーなど)が投資家情報などを書き込んでいき、投資可能な状態を作り出す過程を効率化すること
Regulator Serviceも共有されていくこと。例えばアメリカの証券法に詳しい人と、日本の証券法に詳しい人がいるのは当たり前のことです。なので、会社をまたいでアライアンスを組むことにより、例えば不動産系のトークンを扱う際にUSRealEstateRegulatorService と JapanForeignRealEstateRegulatorService をお互い提供しあうことにより両方の投資家から投資を受けられるようにしよう！みたいな動きが起きていくと良い

と、データ層、ロジック層においてプレイヤー間のコラボレーションが起こることにより証券の決済まわりが大幅に効率化されることです。最近発表してきた資料から、この流れをまとめたものを載せておきます。

Case Study: ある発行体が、USの機関投資家向けにRegulation Dに区分されるSTOを行うことになった。KYCベンダー、適格投資家(Accreditation)判定ベンダーは既に決定している。

KYCベンダーにはResidence情報への、Accreditedベンダーにはそれへの権限を付与している

次に、日本の投資家からも投資を集められるようにしたいと考えたが、この会社は日本の法律に明るくない。そこで日本に強い他のファームと組むことにした。このファームは日本用のRegulator Serviceを既に開発してあり、自分たちのRegistryを使うことにも合意したので、そのRegulator ServiceをToken Implementationに追加するコードレビューを合同で行って、また日本用のKYCベンダーなどに必要な権限を付与した。

USだけでなく日本の投資家からも集めたい！ってなったらRegulator Serviceを追加

無事にトークンセールが終了した後、喜ばしいことにこのトークンはいけてるぞ！ということである取引所がこのトークンを上場することにした。それにあたり、USの投資家には別のKYCベンダーを追加したいという要望と、もう一カ国X用のRegulator Serviceを利用することになった。

取引所(右)がこのトークンを上場したいそうなので、その取引所が使っているKYCベンダーも追加

このように、実際のユースケースを想定して権限管理を含めたワークフローに適したデザインパターンを設計することが大切です。設計には金融周りの知識と、ブロックチェーンや一般のWeb技術の理解の両方が必要になってくるため、難易度はかなり高いですが、脳を回し続けていないと死ぬ人たちにとっては最高の仕事です。

近しい発想のものとしては、HarborのR-Tokenや、近々Blockchain Labsなどから発表されるであろうものがあります。今はまだ黎明期に近いので、様々な仕様が乱立してしまうのは仕方がありません。セキュリティトークンを扱う取引所からも、現時点では主要なスタンダードにはすべて対応していくしかないだろう、と聞いたりします。とはいえ、データやロジックを共有して効率化していこう、というモチベーションがあれば、スタンダードも統一されていくことが望まれます。言わずもがなですがERC20の優秀なところは、殆どすべての開発者が「トークンを送る機能は transfer 」と合意できたところです。2019年はセキュリティトークン周りにおいて、その統一が進む年になるんじゃないかなと思っています！

おわりに

この記事では、セキュリティトークンとは何か、というところからはじめて、その実装のキモと標準化について紹介してきました。ICOはEthereumが広まっていくキラーアプリの一つでしたが、その一種であるSTOではきちんと法規制に則り、収益性についても見通しが立てやすいトークン設計が求められます。技術が先行して詐欺が横行したICOが安全に使われていくためのもので、ブロックチェーン/スマートコントラクトという新しい世界と、既存の金融の世界が融合していきます。中央集権性が少なからず残ってしまうのは事実ですが、数年の時をかけて少しずつそこも改良されていくでしょう。また、当然システムを作っていくにあたりいちばん大事なのはユーザ(ここでは発行体と投資家)に使われることです。段々と、人は秘密鍵を扱えるようになりますし、チェーンのスケーラビリティアップと法規制の改良によりユーティリティ性を持ったセキュリティトークンも登場してくるでしょう。その大切な世の中の流れに貢献していければな、と思っています。それではまた！