---
# System prepended metadata

title: 弊ネットワーク上でのFee支払い

---

# 弊ネットワーク上でのFee支払い

## 前提

1. L2上でUserとOPが同意すれば自由な資産をFeeとして利用することができる
2. なるべくEVMのカスタマイズは最小限にしたい
3. Fee支払いはなるべくOPとの契約という形式にとどめておき（なるべくチェーン内の実装からは切り離しておく）自由にできるようにしたい
4. ネットワーク外でかかる手数料は無視できるくらい小さくある必要がある
5. 対象ユーザーはLNを一切使用しない
6. LN利用ユーザーの利便性を一切損なわない

## 実装を切り離すことにおける難点

- Claimなどを他チェーンに回すと手数料の高さ（これはL1においたときに顕著である）や他チェーンへの依存やステークの必要性が発生する（これはL1以外のチェーンを利用した場合）
    => L1の利用やETH・BTC以外の利用は避けたい
    => われわれのL2でできるようにする
- 我々のL2上で手数料支払いをできるようにしたい
    => L2の
    
## 提案手法の概要

- 通常のTxに追加としてERC20送金データを添付できるようにする
- このデータはTxの実行に先立って任意のERC20を送金できるようにするもの
- この領域の中にFeeの支払いについて承認するZKProofを入れる
- このZKPはTx Payloadと同様にして署名者を明かさずに署名を検証する
- 利用するOneTimeAddressは親Txと同じものをつかう

$$ Signature = Sig(Hash(ParentTxHash + AssetID + Amount + Operator Address), UserPrivkey) $$

$$C_{verifySignedPayment}((oneTimeAddress, signature),(publicKey)) \to \{true,false\}$$

$$zkProve((txHash,onetimeAddress), (publicKey, signature), C_{verifySignedTx}) \to zkProof_{verifySignedTx}$$<br />

- ParentTxHashは親Tx（Feeを払う対象のTx）のTxHash
- AssetIDはFeeとして利用したいERC20的なトークンのID



## 処理フロー

```mermaid

sequenceDiagram

actor U as User
actor O as Operator
participant T as L2 Network

autonumber
U --> O : Send Tx Data and Fee AssetID
O --> U : Calculate and send fee amount
U --> O : Submit fee Payment ZkProof
O --> T : Submit Tx
T --> T : Transfer fee token from User to Operator
T --> T : Then, Execute Tx
T --> O : Send Diff
T --> U : Send Diff

```

## 利点

- 手数料に関してZKEVMは関知しない
- 手数料の条件について同意できない場合はTxを実行しなければいいだけなのでClaimなどが存在しない
- LNの利便性を損なうものではない
- この処理フローだけでFee支払いが完結している
- 追加的なコストはL2の計算コストDiffコストのみ
- 双方新しいステートはわかっている

## 課題点など

- ERC20などの所定のフォーマットを有するアセットは異なる扱いを行うようSolidityなどで制御しないといけない（Exitable Assetの議論と同じ）
- 余計な計算コストやDiffがかかる
