RWAアーキテクチャ：トークン化資産を支えるシステム

現実資産（RWA）プラットフォームにおいて、トークンコントラクトは最も小さな構成要素です。力量のあるエンジニアであれば、制限付きトークンの実装とテストは数週間で終えられます。はるかに時間がかかるのはその周辺のシステムです。保有者の名簿、本人確認と適格性のチェック、発行や凍結を実行できる鍵、チェーンと帳簿の一致を証明する照合、そして分配や償還を処理する仕組みがそれにあたります。

私たちは、RWAプラットフォームはまず記録管理システムとして設計し、ブロックチェーンアプリケーションとしての側面はその次に考えるべきだと考えています。最初に下すべきアーキテクチャ上の判断は、どの台帳を正とするかです。それ以外のコンポーネントはすべて、残りの記録をその台帳と整合させるために存在します。

現実的なモデルは2つあります。1つ目は、オフチェーンのレジストリを信頼できる唯一の情報源とし、チェーンをその同期された写しとして扱うモデルです。2つ目は、オンチェーンの状態そのものを名簿とし、オフチェーンのシステムをイベントから構築するリードモデルとするものです。どちらも機能します。機能しないのは、この問いを未決のままにしておくことです。残高をめぐる最初の争いが起きた時点で、切迫した状況の中で答えを出さざるを得なくなります。

すでに登録機関、名義書換代理人、または法定の名簿が存在する資産については、オフチェーンのレジストリを正とし、トークンはその写しとなる制限付きの手段として扱うのが私たちの基本方針です。この構成であれば、チェーンを不変の法であるかのように扱うことなく、訂正、裁判所の命令による移転、紛失した鍵の回復に対応できます。オンチェーンの名簿が適しているのは、法的な枠組みがそれを明示的に認めており、かつ保有者が他のコントラクトとの間でアトミックに決済する必要がある場合です。この判断は発行体とその法務アドバイザーが下すものであり、アーキテクチャはそれに従います。

適格性ルールを持つ資産を、制限のないERC-20とWebアプリケーション側のチェックの組み合わせで実現することはできません。コントラクトは誰でも直接呼び出せるため、インターフェースだけで強制しているルールは、強制されていないのと同じです。制限は移転の経路そのものに置く必要があります。ERC-3643やERC-1400といった許可型トークン標準が採っているのは、このアプローチです。

典型的な設計では、トークンをアイデンティティレジストリおよびルールモジュールから分離します。トークンは移転が許可されるかどうかをルールモジュールに問い合わせ、モジュールは許可リストと適用される各種の上限を参照します。個人データはオフチェーンにとどめます。チェーン上に置くのはウォレットアドレスと、適格性フラグまたはクレームへの参照だけであり、本人確認書類を載せることは決してありません。

制限付きトークンの管理ロールは、発行、焼却、凍結、残高の移動を実行できます。これらの鍵を握る者が名簿を支配します。私たちはコントラクトより先にロールモデルを設計します。発行、コンプライアンス対応、アップグレードの鍵をそれぞれ分離し、HSMまたはMPC方式で保管したうえで、複数者による承認を必須とし、コントラクトのロジックを変更する操作にはタイムロックも課します。

トレードオフは運用の速度です。3名の承認を要するミント（トークンの発行処理）は数秒では完了しませんが、資産の発行業務であればそれで問題ありません。一方、オンボーディング中の許可リスト更新では許容できないため、このロールは通常、権限をより狭く絞り、自動化を進め、レート制限をかけます。原資産のカストディはカストディアンが担う別の領域であり、プラットフォームはその役割を置き換えるのではなく、カストディアンと連携します。

2つの台帳は必ずずれていきます。送信したトランザクションが破棄される、インデクサーが処理済みのブロックが再編成で消える、レジストリの更新は成功したのに対応する発行が失敗する、といったことが起こります。照合はこうした事象を検知するための統制であり、移転の経路と同じ水準のエンジニアリングを注ぐ価値があります。

私たちは照合を三者間の比較として構築します。ファイナライズ済みのブロックで読み取ったオンチェーン残高、同じ論理時点のオフチェーンレジストリ、そしてカストディアンまたは管理者が保持する原資産の記録です。不一致は分類し、担当者を割り当て、解消まで追跡します。インデクサーはファイナリティを待ってからイベントを確定済みとして扱い、チェーンへの書き込みにはすべて冪等性キーを付与して、リトライによる二重発行を防ぎます。

分配、償還、分割、基準日は、従来の名簿管理では日常業務ですが、オンチェーンでは扱いにくいものです。分配には、特定のブロックにおける保有者のスナップショット、端数処理を決定的に行う計算、そして部分的な失敗の後に再開できる支払いプロセスが必要です。1つのトランザクションで全保有者に支払いを送る方式は、保有者数が増えると成立しなくなります。そのため私たちは、請求型（クレーム方式）のモデル、または完全な監査証跡を備えたオフチェーンのジョブが駆動するバッチ支払いを選びます。

評価額、準備資産の証明、参照レートは、データフィードを通じてチェーンに届きます。フィードの信頼性は、その発行元と署名鍵の信頼性を超えることはありません。私たちはすべてのフィードを、障害モードを持つ外部依存として扱います。値の陳腐化、署名者の侵害、発行元の停止がその例です。コントラクトは値を使用する前にその鮮度を確認し、更新間で変動できる幅に上限を設け、フィードが許容範囲を外れた場合には依存する機能を停止します。

トークンが所有権を表すのか、発行体に対する請求権を表すのか、あるいは法的に強制可能なものを何も表さないのかは、法的なラッパー、募集書類、適用される規制によって決まります。そのいずれもコードで決まるものではありません。エンジニアリングにできるのは、ある仕組みをソフトウェア上で強制可能にし、運用において監査可能にすることであり、基礎となる権利そのものを生み出すわけではないことは明確に述べるべきです。私たちは、発行体とその法務・コンプライアンスアドバイザーが定めた要件に基づいて設計を行い、その役割を代替することはありません。