JP6982345B1

JP6982345B1 - 取引システム

Info

Publication number: JP6982345B1
Application number: JP2020169096A
Authority: JP
Inventors: 淳木村
Original assignee: Datachain
Current assignee: Datachain
Priority date: 2020-10-06
Filing date: 2020-10-06
Publication date: 2021-12-17
Anticipated expiration: 2040-10-06
Also published as: WO2022075046A1; US20230316398A1; JP2022061223A

Abstract

【課題】複数のブロックチェーン上の取引に関わるスマートコントラクトの分散トランザクションにおいてデータの整合性を保証することが可能なシステムを開発可能にする取引システムを提供する。【解決手段】スマートコントラクトを実行するフローにおいて、コーディネータ１１b（コーディネータ部）とパーティシパント１１c（第１ユーザ部）からなるブロックチェーンとしての証券チェーン１１（第１のブロックチェーン）と、パーティシパント１２c（第２ユーザ部）からなるブロックチェーンとしての決済チェーン１２（第２のブロックチェーン）と、を備える。ユーザー間において、証券チェーン１１上で証券トークンが移転され、決済チェーン上で決済トークンが移転されることにより、証券チェーン１１及び決済チェーン１２間のアトミック性を持つ安全なスマートコントラクトの呼び出しが可能となる。【選択図】図３

Description

本発明は、取引システムに関する。

暗号資産による証券売買を行うためには、暗号資産交換業の免許と、金融商品取引業の免許とが必要である。しかしながら、これら双方の免許を有している事業者が日本には存在しないため、現在は法定通貨による証券売買が行われている。つまり、現在の日本では、暗号資産による証券取引は行われていない。

ブロックチェーンを活用してスマートコントラクトを構築するプラットフォームとして広く知られたイーサリアムでは、トークンとしてERC20、ERC1400等の規格が採用されている。ERC1400は、証券（Security）トークンのための規格である。

日本国内では、これらのトークンを用いて証券を売買するサービス事業者は存在しないためトークンによる証券売買は行われておらず、法定通貨でのトークンの購入、検証が行われているにすぎない。

一方、海外では、これらのトークンを用いた証券売買を行うためのプラットフォーム（例えば、Polymath、Harbor、Securitize）が準備されているが、これらは同一チェーン上に実装されたスマートコントラクトによってトークンが生成されるため、様々な証券や取引のデータが１つのブロックチェーン上で管理されることになり、複雑性、処理速度、他のネットワークとの接続性が課題となる。ここで、スマートコントラクトとは、ブロックチェーン上で契約を自動的に実行する仕組みのことである。

特開２０２０−５７８６３号公報

価値取引を行うためには、取引のアトミック性が担保されている必要がある。ここで、取引における「アトミック性」とは、取引の処理が全て完了されているか、もしくは全く実行されていないかのいずれかの状態になっていることを意味する。例えば、ブロックチェーンAでの取引完了が、異なる価値取引を行うブロックチェーンB上でも必ず完了できるかどうか不明であり、チェーンB上で取引の問題がある場合には、チェーンA上での取引も中止しなければならない。

上述の点について、証券のDvP取引を例にして詳細に説明する。ここで、DvP取引は、Delivery Versus Paymentの略で、証券の引渡し（Delivery）と代金の支払い（Payment）とを相互に条件を付け、一方が行われない限り他方も行われないようにすることを意味する。これは、証券決済において、資金（または証券）を渡したにもかかわらず、取引相手からその対価となる証券（または資金）を受け取れないという「取りはぐれ」リスクを回避するための方法・仕組みである（日本銀行のHP参照）。

ブロックチェーンを用いたDvP取引では、資金側のチェーン及び証券側のチェーンが設けられており、資金側のチェーンで取引が完了したからといって、証券側のチェーンでの取引も完了できるかどうか不明である。

ここで、異なるブロックチェーン間での情報・価値交換を実現する方法として、２way-peg方式やHTLC方式(Hashed Time-Locked Contract)が検討されている。2way-peg方式とは、トークンの送信チェーンのロックもしくはバーンの証拠を受信チェーンが検証を行ったうえでトークンを受信チェーン上にミントすることであり、これを逆向きにも可能な方式である。この方式では、資金側のブロックチェーンで証券のトークンを発生させるが、資金側では証券側のルール（例えば、譲渡人数が上限に達していないか、移転先のユーザーはKYC済かなど）をチェックできない。そのため、再度、証券側でチェックすると、他の取引と競合し取引不可となってしまう場合がある。また、HTLC方式とは、受取側のユーザーがハッシュのプリイメージを公開することでトークンを入手することを可能にし、また期限内に受取側のユーザーがハッシュのプリイメージを公開せずタイムアウトになった場合に、送金側のユーザーがトークンを取り戻すことを可能とする方式である。この方式では、プリイメージを公開するタイミングで証券側のルール(例えば、譲渡人数が上限に達していて証券の移転が不可能)に引っかかった場合、代金の支払いは完了するが、証券の引き渡しは完了しない「取りはぐれ」リスクが存在する。

（本発明を創作するに至った経緯）
ブロックチェーンは、単体では他のブロックチェーンとの相互運用性の能力に乏しいことが知られている。ブロックチェーン同士を繋ぐクロスチェーン上の接続方式として、relay方式が知られている。クロスチェーンとは、異なるチェーン同士を跨ぐことを意味する。

これを実現するのに必要なプロトコルストックの標準化のために、ICS（Interchain Standards）がCosmosによって設計されている。ここで、現在、ブロックチェーン技術は普及期にあり、Bitcoinブロックチェーン、Ethereumブロックチェーン等様々なブロックチェーンが存在する。このような背景の下、ブロックチェーンのスピード、スケーラビリティー、相互運用性といった課題を解決するために、ブロックチェーン同士を繋ぐプロジェクトして考えられたものがICSである。

