Biz大学生がSTO規格をまとめてみた

12 min readDec 18, 2018

はじめに

皆さま初めまして。クリプトマト(@coin_ettomato)ことTamotoと申します。Qiita Ethereum Advent Calendar 2018 19日目の記事です。この記事では、Biz側大学生が、現在登場している複数のSTO規格のまとめと比較とを行っていきます。『STOについてぼんやりとは知っているが、実際どうワークしているのか？』と気になっている方、必見です。

動機：なぜ今回STO規格を取り上げたのか？

ブロックチェーンは「知の総合格闘技」と呼ばれたりもします（@megan氏が命名）が、その中でもSTOの分野はリーガルや金融といったBiz側の知識が求められる比重が高い分野です。中でも、STO規格はBizの知識とDevの開発力とが結節点であると認識しています。しかも日本語文献がいまだ少ない分野でもあります。なので、Biz側の人間が貢献できる度合いが高いと踏んで、このAdvent CalendarというDevのお祭りの機会に、その結節点をまとめてみよう、と思ったわけです。
この記事では、以下の構成で説明していきます。

STO規格の要件
各STO規格の解説
各STO規格の比較

STO規格に求められる要件とは

STO規格の概要や必要性についてはAdvent Calendar 5日目に、HAILさんが『セキュリティトークンの標準化について』の中でまとめてくださっているのでそちらをご参照ください。（そもそもSTOとは？という方にはCoin Choiceさんの記事シリーズがとても良くまとめられているのでおススメです。）
規格に求められる要件とは一言でいうと『法準拠』です。証券として規制枠組みに入る中でどのように準拠するか、その一方でブロックチェーンの特性をどう生かすか、がカギです。これらを具体化すると要件は以下のようになると考えています。

トークンの制限：発行、譲渡、償還
投資家情報の登録
トークントラッキング
第三者による強制執行：強制移動、再発行
拡張性：多数のプレイヤーが分散的に参加可能かどうか

『トークンの制限、投資家情報の登録、トラッキング』は証券法免除規定準拠との関連で要求される要件です。『第三者による強制執行』は司法強制執行など法的に要請される強制移譲との関連で要求されます。『拡張性』はトークン規格として非集権的か、の点で大切であるとみています。
また、『投資家情報、トラッキング』をon-chainで行えるか、はブロックチェーンを用いてSTOを行う意義、という点で重要だと考えています。
以下で各STO規格をまとめていきますが、これらの点を重視しながら解説していきます。

STO規格の種類

規格は大きく二つの種類に分類できます。『標準型』と『特化型』です。

標準型：グローバルな発行、運用を目指す規格
特化型：一部の法律に準拠することを目指した規格

今回の記事では現在メジャーな5種類の規格 (Security Token Standard, R-Token Standard, Digital Security Protocol, ERC884, ERC1450)を取り上げますが、それらを分類すると以下の図のようになります。

STO規格各論

記事の長さの関係上、各規格とも概説になってしまいます。詳細のまとめや解説は私のscrapboxをご参照ください。

Security Token Standard(ERC1400)

Security Token Standard(ERC1400)は、Polymathを中心に複数の団体が連携し開発が進められています。『トークン制限からトラッキングまで幅広く規格でカバー』しており、且つ『各情報の登録をon-chain, off-chainどちらにするか』、まで対応しており現状では一番完成度が高い規格である、とみています。
しかし、この規格は数種類のERCに機能が分散されてしまっており、非常に理解の難しいものになっています。そこで、以下の図にERC1400の関係性をまとめてみました。

ここですべての説明をすると記事が膨大になってしまうので各ERCの特徴をサクッと説明していきます。

ERC1410：分割トークンの発行機能
セキュリティトークンには、同じトークンでも部分によって制限要求が異なることがあります。これに対処するため、各投資家のトークン保有分をtranche（グループだと思っていただければOKです）に分割して管理します。 function transferなどの各関数にtrancheデータを bytes32 _partitionで追加して、独自の関数を設定しています。
ERC1594：譲渡制限や管理
法規制の一番カギとなる機能なのでCore Security Token Standardと呼ばれています。譲渡制限の可否を bool ではなく byte でreturnすることで拒否事由を述べられるようにしています。
また、off-chainで認証が行われた場合でもon-chainにつなぎこみを実施できるように、変数に byte _data を用意しています。これは、関係者の署名データを入れれば、認証されたとみなして対処するような仕組みにするために設定されています。（保有者アドレスや送付先アドレスがが他規格を利用するなどしてon-chainで認証できる場合は、この変数は必要ありません）
ERC1633：各ドキュメントデータを管理
投資契約書など調達に関連するドキュメントをon-chainにつなぎこみます。耐改竄性を高めるためにハッシュ化を利用することも考慮して各関数の変数に byte32 が設定されていることが特徴的です
ERC1634：第三者の強制執行を管理
関数に function contorollerTransfer と function controllerRedeem とを備え、司法による強制執行や、投資家の秘密鍵紛失に対処した再発行などが実現可能になっています。第三者の資産移転を認める機能なので、これらの起動条件は厳しく定められる必要がありますが規格ではその点は個々にゆだねられています

各ERCの詳細についてはscrapboxをご覧ください。

R-Token Standard

