CordaとEthereumでCrosschain 〜第一回そもそもCrosschainってなに？〜

公開日

April 9, 2025

カテゴリ

Corda技術を知る

タグ

🤝インターオペラビリティ ⭐Corda5

筆者

新井

1. はじめに

当記事ではEthereum（プライベートネット）にデプロイされているERC20準拠のトークンとCorda上に構築された汎用的なステーブルコインの資産転送（Asset Transfer）を実装する方法を考えていきます．なお，内容が長大になる予感がするため，連載方式にしたいと思います！（※更新頻度は未定です）

というわけで今回は「CordaとEVMでCrosschain」の第一回と称し，「そもそもCrosschainってなに？」というところからCrosschainで転送するトークンの実装例，転送を行う取引主体（エンティティ）のID管理までを扱っていきたいと思います．

連載全体としては以下の項目を説明していく予定です（が，変更になる可能性もあるのでご了承ください）．

Crosschainイントロ

Crosschainの概説
CordaとBesuの概説

データモデルの設計

Cordaトークン設計
Identity設計

フローの設計

ID管理フロー
認証フロー
資産移転フロー

この連載で実装したCrosschainの課題

と，息巻いてきましたが，いきなり大風呂敷を広げて，筆者が途中で蒸発しかねないので，まずは以下の通りスコープを絞って，スモールスタートしていきたいと思います.

Ethereumクライアント：Hyperledger Besu
ユースケース：資産転送（片方のブロックチェーン（以下，BC）ネットワークのトークンをもう一方のBCネットワークのトークンに変換）
コンセンサス：QBFT and IBFT 2.0

Crosschainにおける相互運用のユースケースとして，ISOはデータ転送（Data Transfer），資産転送（Asset Transfer），資産交換（Asset Exchange）の 3 つの相互運用モード (ISO/CD TS 23516)を定義しています．

当記事では現時点で利用可能な技術を用いて実現可能なCordaとBesu間の資産移転について，具体的なユースケースは想定せず，汎用的な実装を目指すものです．ここで紹介する方法は本番のユースケースに直接適用できるものではなく，あくまでCordaとBesu間の資産移転を実現する方法の参考情報として捉えれいただければと思います．また，今後のR3の開発進捗によっては本記事の内容が不適切および陳腐化する可能性があることご了承ください．

2. 対象BC概説

ここでは今回のCrosschainを行うBCプラットフォームについて簡単に紹介します．

2.1 Hyperledger Besu

Hyperledger BesuはLinux FoundationがホストするHyperledgerプロジェクトの一つで，OSSのEthereumクライアントです．エンタープライズ領域での利用を想定した設計となっており，パブリックおよびプライベートのEthereumネットワークの両方をサポートしています．

筆者がYouTubeのBesu関連動画を観漁った限り，読み方は”ベイス” のようです😎

次のような特徴があります．

特徴：

マルチネットワークサポート：

パブリックネット：Ethereumメインネットワークで動作可能なモードです
プライベートネット：企業向けのプライベートネットワークをサポートしており制御されたBCネットワークを構築可能なモードです

コンセンサスアルゴリズム：

複数のコンセンサスアルゴリズムをサポートしており，ユースケースに応じて柔軟にカスタマイズ可能です（PoS, PoA, PoW etc…）

エンタープライズ向けの機能：

プライバシー機能：プライベートネットワークでのトランザクションの機密性を確保するために，Tesseraなどの機能を使用してプライベートトランザクションが発行できます
パーミッション機能：ネットワークに参加可能な企業を制御可能です

EVM互換性：

完全にEVM互換であり，Etherumのスマートコントラクトを実行し，他のEthereumクライアント（GethやNethermindなど）と相互運用が可能です

2.2 Corda

Cordaは規制金融市場を主なターゲットに，データを安全，効率的，かつ透明性のある方法で管理および共有するために設計された分散型台帳技術（DLT）プラットフォームです．現在は規制金融市場にとどまらず，サプライチェーントレーサビリティなど，取引の透明性とプライバシーの両立が求められるユースケースにおいて幅広く採用されています．

宣伝

以下の記事はRWAにおけるCordaのプレゼンスについての記事です．一部日本語訳したものを載せておきます！

Tereza Vachulova R3’s Corda leads tokenized RWA market with over $10 billion in on-chain assets and unrivaled industry adoption - R3

