# LNでのFeeの支払いモデル案 ## 大体のモデル ```mermaid sequenceDiagram actor U as User participant O as Operator participant T as Totoro Network autonumber U --> O : Throw Tx data O --> O : Calc gas fee O --> U : Retern receipt, invoice, ticket U --> O : Pay Fee through LN O --> T : Execute Transaction ``` ### Lazy Operator ```mermaid sequenceDiagram actor U as User participant LO as Lazy Operator participant VO as Valid Operator participant T as Totoro Network participant F as Fund autonumber U --> LO : Throw Tx data LO --> LO : Calc gas fee LO --> U : Retern receipt, invoice, ticket U --> LO : Pay Fee through LN LO --> LO : Hold Tx T --> T : Process some blocks U --> VO : Throw Tx with ticket and payment proof VO --> T : Execute Tx T --> T : Process Tx and Check if Operator is lazy T --> F : Slash Lazy OP's stake F --> LO : Reduce Lazy OP's stake F --> VO : Transfer staking token(LN BTC?) ``` ## Invoice merkle rootをLeaderが提出する実装案(素案) - リーダー選出時に次のリーダー交代より前の有効期限のInvoiceのハッシュ、もしくはInvoicesのハッシュのマークルルートを先にネットワークに登録しておく？ - ユーザーはInvoiceとsiblingsをうけとって検証してから支払う - リーダーが変更されるまでの間それは有効(Invoice hashをTxに付加する) - PreimageとInvoiceと公開鍵がそろっていることを証明 - 課題点としてはいつに支払われたかわからない点 (リーダーがへんこうされた後にも処理されていない場合はproofできるようにする？) - ユーザーがリーダー交代まで支払いわないリスクにどうたいしょするか？ - SMT(Invoice hash, Transction ID)を更新 ```mermaid sequenceDiagram actor U as User participant O as Operator participant T as Totoro Network autonumber O --> T : Submit Invoice Merkle root U --> O : Throw Tx data O --> O : Calc gas fee O --> U : Retern receipt, invoice, siblings U --> U : Validate Invoice U --> O : Pay Fee through LN O --> T : Execute Transaction with invoice hash T --> T : Update Used Invoice SMT(Invoice hash, Transction ID) ``` Lazy Operator ```mermaid sequenceDiagram actor U as User participant O as Operator participant NO as Next Operator participant T as Totoro Network participant F as Fund autonumber O --> T : Submit Invoice Merkle root U --> O : Throw Tx data O --> O : Calc gas fee O --> U : Retern receipt, invoice, siblings U --> U : Validate Invoice U --> O : Pay Fee through LN O --> O : Hold Tx O --> NO : Leader Changed NO --> T : Submit Invoice Merkle root U --> NO : Submit Tx, Invoice hash, siblings, preimage, Operator's pubkey NO --> T : Execute Tx NO --> T : Check if Operator is lazy T --> F : Slash Lazy OP's stake F --> O : Reduce Lazy OP's stake F --> NO : Transfer staking token(LN BTC?) ``` ## Invoice merkle rootをLeaderが提出する実装案(FundがL1に存在する場合) Lazy Operator ```mermaid sequenceDiagram actor U as User participant O as Operator participant NO as Next Operator participant T as Totoro Network participant F as L1 Chain autonumber O --> F : Stake ETH(?) NO --> F : Stake ETH(?) O --> F : Submit Invoice Merkle root U --> O : Throw Tx data O --> O : Calc gas fee O --> U : Retern receipt, invoice, siblings U --> U : Validate Invoice U --> O : Pay Fee through LN O --> O : Hold Tx O --> F : L1 Commit (including SMT hash) O --> NO : Leader Changed NO --> T : Submit Invoice Merkle root U --> NO : Submit Tx, Invoice hash, siblings, preimage, Operator's pubkey NO --> T : Execute Tx NO --> F : Check if Operator is lazy T --> F : Slash Lazy OP's stake F --> O : Reduce Lazy OP's stake F --> NO : Transfer ETH ``` ## セキュリティ ### Operator is lazy - TXを実行しない => 上記のように支払ったことのProofを提出すれば良い ### Operator is Malicious - 誤ったInvoiceを発行する => Merkle rootとあわないので大丈夫（この検証の責任はUserが持つ、すなわち間違ったInvoiceを検証しないで支払った場合は救済はない） - Feeを過大に請求される => Invoiceを確認して支払わない選択をすれば良い => ただし、正しいFeeのInvoiceがかならず請求されるわけではない - 使用済みInvoice Hash SMTを勝手に更新される => TxIDがValueとして入っているため、そのTXIDが存在しなければ良い ### User is Lazy - LNの支払いをしない => Preimageを保有していないのでProofが通らない - Operatorが交代してから支払い、Preimageを入手しようとする => Invoiceの有効期限が切れているのでしはらいがFailする ## メリット - ZKEVM内と紐付かないでgasが支払われる => 殆どの処理をL1やLNに押し付けるので実装が容易＆constraints数が増えない (特にFundをL1上で処理している場合はSMTの更新しかL2に依存しないうえにRootは記録する) - User <=> Operator間の通信が増加しない - Feeの支払いが比較的明快 - 第三者による検証を必要としていない ## デメリット - 予めInvoiceを用意していないないといけないのでgasがフレキシブルにならない (あらかじめ決められた料金候補の中から選択される) - gasがEVMの実装されていないので、料金はOperatorの選択に依存する。 ## 攻撃手法メモ ### リーダー交代ギリギリにユーザーが支払うパターン 悪意のあるユーザーがオペレーターに対する嫌がらせとして次のようなことが考えられる。 invoiceのTTLギリギリに支払いをするがブロック生成には間に合わないので、txがブロックに入らずユーザーがtxを入れてくれなかったと異議申し立てができる。 #### 対策 invoiceのTTLをブロック生成終了のX秒前等余裕を持つことで回避できると思われる。 ### LN払いしたのにtxを提出しないパターン オペレーターがtxをブロックに入れることができず、オペレーターがスラッシュされてしまう。 #### 対策 見積もりの時にすでに受け取ってるので、2回目はtxの提出はしないのかも。feeがlnで着金次第逐次実行。 ### 安いtxで見積もりし安いinvoiceゲットし、別の手数料が高いtxを投げてくる #### 対策 SMTのvalueにtxhashを入れておくことによって対策できる。