# コミットメント周りなどでの不明点
## LN払いに関する点
- LNでの手数料まわりの話とデータストアとしての機能の話が分離していない感じがあって、整理が必要
- LN BTCをネットワークに反映させるのはむずかしい（Atomic Swapでもどこのアドレスに送金するかという問題があり、だれがwithdrawのときの相手先になるかなど問題があり、基本的には秘密鍵をioみたいな形式で保管できないと多分無理。
## データ更新に関する話
- データストア周りの話としてはcustomMessageでメッセージを送ってデータベースを更新していく？
=> シンプルにcustomMessageをタダで使ってネットワークにただ乗りするくらいでもいい気がする

- 手数料支払は結局gasを計算してそれを外部（Lightning Networkのinvoice）もしくは内部（L2のEVM）で行うという認識(ただしL1でOPが支払ってL2でInvoiceで支払う、という選択肢もある)
- リーダー選出アルゴリズムは分散型データストアの更新をスムーズにしてユーザーの利便性を高めるのが目的？（ここへの依存度が高すぎるとふつーに独自ネットワークを作ったときとGoxに関するセキュリティ（コンセンサスのセキュリティではない）が変わらない気がする）
=> 分散型ストレージとしての機能を無視して純粋にZK Networkとして機能することを優先とするならばProofをつくったオペレーターがL1にCommitするのと同時にデータ管理を行っているノード（OP含む）に対して全データとProofを渡して検証してValidであればデータを更新して各State Rootも更新、L1上のState Rootと一致していればValidなノード
（ただし悪意のある第三者がProofを提出して他のノードに渡さない攻撃も考えられるが、GlobalなState関連はCalldataに含めるため復元可能である）

- Light L1 Commitについては利点はユーザーがl1 Commitを待たずに自分でrollupすることでFinalityを確保できる
- 難点はLight L1 Commit自体のFinalityは僕たちの分散型ストレージのネットワークが保有する程度のセキュリティしか持たない(+OVM)
- もしL1 Light Commitに対してOptimisticにChallengeできるとしても今度は分散型ストレージのデータ更新がChallengeさえできればだれでも更新できる（これは良いのか？）感じになる上。上記のFinalityにかかるセキュリティの度合いが向上するわけではない。
**=> Light commitに関してはPoSの仕組みを導入することで攻撃は防げる！**