[日本語訳]

R3のCordaは，100億ドル以上のオンチェーン資産と比類のない業界の採用により，トークン化されたRWA市場をリードしています．

R3のCordaは，100億ドル以上のオンチェーン資産を保有し，トークン化された実世界資産（RWA）市場を独占し，業界の採用基準を設定しています．
世界有数の銀行から信頼されているCordaは，ライブRWAネットワークの最大のエコシステムであり，毎日100万件以上の取引を処理しています．
規制と業界の追い風に支えられたR3のデジタル製品スイート全体のクライアントの勢いにより，世界的に最も多くのライブアプリケーションが稼働しています．

次のような特徴があります．

特徴：

プライバシーとセキュリティ：

「Need to Know」という独自のモデルを使用しており，データはアクセスが必要な取引当事者だけに共有されます

開発者フレンドリー：

ContractおよびFlowはJavaやKotlinなどの金融機関で実績の多いプログラミング言語でコーディングできるため，開発者フレンドリーです

コンセンサスアルゴリズム：

ビジネスレベルのコンセンサスに焦点を当てており，取引に関与する当事者でのみトランザクションに合意，ファイナライズすることが可能です

スケーラビリティ:

独自のコンセンサスアルゴリズム（当事者＋Notaryによる検証とファイナライズ）から低遅延・高TPSを実現しており，その他のエンタープライズ向けブロックチェーンと比較し優位です

3. Crosschainって？

さてこの記事を読んでいる方には釈迦に説法かもしれませんが，当記事でCrosschainという単語を初めて知った方もいるかもしれませんので簡単に説明したいと思います．

BCネットワークを独立した島々に例えて考えてみましょう．それぞれの島（BC）は独自のルールや通貨，資源を持っています．通常，これらの島々は互いに交流できず通貨や資源を直接やり取りすることはできません．

Crosschainとは，このブロックチェーンの島々をつなぐ「橋」と「ルール」のようなものです

少々技術寄りな話に落とし込むとCrosschainは，異なるBCネットワーク間で資産（暗号通貨やNFTなど）やデータを整合性と有効性を保ったままやり取りできる仕組みやそれによって実現されるサービスと言えるのではないでしょうか．そこで私が考えるCrosschainを実現するためのコアの要件として，次の２つが挙げられます：

異なるBC間でデータ（資産，通貨，イベントなどそのBCのオンチェーンのステート）を送受信できる
異なるBCが互いに連携し，他のBC上のアクションをトリガーできる

これらが実装できれば先に紹介したISOが定義するCrosschain相互運用の三つのユースケースに対応できるはずです．

Crosschainの重要性

ところで，なぜCrosschainが必要なのでしょうか？別に相互運用しなくてもBC単体だけでも困ることはないのでは？とお思いの方もいらっしゃるかもしれません．しかし，私はCrosschainを実現することで，以下の恩恵を享受することができ，より豊かなデジタルライフが送れると思っています．

エコシステムの拡大

今まで別々のBCでしか使えなかったサービスや資産，データが自由に行き来できるようになり，資産の流動性が向上し，より便利かつ安定した資産として機能します．正直なところ，BTCであれETHであれ，現在は投機的な色が濃く，通貨として機能しているとは言えないと私は思います．
エコシステムが拡大すれば，例えば，BTCをEthereumで人気の金融サービスで運用したり，あるゲームのアイテム（NFT）を別のBCの市場で売買したり…といったことが可能になります．これによりBCの使い道が一気に広がります．

スケーラビリティ・コスト効率の向上

混雑しているBCから他の空いているBCへ処理を分散させ速度劣化や送金コストの高騰を回避できます．
人気のBCはTPSが落ちたり，ガス代が高くなったりすることがあります．Crosschainがあれば処理の一部を別のBCに委譲したり手数料が安価なBCを経由して送金することで時間もお金も節約できる可能性があります．

新しいユースケース・イノベーションの創造

特性が異なるBC同士が連携し，新たなビジネス価値が生まれるかもしれません．
例えば・・・すみません．思いつきませんでした．（ビジネスは難しいですね😇．ビッグなアイデアを思い付いたら起業します笑）

ユーザー体験の向上

Crosschainを使えば異なるBCの間で，より簡単かつスムーズに資産を移動できるようになります．これにより直感的にストレスなくBCのサービスを利用できるようになるでしょう．将来的にはどのBCを使っているかすら意識しなくなるかもしれません，

