chore(protocol): update Alpha-3 protocol configurations

[davidtaikocha]

Questions to discuss:

• What average block time will we use / assume for A3? (3 seconds?) => 3s seems to be reasonable
• Shall we change minEthDepositAmount to 0.1 ETHs? (some concerns here) => should be fine
• Do we need to increase the cooldown period for A3 network? (proofCooldownPeriod + systemProofCooldownPeriod) => if Sepolia generally work well and we're confident we can get these overwrite transactions in fast enough then seems ok.
• Do we need to change realProofSkipSize? (i think it depends on the avg block time that we predict) => start with realProofSkipSize: 10 for the initial wave, we can reconsider afterwards
• What treasury address will we use? => 0xdf09A0afD09a63fb04ab3573922437e1e637dE8b
• What INITIAL_PROOF_TIME_TARGET will we use? (in current internal devnet, avg proof submission time is ~80s, so shall we use 120s? if we use 120s, then initProofTimeIssued will be 49883) => 2 * 80 (avg proof submission time) = 160
• What param1559.gasIssuedPerSecond will we use? (i think it depends on the avg block time that we predict) => param1559.gasIssuedPerSecond := 2,000,000 gas/s == 4 L2 blocks of 6M gas/L1 block
• Shall we change param1559.yscale / param1559.xscale / param1559.gasExcess? => lets calculate them in TaikoL2's init() function
• Shall we make sure state.blockFee always >=1? (to prevent proposing becomes "totally free"?) => If the proposing EIP-1559 parameters are set well, seems this will be unnecessary (could be a big IF)

[Brechtpd]

Because each proof has the exact same cost currently, I think we should make it so the prover fee cannot change quickly (tweak adjustmentQuotient).

What average block time will we use / assume for A3? (3 seconds?)

Very important this matches the proposing EIP-1559 target!

Do we need to increase the cooldown period for A3 network? (

I don't know how stable Sepolia is, but if things generally work well and we're confident we can get these overwrite transactions in fast enough then seems ok to me.

What param1559.gasIssuedPerSecond will we use? (i think it depends on the avg block time that we predict)

EDIT: I confused this value with gasExcess.

Shall we change param1559.yscale / param1559.xscale / param1559.gasExcess?

See comment on this above.

Shall we make sure state.blockFee always >=1? (to prevent proposing becomes "totally free"?)

If the proposing EIP-1559 parameters are set well, I don't think this will be necessary (could be a big IF)

[Brechtpd]

• Maybe we should do minEthDepositsPerBlock: 1? Feels like that could be a big UX improvement.
• I think smart to start with realProofSkipSize: 10 for the initial wave, we can reconsider afterwards.
• Regardless of the value of minEthDepositAmount, I think there's definitely spam risk on this queue. Anybody with a lot of ETH can make the queue extremely long and we can only process a couple/block, so users may have to wait a long time to get their ETH deposit if abused.
• INITIAL_PROOF_TIME_TARGET = 80s * 2
• prover fee adjustmentQuotient: feat(protocol): Scale up damping factor and flatten curve #13809
• param1559.gasIssuedPerSecond := 2,000,000 gas/s == 4 L2 blocks of 6M gas/L1 block. Seems reasonable to me and is the proposed 3s block times. Other values:

struct EIP1559Params {
        basefee = ? (could just be 0 to start);
        gasIssuedPerSecond = 2000000;
        gasExcessMax = ?;
        gasTarget = 2000000 * 12;
        ratio2x1x = 11250;
    }

Unfortunately not so easy to find all the correct values here because some manual tweaking necessary in the helper script which I haven't tried to do. Something easier and fully automatic like https://github.com/taikoxyz/taiko-mono/blob/main/packages/protocol/script/DetermineNewProofTimeIssued.s.sol + some input parameter simplification #13556 like with the proving fee would certainly help to make this easier to configure!

[davidtaikocha]

Updated the configs based on PR feedbacks: 1f6eed5 , plz review @Brechtpd @dantaik

[Brechtpd]

Have we seen the proposal basefee work within reasonable ranges on our internal testnet?

[davidtaikocha]

Have we seen the proposal basefee work within reasonable ranges on our internal testnet?

In current internal devnet, all provers will at least wait proofTargetTime before submission, but right now the baseFee is still 0, and i think @adaki2004 is working on tuning the parameters.

[Brechtpd]

Ah yeah I heard about that!

It looks like how I name things is a bit confusing, what about the L2 basefee that the proposer pays on L2? That one also depends on proposing blocks at fixed intervals (same as with the proofs) to keep the basefee steady. So was wondering if the behavior there was as expected and we can for sure push that L2 basefee pretty high in a small amount of time (we need that high L2 basefee to prevent spam).

[dantaik]

@davidtaikocha @Brechtpd @adaki2004 Do you think we should get onto a call to quickly resolve this issue?

[davidtaikocha]

@davidtaikocha @Brechtpd @adaki2004 Do you think we should get onto a call to quickly resolve this issue?

after upgrade the proxy implementation and use Dani's new params:

ProofTimeTarget: 150
ProofTimeIssued: 162263074
BlockFee: 1e8 ( 1 TKO was set so far so i guess we stick to it.. if you disagree i need to recalculate the proofTimeIssued)
AdjustmentQuotient: 32000

seems the fee backs to stable again at least for last hour. and before that, our client sometimes will submit the proofs asap, and zkpool's client also always submits proof asap, i think this is also part of the reason.

[davidtaikocha]

@davidtaikocha @Brechtpd @adaki2004 Do you think we should get onto a call to quickly resolve this issue?

And im ok for a call to do the final overall checking of this PR.

[Mehrabani61]

#13483

[Mehrabani61]

Duplicate of #

[Mehrabani61]

update-alpha-3-configs