relay方式を用いたアプリケーションプロトコルとして、PegやEscrow方式によるトークンの移動や交換のプロトコルが様々なコミュニティにおいて議論されているが、多くの方式で対象となるトークンやStateは、Fungible token（つまり、代替可能なトークン）等の単純なStateで表現可能なものとなっている。Cosmosにおいてもアプリケーションプロトコルとして、Fungible tokenの2way-pegがics‐020で提案されている。

そこで、本願発明は、複数のブロックチェーン上のスマートコントラクトの分散トランザクションにおいてデータの整合性を保証することが可能なシステムを開発可能にすることを目的とする。この目的を達成するために、本発明者等は、Cross Frameworkというフレームワークを開発し、以下の（１）及び（２）の要素が必要と考えた。
（１）スマートコントラクトに必要なロックメカニズムとコミットの可否についての分散合意プロトコルを設計する。
（２）分散合意プロトコルを可能とするためにコントラクト（契約）が満足すべき要件を開発者が透過的に満たすことができる仕組みを構築する。

また、このようなスマートコントラクトを実行するトランザクションが上述のCross-chain Transactionに相当する。Cross-chain Transactionは、複数の異なるブロックチェーン間で行う分散トランザクションと同義である。そのため、一般的な分散トランザクションと同様に、Cross-chain Transactionにおいても、ACID特性で定義されているようなトランザクション処理の信頼性を保証する必要がある。ここで、ACID特性は、“Atomicity”（原子性）、“Consistency” （一貫性）、“Isolation”（独立性）、“Durability”（耐久性）の頭文字をつなぎ合わせたものであるが、技術常識であるため、詳細な説明は省略する。

スマートコントラクトとは、Blockchain上で実行可能なプログラムである。それらは状態をもち、多くの場合提供される機能は関数として公開され、定められた条件に従い実行可能である。ユーザが生成したトランザクションによって実行され、状態の更新を行う。Cross Frameworkにおいて、スマートコントラクトは、開発者がリクエストに応じて動的にコントラクトを呼び出し可能となるようにContract Handlerの実装によりもたらされる。それぞれの機能はコントラクト関数として定義される。Cross-chain smart contractは、この複数のチェーンのコントラクト関数の呼び出しを含むスマートコントラクトを指す。

そして、上記設計のサポートを可能にする以下のCross Frameworkを考えた。Cross Frameworkは、Cross-chain smart contractの開発およびこれに対するCross-chain Transactionのサポートを可能にするフレームワークである。フレームワークは、Cross-chain TransactionをサポートするためのCross Moduleとスマートコントラクトを提供するContract Moduleから構成される。Cross Moduleは、Cross-chain Transactionを実現するために必要なモジュールであり、IBCモジュールを介した他のチェーンとのアトミックコミットのためのプロトコルを実装するCross Handlerとそれらの状態を保持するストアから構成される。Contract Moduleは、スマートコントラクトを提供するContract Handler、それらの状態を保持するステイトストア（State Store）から構成される。

続いて、上述のCross Frameworkの設計手順について、（１）Cross-chain smart contract、（２）Cross-chain Transaction、（３）Atomic commit Protocolに項分けして説明する。

（１）Cross-chain smart contract
Cross-chain smart contractについて、（１―１）〜（１−２）に項分けして説明する。
（１−１）Contract Handler及びステイトストア
Contract Handlerには、複数のコントラクト関数を実装可能である。各コントラクト関数には、スマートコントラクトの状態を管理するためのステイトストアが与えられる。各関数は呼び出し引数や記述したロジックに従い、決定性のある状態遷移を行い、その状態をこのステイトストアに永続化する。ステイトストアはGet(K), Set(K,V), Delete(K)といった一般的なキーバリューストア（Key-Value Store）の操作をサポートする。Get(K)は、「Kで指定したキーに対応するバリューを返す」の意味である。Set(K,V)は、「Kで指定したキーに対してVで指定したバリューをセットする」の意味である。Delete(K)は、「Kで指定したキーと対応するバリューを削除する」の意味である。単一のチェーンにおいて逐次的にコントラクト関数を実行する場合には、これらの操作のたびに、もしくは関数の実行後にトランザクションによる変更をストアに反映すれば良いが、トランザクションが処理するコントラクト関数が複数チェーンに分散している場合、すべてのコントラクトの状態遷移をアトミックに行う必要がある。利用するアトミックコミットプロトコルにより異なるが、少なくとも１つのコントラクト関数の実行はPrepare状態に遷移する必要がある。つまり、そのようなコントラクトにおいては他の並行するトランザクションと競合する可能性が発生するため、トランザクションの直列化可能性を保つための仕組みがステイトストアに必要となる。Cross Frameworkでは、デフォルトのステイトストアの実装として各変更操作に対応するロックを取得する単純なストアを提供している。このストアは、各変更操作に対して以下のロックを取得するように構成することができる。

（１−２）Cross-chain calls
各チェーンにおいて、Contract Handlerで定義されたコントラクト関数は、それぞれ別のチェーンのコントラクト関数を呼び出し可能であり、これをCross-chain callsと定義する。これにより、Cross-chain Transactionにおいて、単に複数の関数をアトミックに実行できるだけでなく、チェーン間の価値の移転などといったより複雑なプロトコルを含むスマートコントラクトの開発が可能となる。

