---
# System prepended metadata

title: LNでのFeeの支払いモデル案

---

# 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を入れておくことによって対策できる。




