From 547d66484efa751ad3df02bf3a239d41727ca4a9 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Tue, 8 Jul 2025 13:29:10 +1000 Subject: [PATCH 01/13] Describe fee proposal draft --- documentation/Fee Proposal.md | 57 +++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 documentation/Fee Proposal.md diff --git a/documentation/Fee Proposal.md b/documentation/Fee Proposal.md new file mode 100644 index 00000000..6003ad32 --- /dev/null +++ b/documentation/Fee Proposal.md @@ -0,0 +1,57 @@ +# Fee Proposal + +## Overview + +- I have an intuition that some of the L2 fee-pricing challenges are downstream of reusing and modifying the L1 pricing model, which may not be aligned with the economics of L2s. +- Following similar intuitions to the [generic assertions](https://github.com/OpenZeppelin/minimal-rollup/pull/123) idea, I think rollups should just enforce security-relevant properties and then provide a framework for developers to build whatever they want. We can provide example implementations but they should not be part of the core protocol. +- In this case, I suspect we can simplify the protocol fee requirements. It doesn't remove the complexity of figuring out how much to charge, but it pushes it up to the smart contract layer, which should improve flexibility and allow participants to respond to market conditions. +- I have low confidence in this claim - it's quite possible I'm missing something crucial. Part of the point of this document is to think through the idea. Feedback is very much encouraged. + +## Background + +- As I understand it, the whole L1 gas metering mechanism is supposed to limit third-party costs on staking validators: + - the block gas limit ensures consumer-grade validator devices can keep up with the chain + - the gas price ensures users pay the "costs to the network" for replicating the operation across thousands of validators. It's not perfect because the validators do not receive the payment, but they are compensated by the staking/reward mechanism. +- In the L2 case, there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes, so there are no actual "costs to the network". +- The gas target is not about security, but it is a useful mechanism to smooth out the price volatility produced by sudden changes in demand. We should aim to preserve this property. + +## Idea + +### Transaction Costs + +- The basic idea is to remove the in-protocol fee mechanism (and the implicit gas target), by setting the base fee to zero. +- I think we still want a gas limit so that anyone running a node can reasonably say "if my node has X resources, I will be able to keep up with the chain", but it doesn't need to target consumer devices. I suspect the L1 costs and proving costs will constrain the practical limit, but data-light compute-heavy transactions (or actual attacks like running an infinite loop) may hit the enforced limit. +- In this way, the protocol is no longer opinionated about how much to charge for each opcode (except in the sense that some opcodes will consume more of the gas target). +- Users can incentivize the proposer to include their transaction using any offchain or L2-mechanism they want. The proposer could reproduce the current behaviour by measuring the gas used and charging accordingly, but they could also use arbitrary tokens, or change the metering mechanism, or offer discounts for compressible calldata. From the rollup's point of view, if the proposer is willing to pay the L1 costs, then how they charge users is up to them. +- If we want to retain the EIP1559-style targetting mechanism to smooth out price volatility, that could be achieved by forcing proposers to pay (or burn) L2 ETH when they exceed the target and adjust the target whenever this happens. The difference is that the penalty is applied directly to the proposer, not the individual transactions. + +### Proving costs + +- Similarly, proposers must post a liveness bond with each publication. The protocol will guarantee: + - if the publication is proven in time, the liveness bond is sent to a proposer-specified refund address. + - otherwise, whoever proves it gets the liveness bond. + - the liveness bond is large enough to cover the worst-case "prover killer" blocks (but otherwise does not need to be responsive to the details of the publication or proving costs). + - this almost certainly implies the liveness bond will also cover proving that a publication is invalid (so it becomes an empty block). + - in either case, there is always an incentive to prove an expired publication. +- To facilitate enforceable prover/proposer commitments (like an [auction mechanism](https://github.com/OpenZeppelin/minimal-rollup/blob/main/src/protocol/BaseProverManager.sol)), the protocol could: + - allow an optional special transaction (at the start or end of the publication) that calls `validatePublication` on an arbitrary L2 address chosen by the proposer and passes: + - the refund address on L1 + - a hash of the transactions in the publication + - an arbitrary buffer containing any relevant additional information + - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post linked above) that these values are set correctly (or the publication defaults to an empty block). +- The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: + - it sends the liveness bond minus its chosen fee to the proposer + - it ensures the L1 refund address belongs to the prover + - In this way + - the prover contract can decide how much to charge for the particular publication using whatever rules it wants + - any proposer can accept the deal by constructing a publication that invokes this prover contract + - in the happy case + - the proposer paid the L1 liveness bond, which will be sent to the prover + - the prover paid a slightly smaller amount to the proposer on L2. The difference is the proving fee. + - in the unhappy case + - the proposer still pays the proving fee (in effect) + - the specified prover pays the rest of the liveness bond as a penalty + - both amounts are given to the actual prover +- We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. +- If the `validatePublication` function fails (so the specified prover contract did not actually agree to prove the publication), the actual prover will need to show the publication has empty blocks. The liveness bond (paid by the proposer) should be enough to cover this proof. +- Under this design, delayed publications can be treated like regular publications: the user covers the L1 costs but can specify a prover contract so they only end up paying the proving fee. From e8a347df92f518f1bc7ddf4767c6417670110483 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Tue, 8 Jul 2025 13:40:17 +1000 Subject: [PATCH 02/13] Clarify that validatePublication is a regular function --- documentation/Fee Proposal.md | 1 + 1 file changed, 1 insertion(+) diff --git a/documentation/Fee Proposal.md b/documentation/Fee Proposal.md index 6003ad32..f71ee8e0 100644 --- a/documentation/Fee Proposal.md +++ b/documentation/Fee Proposal.md @@ -39,6 +39,7 @@ - a hash of the transactions in the publication - an arbitrary buffer containing any relevant additional information - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post linked above) that these values are set correctly (or the publication defaults to an empty block). + - note that other than these guarantees, this behaves like a regular transaction that can change L2 state in any way including transferring tokens or ETH. It's still free for the proposer to call it (since the base fee is zero), but it does consume some of the gas limit. - The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: - it sends the liveness bond minus its chosen fee to the proposer - it ensures the L1 refund address belongs to the prover From 019cd579d694ed1d274a37dc747ed596af1ad9f0 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Wed, 9 Jul 2025 18:39:26 +1000 Subject: [PATCH 03/13] Describe Version 2 after feedback --- documentation/Fee Proposal.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/documentation/Fee Proposal.md b/documentation/Fee Proposal.md index f71ee8e0..13429c26 100644 --- a/documentation/Fee Proposal.md +++ b/documentation/Fee Proposal.md @@ -17,13 +17,38 @@ ## Idea -### Transaction Costs +### Transaction Costs - Version 1 - The basic idea is to remove the in-protocol fee mechanism (and the implicit gas target), by setting the base fee to zero. - I think we still want a gas limit so that anyone running a node can reasonably say "if my node has X resources, I will be able to keep up with the chain", but it doesn't need to target consumer devices. I suspect the L1 costs and proving costs will constrain the practical limit, but data-light compute-heavy transactions (or actual attacks like running an infinite loop) may hit the enforced limit. - In this way, the protocol is no longer opinionated about how much to charge for each opcode (except in the sense that some opcodes will consume more of the gas target). - Users can incentivize the proposer to include their transaction using any offchain or L2-mechanism they want. The proposer could reproduce the current behaviour by measuring the gas used and charging accordingly, but they could also use arbitrary tokens, or change the metering mechanism, or offer discounts for compressible calldata. From the rollup's point of view, if the proposer is willing to pay the L1 costs, then how they charge users is up to them. -- If we want to retain the EIP1559-style targetting mechanism to smooth out price volatility, that could be achieved by forcing proposers to pay (or burn) L2 ETH when they exceed the target and adjust the target whenever this happens. The difference is that the penalty is applied directly to the proposer, not the individual transactions. +- If we want to retain the EIP1559-style targeting mechanism to smooth out price volatility, that could be achieved by forcing proposers to pay (or burn) L2 ETH when they exceed the target and adjust the target whenever this happens. The difference is that the penalty is applied directly to the proposer, not the individual transactions. + +### Transaction Costs - Version 2 + +- Based on feedback for the previous version: + - we should retain the EIP1559 mechanism to remain consistent with existing (and battle-tested) infrastructure + - we should include a mechanism to direct funds to the rollup's treasury +- However, I still insist that we should not use the L2 base fee to charge anything other than L2 execution gas. I think incorporating more relevant fees (like the L1 blob costs or proving fees) into the base fee mechanism ends up distorting the market, leading to attacks and complications. +- Instead, I think we should have a two-step process (except possibly for L2 execution): + - users pay the sequencer with the priority fee. If any sequencer wants to set up another L2 or offchain mechanism (eg. to use an ERC20 token), they always have that option. + - the sequencer pays the treasury whatever fees are due. +- In practice, this will have a few components: + - the L2 base fee mechanism continues to charge for L2 execution only. It uses the standard EIP1559 mechanism with some possible modifications: + - the base fee itself could be set to 0 (because as noted above, I think it's not necessary) + - in this case, the sequencer could still optionally have a (per-second) target gas amount, and be charged for it using an EIP1559-style mechanism to maintain the target, and that charge could still be directed to the treasury. + - the difference with the regular mechanism is that sequencers have more flexibility in how (or even whether) to charge each individual transaction for their gas usage. Users with no ETH could pay in other tokens, or MEV-rich transactions could be subsidized. The only requirement is the sequencer is willing to pay the protocol for the overall gas usage. + - if we keep a non-zero base fee, the formula should [be corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. + - the inbox should save the number of blobs used, `BLOBBASEFEE` and `BASEFEE` with the publication. This can be used to compute the L1 costs, so a surcharge percentage can be deducted from the sequencer and sent to the treasury. + - this could be handled inside the L2 EVM by injecting those values (in the anchor or end-of-publication transaction) and doing a direct transfer + - alternatively, it could be computed as part of the state-transition function. + - the proving costs could be handled as described below. We could also track the agreed proving cost and apply a surcharge to the sequencer. However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. +- Under this scheme the sequencer is responsible for covering the publication and proving costs, including the treasury fee surcharges. They will need to recover these costs from user transaction priority fees. Therefore, sequencers should only include transactions that cover their costs, but they have complete flexibility to account for all relevant variables (like whether the transactions compress well, or the current L1 blob fees, or whether the transactions incur large proving costs, etc) + - unfortunately, priority fees are actually a fee-rate, so the amount paid will depend on the L2 gas actually consumed. Sequencers will need to take this into account when deciding whether a transaction is worth including + - this is a consequence of the EIP1559 mechanism only accounting for L2 gas + - sequencers may be able to address this by using wrapper transactions, or just deal with the possibility that they may need to discard transactions after simulating them. + - ideally, there would be a new transaction type that allows for a direct fee payment from user to sequencer, but we would then need to get support from the ecosystem (eg. wallets) to use it. ### Proving costs From f8ac5e1af3ec84070d9329774bbe8fe14d1e2134 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Mon, 21 Jul 2025 22:20:50 +1000 Subject: [PATCH 04/13] Clean up proposal --- documentation/Fee Proposal.md | 83 ------------------- documentation/Taiko Fee Proposal.md | 118 ++++++++++++++++++++++++++++ 2 files changed, 118 insertions(+), 83 deletions(-) delete mode 100644 documentation/Fee Proposal.md create mode 100644 documentation/Taiko Fee Proposal.md diff --git a/documentation/Fee Proposal.md b/documentation/Fee Proposal.md deleted file mode 100644 index 13429c26..00000000 --- a/documentation/Fee Proposal.md +++ /dev/null @@ -1,83 +0,0 @@ -# Fee Proposal - -## Overview - -- I have an intuition that some of the L2 fee-pricing challenges are downstream of reusing and modifying the L1 pricing model, which may not be aligned with the economics of L2s. -- Following similar intuitions to the [generic assertions](https://github.com/OpenZeppelin/minimal-rollup/pull/123) idea, I think rollups should just enforce security-relevant properties and then provide a framework for developers to build whatever they want. We can provide example implementations but they should not be part of the core protocol. -- In this case, I suspect we can simplify the protocol fee requirements. It doesn't remove the complexity of figuring out how much to charge, but it pushes it up to the smart contract layer, which should improve flexibility and allow participants to respond to market conditions. -- I have low confidence in this claim - it's quite possible I'm missing something crucial. Part of the point of this document is to think through the idea. Feedback is very much encouraged. - -## Background - -- As I understand it, the whole L1 gas metering mechanism is supposed to limit third-party costs on staking validators: - - the block gas limit ensures consumer-grade validator devices can keep up with the chain - - the gas price ensures users pay the "costs to the network" for replicating the operation across thousands of validators. It's not perfect because the validators do not receive the payment, but they are compensated by the staking/reward mechanism. -- In the L2 case, there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes, so there are no actual "costs to the network". -- The gas target is not about security, but it is a useful mechanism to smooth out the price volatility produced by sudden changes in demand. We should aim to preserve this property. - -## Idea - -### Transaction Costs - Version 1 - -- The basic idea is to remove the in-protocol fee mechanism (and the implicit gas target), by setting the base fee to zero. -- I think we still want a gas limit so that anyone running a node can reasonably say "if my node has X resources, I will be able to keep up with the chain", but it doesn't need to target consumer devices. I suspect the L1 costs and proving costs will constrain the practical limit, but data-light compute-heavy transactions (or actual attacks like running an infinite loop) may hit the enforced limit. -- In this way, the protocol is no longer opinionated about how much to charge for each opcode (except in the sense that some opcodes will consume more of the gas target). -- Users can incentivize the proposer to include their transaction using any offchain or L2-mechanism they want. The proposer could reproduce the current behaviour by measuring the gas used and charging accordingly, but they could also use arbitrary tokens, or change the metering mechanism, or offer discounts for compressible calldata. From the rollup's point of view, if the proposer is willing to pay the L1 costs, then how they charge users is up to them. -- If we want to retain the EIP1559-style targeting mechanism to smooth out price volatility, that could be achieved by forcing proposers to pay (or burn) L2 ETH when they exceed the target and adjust the target whenever this happens. The difference is that the penalty is applied directly to the proposer, not the individual transactions. - -### Transaction Costs - Version 2 - -- Based on feedback for the previous version: - - we should retain the EIP1559 mechanism to remain consistent with existing (and battle-tested) infrastructure - - we should include a mechanism to direct funds to the rollup's treasury -- However, I still insist that we should not use the L2 base fee to charge anything other than L2 execution gas. I think incorporating more relevant fees (like the L1 blob costs or proving fees) into the base fee mechanism ends up distorting the market, leading to attacks and complications. -- Instead, I think we should have a two-step process (except possibly for L2 execution): - - users pay the sequencer with the priority fee. If any sequencer wants to set up another L2 or offchain mechanism (eg. to use an ERC20 token), they always have that option. - - the sequencer pays the treasury whatever fees are due. -- In practice, this will have a few components: - - the L2 base fee mechanism continues to charge for L2 execution only. It uses the standard EIP1559 mechanism with some possible modifications: - - the base fee itself could be set to 0 (because as noted above, I think it's not necessary) - - in this case, the sequencer could still optionally have a (per-second) target gas amount, and be charged for it using an EIP1559-style mechanism to maintain the target, and that charge could still be directed to the treasury. - - the difference with the regular mechanism is that sequencers have more flexibility in how (or even whether) to charge each individual transaction for their gas usage. Users with no ETH could pay in other tokens, or MEV-rich transactions could be subsidized. The only requirement is the sequencer is willing to pay the protocol for the overall gas usage. - - if we keep a non-zero base fee, the formula should [be corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. - - the inbox should save the number of blobs used, `BLOBBASEFEE` and `BASEFEE` with the publication. This can be used to compute the L1 costs, so a surcharge percentage can be deducted from the sequencer and sent to the treasury. - - this could be handled inside the L2 EVM by injecting those values (in the anchor or end-of-publication transaction) and doing a direct transfer - - alternatively, it could be computed as part of the state-transition function. - - the proving costs could be handled as described below. We could also track the agreed proving cost and apply a surcharge to the sequencer. However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. -- Under this scheme the sequencer is responsible for covering the publication and proving costs, including the treasury fee surcharges. They will need to recover these costs from user transaction priority fees. Therefore, sequencers should only include transactions that cover their costs, but they have complete flexibility to account for all relevant variables (like whether the transactions compress well, or the current L1 blob fees, or whether the transactions incur large proving costs, etc) - - unfortunately, priority fees are actually a fee-rate, so the amount paid will depend on the L2 gas actually consumed. Sequencers will need to take this into account when deciding whether a transaction is worth including - - this is a consequence of the EIP1559 mechanism only accounting for L2 gas - - sequencers may be able to address this by using wrapper transactions, or just deal with the possibility that they may need to discard transactions after simulating them. - - ideally, there would be a new transaction type that allows for a direct fee payment from user to sequencer, but we would then need to get support from the ecosystem (eg. wallets) to use it. - -### Proving costs - -- Similarly, proposers must post a liveness bond with each publication. The protocol will guarantee: - - if the publication is proven in time, the liveness bond is sent to a proposer-specified refund address. - - otherwise, whoever proves it gets the liveness bond. - - the liveness bond is large enough to cover the worst-case "prover killer" blocks (but otherwise does not need to be responsive to the details of the publication or proving costs). - - this almost certainly implies the liveness bond will also cover proving that a publication is invalid (so it becomes an empty block). - - in either case, there is always an incentive to prove an expired publication. -- To facilitate enforceable prover/proposer commitments (like an [auction mechanism](https://github.com/OpenZeppelin/minimal-rollup/blob/main/src/protocol/BaseProverManager.sol)), the protocol could: - - allow an optional special transaction (at the start or end of the publication) that calls `validatePublication` on an arbitrary L2 address chosen by the proposer and passes: - - the refund address on L1 - - a hash of the transactions in the publication - - an arbitrary buffer containing any relevant additional information - - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post linked above) that these values are set correctly (or the publication defaults to an empty block). - - note that other than these guarantees, this behaves like a regular transaction that can change L2 state in any way including transferring tokens or ETH. It's still free for the proposer to call it (since the base fee is zero), but it does consume some of the gas limit. -- The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: - - it sends the liveness bond minus its chosen fee to the proposer - - it ensures the L1 refund address belongs to the prover - - In this way - - the prover contract can decide how much to charge for the particular publication using whatever rules it wants - - any proposer can accept the deal by constructing a publication that invokes this prover contract - - in the happy case - - the proposer paid the L1 liveness bond, which will be sent to the prover - - the prover paid a slightly smaller amount to the proposer on L2. The difference is the proving fee. - - in the unhappy case - - the proposer still pays the proving fee (in effect) - - the specified prover pays the rest of the liveness bond as a penalty - - both amounts are given to the actual prover -- We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. -- If the `validatePublication` function fails (so the specified prover contract did not actually agree to prove the publication), the actual prover will need to show the publication has empty blocks. The liveness bond (paid by the proposer) should be enough to cover this proof. -- Under this design, delayed publications can be treated like regular publications: the user covers the L1 costs but can specify a prover contract so they only end up paying the proving fee. diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md new file mode 100644 index 00000000..456d2a05 --- /dev/null +++ b/documentation/Taiko Fee Proposal.md @@ -0,0 +1,118 @@ +# Taiko Fee Proposal + +## Overview +- I have an intuition that some of the L2 fee-pricing challenges are downstream of reusing and modifying the L1 pricing model, which may not be aligned with the economics of L2s. +- In particular, it seems to me that L1 protocol-enforced-fees are useful to: + - apply a "negative externality fee" to account for costs to the network. This accounts for the cost of running the consensus mechanism. + - limit the total resource consumption to a level where other network participants can keep up. + - technically, the actual resource limits (block gas limit and blob number limit) achieve this function, but the fee makes it possible to have a target that it less than the actual limit, to smooth out volatility. +- In the L2 case: + - there are no relevant _staking_ validators. We don't actually care how many people run L2 nodes so there are no actual "costs to the network". + - L2 sequencers have to pay L1 publication costs out of their own account. + - L2 provers have to pay L1 proving costs out of their own account, and may incur significant offchain proving costs. + - We want a mechanism to direct funds towards the treasury. +- I believe attempting to combine the relevant fees into an L2 base fee is unnecessarily complicated and distorts the market, which leads to attacks and complications. +- Instead, we should analyse the dynamics of each resource independently. + +## Proposal + +I will first describe my suggested proposal, and then explain the rationale. + + +1. L2 gas should only cover L2 execution. There are two options: + - use the existing EIP1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. + - charge for publications (not transactions): + - set the base fee to zero + - use an EIP1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. + - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens or MEV-rich transactions could be subsidized. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol. + - some or all of the protocol fee can be directed to the treasury or burned. +2. The protocol does not compute or enforce any L1 data fee requirements. + - Sequencers pay the L1 publishing costs to the L1 network. + - They decide for themselves how to charge users for L1 costs. + - The inbox should save the number of blobs used, `BLOBBASEFEE` and `BASEFEE` with the publication. This can be used to compute the L1 costs, so a surcharge percentage can be deducted from the sequencer (on L2) and sent to the treasury. + - this could be handled inside the L2 EVM by injecting those values (in the anchor or end-of-publication transaction) and doing a direct transfer. + - alternatively, it could be computed as part of the state-transition function. +3. Similar to the existing protocol, proposers must post a liveness bond with each publication. + - The protocol will guarantee: + - if the publication is proven in time, the liveness bond is sent to a proposer-specified refund address. + - otherwise, whoever proves it gets the liveness bond. + - To facilitate enforceable prover/proposer commitments (like an [auction mechanism](https://github.com/OpenZeppelin/minimal-rollup/blob/main/src/protocol/BaseProverManager.sol)), the protocol could: + - allow an optional special transaction (at the start or end of the publication) that calls `validatePublication` on an arbitrary L2 address chosen by the proposer and passes: + - the refund address on L1 + - a hash of the transactions in the publication + - an arbitrary buffer containing any relevant additional information + - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post linked above) that these values are set correctly (or the publication defaults to an empty block). + - note that other than these guarantees, this behaves like a regular transaction that can change L2 state in any way including transferring tokens or ETH and consumes L2 gas (which may be free for the proposer in the scenario where the base fee is zero). + - The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: + - it sends the liveness bond minus its chosen fee to the proposer + - it ensures the L1 refund address belongs to the prover + - In this way + - the prover contract can decide how much to charge for the particular publication using whatever rules it wants + - any proposer can accept the deal by constructing a publication that invokes this prover contract + - in the happy case + - the proposer paid the L1 liveness bond, which will be sent to the prover + - the prover paid a slightly smaller amount to the proposer on L2. The difference is the proving fee. + - in the unhappy case + - the proposer still pays the proving fee (in effect) + - the specified prover pays the rest of the liveness bond as a penalty + - both amounts are given to the actual prover + - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. + - If the `validatePublication` function fails (so the specified prover contract did not actually agree to prove the publication), the actual prover will need to show the publication has empty blocks. The liveness bond (paid by the proposer) should be enough to cover this proof. + - We could track the agreed proving costs (as part of the `validatPublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. + +Note that under this design, the costs for a publication are self-contained, so delayed publications can be treated like regular publications. + +## Rationale + +### Overall Intuition + +- The goal is to reflect the real-world costs as faithfully as possible. +- Any opinionated pricing formulas enforced by the protocol, particularly ones that rely on empirically-derived parameters (like average transaction sizes), can get out of sync with the market conditions. +- Moreover, attempting to charge for the wrong resource (eg. L1 costs being included the L2 base fee) can let users craft transactions that exploit the discrepancy. + +### L2 Gas +- As I understand it (although this should be validated), since there is no security reason to encourage users to run L2 nodes, we do not need to charge for "costs to the L2 network". This means the L2 gas fee can be set to zero. +- The sequencer may still want to charge for the offchain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction. +- However, we probably do want to include an overall gas limit to ensure that other users can keep up with the chain. I suspect it can be large enough that it is never reached in practice (because the publication and proving cost limits will likely be reached first), but it is still necessary to prevent malicious compute-only transactions (like running an infinite loop). +- Once we've decided to include a limit, I think it also makes sense to have a smaller target, so that unexpected volatility does not create immediate scarcity (and correspondingly very high prices). The EIP1559 mechanism seems like a good way to regulate this. +- However, applying the mechanism to the sequencer (instead of the transactions) has some benefits: + - it is simpler. We only need to do one update calculation per publication (rather than for every block) + - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer) + - users and sequencers have more flexibility around when and how payments are made. + +### Publication Costs +- Since sequencers must pay the publication costs, it seems natural for users to compensate them directly. +- Morever, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). +- When discussing this idea, one concern was that if the publication fee was not incoporated into the base fee, it would not be subject to the EIP1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. +- With this mechanism, Taiko does not have to model the L1 changes, but can still direct a fraction of the actual (not estimated) publication costs to the treasury. + - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. + - If standardisation is preferred, Taiko could still create a suggested fee formula that sequencers can use. + + + +### Proving Costs +- Following the same intuitions, if sequencers compensate provers at whatever rate they agree, then sequencers and users are incentivised to optimise the proving costs. +- For example, sequencers can offer discounts for transactions that are easy to prove. +- This also lets Taiko be maximally flexible about the best way to estimate proving costs. Anyone is free to: + - use a "zk-opcode" method + - use L2 gas as a proxy for proving costs + - invent a new method specialised for their proving hardware. + +## Wallet compatibility + +There are two challenges that I think will need to be addressed, and may depend on the cooperation of wallet developers: + +- Fee discovery + - Sequencers will need a way to signal to wallets how much they would charge for a given transaction + - I'm not sure how this works in practice, and whether wallets can change which endpoint they query based on who the next sequencer is, or if sequencers can register their fee calculation with some shared provider. +- Using total fees + - As I've described the mechanism, the transactions will pay some base fee (possibly zero) associated with the L2 gas execution, and should also specify a priority fee to account for the other charges + - However, current transaction types require them to specify a _priority fee rate_ (not absolute fee) against L2 gas. + - As noted, I don't think they should charge per unit of L2 gas execution, so they will need to compute the total fee and then divide it by the actual gas consumed. + - Unfortunately, users do not necessarily know exactly how much gas will be consumed when constructing the transaction because that might depend on if any other transactions change the state before this transaction is sequenced. + - Ideally, this would be solved with a new transaction type, allowing users to specify the total priority fee. + - Until then, sequencers will need to simulate the transaction to determine the actual gas consumed, and only then can they figure out whether the priority fee will be sufficient. + - They could also use a wrapper smart contract that first executes the transaction and then consumes the remaining gas so that the transaction gas limit would be equivalent to the actual gas consumed, but this seems pretty hacky. + + + From e14777efa44fc05e95fc76926b77ca4a0a70b2ea Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Mon, 21 Jul 2025 22:45:22 +1000 Subject: [PATCH 05/13] Remove "linked above" clause. It is no longer linked in this version --- documentation/Taiko Fee Proposal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index 456d2a05..ee749c71 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -41,7 +41,7 @@ I will first describe my suggested proposal, and then explain the rationale. - the refund address on L1 - a hash of the transactions in the publication - an arbitrary buffer containing any relevant additional information - - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post linked above) that these values are set correctly (or the publication defaults to an empty block). + - the state transition function will guarantee (similar to the "consistency hash" mechanism described in the generic assertions post) that these values are set correctly (or the publication defaults to an empty block). - note that other than these guarantees, this behaves like a regular transaction that can change L2 state in any way including transferring tokens or ETH and consumes L2 gas (which may be free for the proposer in the scenario where the base fee is zero). - The L2 address represents a prover, and the `validatePublication` function will ensure the prover is willing to prove that publication. It could be designed (but this is not enforced) so that: - it sends the liveness bond minus its chosen fee to the proposer From cfb9a24555834a04e76b360d43f62d0beb0aece5 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Mon, 21 Jul 2025 23:20:45 +1000 Subject: [PATCH 06/13] Fix typo --- documentation/Taiko Fee Proposal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index ee749c71..b7242640 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -83,7 +83,7 @@ Note that under this design, the costs for a publication are self-contained, so ### Publication Costs - Since sequencers must pay the publication costs, it seems natural for users to compensate them directly. - Morever, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). -- When discussing this idea, one concern was that if the publication fee was not incoporated into the base fee, it would not be subject to the EIP1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. +- When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee, it would not be subject to the EIP1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. - With this mechanism, Taiko does not have to model the L1 changes, but can still direct a fraction of the actual (not estimated) publication costs to the treasury. - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. - If standardisation is preferred, Taiko could still create a suggested fee formula that sequencers can use. From 4bc4a30d9a0ca5e4722f226f7e926be661c83449 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Tue, 22 Jul 2025 11:09:29 +1000 Subject: [PATCH 07/13] Fix typos --- documentation/Taiko Fee Proposal.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index b7242640..6f5017f9 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -58,7 +58,7 @@ I will first describe my suggested proposal, and then explain the rationale. - both amounts are given to the actual prover - We could avoid actually transferring funds between L1 / L2 (or requiring the proposer to have L1 funds) by using a slightly more complicated refund address that both provides and receives the bond (like a flash loan), and the prover contract on L2 would retrieve the fee rather than refund the bond amount. - If the `validatePublication` function fails (so the specified prover contract did not actually agree to prove the publication), the actual prover will need to show the publication has empty blocks. The liveness bond (paid by the proposer) should be enough to cover this proof. - - We could track the agreed proving costs (as part of the `validatPublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. + - We could track the agreed proving costs (as part of the `validatePublication` interface) and apply a surcharge to sequencer, directed to the treasury (just like the L1 publication costs). However, since this value is negotiated between the sequencer and prover, the fee could be bypassed by setting the official proving cost as zero and using some other mechanism to pay the fee. Note that under this design, the costs for a publication are self-contained, so delayed publications can be treated like regular publications. @@ -82,7 +82,7 @@ Note that under this design, the costs for a publication are self-contained, so ### Publication Costs - Since sequencers must pay the publication costs, it seems natural for users to compensate them directly. -- Morever, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). +- Moreover, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). - When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee, it would not be subject to the EIP1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. - With this mechanism, Taiko does not have to model the L1 changes, but can still direct a fraction of the actual (not estimated) publication costs to the treasury. - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. From 1a9607c889e27c8f6b632fded02a5a71ee2f08f2 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Tue, 22 Jul 2025 11:12:35 +1000 Subject: [PATCH 08/13] Fix typo --- documentation/Taiko Fee Proposal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index 6f5017f9..2904a755 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -68,7 +68,7 @@ Note that under this design, the costs for a publication are self-contained, so - The goal is to reflect the real-world costs as faithfully as possible. - Any opinionated pricing formulas enforced by the protocol, particularly ones that rely on empirically-derived parameters (like average transaction sizes), can get out of sync with the market conditions. -- Moreover, attempting to charge for the wrong resource (eg. L1 costs being included the L2 base fee) can let users craft transactions that exploit the discrepancy. +- Moreover, attempting to charge for the wrong resource (eg. L1 costs being included in the L2 base fee) can let users craft transactions that exploit the discrepancy. ### L2 Gas - As I understand it (although this should be validated), since there is no security reason to encourage users to run L2 nodes, we do not need to charge for "costs to the L2 network". This means the L2 gas fee can be set to zero. From ba45ba5f8e4495b7f70fc4989c1fe8d4fb0649ca Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Thu, 24 Jul 2025 14:00:01 +1000 Subject: [PATCH 09/13] Include (temporary) "Alternatives" section --- documentation/Taiko Fee Proposal.md | 31 +++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index 2904a755..ebc0e8fc 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -114,5 +114,32 @@ There are two challenges that I think will need to be addressed, and may depend - Until then, sequencers will need to simulate the transaction to determine the actual gas consumed, and only then can they figure out whether the priority fee will be sufficient. - They could also use a wrapper smart contract that first executes the transaction and then consumes the remaining gas so that the transaction gas limit would be equivalent to the actual gas consumed, but this seems pretty hacky. - - +## Alternatives + +- To address the question of wallet compatibility, I should get familiar with how wallets choose fees and display them to users. At this point I do not have enough background to understand claims about whether it is or is not possible. +- I will be offline for a few days, but in the mean time, I think it might be worthwhile to consider alternatives, to provoke a discussion and better pinpoint exactly what the constraints are. + +### Independent L2 charges + +- If we cannot use priority fees (or it is too difficult to use the priority fee rate), my preference is to use an external L2 mechanism to charge the fee. +- For example: + - sequencers could require all transactions to go to a wrapper contract that extracts fees (potentially in tokens) as part of the user operation + - sequencers could require users to create independent transactions that pay the fees directly +- This is a minor preference because the annoyance of having an external mechanism may be worse than poorly specified fees. +- If we do go down this path, we should create a standard default mechanism (eg. a standard wrapper contract) to minimize inconsistencies. + +## Sequencer chosen base rate + +- If we do decide to use the L2 base fee for all charges, it's not clear to me why Taiko needs to be opinionated about the amount. +- Can we just let sequencers pick an arbitrary base fee for their blocks, disconnected from whatever else is happening in the protocol? +- My rationale is: + - as noted, we do not need to ensure they cover "costs to the network" + - this is another way of letting users and sequencers negotiate a market price, based on the realtime expected costs +- Potential counterarguments (and my response): + - this could lead to issues where compute-heavy transactions subsidize the data-heavy transactions + - I think that's a consequence of charging the same base fee for all transactions, and charging for each computational step. As far as I can tell, it's not worsened by choosing any specific number. + - this may allow wide price swings between publications if some sequencer chooses a ridiculously high gas fee amount. + - I think that risk already exists, because sequencers can demand high priority fees or refuse to sequence transactions that spend too little gas. Since sequencers have monopoly power, any scheme we come up with is going to be vulnerable to sequencers making ridiculous demands. The solution has to be some version of users setting reasonable maximum fee limits + - On the other hand, the ability to allow massive price swings may actually just be sequencers responding to real-world market conditions. + - It also lets users and sequencers be more creative about how to arrive at the correct charge given the base-fee constraint. For example, the sequencer could include all data-heavy transactions in a block with a high base fee (to indirectly charge for the L1 blobs), and then go back to regular block charges for regular L2 transactions. +- Any feedback on if I'm missing something would be appreciated. \ No newline at end of file From 4bb9da1e2da9b8666d90aba9147dc1b5d8271eac Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Thu, 24 Jul 2025 14:09:31 +1000 Subject: [PATCH 10/13] Fix heading depth --- documentation/Taiko Fee Proposal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index ebc0e8fc..60f6bb04 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -128,7 +128,7 @@ There are two challenges that I think will need to be addressed, and may depend - This is a minor preference because the annoyance of having an external mechanism may be worse than poorly specified fees. - If we do go down this path, we should create a standard default mechanism (eg. a standard wrapper contract) to minimize inconsistencies. -## Sequencer chosen base rate +### Sequencer chosen base rate - If we do decide to use the L2 base fee for all charges, it's not clear to me why Taiko needs to be opinionated about the amount. - Can we just let sequencers pick an arbitrary base fee for their blocks, disconnected from whatever else is happening in the protocol? From a8b6c0ef1ebe2910b98b1a3666cf9e6684dfb406 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Wed, 20 Aug 2025 20:37:45 +1000 Subject: [PATCH 11/13] Add Resolution section --- documentation/Taiko Fee Proposal.md | 30 ++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index 60f6bb04..5138c59c 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -142,4 +142,32 @@ There are two challenges that I think will need to be addressed, and may depend - I think that risk already exists, because sequencers can demand high priority fees or refuse to sequence transactions that spend too little gas. Since sequencers have monopoly power, any scheme we come up with is going to be vulnerable to sequencers making ridiculous demands. The solution has to be some version of users setting reasonable maximum fee limits - On the other hand, the ability to allow massive price swings may actually just be sequencers responding to real-world market conditions. - It also lets users and sequencers be more creative about how to arrive at the correct charge given the base-fee constraint. For example, the sequencer could include all data-heavy transactions in a block with a high base fee (to indirectly charge for the L1 blobs), and then go back to regular block charges for regular L2 transactions. -- Any feedback on if I'm missing something would be appreciated. \ No newline at end of file +- Any feedback on if I'm missing something would be appreciated. + + +## Resolution + +- As I understand it, this recommendation is not possible for Taiko because existing wallets do not have standard RPCs for fetching priority fees. +- Moreover, we cannot use the "Sequencer chosen base rate" alternative, because (most) wallets compute the base fee from internal node logic, so there is no place for the current sequencer to inject their preference on a per-transaction basis. +- We cannot manipulate the L2 block-producing mechanism to change the base fee arbitrarily on a per-block basis (which would allow seqeuncers to group data-heavy transactions into the same block) because the preconfirmation mechanism now enforces regular block lengths (of 2 seconds). +- Overall, this implies that at least for now, any solutions must involve + - setting the base fee for all transactions in a particular 2-second window + - be computable from a predetermined formula + - be charged against L2 computational steps +- As noted already, this means the fee will not correctly track the cost of the resources it consumes. +- Ideally, we should push for more flexible fee-choosing mechanisms, particularly for the priority fee. My preference is: + - accounts should be able to specify how they would like to select fees. + - note that this doesn't change anything about what fees are enforced by the protocol. L1 must still charge gas fees as a proxy for network costs, but L2s could set the base fee to zero. + - they should be able to specify a total priority fee as well as the priority fee rate. + - wallets will choose the fees they present to the user (before signing) as follows: + - if the account has specified an actual formula they want to use, use that. + - if the account has specified an RPC to call, use that. + - if the account has not specified a fee-choosing mechanism, use whatever mechanism they currently use. +- Until then, there are two kinds of risks that I see: + - the best case scenario is that the base fee correctly tracks the overall cost for average transactions. However, sequencers can only signal desired changes for future publications, which distorts the incentive to get it right, particularly for a diverse set of sequencers. + - transactions with higher than average data-to-L2-compute ratios will be underpriced. + - such transactions will either be subsidized by the sequencer, or will not be included at all. + - moreover, sequencers may have to process these transactions (since the actual gas consumed will be unknown until it is executed locally) before deciding to discard them. + - the same problem exists for transactions with higher than average proving-cost-to-L2-compute ratios. + - transactions with lower than average data-to-L2-compute or proving-cost-to-L2-compute ratios will be overpriced. +- Note that this doesn't change the treasury fee analysis. I still believe that Taiko can direct a fraction of the measured L1 costs to the treasury, instead of (or in addition to) the base fee fraction. \ No newline at end of file From 95a81de699495aeba853aec9f677865b478f31bb Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Thu, 21 Aug 2025 16:39:57 +1000 Subject: [PATCH 12/13] Fix typos --- documentation/Taiko Fee Proposal.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index 5138c59c..56100c11 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -20,10 +20,10 @@ I will first describe my suggested proposal, and then explain the rationale. 1. L2 gas should only cover L2 execution. There are two options: - - use the existing EIP1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. + - use the existing EIP-1559 mechanism, [corrected](https://github.com/taikoxyz/taiko-mono/issues/19160) to account for variable-length blocks. - charge for publications (not transactions): - set the base fee to zero - - use an EIP1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. + - use an EIP-1559-style mechanism to charge the sequencer for the total gas used in their publication and to maintain a per-second gas target. - sequencers can decided for themselves how (or even whether) to charge each user for their gas consumption. In the simplest case they would use the L2 priority fee, but users with no ETH could also pay in other tokens or MEV-rich transactions could be subsidized. The protocol remains completely unopinionated about how sequencers charge users as long as the sequencer pays the protocol. - some or all of the protocol fee can be directed to the treasury or burned. 2. The protocol does not compute or enforce any L1 data fee requirements. @@ -74,7 +74,7 @@ Note that under this design, the costs for a publication are self-contained, so - As I understand it (although this should be validated), since there is no security reason to encourage users to run L2 nodes, we do not need to charge for "costs to the L2 network". This means the L2 gas fee can be set to zero. - The sequencer may still want to charge for the offchain processing costs, but this can be incorporated in the priority fee. When combined with the other recommendations, it also means that users and sequencers just need to negotiate a single priority fee to account for all the resources (L2 gas, publication costs and proving costs) associated with the transaction. - However, we probably do want to include an overall gas limit to ensure that other users can keep up with the chain. I suspect it can be large enough that it is never reached in practice (because the publication and proving cost limits will likely be reached first), but it is still necessary to prevent malicious compute-only transactions (like running an infinite loop). -- Once we've decided to include a limit, I think it also makes sense to have a smaller target, so that unexpected volatility does not create immediate scarcity (and correspondingly very high prices). The EIP1559 mechanism seems like a good way to regulate this. +- Once we've decided to include a limit, I think it also makes sense to have a smaller target, so that unexpected volatility does not create immediate scarcity (and correspondingly very high prices). The EIP-1559 mechanism seems like a good way to regulate this. - However, applying the mechanism to the sequencer (instead of the transactions) has some benefits: - it is simpler. We only need to do one update calculation per publication (rather than for every block) - We can charge the sequencer at the new rate after accounting for any excess they personally introduced (rather than allowing their publication to increase the costs for the next sequencer) @@ -83,7 +83,7 @@ Note that under this design, the costs for a publication are self-contained, so ### Publication Costs - Since sequencers must pay the publication costs, it seems natural for users to compensate them directly. - Moreover, sequencers are incentivised to optimise the publication costs, and can pass on those optimisations to the user (for example, they can offer discounts for transactions that compress well with other transactions in the publication). -- When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee, it would not be subject to the EIP1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. +- When discussing this idea, one concern was that if the publication fee was not incorporated into the base fee, it would not be subject to the EIP-1559 mechanism to smooth volatility. I suspect that's incorrect, because the fee should be the sequencer's best estimate at what the L1 publication costs will be, which are already governed by the L1 fee-smoothing mechanism. - With this mechanism, Taiko does not have to model the L1 changes, but can still direct a fraction of the actual (not estimated) publication costs to the treasury. - this doesn't remove the need for sequencers to be able to estimate L1 costs when deciding whether to preconfirm a transaction. However, they can respond to the market conditions in realtime with whatever level of sophistication they have. - If standardisation is preferred, Taiko could still create a suggested fee formula that sequencers can use. @@ -149,7 +149,7 @@ There are two challenges that I think will need to be addressed, and may depend - As I understand it, this recommendation is not possible for Taiko because existing wallets do not have standard RPCs for fetching priority fees. - Moreover, we cannot use the "Sequencer chosen base rate" alternative, because (most) wallets compute the base fee from internal node logic, so there is no place for the current sequencer to inject their preference on a per-transaction basis. -- We cannot manipulate the L2 block-producing mechanism to change the base fee arbitrarily on a per-block basis (which would allow seqeuncers to group data-heavy transactions into the same block) because the preconfirmation mechanism now enforces regular block lengths (of 2 seconds). +- We cannot manipulate the L2 block-producing mechanism to change the base fee arbitrarily on a per-block basis (which would allow sequencers to group data-heavy transactions into the same block) because the preconfirmation mechanism now enforces regular block lengths (of 2 seconds). - Overall, this implies that at least for now, any solutions must involve - setting the base fee for all transactions in a particular 2-second window - be computable from a predetermined formula From cb1b1cc4c6ea2edbfd36c87d6c78ca0894f309b8 Mon Sep 17 00:00:00 2001 From: Nikesh Nazareth Date: Thu, 21 Aug 2025 16:42:32 +1000 Subject: [PATCH 13/13] Mention walletbeat as an influence option --- documentation/Taiko Fee Proposal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/Taiko Fee Proposal.md b/documentation/Taiko Fee Proposal.md index 56100c11..55a29c94 100644 --- a/documentation/Taiko Fee Proposal.md +++ b/documentation/Taiko Fee Proposal.md @@ -155,7 +155,7 @@ There are two challenges that I think will need to be addressed, and may depend - be computable from a predetermined formula - be charged against L2 computational steps - As noted already, this means the fee will not correctly track the cost of the resources it consumes. -- Ideally, we should push for more flexible fee-choosing mechanisms, particularly for the priority fee. My preference is: +- Ideally, we should push for more flexible fee-choosing mechanisms, particularly for the priority fee (perhaps by influencing the [wallet beat](https://github.com/walletbeat/walletbeat) criteria). My preference is: - accounts should be able to specify how they would like to select fees. - note that this doesn't change anything about what fees are enforced by the protocol. L1 must still charge gas fees as a proxy for network costs, but L2s could set the base fee to zero. - they should be able to specify a total priority fee as well as the priority fee rate.