# 弊ネットワーク上での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がかかる
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up