まとめ

Crosschainはバラバラだった「島々」の世界をつなぐ「橋」となり，私たちの（デジタル）ライフをより便利で可能性に満ちたものに変えてくれる可能性を秘めています．CrosschainはBCのエコシステムをさらに統合し，多様なネットワークが協力できる環境を作ることを可能にします．これはインターネットが異なるコンピューターネットワークを接続し，グローバルでシームレスな情報のやり取りを可能にしたのと同じように，BC世界におけるインターネットを実現することに他ならないのです．

4. Crosschainを実装する前に考えるべきこと

いざ，より豊かなデジタルライフを実現するために，Crosschainをしよう！と息巻いても残念ながらそんなに簡単ではありません．．．今回取り上げる「（互いにプライベートな）CordaとBesuで資産移転」という非常にシンプルなユースケースを実現するだけでも，最低限以下を考慮する必要があります．

プルーフとその検証メカニズムの設計
相手アプリケーションの認証設計
データモデルの設計

Cordaトークン設計
ID設計

フローの設計

メッセージングメカニズム
プルーフの構築・検証メカニズムの設計
IDマッピング
エンドユーザ認証
サービス（相手BCのファンクションコールを行うサービス）認証
資産移転（発行，移転，ロック．．．．）

この他にもユースケースによっては要考慮事項がさらに増えるでしょう．．．

ご参考までに規制金融市場におけるCrosschainの議論の場であるHyperledger Labs Harmoniaを紹介いたします．ここでは数あるユースケースの中でも特に法規制や取引に求められる厳密性が高度な規制金融市場においてCrosschainがどのように実装されるべきかについて，その方針とレファレンス実装を示しています．

また，これらの項目を考える前に，CordaとBesuはの根本的な違いについても考慮する必要があります．当たり前ですが，BCが異なればその設計思想，運用方針が全く異なることが多々あります．それらの異なる思想の元に作られたBC同士が協調していくためには，まずは相手の特性を知ることが肝要です．

理解できないと投げ出す前に，理解しようと相手と同じレベルに立って感じることを心がけましょう．

瀬戸内寂聴　-

（日本の小説家，天台宗の尼僧 / 1922～2021）　Wikipedia

と瀬戸内寂聴さんもおっしゃっています😌

では，早速CordaとBesuの主な違いを見ていきましょう！

データモデル

Besu: アカウントモデルを採用しています．アカウントごとにステート（残高，ストレージ）が管理されています．同時に複数の支払いはできませんが，残高照会などの情報を照会する処理が早いという長所があります（PASMOで支払うイメージ）．
Corda: UTXOモデル（かの有名なBitcoinと同じですね）を採用しています．トランザクションは既存のステートを消費し，新しいステートを生成します．各ステートは特定の当事者によって所有される個別のオブジェクトと言えるでしょう．同時に複数の支払いができる長所があります（複数の人に財布から紙幣やら小銭やらで決済するイメージ）．

要考慮事項:

CordaのUTXOとBesuのトークンコントラクトをどのように紐つけるか（交換レート，交換可否）

プライバシーモデルの違い

Besu: トランザクションはNW全体に伝搬されます．Tesseraにプライベートトランザクション機能はありますが，Cordaほどの秘匿性は実現できていません．
Corda: need-to-knowのプライバシー設計となっています．トランザクションの詳細は関係者のみが共有し，ネットワーク全体には公開されません．

要考慮事項:

Cordaの厳格なプライバシーをBesuと連携する際にどのように維持するか

コミュニケーション

Besu: スマートコントラクトにより全ての業務処理や状態遷移処理がEVM上で実行され，全バリデータノードで処理されます
Corda: ビジネスロジックは主にFlow（オフチェーンのワークフロー），状態遷移の確定およびトランザクションの検証はコントラクトコードで処理されます

要考慮事項:

BCを跨ぐメッセージの伝搬方法はどうするか
相手BCのトランザクションをどのように検証するか
オーケストレーションはどうするか

コンセンサスとファイナリティ