この規格はHarborによって開発されています。この規格は ERC20規格に function check を加えたシンプルな規格となっています。
プレイヤーはRToken, Retulator Service, Service Registryの３つが登場します。

RToken ： function check を regulator Service へ呼んで、譲渡制限の可否を聞く
regulator Service ：登録情報を参照して RToken に譲渡制限の結果を返答する
参照プロセスは以下の図のようにホワイトペーパーで説明されています

Service Registry ：適切な regulator Service のアドレスを RToken へ教える（ regulator Service は各法準拠ごとに1つ存在するため）

三者の関係性は以下の図のように説明されます。

この規格は譲渡制限判断、投資家情報の参照など、法準拠のほとんどの要素を Regulator Service が担う形となっています。現在このサービスはHarbor自身が担っているようですが、今後の規格の拡張性はこのRegulator Serviceの発展次第かな、とみています

更なるR-Tokenの詳細はこちらで説明しています。

Digital Security Protocol

この規格はSecuritizeによって開発されています。この規格の特徴は、 DS Appsをだれでも作成でき、このプロトコルに参加できる、という点にあります。
この規格は大きく4つの要素から構成されています。

Digital Security Token : Compliance Service を function transfer や function transferFrom を用いて参照し、譲渡制限に準拠したトークン
Digital Services ：Securitizeが提供する3つの規格。譲渡制限の役割を担う Compliance Service , 登録情報の管理を担う Registry Service , 投資家との情報管理を行う Comms Service から構成されます
DS Apps ：セキュリティトークンに必要なアプリケーション機能を担う。ここにコントラクトが収納される。各プレイヤーはそれぞれ DS Apps を開発することでDSエコノミーに参加できる。発行プラットフォームのSecuritize は Issuing Apps , Voting Apps , Dividend Apps を備えた1プレイヤーに過ぎない。
DS Protocol ：各 DS Apps と DS Service を媒介するインターフェース。ここに規格が設定されている。

これら要素の関係をホワイトペーパーでは以下のような図で説明されています。

この規格は、 Compliance Service と Registry Service によって、『譲渡制限、投資家情報管理』とをon-chainで可能にすることを実現しています。一方、各 DS Apps が本当にSecuritize以外のプレイヤーも開発して参入できるのか、拡張性の部分に疑問も残ります。

各要素間の関係性などの詳細はこちら。

ERC884

この規格はDelaware州法に準拠することに特化した規格です。Delaware州はDLTを株主名簿として利用することが法的に認めています。なので、株主管理をどうやって行うのか、という点を丁寧に設計しています。具体的には、株主数の管理や、株主情報の変更の記録をカバーしている点が注目されます。（ function holderCount , function holderAt , function isSuperseded 等が特徴的）ただ、一方で譲渡制限などについてはこの規格のスコープ外とされており、連邦証券法に準拠する必要もあることから、他の規格との併用が求められると推測されます。
各関数やインターフェースについてはこちらをご覧ください。

ERC1450

この規格は、米国証券法の例外規定(Reg CF, Reg D, Reg A+)に準拠することに特化した関数です。各例外規定についてはCoin Choiceさんの『第2回：STO(セキュリティ・トークン・オファリング)に適用の免除規定～コンプライアンス要求まで解説』にわかりやすくまとめられているのでご覧ください。
この規格は、 Registered Transfer Agent が各譲渡を管理することで法規制準拠を実現します。AgentとはSEC（証券取引委員会）より認可を与えられた主体です。各譲渡に係る関数に modifier として、 onlyIssuerTransferAgent を設定して譲渡に関与できる主体をAgentのみに制限しています。ERC20のうち、譲渡制限がかかっていない function transfer や function transferFrom 等は使用できないようにインターフェースで定められている点が特徴的です。
各投資家データなどはAgentが持つことになっており、on-chainの有効活用という点では少し疑問も残ります。

詳細はこちらをご覧ください。

各STO規格の比較

この記事の最後に各STO規格を最初に挙げた5つの軸で切って比較してみたいと思います。

拡張性の部分においての〇と△とは私見に基づいたものです。判断軸は、各プレイヤー/要素の参入が1団体によって実質的に制限されていないか、です。

上の図からわかるように、一番拡張性＆ブロックチェーンの意義を追求した規格は現状ではSecurity Token Standardだと考えています。しかし、無駄に感じる部分もあるなど、さらに改良がくわえられることが待たれます。

また、直近のSTOの成功に向けた要因は拡張性＆ブロックチェーンの活用に依るわけではないという点にも注意が必要です。現在は拡張性が低く、集権的な規格であっても、既存社会システムにうまくマッチしたサービスを提供できれば今後それがスタンダードになっていくかもしれません。

世界には、今回取り上げられなかったSTO規格も存在しています。今回の記事で興味を持たれた方、是非調べてみてはいかがでしょうか。僕も今後時間があればまた記事を書いてみたいと思います。
今後もBiz側大学生としてSTOに関わる記事をたまーに書いてみたいと思います！
その際はまたご覧ください！！

長い記事でしたが最後までご覧くださりありがとうございました。
この記事は、個人で調査した結果の記載＆ Dev側知識が少ない中での執筆、という2要因により、誤植、誤解、不足等々あるかと思います。
是非とも、この記事のコメントや、twitter アカウントの方にご意見を頂戴できれば幸いです。宜しくお願い申し上げます。