（２）Cross-chain Transaction
Cross-chain Transaction について、（２−１）〜（２−４）に項分けして説明する。
（２−１）Cross-chain Transactionは、IBC channelで接続されたチェーン間で実行可能な分散トランザクションである。Cross Frameworkでは、トランザクションにおけるデータの整合性を保証するために複数のアトミックコミットプロトコルをサポートし、またそれを実現するためのロックメカニズムを実装したステイトストアを提供している。トランザクションはユーザからリクエストを受けたチェーンがその内容を検証し、指定されたチェーンに対してコントラクト呼び出しリクエストを含むパケットを送信することで開始される。ユーザのトランザクション開始のリクエストを受け取るチェーンをInitiator chainと定義する。Initiator chainは、リクエストを受け取ると、指定された形式に従ってアトミックコミットのフローを実行する。例えば、アトミックコミットとして２層コミットを選択した場合、Initiator chainが２層コミットのコーディネータの役割を担い、ユーザのリクエストに含まれる各チェーンのコントラクト関数の呼び出しを行うとともに、その結果を管理し、最終的なコミットの可否を決定し、その決定を受け取った各パーティシパントチェーンがコミットもしくはアボートを行う。

（２−２）Cross-chain transactionの作成と検証
Cross-chain transactionを開始するために、ユーザは以下の（i）〜（iｖ）の要素を持つMsgInitiate を作成し、Initiator chainに提出する。
（i）Type
これはコミットフローの種別のことである。各コミットフローの詳細については、後述する。
（ii）Nonce
これはナンス値のことである。
（iii）Timeout
トランザクションが取り込むことが可能なBlock heightもしくはBlock timeの上限値のことである。
（iｖ）コントラクトトランザクション
これは、各コントラクトの呼び出し情報のことであり、以下の（iｖ-1）〜（iｖ-6）からなる構造体の配列となっている。
（iｖ-1）ChainID
このコントラクトトランザクションを処理するチェーンを示すIDのことである。
（iｖ-2）Signers
このコントラクトのトランザクション作成に承認が必要となるアカウントの配列のことである。
（iｖ-3）Call Info
コントラクトの識別子、関数名、引数などを含む呼び出し情報のことである。フォーマットはContract handlerの仕様に依存する。
（iｖ-4）State Constraint
このコントラクトが参照する状態、更新後の状態に対して制約をかけることを意味する。ただし、これはオプションであり、省略することもできる。
（iｖ-5）Return Value
このコントラクトの実行の戻り値のことである。ただし、これはオプションであり、省略することもできる。
（iｖ-6）Links
このコントラクトの実行時に参照される他のコントラクト呼び出し結果のことである。ただし、これはオプションであり、省略することもできる。

ここで、アカウントは、トランザクションの実行者を定義する概念である。アカウントが適切であるかは、トランザクションの内容に応じて検証される。トランザクションの検証ロジック、およびアカウントによる承認とその識別子の仕様はブロックチェーンやDLTごと様々である。
Cross Frameworkでは、トランザクションの開始の際にSigners （上述の（iｖ-2））で指定された全てのアカウントの承認が必要であるが、各アカウントの承認方法およびそれぞれの検証方法は任意のロジックを実装可能であり、利用するブロックチェーンやDLTに適した方法を選択することが推奨される。例えば、既存の実装としてCosmos-SDKのauth/StdTxの署名検証を用いたものがある。

MsgInitiate を受け取ったInitiator chainは、承認が必要な全てのアカウントにより、このCross-chain transactionが承認されたことを確認する必要がある。この検証フローには、以下に示すいくつかのパターンがある。
パターン１：アカウントが鍵を持つ場合、Initiator chainに対しMsgInitiate の提出とともに各アカウントによる署名を提出してそれを検証する。
パターン２：アカウントが鍵を持たない場合、Initiator chain上に提出されたMsgInitiate の提出により発行されたトランザクションを示すIDに対して、各アカウントが非同期に承認する。
パターン３：アカウントが鍵を持たない、かつ、Initiator chainにアクセスできない場合、各アカウントはContract Moduleを含むチェーンに対して承認を行い、その結果をパケットを経由してInitiator chain上で検証する。これはパーミッションドなチェーンに適したフローである。
上記のいずれかの方式で検証をした後にInitiator chainは、Type に従いアトミックなコミットを行うフローを開始する。コントラクトトランザクションに指定された各コントラクトのトランザクションを含めたパケットをそれぞれのチェーンのContract handlerに送信する。その際のコミットのフローの種類とそれぞれの詳細については、後述する（３）のアトミックコミットプロトコルの章で説明する。コミットフローの種類にかかわらず、MsgInitiate で宣言された各コントラクトの関数の実行が全て成功し、またState Constraint などの実行時の状態に対する制約がある場合は、それを満たす場合のみ全てのトランザクションがコミットされることが保証されている。

（２−３）State constraintsとSimulation
State constraintsは、トランザクションを実行する際の事前状態、事後状態、またはその両方に対して制約をかけるための機能である。この機能は、コントラクト関数の実行時に厳密な状態遷移を必要とする場合に役立つ。アプリケーションからコントラクト関数を実行するトランザクションをリクエストする際に、その処理を一度だけ実行することをより厳密に保証することができる。
Simulationはトランザクションの生成なしでコントラクトの実行を行うことができる機能である。これを利用してState constraintsで指定するための制約を生成することが可能である。Simulateのリクエスト時にStateConstraintType を指定することで制約として参照可能なステイトストアの状態を返信する。ユーザはMsgInitiate の作成時にこれをコントラクトトランザクションのStateConstraintに指定することでSimulation時の状態を利用した制約をトランザクションにかけることができる。

