A malicious sequencer could grieve, but it is very unlikely that their block would win in that case. for the following reasons:
The block commitment contains a transcript of the rollup proof effectively assigning, one prover to a given part of the tree. The proposers score is dependant on that prover constructing that proof. If they do not (as the block was not revealed) the score will be lower as a result.
There is a higher cost to this attack as it would require submitting 2 transactions on chain (1 for the block commitment, and one for the proof). The cost to reverse incorrect slashing for an honest prover is only 1 transaction, so the attack is unlikely to prevail.
Since the provers need to vote blindly to the parts of the block, I think TXs withholded by the sequencer can be problematic. The sequencer can withhold a tx pertaining to a part of the block one “attacked prover” has voted on. If raw TXs are not published on L1 with the block proof the attacked prover will be slashed, because he won’t be able to generate the valid proof to revert the slashing, by never having access to the withholded TX. If you have enough “score legroom” as a proposer, you’d be able to choose to slash specific provers of competitors. If the raw TXs are published on L1 then the time window for reverting slashings have to be sufficiently large to allow the prover to do the proving work after the block has been submitted to L1.
Another idea is that the ability to revert a slashing opens the ability for the provers to manipulate scores of blocks, where they commit to blocks of other proposers and then they don’t provide the proof to the proposer and they just revert the slashing afterwards. The proposer score will be affected by this and they can use this mechanism to choose which proposer wins. I’m assuming the the revert of slashings happens after the PROOF_ACCEPTANCE_WINDOW where the winner block has already been determined.
I don’t see that provers need to vote blindly. The proposals are shared on L2 gossip network, so the provers can compute the commitment and see if it matches what is on L1. Only if the block is available to you will you then want to vote on the block and share this intent on the gossip network otherwise just ignore the proposal.
A commitment to the order of transactions in the block (a random secret is used as this will be revealed later).
This protects the MEV-extracting ordering from being disclosed before provers have already commited but It has the side effect of making the provers vote blindly. If the provers only voted for blocks they know, they’d have to be controlled by the sequencer if the sequencer doesn’t want to disclose the tx selection and ordering.
The only issue with provers voting blindly, is that they may vote on a block they can’t produce. I am not too worried about this for the following reasons:
There is a cost to the proposer to sustain this attack. They have to commit a transaction to L1, and get a block made and published on L1.
If a proposer does manage to do (1) an honest prover can always create a proof after the fact to reverse any slashing as a result of the greiving prover. The data will be available at that point.
An all pays prover model will also likely detract from this occurring.
If this is deemed an issue, the transaction order can be made public along with the block transcript commitment on L1. The main goal is that the proposal on L2 is hidden to prevent gazumping of a profitable ordering.
This is very unlikely after the commitment is broadcast to L1, as such a commitment has amassed hundreds of unique prover votes which a new proposal will struggle to do. (A vote contains the block hash, which is unique to the proposer sending it)
Is coordinating votes on L1 not very costly? For example, if you have 100 entities voting per block that’s 100 L1 transactions whose cost will have to be borne by L2 tx fees.
Even a basic voting protocol will likely change 2 state variables (~50k gas per tx), so we could be looking at 5 million gas per block just for coordinating votes for 100 participants.
One random thought is: what happens if we change B52 from voting per-block to being more of a prediction market?
The votes are proved via a ZK snark verified on L1, so there is a fixed cost to verify. This is amortised with the rest of the networks computation so only 1 snark verification is needed for each block around ~3-400k gas.
I see that the B52 and the Fernet proposals are in the ‘finals’, may we know what kind of mechanism will decide which one becomes the ‘‘one’’?
Is it going to be purely Aztec engineers’ decision or is there going to be some kind of voting?
(I personally would favour the first way or in case of voting, a voting among engineers of Aztec and maybe some other friendly teams from of the ethereum/zk community)
Aztec Labs will put forward a recommendation and final spec as a request for comments. This will take into account a report written by BlockScience, that will be shared publicly in the coming weeks.
We will update the main thread once we have a decsion.