Corda Privacy
WIP
Back-Chain Fetching on Corda
UTXO型であるため、TXにsignするためにはそのinputsが「正しい」ことを検証する必要がある
1. 不正な状態遷移によって生成されたUTXOではない
2. 二重支払いされたUTXOではない
1. の検証
そのUTXO Chainの過去全てのState遷移がContract Constraintsに従っているか
2. の検証
そのUTXO Chainの過去全てのState遷移にNotaryの署名が存在するか
この検証を行うためには 検証したいInputStatesの依存するTXを手元に持っていなければならない
しかし、Cordaは自身に関係のあるTxしか保持していないため、持っていないTxは保持している他のNodeに取りに行く必要がある
https://gyazo.com/c596803ff4068b09f8a2467b47f468c3
ここで上記のような場合を考える
Tx 02においてBobがTransactionのInitiator、CarolがResponderとする
この時、
BobはTx02を作成、signする際にInputにする CarolのSecureDeal Stateを検証する必要がある
CarolはこのDealStateを DaveからTransferされており(Tx 11)、DaveはElvinからIssue (Tx 10)されていたとする
BobはこのSecurityDeal Stateを検証するために、CarolからTx 11とTx10を共有してもらう必要がある
この時、Tx 02に全く関係がないDaveとElvinが過去に行ったTxの内容がBobに知られてしまう
Implementation of back-chain fetching
Corda Privacy Leak Problems
https://gyazo.com/7e41defdd614f5da08ff1c4dead60121
(1) 過去のTXを検証する際に、関係ないNodeの取引内容がleakしてしまう -> confidential Txで解決可能
(2) confidential Transactionを行ったとしても、取引相手には自Nodeがidentifyされているため、InputにしたStateの一つ前のTXのOutputsはバレてしまう (その取引に関係のないStateの情報を取引相手に与えてしまう) -> Merkle Proof で解決可能
(3) 相手にもっていないTxを取りにいくかどうかで、これまでそのTxに関わったか判明してしまい、プライバシーに問題がある
(4) identityが途中でかわったときに、遡及的検証時では結果が異なってしまう -> ?
参考 :
Responderが動かすReceiveFinalityFlowはdefaultでは StatesToRecord = ONLY_RELEVANT設定になっており、この設定だと、back-chain fetching時に共有されたStatesのうち、自分がparticipantsに含まれているStateしかVaultに保存しない
しかし、StatesToRecord = ALL_VISIBLEの設定にすると、back-chain fetching時にvisibleなstateを、自分がparticipantsでなくても、全てvaultに保存する
このため、保存されないから大丈夫という話ではない
豆知識 :
Observer Nodeに Stateを共有する ObserverAwareFinalityFlowでは、defaultの設定がStatesToRecord = ALL_VISIBLEになっている
Observer NodeはTxのparticipantsではないが、Stateを保存する必要があるため
Solutions 1 : Receipt Pattern
https://gyazo.com/8f2f17e108ce048815858b2c3d5ea477
上記のTxを例にする
Receipt Patternにおいては、そのTxのEnabler と Dependencies というStateの分類が存在する
上記のTxにおいては
Cashを送信することがAliceがBobからSecretDeal を貰う前提条件となるため
Enabler : Cash State
Dependencies : SecretDeal State
となる
Receiptsパターンでは、Cashの状態を直接含める代わりに、Cashの遷移が起こったことを確認するReceiptの状態を含める
https://gyazo.com/17e9e316992516296d14cf94264929d6
https://gyazo.com/ffc33c14a26d18023ee3f6025d4ed451
このようにReceiptをInputに含めるとCarolが訴求的検証で見れるStateの範囲は以下のようになる
https://gyazo.com/cb64f18e89391602f50099b9214f97f3
こうすると、Cashの過去のStateは見えてしまうが、SecretDealの過去のStateを見ることはできない
Etaro.icon > これ普通にAtomic性失われるのでは?
具体的にはBobがCashをCarolに送信した(この時点でCarolはCashを入手している)後に、BobはそのReceiptをinputにしてCarol のSecurityを自身に Transfer しようとするが、ことTx02にCarolの署名が必要であれば、Carolが署名しなければAtomic性が失われる
Etaro.icon > 結局、Enabler Stateの方の過去のState遷移は見えてしまう
Solutions 2 : Confidential Transaction (Token SDK)
端的にいうと「TXの度に毎回新しいAddressを発行してそれを使用する」
Corda 4.4 Update
Bulk back-chain fetching
訴求的検証を行う際に、自分の持っていないState を他のnodeにリクエストしに行くことをback chain fetching という
Corda 4.4 以前だと、一個ずつdependenciesを取得しに行っていたが、4.4ではこのdependenciesのrequestもsupplyもbulkで行えるようになった
node.conf で backchainFetchBatchSize = 1 のように記述することでbulkのsizeを自由に設定可能
Corda 4.3以前のnodeが混在してるnetworkでも、旧nodeは「1request, 1supply」で動作するだけなので互換性あり
Other Updates
References