（２−４）LinkとCross-chain calls
上述のCross-chain callsで紹介したような他のContract handlerの外部のコントラクト関数を呼び出すには以下の要素a〜ｃを考慮する必要がある。
a. 各Contract Handlerのコントラクト関数はそれぞれのチェーン上で並行して実行される場合がある。
b. 外部のコントラクト関数の実行はその呼び出し元の関数の実行とアトミックに行われる必要がある。
c. 外部のコントラクト関数の実行による返り値を呼び出し元関数で参照できる。
これらのうち、a, bはアトミックコミットプロトコルにより実現される。Linkは前記のcの要素を満たすための機能である。
Linkは以下の構造を持つ。
type Link struct {
SrcIndex uint8
}
SrcIndex により、呼び出し先のコントラクト関数の実行を処理するトランザクションを示すコントラクトトランザクションのインデックスを指定する。
MsgInitiate を受け取ったInitiator chainは、コントラクトトランザクションの各要素のLinkの情報を呼び出し先のコントラクト関数のChainIDと返り値を含むオブジェクト ConstantValueObject として解決し、Linkの参照元のコントラクト関数内の外部呼び出しはこのConstantValueObject に置き換えられる。
そして、以下のようなステップ１〜３で実行される。
ステップ１：Contract Handlerの外部コントラクトを参照する関数は呼び出し情報に加え、参照先チェーンを示すChainID を設定する必要がある。これはChannelIDやInterchain DNSのドメインネームなどで実装される。
type ChainID interface {
Equal(ChainID) bool
}
ステップ２：Initiator chainは、コントラクトトランザクションの各要素のLinks の情報を元に呼び出し先のコントラクト関数のChainIDと返り値を含むオブジェクトConstantValueObject として解決する。
type ConstantValueObject struct {
ChainID ChainID
Value []byte
}
ステップ３：Initiator chainは、アトミックコミットフローに従い、コーディネータとしてコントラクトトランザクションとステップ２のConstantValueObject および参照先の呼び出し情報をパケットのデータとしてセットし、各チェーンのContract handlerに送信する。
ステップ４：チェーンのContract handlerは、受け取ったパケットの呼び出し情報に従い、コントラクト関数を実行する。関数内の外部コントラクト関数の呼び出し時に、プログラム中の参照先のChainIDおよび呼び出し情報と比較し、一致している場合、ConstantValueObject のValue を返す。一致していない場合、その関数の処理は失敗となる。

（３）アトミックコミットプロトコル
アトミックコミットプロトコルは、複数の操作の集合を１つの処理として実行可能にするプロトコルであり、代表的なものとして例えば２層コミット及び３層コミットが用いられる。Cross Frameworkでは、Simple commit protocol, Two-phase commit protocolの2種類のプロトコルを用いることができる。Simple commit protocolはパーティシパントが2つに限られる。Two-phase commitはパーティシパントが3つ以上であってもサポートすることができる。

Two-phase commit protocol, Simple commit protocol についてそれぞれ以下の（３−１）,（３−２）で詳細に説明する。
（３−１）Two-phase commit protocol
２層コミット(2PC)では、あるチェーンをコーディネータとして、他のコントラクト関数の実行とコミットを行うチェーン群をパーティシパントとして次のようなフローでコミット、もしくはアボート状態に至る。コーディネータがパーティシパントにコミット準備を要求し、すべてのパーティシパントが成功した場合には、全パーティシパントにコミット要求を出す。コミット準備に１人でも失敗した場合には、全パーティシパントにアボート要求を出す。

図１を参照しながら、コミットのフローを説明する。同図において、Xはコーディネータ, A, B, Cは各パーティシパント,矢印はフローの各ステップのリクエストの向きを示している。
ステップ１：Initiate step
ユーザは、トランザクション開始のリクエストである“MsgInitiate”をInitiator chainに提出する。Initiator chainは２層コミットのコーディネータとして“MsgInitiate”に指定されたコントラクトの関数を含むパーティシパントチェーンに“Prepare”を要求するパケットである“PacketPrepare”を送信する
ステップ２：Prepare step
各パーティシパントチェーンは、“PacketPrepare”を受け取ると、上述の「（２−２）Cross-chain transactionの作成と検証」で説明したコントラクトトランザクションで指定されるコントラクト関数を実行する (ただし、この際に実際のコミットはされていない)。実行に成功した場合、ステイトストアに対しての変更操作の保存と変更対象へのロックを取得する。このロックメカニズムの詳細は、上述の「（１−１）Contract Handler及びステイトストア」で説明したから、説明を繰り返さない。最後にパケット“PacketPrepareAcknowledgement”の“Status”に成功を示す“PREPARE_RESULT_OK”を
セットして返す。
一方、実行に失敗した場合、変更操作を破棄して、パケット“PacketPrepareAcknowledgement”の“Status”に失敗を示す“PREPARE_RESULT_FAILED”をセットして返す。
ステップ３：Confirm step
コーディネータチェーンは、Prepare step（ステップ２）において各パーティシパントチェーンが送信するACK“PacketPrepareAcknowledgement”を受け取る。各ACKの処理については、以下の１〜３のような状態遷移を行う。
1. 次のACKの受信待ち
2. 受信したACKの“Status”が“PREPARE_RESULT_OK”かつ未受信のACKがある場合、１に遷移する。すべて受信した場合、各パーティシパントチェーンにコミット要求をするために“PacketCommit”の“Status”に”COMMIT”をセットして送信し、ステップ４のCommit stepに進む。
3. 受信したACKの“Status”が“PREPARE_RESULT_FAILED”の場合、各パーティシパントチェーンにアボート要求をするために“PacketCommit”の“Status”に“ABORT”をセットして送信し、ステップ４のCommit stepに進む
ステップ４：Commit step
各パーティシパントチェーンは、コミット要求があった場合、Prepare step（ステップ２）で保存していた変更操作をステイトストアに適用し、ロックを削除してコーディネータチェーンに完了済みを示す“PacketCommitAcknowledgement”を送信する。各パーティシパントチェーンは、アボート要求があった場合、Prepare step（ステップ２）で保存していた変更操作とロックを削除してコーディネータチェーンに完了済みを示す“PacketCommitAcknowledgement”を送信する。

