# User Transaction に関するテスト設計

###### tags: `テスト設計`

[UserTransactionに関するYP](https://hackmd.io/z6OI1vBuTNCtbClE8qD59A#Transaction)

単一オペレータについて Genesis block でテスト用アカウントについてトランザクションが実行可能な設定を施した上でノードを起動する。Client(LN node + Wallet)側でTxを投げるテストを走らせて、各 response が正しいかを検証する。

## Tx検証

[ClientAlgortihm](https://hackmd.io/z6OI1vBuTNCtbClE8qD59A#Client-algorithm)に従い `make_tx` を実行する。この tx について、オペレータ側で次の検証が通るかテストする。また、それぞれ1ユーザについて2回行う。

### Client 側不正パターン

1. LatestTreeRoots が過去に存在しない trees root を使用した場合に失敗する。
- 存在しないルートを使用した不正
2. 同一の onetimeAddress で実行が失敗する。
- 重複 onetimeAddress を使用した不正
3. 各 zkProof(**verifySignedTx/verifyUserStateUpdate**) において publicInput の onetimeAddress が異なる場合に失敗する。
- 異なる署名を用いてTxを実行しようとする不正
4. 前回の stateUpdate を更新せずに実行した時に失敗する。
- stateDiff の更新を行わない不正
6. 各 zkProof それぞれについて、不適切な値を指定したときに失敗する。
- PrivateInput に不適切な値をいれる不正

--- Fee系 ---

5. Fee の支払いを行わなかった場合に、Tx が実行されない。

[その他のクリティカルな攻撃手法について](https://hackmd.io/bKiyiuBJSSCqNwxrPzTJCA#%E6%94%BB%E6%92%83%E6%89%8B%E6%B3%95%E3%83%A1%E3%83%A2)

### Operator 側不正パターン

1. 正しい Tx について誤った receipt が返却された時に、receipt の inclusion proof から不正であることを検証し別のオペレータ(または分散ストレージ)から正しい receipt の要求ができる。
- オペレータが不正な receipt を渡したパターン
2. Fee の支払を行ったのに withold されたとき、L1にて Operator の供託を奪う事ができる。
- オペレータが tx を実行しなかったパターン

### 両サイド不正パターン
これは L1 commit の zkVerify で弾かれるので L1 commit のテストで網羅する。

### 正常系
1. 正常な Tx について正しい receipt が返却されることを検証する。
- ex) ERC20 で A->B に 20 送金したときに、 {A: -20, B: +20} の内容が存在する。
- txHash, onetimeAddress or receiveAddress, diff の中身について正しいこを検証する。

## StateUpdate検証

[ClientAlgorithm](https://hackmd.io/z6OI1vBuTNCtbClE8qD59A#Client-algorithm1)に従い `make_state_diff` を実行する。この StateUpdate について、オペレータ側で次の検証が通るかテストする。

### Client側不正パターン
1. 存在しないdiffRootを指定したときに、失敗する。
- 不正なdiffをマージしようとする不正
2. stateDiffRoot について、昔のStateDiffRootを使った場合失敗する。
- 同一の stateDiff を二度マージしようとする不正
3. zkProof に異なる値を入れた場合失敗する。
- PrivateInput に不適切な値をいれる不正

### Operator側不正パターン
1. 正常な stateUpdate が無視された場合に、再度 stateUpdate を投げる。
2. 正常な stateUpdate の更新後、オペレータの latestRoots では更新が確認できるが L1 に刻まれている root とは異なる場合に、再度 stateUdpate を投げる。
- ユーザに見せるものだけごまかす不正。

### 正常系
1. 正常な stateUpdate の更新後、オペレータの latestRoots,optimistic Commit のルートまたは L1 commit のルートから更新後の userState の inclusionProofができる。

## Tx&StateUpdate実行(secenario)

複数のClinetから、失敗するTxも含めて並列で Tx が送られたときにそれぞれについて正しく Response が返ってくることをテストする。また、StateUpdate についても同様に並列で送り、それらが正しく適用されていることをテストする。