# YP完成版の清書に関して攻撃を考える

## ユーザー => オペレーター
### DoS系
- Txの中のZKPのProofと見せかけて、めちゃくちゃデカいバイト列を送ってくる
- 対策: 前段のnginxとかでxxMBでstatus code: 413 Payload too large等を返す?

- ZKPのVerifyに時間がかかるProofを生成し送りつけてくる
- 疑問: そもそもそんなProofは生成できないかも？
- 対策:

- User State Updateと見せかけて、偽のProofをバンバン投げてくる
- 対策: ダメなProofのハッシュ値をdenylistに入れておく？

- validなspam txを大量に投げてくる
- 対策: クライアントサイドZKPが必要なので、攻撃側も結構コストがかかるはず(?)

- hash衝突させて自分のstate rootを都合よく書き換えてくる
- 疑問: 自分に都合のいいstateを生成しつつ、hash衝突させるのはほぼほぼ不可能？

### フロントランニング系
- SRUのバッチのコミットを他人がフロントランニングしてくる
- 対策: onlyOwnerとか？

## オペレーター => オペレーター
### ln系

- lnコミュニティから嫌われて誰にチャネルを開いてもcloseされ、実質的にln払いが不可能に
- 対策:

## オペレーター　=> ユーザー

### 検閲系
- txの検閲をして、任意のtxを入れない
- レシート要求してもくれない
- User State Updateはfeeとかないので、無視してくる
- 対策: 最初はオペレーターは自分たちでやるので問題ない。今後も1人でもいればいいので問題ない。
- 実際の値より、大きかったり小さいstate diffを渡してくる
- 対策: ZKPでstate diffを束縛する

## オペレーター => L1

### Pre commit
- 嘘をついて偽Proofを提出してくる
- 対策: スラッシュもある。そしてmain commitまではexitできないので大丈夫。
- 課題1: finalizeが遅いので対面の支払いとかには向かない。(Bitcoinとかでもだけど)
- 課題2:

## 本当にzkRUなの？
ちょっと別の攻撃だけど、口撃されそう。
- Validiumじゃね？
　　- 対策: 自分のStateは自分で管理すれば部分的にexit可能だからいいんじゃね？

- コントラクトに預けてる資産どうなるの？
- 対策:
-

## 激ヤバ系の攻撃
### ZKPがガバガバになるProofの発明がされる
- 普通のブロックチェーンはECDSA, EDDSAが署名アルゴリズムとして使われている
- それの強度がセキュリティになっている
- しかし、今回の場合はその署名検証をZKPによって圧縮してしまっているので、オペレーターはtxの署名の検証はしない
- よって、ZKPの強度がセキュリティになっている

### user state rootのhash値がセキュリティになっている
- 普通のブロックチェーンは偽のinclusion proofを投げられたとしても、自身のストレージにあるマクパトで検証可能である。
- しかし、IntMaxではuser stateを秘匿するため、オペレーターにuser state root以外を知られることはない
- 何らかの方法で、onetime addressとかはそのままで、自分のERC20の残高を増やし、ハッシュ値の衝突をできるようになれば好きなように資産を操れる。
- IntMaxが成り立つ仮定として、Poseidon(orその他のハッシュ)が衝突耐性がある必要がある