（３−２）Simple commit protocol
このSimple commit protocolは、パーティシパントの数に対する制約があるアトミックコミットのプロトコルである。２層コミットとは異なり、パーティシパントは2つに制限され、またそれらのどちらか一方がコーディネータの役割を担う必要がある。
図２を参照しながら、コミットのフローを説明する。
ステップ１：Initiate
ユーザは、Cross-chain transactionを開始するために“MsgInitiate”をInitiator chainに提出する。このSimple commit protocolのフローでは、Initiator chainはコーディネータとパーティシパントの役割を兼ねる。
ステップ２： Prepare(A)
Aは“MsgInitiate”で指定されたコントラクト関数をPrepare実行する。実行に成功した場合、ステイトストアに対しての変更操作の保存と変更対象へのロックを取得する。このロックメカニズムの詳細は、上述の「（１−１）Contract Handler及びステイトストア」で説明したから、説明を繰り返さない。その後、Bのコントラクト関数の呼び出し情報を含む、パケット“PacketDataCall”を作成しBとのチャンネルに送信する。実行に失敗した場合、このトランザクションの処理をアボートして終了する。
ステップ３： Commit(B)
Bは“PacketDataCall”を受け取り、指定されたコントラクト関数を実行する。実行に成功した場合、Commitを行う。その後、“PacketCallAcknowledgement“に“Status”として“COMMIT_OK”をセットして、Aとのチャンネルに送信する。実行に失敗した場合、アボートを行う。その後、“PacketCallAcknowledgement”に“Status”として“COMMIT_FAILED”をセットして、AとのChannelに送信する。
ステップ４：Commit(A)
Aは“PacketCallAcknowledgement”を受け取り、その“Status”を確認する。“Status”が“COMMIT_OK”の場合、AはPrepare時に保存していた変更操作をステイトストアに適用し、ロックを削除する。“Status”が“COMMIT_FAILED”の場合、AはPrepare時に保存していた変更操作を破棄し、ロックを削除する。

本発明によれば、２way-pegのように、例えば、資金側で証券側のルール等がチェックできないため、再度証券トークン側でチェックした際に、他の取引と競合して取引が不成立になるなどの問題を回避することができる。

コミットのフローである。コミットのフローである。スマートコントラクトを実行するフローである（第１実施形態）。模擬コードの模式図である（前半）。模擬コードの模式図である（後半）。模擬コードの模式図である。スマートコントラクトを実行するフローである（第３実施形態）。

（第１実施形態）
上記解決手段で説明した設計思想に基づく本発明の取引システムの一実施形態について、図３を参照しながら説明する。図３は、証券取引のシーケンスフロー（言い換えると、スマートコントラクトを実行するフロー）である。

本実施形態の取引システムは、ブロックチェーンとしての証券チェーン１１（第１のブロックチェーンに相当する）と、ブロックチェーンとしての決済チェーン１２（第２のブロックチェーンに相当する）とを含む。コーディネータ１１b（コーディネータ部に相当する）、パーティシパント１１c（第１ユーザ部に相当する）は証券チェーン１１側に配設され、パーティシパント１２c（第２ユーザ部に相当する）は決済チェーン１２側に配設される。本実施形態では、二人のユーザー(以下ユーザーA、Bとする)間において、証券チェーン上でユーザーAからユーザーBへ１００口の証券トークンが移転され、決済チェーン上でユーザーBからユーザーAへ１０万円分の決済トークンが移転される指図としている。その際に、証券チェーン１１及び決済チェーン１２間のアトミック性を持つ安全なスマートコントラクトの呼び出しが可能なフレームワークが提供される。

コーディネータ１１b、パーティシパント１１c、パーティシパント１２c、リレイアー１３はそれぞれコンピュータにより実現され、コーディネータ１１b、パーティシパント１１c、パーティシパント１２cは分散型のネットワークを構成している。コーディネータ１１ｂ及びパーティシパント１１ｃ,１２ｃは互いに、リレイアー１３を介して交信する。なお、ユーザーA及びBはそれぞれパーティシパント１１c及びパーティシパント１２cに対応している。

コーディネータ部１１ｂは層構造としてIBC Module及びCross Moduleを備える。

パーティシパント１１ｃは層構造としてIBC Module、Cross Module、Contract Moduleを備えている。証券チェーン１１側のContract Module を構成するContract Handlerには証券トークンの発行コントラクト、移転コントラクトが定義されている。模擬コードを前半と後半に分けてそれぞれ図４Ａ及び図４Ｂに示す。パーティシパント１２ｃは、パーティシパント１１ｃと同様に、層構造としてIBC Module、Cross Module、Contract Moduleを備えている。決済チェーン１２側のContract Module を構成するContract Handlerには、決済トークンの発行コントラクト、移転コントラクトが定義されている。模擬コードを図５に示す。

スマートコントラクトが実行される前提として、以下の処理が行われているものとする。証券チェーン１１上で、ユーザーAからユーザーBへの証券トークンを移転するために呼び出すコントラクト関数(図４Aにおけるtransfer)並びに、決済チェーン１２上で、ユーザーBからユーザーAへの決済トークンを移転するために呼び出すコントラクト関数(図５におけるtransfer)を引数にもつトランザクション(MsgInitiate)が作成され、コーディネータ１１bに送信される。以上の処理が実行されていることを前提として、以下のシーケンスフローは実行される。本シーケンスフローは、主として「準備フェーズ」及び「コミットフェーズ」からなる二つのフェーズに分割することができる。

コーディネータ１１bは、受信したトランザクション(MsgInitiate)を確認してトランザクションの形式に問題がないか検証する。（ステップS１）。一つでも問題があった場合は、トランザクションを直ちに破棄して、処理を終了する。問題がない場合は、処理はステップS２に進む。

