diff --git a/yellow-paper/docs/gas-and-fees/gas-and-fees.md b/yellow-paper/docs/gas-and-fees/gas-and-fees.md index f4d63b6b4bf..21ee12c5abb 100644 --- a/yellow-paper/docs/gas-and-fees/gas-and-fees.md +++ b/yellow-paper/docs/gas-and-fees/gas-and-fees.md @@ -33,9 +33,9 @@ We can define a number of requirements that serve to provide a transparent and f ## High Level Concepts and Design -1. We will use concepts of L1 and L2 gas to universally define units of resource for the Ethereum and Aztec networks respectively. L1 gas directly mirrors the actual gas specification as defined by Ethereum, L2 gas covers all resource expended on the L2 network. -2. We will deterministically quantify all resource consumption of a transaction into 4 values. These being the amortized and transaction specific quantities of each of L1 and L2 gas. -3. The transaction sender will provide a single fee for the transaction. This will be split into 2 components to cover each of the L1 and L2 gas costs. The sender will specify `feePerGas` and `gasLimit` for each component. Doing so provides protection to the sender that the amount of fee applicable to L1 costs has an upper bound and L2 a lower bound. +1. We will use concepts of L1, L2 and DA gas to universally define units of resource for the Ethereum and Aztec networks respectively. L1 gas directly mirrors the actual gas specification as defined by Ethereum, L2 gas covers all resource expended on the L2 network. Finally, DA gas accounts for the data stored on the network's Data Availability solution. +2. We will deterministically quantify all resource consumption of a transaction into 7 values. We will define these value later but essentially they represent the amortized and transaction specific quantities of each of L1, L2 and DA gas. +3. The transaction sender will provide a single fee for the transaction. This will be split into 3 components to cover each of the L1, L2 and DA gas costs. The sender will specify `feePerGas` and `gasLimit` for each component. Doing so provides protection to the sender that the amount of fee applicable to any component is constrained. 4. We will constrain the sequencer to apply the correct amortized and transaction specific fees ensuring the sender can not be charged arbitrarily. 5. We will define a method by which fees can be paid in any asset, either publicly or privately, on Ethereum or Aztec but where the sequencer retains agency as to what assets and fee payment methods they are willing to accept. 6. Upon accepting a transaction, we will constrain the sequencer to receive payment and provide any refund owing via the methods specified by the sender. @@ -63,33 +63,34 @@ Some operations are specific to a transaction, such as public function execution All of the operations listed in the transaction specific table can provide us with deterministic gas values for a transaction. The transaction can be simulated and appropriate gas figures can be calculated before the transaction is sent to the network. The transaction will also need to provide a fee to cover it's portion of the amortized cost. This can be done by deciding on a value of `N`, the number of transactions in a rollup. Of course, the transaction sender can't know in advance how many other transactions will be included in the same rollup but the sender will be able to see how many transactions were included in prior rollups and decide on a value that will give them some certainty of inclusion without overpaying for insufficient amortization. As with all costs, any additional amortization will be refunded to the sender. -For example, if the previous 10 rollups consist of an average of 5000 transactions, the sender could decide on a value of 1000 for `N` in it's amortization. If the transaction is included in a rollup with > `N` transactions, the fee saved by the additional amortization will be refunded to the sender. +For example, if the previous 10 rollups consist of an average of 5000 transactions, the sender could decide on a value of 1000 for `N` in it's amortization. If the transaction is included in a rollup with > `N` transactions, the fee saved by the additional amortization will be refunded to the sender. If the sequencer chooses to include the transaction in a rollup with < `N` transactions, the sequencer will effectively subsidize that reduced amortization. -The transaction will be provided with 6 gas values: +The transaction will be provided with 7 gas values: | Value | Description | | -------- | -------- | -| `l1BaseGasLimit` | The maximum quantity of gas permitted for use in amortized L1 operations | -| `l1TxGasLimit` | The maximum quantity of gas permitted for use in transaction specific L1 operations | -| `l2BaseGasLimit` | The maximum quantity of gas permitted for use in amortized L2 operations | -| `l2TxGasLimit` | The maximum quantity of gas permitted for use in transaction specific operations | -| `l1FeeDistributionGas` | The quantity of L1 gas the sequencer can charge for executing the fee distribution function | -| `l2FeeDistributionGas` | The quantity of L2 gas the sequencer can charge for executing the fee distribution function | +| `L1BaseGasLimit` | The maximum quantity of gas permitted for use in amortized L1 operations | +| `L1TxGasLimit` | The maximum quantity of gas permitted for use in transaction specific L1 operations | +| `L2BaseGasLimit` | The maximum quantity of gas permitted for use in amortized L2 operations | +| `L2TxGasLimit` | The maximum quantity of gas permitted for use in transaction specific L2 operations | +| `L2FeeDistributionGas` | The quantity of L2 gas the sequencer can charge for executing the fee distribution function | +| `DAFeeDistributionGas` | The quantity of DA gas the sequencer can charge for storing state updates produced as part of fee distribution | +| `DATxGasLimit` | The maximum quantity of DA gas permitted for use in transaction specific Data Availability functions | By constraining each of the above values individually, the transaction sender is protected from a dishonest sequencer allocating an unfairly high amount of gas to one category and leaving insufficient gas for other categories causing a transaction to erroneously be deemed 'out of gas' and a fee taken for improper execution. ### Gas Measurement By A Sequencer -When a transaction is received by a sequencer, it will want to determine if the transaction has been endowed with sufficient fee to be considered for inclusion in a rollup. Although the transaction contains information as to the gas limits and fees it provides, these may not be accurate either because the sender is dishonest or because the simulation of any public functions was performed on a system state that differs to that at the point of inclusion. Unlike transactions on Ethereum it is not simply a case of linearly executing the transactions opcodes until completion of the transaction exceeds the provided gas. Rollup inclusion and public function execution and proving require significant resource investment on the part of the sequencer even for the most trivial of transaction. +When a transaction is received by a sequencer, it will want to determine if the transaction has been endowed with sufficient fee to be considered for inclusion in a rollup. Although the transaction contains information as to the gas limits and fees it provides, these may not be accurate either because the sender is dishonest or because the simulation of any public functions was performed on a system state that differs to that at the point of inclusion. Unlike transactions on Ethereum, it is not simply a case of linearly executing the transactions opcodes until completion of the transaction exceeds the provided gas. Rollup inclusion and public function execution and proving require significant resource investment on the part of the sequencer even for the most trivial transaction. There are a series of steps the sequencer would wish to perform such that it incrementally increases it's commitment to processing the transaction as it becomes more confident of a successful outcome: -1. Determine how much fee has been provided and verify that this is sufficient to cover the L1 and L2 gas limits specified in the transaction. Later on we will look at how this is done but it may involve simulation of a public function. The sequencer will have visibility over which function on which contract has been specified for this step and has agency to disregard the transaction if it is not willing to execute this step. -2. Once the fee is known, verify that enough fee exists to cover the transaction's requirements at this stage. This would include publishing the results of the private stage of the transaction and the amortized cost of rollup construction and publishing. +1. Determine how much fee has been provided and verify that this is sufficient to cover the L1, L2 and DA gas limits specified in the transaction. Later on we will look at how this is done but it may involve simulation of a public function. The sequencer will have visibility over which function on which contract has been specified for this step and has agency to disregard the transaction if it is not willing to execute this step. +2. Once the fee is known, verify that enough fee exists to cover the transaction's requirements at this stage. This would include publishing the results of the private stage of the transaction and the amortized cost of rollup construction and verification. 3. If at least one public function is enqueued, verify that enough fee exists to cover at least 1 iteration of the public VM, 1 iteration of the public kernel circuit and a non-zero amount left for public function simulation. The sequencer here will seek to determine if it is worth proceeding with the transaction. Proceeding requires an investment at least covering the cost of the minimum public VM execution and an iteration of the public kernel circuit. The minimum cost could be described as the cost to simulate, execute and prove a function which reverts as soon as it enters the function. -Each of the above steps should be relatively trivial for the sequencer to perform and they have agency to disregard the transaction after each one. Having decided that a transaction is worth proceeding with, the sequencer will simulate any public portion of the transaction until completion or simulation exceeds the provided L1 or L2 gas limits. As simulation takes place, it should be noted that further L1 state updates will be made and any nested public calls will incur additional public VM and public kernel iteration costs. +Each of the above steps should be relatively trivial for the sequencer to perform and they have agency to disregard the transaction after each one. Having decided that a transaction is worth proceeding with, the sequencer will simulate any public portion of the transaction until completion or simulation exceeds the provided gas limits. As simulation takes place, it should be noted that further DA state updates will be made and any nested public calls will incur additional public VM and public kernel iteration costs. After simulation, the sequencer will have complete visibility over the gas profile of the transaction and can determine how much witness generation and proving is required for transaction inclusion. @@ -99,9 +100,9 @@ Now that we have a method for defining and measuring the gas consumption of a tr To achieve the above requirements we will break the transaction into 3 components: -1. The fee preparation component can have both private and/or public functions. -2. The transaction payload component can have both private and/or public functions. -3. The fee distribution component only has a public function. +1. The fee preparation component can contain both private and/or public functions. +2. The transaction payload component can contain both private and/or public functions. +3. The fee distribution component only contains a public function. All of these components occur **within the same transaction**, ultimately they result in 2 sets of public inputs being emitted from the private kernel circuits. Those related to the fee payment and those related to the transaction payload. State changes requested by the transaction payload are reverted if any component fails. State changes in the fee preparation and distribution components are only reverted if either of those components fail. @@ -109,17 +110,17 @@ All of these components occur **within the same transaction**, ultimately they r ### Fee Preparation -This component can consist of both private and/or public execution, the result of which must be that an easily identifiable fee be made available to the sequencer. This could be implemented in a variety of ways but typically, we would expect a call to a 'fee payment', escrowing the funds to later be released by the fee distribution component. Any public execution should be minimal to reduce unnecessary work for the sequencer during the period of evaluating whether a transaction is to be included. If public execution is required as part of fee preparation, the sequencer will have complete visibility over what they are being expected to execute. We expect that sequencers will select only those transactions that provide identifiable fees using whitelisted contract addresses and functions. Ultimately, whilst a sequencer's goal is to include as many transactions as possible within a rollup, it will have agency over how much risk it is willing to take that a transaction does not successfully provide a sufficient fee. +This component can consist of both private and/or public execution, the result of which must be that an easily identifiable fee be made available to the sequencer. This could be implemented in a variety of ways but typically, we would expect a call to a 'fee payment' contract, escrowing the funds to later be released by the fee distribution component. Any public execution should be minimal to reduce unnecessary work for the sequencer during the period of evaluating whether a transaction is to be included. If public execution is required as part of fee preparation, the sequencer will have complete visibility over what they are being expected to execute. We expect that sequencers will select only those transactions that provide identifiable fees using whitelisted contract addresses and functions. Ultimately, whilst a sequencer's goal is to include as many transactions as possible within a rollup, it will have agency over how much risk it is willing to take that a transaction does not successfully provide a sufficient fee. ### Transaction Payload -This is the main component of the transaction, the part containing the execution the transaction sender wishes to make. This may revert or run out of gas, causing it's state changes to be reverted, but the sequencer will still be able to claim payment for the work performed. +This is the main component of the transaction, the part containing the execution the transaction sender wishes to perform. This may revert or run out of gas, causing it's state changes to be reverted, but the sequencer will still be able to claim payment for the work performed. ### Fee Distribution Fee distribution consists of a single call to a contract function specified by the client. The function will require the sequencer to provide accurate information about the gas consumed throughout the execution of the transaction payload and perform the necessary steps to finalize the payment to the sequencer and any refund owed to the client. -Like the fee payment component, this must have a very low probability of failure and the sequencer is free to only consider transactions with fee distribution components that they deem acceptable. Reverting here reverts the entire transaction as no fee is distributed to the sequencer. However, it should be straight forward to create fee distribution functions that will not fail given valid inputs that have been verified by the sequencer. +Like the fee payment component, this must have a very low probability of failure and the sequencer is free to only consider transactions with fee distribution components that they deem acceptable. Reverting here reverts the entire transaction as no fee is distributed to the sequencer. However, it should be straight forward to create fee distribution functions that will not fail given valid inputs that have been verified by the sequencer. Payment for execution of this function is provided by the fixed values of `L2FeeDistributionGas` and `DAFeeDistributionGas` so fee distribution functions with highly deterministic gas profiles will be favoured by sequencers. ### Sequencer Validation and DOS Protection @@ -129,13 +130,13 @@ It is of course possible that the fee payment contract and asset is supported by ### Fee Collection -We will define a new block scoped global value ‘coinbase’ that will be used to identify the address of the sequencer for the current block. The sequencer will provide this address to public VM, public kernel and rollup circuits. The rollup circuits will constrain that the same value is used for all circuits in the proving tree. +We will define a block scoped global value ‘coinbase’ that will be used to identify the address of the sequencer for the current block. The sequencer will provide this address to public VM, public kernel and rollup circuits. The rollup circuits will constrain that the same value is used for all circuits in the proving tree. -With this new value defined, a typical fee payment flow might look as follows: +With this value defined, a typical fee payment flow might look as follows: 1. Sequencer executes the public portion of the fee preparation component, escrowing some funds by transferring them to a public balance within a ‘fee payment’ contract. 2. Sequencer executes the transaction payload, in doing so computes the actual cost of the transaction. -3. Sequencer executes the fee distribution function, transferring the actual cost to the ‘coinbase’ address and any refund back to the transaction sender. +3. Sequencer executes the fee distribution function, transferring the final cost to the ‘coinbase’ address and any refund back to the transaction sender. The final cost here will be the sum of the transaction specific cost, the amortised cost and the fee provided for executing the fee distribution function. ## Transaction and Fee Lifecycle @@ -145,16 +146,18 @@ We will attempt to walk through the process by which a transaction is created wi Transactions begin on a user's device where a user opts to interact privately with a contract. This execution results in the generation of new notes and nullifiers and potentially some enqueued public function calls. Additionally, at some point during this execution, a fee will need to be generated. The state updates related to this fee will be added to a separate collection of notes, nullifiers and public calls where these state updates only revert on failure of the fee preparation or distribution logic. -This would appear to introduce a circular dependency whereby an appropriate fee can't be produced without knowing the gas profile (the required quantities of L1 and L2 gas) but the gas profile can depend on the fee required. When simulating the transaction, we will introduce new values to the global context: +This would appear to introduce a circular dependency whereby an appropriate fee can't be produced without knowing the gas profile (the required quantities of L1, L2 and DA gas), but the gas profile can depend on the fee required. When simulating the transaction, we will introduce values to the global context: - **feePerL1Gas** - The fee provided per unit of L1 gas - **feePerL2Gas** - The fee provided per unit of L2 gas -- **l1BaseGasLimit** - The upper bound of L1 amortized gas the transaction is willing to pay for -- **l2BaseGasLimit** - The upper bound of L2 amortized gas the transaction is willing to pay for -- **l1TxGasLimit** - The upper bound of L1 transaction specific gas the transaction is willing to pay for -- **l2TxGasLimit** - The upper bound of L2 transaction specific gas the transaction is willing to pay for -- **l1FeeDistributionGas** - The amount of L1 gas the transaction is willing to pay for execution of the fee distribution function -- **l2FeeDistributionGas** - The amount of L1 gas the transaction is willing to pay for execution of the fee distribution function +- **feePerDAGas** - The fee provided per unit of DA gas +- **L1BaseGasLimit** - The upper bound of L1 amortized gas the transaction is willing to pay for +- **L2BaseGasLimit** - The upper bound of L2 amortized gas the transaction is willing to pay for +- **L1TxGasLimit** - The upper bound of L1 transaction specific gas the transaction is willing to pay for +- **L2TxGasLimit** - The upper bound of L2 transaction specific gas the transaction is willing to pay for +- **DATxGasLimit** - The upper bound of DA transaction specific gas the transaction is willing to pay for +- **L1FeeDistributionGas** - The amount of L1 gas the transaction is willing to pay for execution of the fee distribution function +- **DAFeeDistributionGas** - The amount of DA gas the transaction is willing to pay for execution of the fee distribution function Simulation of the transaction will provide feedback as to it's gas consumption, this can be repeated to converge on the optimum values of fee and gas limits for the transaction. The private portion of the transaction will be proven via the private kernel circuit resulting in a number of fee related public inputs: @@ -167,12 +170,14 @@ Simulation of the transaction will provide feedback as to it's gas consumption, - **feeUnencryptedLogsHash** - The hash of unencrypted logs generated by the fee payment - **feePerL1Gas** - The fee provided per unit of L1 gas - **feePerL2Gas** - The fee provided per unit of L2 gas -- **l1BaseGasLimit** - The upper bound of L1 amortized gas the transaction is willing to pay for -- **l2BaseGasLimit** - The upper bound of L2 amortized gas the transaction is willing to pay for -- **l1TxGasLimit** - The upper bound of L1 transaction specific gas the transaction is willing to pay for -- **l2TxGasLimit** - The upper bound of L2 transaction specific gas the transaction is willing to pay for -- **l1FeeDistributionGas** - The amount of L1 gas the transaction is willing to pay for execution of the fee distribution function -- **l2FeeDistributionGas** - The amount of L2 gas the transaction is willing to pay for execution of the fee distribution function +- **feePerDAGas** - The fee provided per unit of DA gas +- **L1BaseGasLimit** - The upper bound of L1 amortized gas the transaction is willing to pay for +- **L2BaseGasLimit** - The upper bound of L2 amortized gas the transaction is willing to pay for +- **L1TxGasLimit** - The upper bound of L1 transaction specific gas the transaction is willing to pay for +- **L2TxGasLimit** - The upper bound of L2 transaction specific gas the transaction is willing to pay for +- **DATxGasLimit** - The upper bound of DA transaction specific gas the transaction is willing to pay for +- **L2FeeDistributionGas** - The amount of L2 gas the transaction is willing to pay for execution of the fee distribution function +- **DAFeeDistributionGas** - The amount of DA gas the transaction is willing to pay for execution of the fee distribution function ### Transaction Selection and Execution @@ -188,27 +193,30 @@ struct TxContext { l2BaseGasLimit; // provided by the client l1TxGasLimit; // provided by the client l2TxGasLimit; // provided by the client - l1FeeDistributionGas: // provided by the client + dATxGasLimit; // provided by the client + dAFeeDistributionGas: // provided by the client l2FeeDistributionGas: // provided by the client feePerL1Gas; // provided by the client feePerL2Gas; // provided by the client + feePerDAGas; // provided by the client l1GasUsed; // accumulated through circuits l2GasUsed; // accumulated through circuits + dAGasUsed; // accumulated through circuits refundRecipient; // used in the case of public payments/refunds txId; // identifier used for private refunds rollupSize; // set by the sequencer for the rollup } ``` -The sequencer will need to specify the intended size of the rollup (determined as part of the sequencer selection commitment phase) and use this value to calculate gas amortization. These values of amortized L1 and L2 gas will be added to the `l1GasUsed` and `l2GasUsed` accumulators. These accumulators will need to accurately reflect the gas consumption of the transaction prior to public function execution including state updates produced as part of private execution. +The sequencer will need to specify the intended size of the rollup (determined as part of the sequencer selection commitment phase) and use this value to calculate gas amortization. These values of amortized L1 and L2 gas will be added to the `l1GasUsed` and `l2GasUsed` accumulators. These accumulators, along with `dAGasUsed` will need to accurately reflect the gas consumption of the transaction prior to public function execution including state updates produced as part of private execution. -Any enqueued public function calls can be simulated by the sequencer to obtain an accurate gas profile of their execution. This simulation will enable the sequencer to compute the number of additional state updates to be made, the number of public function calls and the L2 gas consumption of each of those calls. If either the L1 or L2 gas limits are breached, simulation will identify where in the execution trace this takes place and so the sequencer will only need to perform iterations of the public VM and public kernel circuits for the calls that either partially or completely succeeded. This ensures that the sequencer is not forced to execute and prove circuits for which they will not be compensated. +Any enqueued public function calls can be simulated by the sequencer to obtain an accurate gas profile of their execution. This simulation will enable the sequencer to compute the number of additional state updates to be made, the number of public function calls and the L2 gas consumption of each of those calls. If any of the gas limits are breached, simulation will identify where in the execution trace this takes place and so the sequencer will only need to perform iterations of the public VM and public kernel circuits for the calls that either partially or completely succeeded. This ensures that the sequencer is not forced to execute and prove circuits for which they will not be compensated. -The public VM circuit can now be executed and proven until completion or until the gas limit is reached. Each invocation of the circuit will constrain it's reported usage of both L1 and L2 gas. +The public VM circuit can now be executed and proven until completion or until a gas limit is reached. Each invocation of the circuit will constrain it's reported usage of all types of gas. Public kernel circuit iterations will be executed for each public function call that actually took place. The combination of VM and kernel circuit executions will constrain the sequencer to correctly maintain the `TxContext` object such that: -1. The gas consumption claimed by the sequencer is correct for both L1 and L2 gas. +1. The gas consumption claimed by the sequencer is correct for all types of gas. 2. Any reverts claimed by the sequencer did indeed occur. 3. After such reverts no unnecessary gas consumption took place. @@ -216,14 +224,15 @@ Once transaction execution is complete, the sequencer will execute the fee distr ### Fee Distribution -Once public function execution has completed (or hit the gas limit), the fee distribution component is executed. This is a public function and will also need to be proven via the VM and public kernel circuits. The sequencer will have agency over which functions they are willing to accept and this will be part of the earlier transaction acceptance. Execution of this function is paid for using a fixed fee, specified by the gas values `l1FeeDistributionGas` and `l2FeeDistributionGas`. The sequencer will be able to verify that these are sufficient to cover the likely cost of calling this function. +Once public function execution has completed (or hit a gas limit), the fee distribution component is executed. This is a public function and will also need to be proven via the VM and public kernel circuits. The sequencer will have agency over which functions they are willing to accept and this will be part of the earlier transaction acceptance. Execution of this function is paid for using a fixed fee, specified by the gas values `l2FeeDistributionGas` and `dAFeeDistributionGas`. The sequencer will be able to verify that these are sufficient to cover the likely cost of calling this function. -The total fee taken by the sequencer is calculated from the values of consumed L1 and L2 gas and the `feeDistributionGas` and `feePerGas` values provided with the transaction. Any balance remaining must be refunded. +The total fee taken by the sequencer is calculated from the values of consumed L1, L2 and DA gas and the `feeDistributionGas` and `feePerGas` values provided with the transaction. Any balance remaining must be refunded. ``` -let actual_l1_cost = (tx_context.l1GasUsed + l1FeeDistributionGas) * tx_context.feePerL1Gas; +let actual_l1_cost = (tx_context.l1GasUsed) * tx_context.feePerL1Gas; let actual_l2_cost = (tx_context.l2GasUsed + l2FeeDistributionGas) * tx_context.feePerL2Gas; -let total_tx_cost = actual_l1_cost + actual_l2_cost; +let actual_da_cost = (tx_context.dAGasUsed + dAFeeDistributionGas) * tx_context.feePerDAGas; +let total_tx_cost = actual_l1_cost + actual_l2_cost + actual_da_cost; let refund = tx_context.totalFee - total_tx_cost; ``` @@ -232,12 +241,12 @@ let refund = tx_context.totalFee - total_tx_cost; To ensure clients are fairly charged for complete execution of their transactions, the public kernel circuit will verify: 1. The values of `base` gas applied to the transaction correctly corresponds to the size of rollup selected by the sequencer -2. The values of l1 and l2 gas accumulated within the `TxContext` object were accurate -3. The l1 and l2 gas limits specified in the transaction were respected -4. The correct values of `feePerL1Gas` and `feePerL2Gas` were used +2. The values of L1, L2 and DA gas accumulated within the `TxContext` object were accurate +3. All gas limits specified in the transaction were respected +4. The correct values of `feePerL1Gas`, `feePerL2Gas` and `feePerDAGas` were used 5. The correct public functions were called as part of the fee preparation and fee distribution components -Additionally, the merge and root rollup circuits will constrain that the value of `base` gas was consistent with the actual rollup size +Additionally, the merge and root rollup circuits will constrain that the value of `base` gas was consistent with the actual rollup size. ## Payment Methods @@ -257,14 +266,3 @@ This next example differs in that the refund is performed privately using partia In both of these examples the fee is effectively escrowed as part of the private portion of fee preparation. The enqueued public function is simply an instruction to increase the balance of the payment asset held by the fee payment contract. The sequencer should be able to inspect the public call instruction, consisting of contract address, function selector and arguments and be confident that this function will not fail. Provided the logic of the fee payment contract is defined correctly, once escrowed, the fee can't be modified by the user's transaction payload. This gives the sequencer the guarantee that they will be paid for the work they perform. Finally, the fee distribution function in either of these examples can be written such that the sequencer can be confident of success. This function simply needs to take the securely escrowed fee, compute the actual fee and subsequent refund before increasing the balance of the 2 parties within the payment asset. - - -### Paying Via L1 - -As a further option, it would be possible to facilitate payments directly from L1. Here, a mechanism similar to L1 -> L2 messaging would be used to transmit the payment to the sequencer. - -1. The user deposits the fee to the rollup contract and sends an L1 -> L2 message along the lines of 'L1 fee of $100 for transaction X'. -2. The user creates the transaction and executes the fee payment circuit with the message 'L1 fee of $100 for transaction X'. -3. The sequencer accepts the transaction and the L1 -> L2 message confirming that the funds have been made available on L1. -4. The sequencer executes the transaction and the fee distribution function taking their fee and distributing a refund on L2. -5. The L1 -> L2 message is consumed by the rollup transaction on L1.