Fee payment discussion

Aztec
,
6

Re the “Depositing Value into Aztec” section in the original post.

There’s a related question I wrote in the discourse thread about L1->L2 comms, which asks how a Sequencer would be paid for an L1->L2 call which adds a message to the message tree. This topic seems related to how a Sequencer would be paid for a deposit (also an L1->L2 call).

In my old specs, I suggest something similar to the following (updated to allow for the new L1->L2 comms):

  • At the time the L1->L2 message is added to the message queue (on L1, via the Rollup Contract), allow value to be escrowed in the Rollup Contract. It’d be up to the logic of the Portal Contract to ensure value can be transferred (either ETH or an ERC20) at the time of making the call.
  • The Rollup Contract would expose an addMessageAndPayFee function for this purpose.
  • The following could be stored in the Rollup Contract’s storage against a particular message:
    • inboxFee: uint256 ← the fee that’s been escrowed to pay to the Sequencer when they add this message to the inbox.
    • l2TxFee: uint256 ← the fee to pay to the Sequencer if they include a particular L2 tx in a rollup.
    • l2TxId: uint256 ← an identifier for the L2 tx for which the l2TxFee will be paid.
      This l2TxId could be a simple hash of the signedTxObject of the L2 function call. Note: the signedTxObject can always be computed in advance.
  • The Kernel Circuit spec already contains logic to optionally reveal certain data depending on certain boolean flags. One such boolean is payFeeFromL1, which forces the kernel circuit to reveal this l2TxId to L1 as calldata, so that the fee can be collected on L1.

Pros:

  • The L2 function being called doesn’t need to handle fee payment logic (it doesn’t even need handle money at all).
  • This allows non-financial apps to make L1->L2 calls, even if the user doesn’t-yet have any L2 funds.
  • Any message to the L1->L2 message box can make a payment to the Sequencer (see linked post which elaborates further on this possibly outstanding problem).
  • Any L2 function could be paid-for via this L1 payment mechanism, if the user doesn’t have funds on L2, giving further flexibility.
13 Likes