コーディネーター１１bは、検証したトランザクション(MsgInitiate)に基づきパケット（PacketPrepare）を作成し、リレイアー１３を経由して証券チェーン１１のパーティシパント１１c及び決済チェーン１２のパーティシパント１２cに送信する（ステップS２、ステップS３）。このパケット（PacketPrepare）が請求項１に記載の「第１のパケット」に相当する。

証券チェーン１１のパーティシパント１１cは、リレイアー１３経由で受信したパケット(PacketPrepare)を確認して、１００口の証券トークンをユーザーAからユーザーBに移転することができるか否かを検証する（ステップS４）。具体的には、受け取ったパケット(PacketPrepare)内で指定されているコントラクト関数を実行する(この際、実際にコミットはされないことに注意する)。

実行に失敗した場合、変更操作を破棄して、証券チェーン１１のコーディネータ１１ｂに対して、パケット（PacketPrepareAcknowledgement）の“Status”に“PREPARE_RESULT_FAILED”をセットして（言い換えると、“Status”を実行不可にセットして）リレイアー１３を介して送信する（ステップS６、S１０）。ここで送信されるパケット（PacketPrepareAcknowledgement）が請求項１に記載の「第３のパケット」に相当する。実行に成功した場合、自身のステイトストアへの変更操作の保存と変更対象へのロックを取得する（ステップS５）。ロックを取得できた後に、証券チェーン１１のコーディネータ１１ｂに対して、パケット（PacketPrepareAcknowledgement）の“Status”に “PREPARE_RESULT_OK”をセットして（言い換えると、“Status”を実行可能にセットして）リレイアー１３を介して送信する（ステップS６、S１０）。ここで送信されるパケット（PacketPrepareAcknowledgement）が請求項１に記載の「第２のパケット」に相当する。

決済チェーン１２のパーティシパント１２cは、リレイアー１３経由で受信したパケット(PacketPrepare)を確認して、証券トークンの対価として１０万円分の決済トークンをユーザーBからユーザーAに移転することができるか検証する（ステップS７）。具体的には、受け取ったパケット(PacketPrepare)内で指定されているコントラクト関数を実行する(この際、実際にコミットはされないことに注意する)。

実行に失敗した場合、変更操作を破棄して、証券チェーン１１のコーディネータ１１ｂに対して、パケット（PacketPrepareAcknowledgement）の“Status”に“PREPARE_RESULT_FAILED”をセットして（言い換えると、“Status”を実行不可にセットして）リレイアー１３を介して送信する（ステップS９、S１０）。ここで送信されるパケット（PacketPrepareAcknowledgement）が請求項１に記載の「第５のパケット」に相当する。実行に成功した場合、自身のステイトストアへの変更操作の保存と変更対象へのロックを取得する（ステップS８）。ロックを取得できた後に、証券チェーン１１のコーディネータ１１ｂに対して、パケット（PacketPrepareAcknowledgement）の“Status”に“PREPARE_RESULT_OK”をセットして（言い換えると、“Status”を実行可能にセットして）リレイアー１３を介して送信する（ステップS９、S１０）。ここで送信されるパケット（PacketPrepareAcknowledgement）が請求項１に記載の「第４のパケット」に相当する。

上述の処理によって、コーディネーター１１bは、パケット（PacketPrepareAcknowledgement）を各パーティシパント（本実施形態では、パーティシパント１１ｃ、１２ｃ）から受け取る。

コーディネーター１１bは、受け取ったパケット（PacketPrepareAcknowledgement）を確認して（ステップS１１）、“Status”に応じて以下の処理を行う。すなわち、「Status＝PREPARE_RESULT_FAILED」のパケットを一つでも受け取った場合には、アボート要求をするためにステップS１２に進む。すべてのパーティシパント（本実施形態では、パーティシパント１１c、１２c）から「Status＝PREPARE_RESULT_OK」のパケットを受信した場合には、コミット要求をするためにステップS１２に進む。

コミットフェーズはステップS１２から開始される。ステップS１２において、アボート要求を行う際には、パケット(PacketCommit)を作成し、“Status”を“ABORT”に設定して、全てのパーティシパント（本実施形態では、パーティシパント１１c、１２c）にリレイアー１３を介してマルチキャストする（ステップS１３、S１４、S１６）。このアボート要求を行うためのパケット(PacketCommit)が請求項１に記載の「第７のパケット」に相当する。ステップS１２において、コミット要求を行う際には、パケット(PacketCommit)を作成し、“Status”を“COMMIT”に設定して、全てのパーティシパント（本実施形態では、パーティシパント１１c、１２c）にリレイアー１３を介してマルチキャストする（ステップS１３、S１４、S１６）。このコミット要求を行うためのパケット(PacketCommit)が請求項１に記載の「第６のパケット」に相当する。

ステップS１４において、パーティシパント１１cは、受信したパケット(PacketCommit)のStatusが“COMMIT”である場合、準備フェーズで保存していた変更操作をステイトストアに適用し、ロックを削除してコーディネータ１１ｂに完了済みを示すパケット(PacketCommitAcknowledgement)を送信する（ステップＳ１５，Ｓ１８）。
このコミット時に送信されるパケット(PacketCommitAcknowledgement)が、請求項１に記載の「第８のパケット」に相当する。

一方、受信したパケットの“Status”が“ABORT”である場合、準備フェーズで保存していた変更操作とロックを削除してコーディネータ１１ｂに完了済みを示すパケット(PacketCommitAcknowledgement)を送信する（ステップＳ１５，Ｓ１８）。このアボート時に送信されるパケット(PacketCommitAcknowledgement)が、請求項１に記載の「第９のパケット」に相当する。
ステップS１６及びＳ１７において行われる処理はそれぞれ、ステップＳ１４及びＳ１５において行われる処理と同様であるから、詳細な説明を省略する。