Besu: IBFT 2.0，QBFT，Clique（PoA）やEthash（PoW）などのコンセンサスアルゴリズムを選択可能です．ファイナリティの保証は選択したアルゴリズムによる（PoWでは確率的，BFT系では決定的）
Corda: Notaryによりステートの一意性が保証されます．トランザクションはNotaryと全当事者の署名を得ることでファイナライズされる，決定的ファイナリティ．

要考慮事項:

あるチェーン上のアクションが確定したとみなされるタイミングをどう定義するか

CordaではNotaryの署名取得が完了すれば確定とみなせるが，Besuではブロックの最終化（BFTなら即時，PoWなら一定のブロック承認数）を考慮する必要があります

アイデンティティ

Besu: Ethereumウォレットの公開鍵がIdentityであり，Identifier．パーミッション型ネットワークでは，オンチェーンの許可制コントラクトや外部の認証システムがアドレスと実世界のエンティティを紐づけています．Identityを保有できる最小単位は個人です．
Corda: X500に準拠した厳格なIdentity管理がなされています．基本的にIdentityを持つことができる最小単位はノードです．

要考慮事項:

互いのIdentityの真正性をどのように検証するのか
異なるBCのIdentityのマッピングをどう管理するか

トランザクションの制御

Besu: トランザクションの実行から，検証，ファイナライズまでスマートコントラクトで完結．
Corda: Flowでトランザクションを組成し，コントラクトで検証，Flowでファイナライズ．

要考慮事項:

相手のトランザクションの正当性を検証するコンポーネントが必要
取引をどのようにアトミックに完了するか
障害発生時の対応は
HTLCを適用する場合，CordaのContract/FlowとBesuのスマートコントラクトで互換性のあるロック＆ハッシュロジックを設計する必要がある
CordaのVaultの更新を監視するコンポーネントとBesuのイベントを監視するコンポーネントが必要
二重支払をどのように防ぐか

さて，つらつらと要考慮事項を列挙致しましたが，一度で全てをカバーしようとすると（主に私の）頭が爆発してしまうと思うので，まずはデータモデルの設計について考えていきたいと思います．

閑話休題

Crosschainプロトコル

上述の通りCrosschainを実現するためには，考えるべきことが多岐にわたります．これらを一から設計することも可能ですが，世の中には偉大な先人たちが既にいくつかのCrosschainを実装するための方法を確立してくれています．ここではその中でも特に有名で実績のある三つの手法について紹介したいと思います．

Enterprise Ethereum Alliance Crosschain Interoperability Technical Specification Messaging Interface（以下，EEA仕様）

異なるBC間の安全で効率的な相互運用性を目的とした仕様を定義しています．特に金融サービスやサプライチェーン管理などの複雑で規制の厳しい分野で，さまざまなBCがシームレスに取引を行う必要性に対処しているという特徴があります．送金に限らない多様なユースケースに対応可能であるというのが素晴らしいですね， [補足]EEA発でありながら，対象範囲はエンタープライズEthereumクライアントに留まらず，その他のエンタープライズ領域のBCエコシステムをカバーしていてCordaもその一つです．

ユースケース：

IBC

異なるBC間の認証とデータ転送を処理するオープンソースプロトコルです．異種のBCが相互にトラストレスに通信し，データやメッセージ，トークンを交換できるという特徴がある．多様なユーケースに対応可能です．

ユースケース：

ILP

シームレスな国境を越えた取引と，異なる決済ネットワークと元帳間の相互運用性を促進するために設計されたオープンソース決済プロトコルです． [補足]基本的に送金を対象としていて，他のトランザクションはスコープ外のようです．

ユースケース：

本記事では以下の理由からEEA仕様でCrosschainの実装を考えていきたいと思います．

Cordaの堅牢なプライバシー機能を存分に発揮したい
将来の拡張性を見据え，送金だけではなく，様々なトランザクション（STやNFT，UTとSCのDvPなど）に対応できるようにしたい

5. データモデル

いよいよ本題です．先に挙げた考えるべき項目のうち，データモデルについて考えていきたいと思います．

5.1 トークン

ここでは今回の資産移転の対処となるFungibleトークンを設計していきます．

5.1.1 Besu側トークン

まずはBesu側トークンについてです．ご存知の通り，EthrereumにはERC20というFungibleトークンの標準が既に存在するので，車輪の再開発はせず，この標準に準拠してトークンを実装していただければと思います．

参考までにERC20の実装のリンクを掲載しておきます：GitHub openzeppelin-contracts/contracts/token/ERC20/ERC20.sol at master · OpenZeppelin/openzeppelin-contracts

