セキュリティトークンプロトコルにおける相互運用性の必要性 – Thought Leaders
編集者注: この記事は、セキュリティトークン標準の初期開発段階で外部から投稿されたものです。執筆時点でのEthereumベースのコンプライアンスプロトコルと相互運用性の課題の状況を反映しています。具体的な実装はその後進化していますが、ここで示したアーキテクチャ上のトレードオフと摩擦点は、初期のトークン化取り組みが規模拡大に苦戦した理由を理解する上で有用な歴史的文脈となります。 トークンの簡単な歴史 ビットコインがブロックチェーン技術を世界に初めて紹介してから10年以上が経過しました。その間に、分散型台帳の潜在的なユースケースは急速に拡大し、デジタル通貨からサプライチェーン、アイデンティティ管理に至るまで多岐にわたります。根底にあるのは、ユーザーがピアツーピアでデジタル資産を保有・転送できるという共通構造です。言い換えれば、中央の信頼できる権限がなくてもデジタル資産の取引や追跡が可能になったということです。 この領域の進化は自然に「トークン」の発明へとつながりました。トークンとはブロックチェーン上の所有可能で転送可能なデジタル資産です。トークンは大きく二つに分類されます：ネイティブなデジタル資産を表すものと、実世界の基礎資産を表すものです。この新しいパラダイムを活用し、Ethereumだけでも数十万種のトークンが作成され、執筆時点での合計時価総額は150億ドルを超えています。 トークンの最も有望な応用の一つは、実世界の証券をオンチェーンで表現することです。これにより、商業用不動産のような従来は流動性が低い資産を分割化し、ピアツーピアで転送できるようになります。このプロセスは「トークン化」と呼ばれ、既存の資本市場における多くの課題を緩和できる可能性から、既存の金融機関と新興スタートアップの双方で大きな関心を集めています。 規制遵守 ブロックチェーンは技術的には所有権の転送を容易にしますが、セキュリティトークンは従来の証券と同様に法令や規制の対象です。セキュリティトークンが規制に適合していることを確保することは、トークン化の可能性を実現する上で不可欠であり、これまでの採用の壁となってきました。下のチャートが示すように、規制の不確実性はブロックチェーン採用における最大の障壁と広く認識されています。 ブロックチェーン領域では多数のプロジェクトが登場し、セキュリティトークンの規制・取引・管理を簡素化・標準化しようとするプロトコルを設計しています。Ethereumだけでも、Securitize、Harbor、Polymath などが標準化に取り組むプロジェクトとして公開されています。しかし、現在のプロトコル設計に変更が加えられなければ、投資家や取引所はトークン化証券の売買時に大きな摩擦を経験し続けます。なぜでしょうか？ それは「相互運用性」の欠如です。 相互運用性は重要です 相互運用性はトークン化の最も重要な利点の一つです。共通のソフトウェア標準を共有することで、資本市場アプリケーションや製品のエコシステム全体が相互に統合できるようになります。しかし、アプリケーションや製品レベルで相互運用性を実現するには、まずトークン自体のレベルで始める必要があります。セキュリティトークン領域では、相互運用性は取引所と投資家という二つの主要な関係者にとって不可欠です。 取引所としては、投資家が購入資格を持つあらゆるセキュリティトークを承認できるようにしたいと考えます――トークンを発行した企業が誰であっても構いません。つまり、各セキュリティトークごとに個別の統合を行うのではなく、すべてのトークンに対して統一されたシンプルで汎用的な統合が必要です。 投資家としては、オンボーディングプロセスをできるだけシンプルで摩擦なくしたいと考えます。現在、投資家が複数のプラットフォームで株式を購入しようとすると、何度も個人情報を提供しなければならない「顧客確認（KYC）」プロセスが発生します。ブロックチェーンはこの情報をオンチェーンに不変的に保存し、すべてのセキュリティトークが参照できるようにすることで、同じ情報を繰り返し提供する必要をなくす可能性があります。初回登録後は、補足的または更新された情報だけが求められるようになるでしょう。ただし、このプロセスが実現するのは、セキュリティトーク間の相互運用性が標準に組み込まれている場合に限ります。 プロトコル Ethereum の主要なセキュリティトークプロトコルは、Securitize、Harbor、Polymath の3社が公開しています。これらはすべて Ethereum の ERC-20 トークン標準上に構築され、さらに取引時にコンプライアンスを強制する拡張が加えられています。具体的には、取引が行われるたびに第2のコントラクトに対して合法性を照会します。 プロトコルごとに名称は異なりますが、第2のコントラクトを使用する点は共通で、目的は同じです――コンプライアンスに違反する取引を防止することです。この第2の「Regulator」コントラクトは、オフチェーンで認可されたサービス（例：取引所やトークン発行者）がユーザーの KYC や認定情報を更新することで最新の状態が保たれます。 これら3つのコンポーネントは、セキュリティトークを規制するために必要な要素すべてを備えているように見えます（最も単純な形では実際にそうです）。しかし、相互運用性はコンポーネントの実装方法に依存します。残念ながら、現在のプロトコルは以下の2つの重要領域で相互運用性が欠如しており、これが技術の採用を遅らせる摩擦となっています： 認可された当事者は、ユーザー情報をオンチェーンでどのように更新するか？ Harbor Harbor はホワイトペーパーで、当面はユーザー情報をオンチェーンで更新できる唯一の当事者は自社だけになると宣言しています。この役割の集中化により、取引所は Regulator が参照するデータを更新できず、新たなトークン受取人を承認できません。その結果、Harbor プラットフォーム外でトークンを容易に取引できなくなります。 Securitize Securitize はすでに複数の当事者が認可できるシステムを実装しており、投資家は複数の場所でコンプライアンス情報を登録でき、Securitize…