このように、本実施形態によれば、証券チェーン１１のパーティシパント１１c及び決済チェーン１２のパーティシパント１２cのそれぞれに実現可能性を問い合わせており、双方で実現可能性が確認できた場合にだけ、複数チェーンでのコントラクト関数の呼び出し結果をコミットする。したがって、２way-pegのように、資金側で証券側のルール（例えば、譲渡人数が上限に達していないか、移転先のユーザーはKYC済かなど）等がチェックできないため、再度証券チェーン側でチェックした際に、他の取引と競合して取引が不成立になるなどの問題を回避することができる。

（第２実施形態）
上述の第１実施形態で説明した処理は、取引のアトミック性が求められる他の取引（例えば、遺言信託）にも用いることができる。この場合、証券チェーン１１を相続チェーン（第１のブロックチェーンに相当する）、決済チェーン１２を資産チェーン（第２のブロックチェーン）と読み替えて、遺言信託の取引に適用することができる。

被相続人は、信託会社に遺言書や資産を提示して、これが相続チェーン上にスマートコントラクトして登録される。従来は、被相続人が死去した場合に、相続人から信託会社に連絡が入り、信託会社は資産管理会社に資産を問い合わせて、遺言を実行できるか否かを確認しなければならなかった。

本実施形態では、相続チェーン上に登録された遺言書に基づく資産の移動が可能かどうかを資産チェーンに問い合わせる際に、アトミック性が担保されているため、２way-pegを用いる場合と異なり、遺産分割の条件に当てはまらず、覆って遺産分割が不可能になるなどのチェックを行う必要がなくなる。また、信託会社は、遺言内容の執行と資産分割履行の双方の実行結果を確認することができる。

（第３実施形態）
図６のフローチャートを参照しながら、本発明の第３実施形態について説明する。本実施形態は、コーディネータ１１ｂ及びパーティシパント１１ｃが行う処理を、兼用部１１ｂｃが行う点で第１実施形態と相違する。その結果、一方のパーティシパントはコミット準備を省略することができる。また、第１実施形態と同様に、証券取引を例にして本実施形態の処理を説明する。ただし、本実施形態で説明した処理は、取引のアトミック性が求められる他の取引（例えば、遺言信託）にも用いることができる。この点については、第２実施形態に詳細を記載しているから、説明を省略する。本実施形態の取引システムは、一方のパーティシパントのコミット準備を省略することができるコミット方式(Simple Commit protocol)に基づき設計されている。このコミット方式は、パーティシパントの数が２つに制限されている点で、第１実施形態の２層コミットと相違する。また、いずれかのパーティシパントがコーディネータの役割を担う。

兼用部１１bｃはコンピュータにより実現される。兼用部１１ｂｃ及びパーティシパント１２cは分散型のネットワークを構成している。兼用部１１ｂｃ及びパーティシパント１２ｃは互いに、リレイアー１３を介して交信する。

ステップＳ１０１の前に行う処理は、第１実施形態と同じであるから、説明を繰り返さない。ステップＳ１０１において、兼用部１１ｂｃは、受信したトランザクション(MsgInitiate)を確認してトランザクションの形式に問題がないか検証する。一つでも問題があった場合は、トランザクションを直ちに破棄して処理を終了する。

ここで、本実施形態では、兼用部１１ｂｃがコーディネータとパーティシパントとの役割を兼用しているため、このタイミングで、１００口の証券トークンをユーザーAからユーザーBに移転可能かをパーティシパントとして検証する（ステップS１０２）。

具体的には、受け取ったトランザクション(MsgInitiate)内で指定されているコントラクト関数を実行する(この際、実際にコミットはされないことに注意する)。実行に失敗した場合、このトランザクションの処理をアボートして終了する。

実行に成功した場合、兼用部１１ｂｃは、パーティシパントとして自身のステイトストアへの変更操作の保存と変更対象へのロックを取得する（ステップS１０３）。ロックを取得できた後に、決済チェーンのコントラクト関数の呼び出し情報を(本実施形態では、決済チェーン上での10万円分の決済トークンをユーザーBからユーザーAへ移転するために呼び出すコントラクト関数)含むパケット(PacketDataCall)を作成し、パーティシパント12Cに送信する（ステップS１０４，S１０５）。このパケットが、請求項５に記載の「第１のパケット」に相当する。

ステップS１０６において、パーティシパント１２ｃは、パケット(PacketDataCall)を受け取り、指定されたコントラクト関数を実行する。実行に成功した場合、コミットを行う（ステップS１０７）。その後、パケット(PacketCallAcknowledgement)の“Status”に“COMMIT_OK”をセットして兼用部11bcに送信する（ステップS１０８，S１０９）。このコミット時に兼用部１１ｂｃに送信するパケット(PacketCallAcknowledgement)が、請求項５に記載の「第２のパケット」に相当する。実行に失敗した場合、アボートを行う。その後、パケット(PacketCallAcknowledgement)の“Status”に“COMMIT_FAILED”をセットして兼用部11bcに送信する（ステップS１０８，S１０９）。このアボート時に兼用部１１ｂｃに送信するパケット(PacketCallAcknowledgement)が、請求項５に記載の「第３のパケット」に相当する。

兼用部１１ｂｃは、パーティシパントが行う処理として、パーティシパント１２ｃから受信したパケット(PacketCallAcknowledgement)を確認し、“Status”がCOMMIT_OKならコミットする(保存していた変更操作をステイトストアに適用し、ロックを削除する)。“Status”がCOMMIT_FAILEDならアボートする(保存していた変更操作とロックを削除する)。