5.1.2 Corda側トークン

次にCorda側のトークンについて考えていきます．Ethereumと違ってCordaではトークンが標準化されていませんので，自分でデータ構造を考える必要があります．とはいえ，まっさらな状態から一から仕様を考える必要はありません．Corda5にはToken Selection APIというトークン操作に関する便利なライブラリを利用するためにAPIが用意されているので，そちらに準拠する形で実装していきます．

主な仕様は以下の通り：

Attribute	Type	Provided By	Description
StateRef	StateRef	Platform	The reference to the state linked to this token.
Notary X500 Name	MemberX500Name	Platform	The notary of the state linked to this token.
Token Type	String	Both	By default, the platform sets this to the FQN name of the Java Type of the state class this token is linked to. As a CorDapp Developer, you can override this with your own definition.
Issuer Hash	SecureHash	User	The hash of the issuer of the state, as defined by the CorDapp Developer.
Symbol	String	User	The user-defined symbol for the token.
Amount	BigDecimal	User	The amount/value of the state linked to this token.
Tag	String	User	An optional string that can be searched using a regular expression when selecting tokens.
Owner Hash	SecureHash	User	An optional hash of the owner of the state.

これらの属性をトークンのプロパティとして実装すれば，TokenSelection APIを使ってトークンの操作が可能になります．その他にも自分で実装しなければならないクラスがいくつかありますが，この記事のスコープではないので割愛します．詳しく知りたい方は以下のリンクをご参照ください． R3 Documentation ledger.utxo.token.selection - Corda 5.2

上記APIを利用できるように実装したトークンが以下になります：

Token：

data class Token(
    private val issuer: PublicKey,
    private val owner: PublicKey,
    private val quantity: NumericDecimal,
    private val issuerHash: SecureHash,
    private val ownerHash: SecureHash,
    private val symbol: String,
    private val tag: String?,
    private val participants: List<PublicKey> = listOf(owner)
) : FungibleState<NumericDecimal>, IssuableState, OwnableState

symbol: トークンのシンボル（例: JPY, BTC）
amount: トークンの数量を表す値
tag: トークンに付与される識別用タグ
issuer: トークンの発行者
owner: トークンの所有者
participants: トランザクションの参加者の公開鍵リスト．このリストの参加者にのみトランザクションが共有される

補足

トークンの一意性はsymbolとissuerAccountの組み合わせによって担保される
発行体が署名するタイミングは発行と償還時のみ
移転に際しては，現行（移転元）所有者のみが署名し，移転先所有者は署名しない

5.2 Identity

この文脈ではIDはIdentityのこと指します．以降，IdentityはID，Identifierはidと表記します．

そのBCにおけるIDはBCの仕様によって異なります．今回扱うCordaとBesuではIDはそれぞれ以下の属性の集合によって表現されます：

Besu：Externally Owned Account（以下，EOA）

Cryptographic Key Pair: 秘密鍵と公開鍵のキーペア
Address: アドレス．公開鍵のKeccak-256ハッシュの末尾20Bytes
State Components:

Corda：VNodeのMemberInfo

@CordaSerializable
public interface MemberInfo {
    /**
     * @return Context representing the member set data regarding this members information. Required data from this
     * context is parsed and returned via other class properties or extension properties internally.
     */
    @NotNull MemberContext getMemberProvidedContext();

    /**
     * @return Context representing the MGM set data regarding this members information. Required data from this context
     * is parsed and returned via other class properties or extension properties internally.
     */
    @NotNull MGMContext getMgmProvidedContext();

    /**
     * @return Member's X.500 name. X.500 name is unique within the group and cannot be changed while the membership
     * exists.
     */
    @NotNull MemberX500Name getName();

    /**
     * @return List of current and previous (rotated) ledger keys, which the member can still use to sign unspent
     * transactions on ledger. The key at index 0 is always the latest added ledger key.
     */
    @NotNull List<PublicKey> getLedgerKeys();

    /**
     * @return Corda platform version that the member is running on.
     */
    int getPlatformVersion();

    /**
     * @return An arbitrary number incremented each time the {@link MemberInfo} is changed.
     */
    long getSerial();

    /**
     * @return True if the member is active. Otherwise, false.
     */
    boolean isActive();
}

