Note, the answers I’ll provide are our current design and may change in the future. That being said:
** How exactly is a challenge posted? What is the stake?**
Challenge would be posted on a block by block basis. So you would just challenge an entire block if any aspect of the transition is invalid.
If by “stake” you mean block bond, the bond would be something reasonable enough to create crypto-economic guarantees around wanting to both fraud prove and win the game and receive a portion of the winnings. In our case, the bond range per block would be something between .1 - 1 ether per block (TBD). Note that similar to Fuel V1, if the block is valid, you would get that bond back at the end of the dispute window (in our case between 8hs - 7 days… TBD).
** Is there an interaction game at all? At least from finding the right block from the batch?**
We minimize the interactive game down to a single round. So it’s not a multi-round game, it’s just “if a block is invalid, post a fraud proof, everyone builds off the next most valid block in the meantime”.
Having a simple game ensures we don’t need a complex multi-step crypto-economic game to ensure security, it’s simply, if a block is invalid, just produce a valid ZK proof to show that.
** What is the prover used for the validity proof generation?**
For our first version of the Fuel prover we will likely use Risc0, but we play to include other provers such as Powdr and zkSyncs LLVM proving architecture in the future. An additive approach will ensure that even if a single proving archiecture has a bug, that there are fallbacks to workout disputes.
In the future, Fuel will just have a full zkFuelVM and we would step away from optimistic techniques entirely once ZK is ready.