このように、本実施形態によれば、証券チェーン１１及び決済チェーン１２において取引のアトミック性が担保されている。したがって、２way-pegのように、資金側で証券側のルール（例えば、私募に限定）等がチェックできないため、再度証券トークン側でチェックした際に、他の取引と競合して取引が不成立になるなどの問題を回避することができる。

（第３実施形態の変形例）
本実施形態では、証券チェーン１１側のパーティシパントにコーディネータとしての役割を担当させたが、決済チェーン１２側のパーティシパント１２ｃにコーディネータとしての役割を担当させてもよい。本実施形態を遺言信託のユースケースに適用する場合には、相続チェーン側に兼用部１１ｂｃ、資産チェーン側にパーティシパント１２ｃを実装することができる。ただし、相続チェーン側にパーティシパント１２ｃ、資産チェーン側に兼用部１１ｂｃを実装してもよい。

１１証券チェーン、相続チェーン
１１ｂコーディネータ
１１ｃ、１２ｃパーティシパント
１２決済チェーン、資産チェーン
１３リレイアー

Claims

第１のブロックチェーンと第２のブロックチェーンとの間で取引に関わるスマートコントラクトをアトミックに実行するための取引システムであって、
前記第１のブロックチェーン側のコーディネータ部及び第１ユーザ部と、
前記第２のブロックチェーン側の第２ユーザ部と、
を有し、
前記コーディネータ部は、コントラクト関数が指定された所定のトランザクションに基づき作成した第１のパケットを前記第１及び第２ユーザ部に送信し、
前記第１ユーザ部は、前記コーディネータ部から受信した前記第１のパケットのコントラクト関数の実行に成功した場合には、自身のステイトストアへの変更操作の保存と変更対象へのロックを取得して、ステータスを実行可能にした第２のパケットを前記コーディネータ部に送信し、実行に失敗した場合には、自身のステイトストアへの変更操作を破棄して、ステータスを実行不可にした第３のパケットを前記コーディネータ部に送信し、
前記第２ユーザ部は、前記コーディネータ部から受信した前記第１のパケットのコントラクト関数の実行に成功した場合には、自身のステイトストアへの変更操作の保存と変更対象へのロックを取得して、ステータスを実行可能にした第４のパケットを前記コーディネータ部に送信し、実行に失敗した場合には、自身のステイトストアへの変更操作を破棄して、ステータスを実行不可にした第５のパケットを前記コーディネータ部に送信し、
前記コーディネータ部は、前記第１及び第２ユーザ部から受信したパケットの実行可否検証結果を元に、全てのパケットのステータスが実行可能な場合にはコミット要求を行うため第６のパケットを前記第１及び第２ユーザ部に送信し、少なくとも１つのパケットのステータスが実行不可の場合にはアボート要求を行うため第７のパケットを前記第１及び第２ユーザ部に送信し、
前記第１及び第２ユーザ部は、前記コーディネータ部から前記第６のパケットを受信すると、事前に保存していた変更操作をステイトストアに適用し、ロックを削除して第８のパケットを前記コーディネータ部に送信し、前記コーディネータ部から前記第７のパケットを受信すると、事前に保存していた変更操作とロックを削除して第９のパケットを前記コーディネータ部に送信することを
特徴とする取引システム。
前記コーディネータ部と、前記第１及び第２ユーザ部との交信を仲介するリレイアーを有することを特徴とする請求項１に記載の取引システム。
前記第１のブロックチェーンは証券チェーンであり、前記第２のブロックチェーンは決済チェーンであることを特徴とする請求項１又は２に記載の取引システム。
前記第１のブロックチェーンは相続チェーンであり、前記第２のブロックチェーンは資産チェーンであることを特徴とする請求項１又は２に記載の取引システム。
第１のブロックチェーンと第２のブロックチェーンとの間で取引に関わるスマートコントラクトをアトミックに実行するための取引システムであって、
前記第１のブロックチェーン側に設けられるコーディネータ部及び第１ユーザ部を兼用する兼用部と、
前記第２のブロックチェーン側の第２ユーザ部と、
を有し、
前記兼用部は、コントラクト関数が指定された所定のトランザクションの実現が可能な場合には、前記第１ユーザ部として自身のステイトストアへの変更操作の保存と変更対象へのロックを取得して、前記第２ユーザ部のコントラクト関数の呼び出し情報を含む第１のパケットを前記第２ユーザ部に送信し、実現が不可能な場合には、処理を終了し、
前記第２ユーザ部は、前記兼用部から受信した前記第１のパケットに基づき、コントラクト関数を実行し、実行に成功した場合にはコミットを行うとともに、ステータスを実行可能にした第２のパケットを前記兼用部に送信し、実行に失敗した場合にはアボートを行うとともに、ステータスを実行不可にした第３のパケットを前記兼用部に送信し、
前記兼用部は、前記第２ユーザ部から前記第２のパケットを受信した場合には、前記第１ユーザ部として事前に保存していた変更操作をステイトストアに適用し、ロックを削除し、前記第２ユーザ部から前記第３のパケットを受信した場合には、前記第１ユーザ部として事前に保存していた変更操作を破棄し、ロックを削除することを特徴とする取引システム。
前記兼用部と、前記第２ユーザ部との交信を仲介するリレイアーを有することを特徴とする請求項５に記載の取引システム。
前記第１のブロックチェーンは証券チェーン及び決済チェーンのうちいずれか一方のチェーンであり、前記第２のブロックチェーンは他方のチェーンであることを特徴とする請求項５又は６に記載の取引システム。
前記第１のブロックチェーンは相続チェーン及び資産チェーンのうちいずれか一方のチェーンであり、前記第２のブロックチェーンは他方のチェーンであることを特徴とする請求項５又は６に記載の取引システム。