fix(protocol): make block minTier selection deterministic

[dantaik]

from OZ:

The problem: With the current code, provers could theoretically never have to provide any zk proof. This could lead to zk provers not being incentivized to monitor Taiko blocks (to contest any invalid proof). Do we agree on this ?

About the pr: The pr is an improvement over the previous state IMO, but doesn’t address the payment of the fee to the assigned prover. In the pr, the fee of the prover would always be the same (because minTier == 0), no matter if the block turns out to have min_tier zk proven or SGX proven. I don’t see an easy way around this issue without adding a bunch of code (something like proposer would advance funds (how much tbd), part of which would be paid later to prover when min_tier is determined, rest being refunded).

A partial solution: How about making the min_tier deterministic as a function of numBlocks ? For example, minTier = ZK if numBlocks % 100 == 0 else SGX. It’s a bit naive, but it’s simple and at least zk provers are guaranteed to have some blocks to prove. The difficulty the code is computing would still be used as randao on L2.

[openzeppelin-code[bot]]

fix(protocol): make block minTier selection deterministic

Generated at commit: 0644a30ca71374ccbc9b73d37342b1b4ab3583b6

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 5 41 50
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[adaki2004]

For me it seems only better from prover point of view (so they know when exactly ZK proofs needed) but this implies we might see a dropout around ZK-proven blocks from proposer point of view, bc. if ZK proof costs more money (less revenue), they would just wait X blocks to have SGX only.

With the current system it is also possible - but less deterministic (pseudo-random) at least.

And also in my opinion ZK is either there entirely or not at all. So once we have SP1/Powder/R0 running soon (hopefully in x months) we can just require ZK proofs per each block.

[dantaik]

For me it seems only better from prover point of view (so they know when exactly ZK proofs needed) but this implies we might see a dropout around ZK-proven blocks from proposer point of view, bc. if ZK proof costs more money (less revenue), they would just wait X blocks to have SGX only.

With the current system it is also possible - but less deterministic (pseudo-random) at least.

And also in my opinion ZK is either there entirely or not at all. So once we have SP1/Powder/R0 running soon (hopefully in x months) we can just require ZK proofs per each block.

It seems there is no perfect solution for this one. I created this PR as I tend to like this deterministic approach as it seems to be fair for every proposers.

@Brechtpd what's your take?

[Brechtpd]

This seems to be a redo of the discussion we had back in January when I also raised this issue: https://github.com/taikoxyz/taiko-mono/pull/15568#issuecomment-1910538272.

I still have the same opinion on this than back then so I don't really have much more to add on top of this. Because even if the cost is deterministic for proposers, it's still a spike in the tx fees the users have to pay to get their transactions included so the UX seems to be quite a bit worse (if indeed the zk proof cost is expensive, if it's not expensive it would be part of the base set of proofs). You can think of more complicated ways to solve this problem but that would require substantial changes and I don't think those are probably worth it.

[dantaik]

This seems to be a redo of the discussion we had back in January when I also raised this issue: #15568 (comment).

I still have the same opinion on this than back then so I don't really have much more to add on top of this. Because even if the cost is deterministic for proposers, it's still a spike in the tx fees the users have to pay to get their transactions included so the UX seems to be quite a bit worse (if indeed the zk proof cost is expensive, if it's not expensive it would be part of the base set of proofs). You can think of more complicated ways to solve this problem but that would require substantial changes and I don't think those are probably worth it.

yeah, we have been back and force on this topic and it does seem to me there is no solution without bigger modification. I tried to change the protocol so that blocks' min tier is decided by their next/child blocks, but it does involve more changes in AssignmentHook...

Let me get back to OZ with a no-go answer for this one.