CordaとエンタープライズEVM（本記事ではHyperledger BESUを使用します）でアトミックスワップを実現する方法
はじめに
この記事では，Hyperledger Labs Harmoniaに基づいてCorda-EVMでアトミックスワップを実現する方法について説明します．Harmoniaについてはまた別の記事で詳しく説明したいと思いますが，Harmoniaの目的を一言で説明するならば次のようになるでしょう：
つまり，既存の技術では対応できない規制金融市場におけるIOPの一助になろうということです．
この考えを念頭に置いていただいてから，以降の説明を読んでいただけると幸いです．
参照：https://github.com/hyperledger-labs/harmonia
アトミックスワップとは
この記事をご覧の方には釈迦に説法かと存じますが，念のために一般的なブロックチェーンにおけるアトミックスワップ一般について説明させていただきます．
一言で言うとアトミックスワップは異なるブロックチェーン間での資産の直接交換を可能にする技術です．
特徴としては：
- 信頼できる第三者（仲介者）を必要としない
- 取引は全く行われないか，完全に完了するかのどちらかである（取引が非対称で終わらない）
といったことが挙げられます．
ユースケースとしては，通貨と通貨を交換するPvP(Payment VS Payment)やデジタルアセットとデジタル通貨の交換(Deliverly VS Payment)が挙げられます．
実現方式
アトミックスワップを実現するためには，実装方法によって多少の違いはあると思いますが，基本的に以下の流れは共通していると思います．
1. アリスが資産をロック:
アリスはボブに送りたい資産を自分のブロックチェーンでHTLCにロックします．このHTLCにはハッシュロックとタイムロックが設定されています．
アリスはプレイイメージを作成し，そのハッシュ値をボブに送ります．
2. ボブが資産をロック:
ボブはアリスに送りたい資産を自分のブロックチェーンでHTLCにロックします．このHTLCには同じハッシュ値のハッシュロックとタイムロックが設定されています．
3. アリスがボブの資産を引き出す:
アリスはボブのブロックチェーンでボブがロックした資産を引き出すために，プレイイメージを提示します．このプレイイメージが正しければ，アリスは資産を受け取ります．
4. ボブがアリスの資産を引き出す:
アリスがプレイイメージを公開したことで，ボブはそれを使用してアリスのブロックチェーンでロックされた資産を引き出します．
5. タイムロックの管理:
一定期間内に取引が完了しない場合．タイムロックが発動し，ロックされた資産は元の所有者に戻ります．
このプロセスにより，仲介者を必要とせずに異なるブロックチェーン間で安全に資産を交換することができます．
後に紹介するR3の参照実装が上記と異なる点は，Harmoniaは時限による取引の不成立を良しとしないので，ハッシュタイムロックではなく，単なるハッシュロックを使用していると言う点です．
参照実装
HarmoniaのGitHubリポジトリに上がっている参照実装のうち，R3が実装したものについてご紹介します．
HarmoniaではIOPを実現する上で考慮しなければならない，いくつかの原則や規制金融市場で求められる要件について説明されています． 実際に参照実装のフローを説明する前に，ここではR3の参照実装が順守しているアーキテクチャレベルのIOPの原則について紹介します．
- ファイナリティの尊重: トランザクションはネットワークでファイナライズされると，取り消すことができません．クロスネットワークの合意を待つ「保留」状態は，取り消すことができないローカルにファイナライズされたトランザクションの結果として実装する必要があります．
- 非決定性の回避: クロスネットワークワークフローの結果は，ネットワークのレイテンシー時間やタイムスタンプ機関間のクロックドリフトによって発生するような，観察可能な非決定性に依存すべきではありません．
- 一方的なボトルネックの排除: クロスネットワークワークフローの状態を進める機能は，1つの当事者に限定すべきではありません．
- 信頼の活用による証明の簡素化: 信頼できる当事者による事実の証明は事実そのものを検証するよりも簡単なことがよくあります．
これらは信頼性の高いIOPを実現する上で必要な要素と言えます．
最後の項目については，アトミックスワップは基本的に第三者の仲介を不要としている方式ですが，ビジネス要件や環境上の制約によっては信頼できる第三者の介入も必要というのがR3の見解です．実際にこの後に紹介する参照実装では，相手チェーンの証明の検証に第三者が介入するモデルとなっています．
参照：https://github.com/hyperledger-labs/harmonia/blob/main/docs/r3/architecture_principles.md
前提
- 取引方式：アトミックスワップ
- 対応基盤：
- Corda：4.9.8
- EVM：BESU
- 対応トークン：
- Corda：OwnableStateを実装した任意のState．
- EVM：ERC20, ERC721, ERC1155準拠トークン.
- ID：取引当事者がCordaとEVMにそれぞれにIDを持つ（Cordaの場合はノード，EVMの場合はEOA）
- IDのマッピング：Corda（オフチェーン）
- 証明検証：オンチェーン検証
- バリデータ：
- Corda：Oracleノード
- EVM：CordaのOracleノードのEOA
NW全体像
登場人物
- Alice：Cordaデジタルアセットの買い手（EVMのデジタル通貨の支払い手）
- Bob：Cordaデジタルアセット売り手主体（EVMのデジタル通貨の受け取り手）
- バリデータ：Corda/EVMトランザクションの検証と署名を行うCorda上のOracleノード（EOAを持つ）
オフチェーンで合意する内容
- 取引するデジタルアセットと支払いデジタル通貨
- 取引の期間
- バリデータの選定
- トランザクションを正当とみなすバリデータ署名数の閾値
- 互いのチェーンでのトランザクションの検証方法
- チェーン間でのIDのマッピング
- チェーン間のエンドポイント
など
DvP全体像
Flow
- オフレッジャーで取引を合意する（合意内容は前述の通り）．
- Bob@CordaがDraft TX（ファイナライズ前のTXで，署名なし．）を作成し，Alice@Cordaに送付する．
- Alice@CordaはDraft TXを受領し，オフレッジャーで合意した内容と相違ないか検証する．
- Alice@EVMはデジタル通貨をスワップコントラクトにコミットする．パラメータはDraft TXID（この取引のIDとなる），トークンコントラクトアドレス，数量，Bob@EVMのEOAアドレス，バリデータ@EVMのEOAアドレスとその署名数の閾値m (< n)，取引内容のハッシュ．
- Bob@Cordaはコミットのトランザクションレシートを検証し，事前に合意した内容と相違なければDraft TXに署名しファイナライズ，さらにバリデータ@Cordaに署名してもらう（Notaryの署名も入る）．ここでCordaのデジタルアセットがロックされる．
- Alice@CordaはNotarizeされたDraft TXを検証し，事前に合意した内容と相違なければ，Alice@EVMはBob@EVMに支払いを行う．（Cordaのデジタルアセットのロックの証明を提出することで，Bob@EVMからでもEVM上のデジタル通貨の移転は可能．これにより取引の非対称終了を回避）
- Bob@CordaはEVMでの支払いのトランザクションレシートを検証し，事前に合意した内容と相違なければ，バリデータにEVMでのトランザクションの証明を作成してもらう．（Alice@Cordaからも可能）
- Bob@Cordaは上記で作成してもらった証明をパラメータに，ロックされていたCordaアセットのロックを解除し，Alice@Corda宛にアセットを移転する．（EVM上でのデジタル通貨の支払いの証明を提出することでAlice@CordaからでもCordaのデジタルアセットは可能．これにより取引の非対称終了を回避）
ハンズオン
文章による説明だけではイメージが湧きにくいと思いますので，ここからは実際にローカル環境でアプリを動かしていこうと思います．
環境準備
デモ用アプリは以下の環境で動作確認してます．
BESUテストネットワークセットアップ
- quickstartのソース一式を取得します
- スマートコントラクトのデプロイ