Corda上のIDとそのオルター・エゴであるBesu上のID間で価値を移転するためには，それぞれのBCにおいてIDのマッピング情報を管理する必要があります．そこでそれぞれのBCでIDの紐付けを管理するものとして以下の構造体を定義します：

Besu

コントラクト自体が状態を保持できるBesuについては，個別に構造体は定義せず，Crosschainのメッセージングを担うCrosschainMessagingコントラクト（急に出てきて驚いたと思いますが，次回以降解説します！）のプロパティの一つとしてIDのマッピングを定義する，

contract CrosschainMessaging is ICrosschainVerifier {
// ...
    mapping(address => bytes32) public cordaIdentityMappings;
// ...

address: EOAアドレス
bytes32: Corda NodeのLedgerKey

Corda

UTXOモデルのCordaについては，IDマッピングを表す構造体を定義します．

data class RemoteEVMIdentity(
    val cordaAccountId: UUID,
    val eoaAddress: String,
    val remoteEvmNetworkId: BigInteger,
    val localNetworkId: BigInteger,
    val host: PublicKey,
    private val participants: List<PublicKey>,
) : ContractState

cordaAccountId: Cordaアカウントを一意に識別するUUID
eoaAddress: 対応するEVMネットワーク上のEOAアドレス
remoteEvmNetworkId: 対応するEVMネットワークのチェーンID
localNetworkId: CordaネットワークのチェーンID
host: アカウントを管理するホスト（ノード）の公開鍵
participants: トランザクションの参加者の公開鍵リスト

そもそもIdentifierとIdentityの違いって？？

どちらもIDを表記されることが多いため，意外と混同されがちですが，筆者は以下の通り区別してます．

Identity：エンティティ（実体）そのものを表している情報
ITシステムを利用する際にユーザー，モノ，または組織などの管理単位（エンティティやサブジェクトとも言います）を定義するための情報の集合体
デジタルの世界では，これを「Digital Identity（デジタルアイデンティティ）」と呼び，ID管理システムと言うときのIDや，アカウントと呼ばれるものはこのIdentityを略したもの
Identifier：Identityを他と区別し一意に特定するための情報

さて，IDを管理する構造体を定義しましたが，これで終わりではありません．

と言いたいところですが，そろそろ疲れてきたので続きは第二回にしたいと思います！

6. まとめ

お疲れ様でした．以上で連載「CordaとEthereumでCrosschain」の第一回としたいと思います．

本記事ではCordaとBesuという異なるBCプラットフォーム間での資産転送（Asset Transfer）の実装について探究を開始しました．まず，Crosschainの基本概念と重要性について解説し，エコシステムの拡大，スケーラビリティ向上，イノベーション創出などの利点を確認しました．また，CordaとBesuの基本的な違い（データモデル，プライバシー設計，コンセンサスメカニズムなど）を比較することで，Crosschain実装における課題を明確にしました．データモデルの設計部分では，Besu側ではERC20標準を活用し，Corda側ではToken Selection APIに準拠したトークン設計を提案しました．さらに，異なるBC間でのIdentity管理の重要性と，それぞれのチェーンでのID構造体の設計について説明しました．次回は，今回定義したトークンとIDを管理するフローについて掘り下げていく予定です！Crosschainの実装における重要な部分である認証フローや資産移転フローなどの設計について詳しく解説していきます．

CordaとEthereumでCrosschain 〜第一回 そもそもCrosschainってなに？〜

1. はじめに

2. 対象BC概説

2.1 Hyperledger Besu

2.2 Corda

3. Crosschainって？

Crosschainの重要性

まとめ

4. Crosschainを実装する前に考えるべきこと

データモデル

要考慮事項:

プライバシーモデルの違い

要考慮事項:

コミュニケーション

要考慮事項:

コンセンサスとファイナリティ

要考慮事項:

アイデンティティ

要考慮事項:

トランザクションの制御

要考慮事項:

Crosschainプロトコル

Enterprise Ethereum Alliance Crosschain Interoperability Technical Specification Messaging Interface（以下，EEA仕様）

IBC

ILP

5. データモデル

5.1 トークン

5.1.1 Besu側トークン

5.1.2 Corda側トークン

5.2 Identity

6. まとめ

CordaとEthereumでCrosschain 〜第一回そもそもCrosschainってなに？〜