Data structure during arbitration process

[tianyinglan]

Discussion Topic

I would like to request help. I am a blockchain engineer and currently researching optimism. We hope to place the arbitration process of l1 off the chain and implement OP proof on btc (because btc does not have an EVM execution environment). However, I have a few doubts.

1. If we want to implement the arbitration process of l1 off the chain, is this feasible? What data needs to be obtained from l1 (btc) and l2, and what data needs to be uploaded to l1 after arbitration is completed?
2. Prologue is a load of the inputs, given minimal bootstrapping, with possible test overlaps. The component of, but I couldn't find the corresponding implementation. Can you tell me which file the code for this implementation is in;
3. What is the specific content of the preimage of l1 and how was it obtained;
4. I saw the logic from l1 deriving L2 blocks in https://github.com/ethereum-optimism/optimism/blob/develop/op-node/rollup/derive/pipeline.go Inside, but I didn't see the process of generating the corresponding l2 block. Can you tell me which code file and lines the specific implementation of generating the l2 block is in;

[sbvegan]

Hey I'll work on getting a protocol engineer's eyes on these questions. If you haven't seen them yet, here's some references you can take a look at:

• https://docs.optimism.io/stack/protocol/fault-proofs/overview
• https://specs.optimism.io/experimental/fault-proof/index.html

[tianyinglan]

Hello, I have read these two articles, but I still don't quite understand the aspects in my question. I still need more detailed assistance

[sbvegan]

Hey @tianyinglan, I was able to get some initial thoughts from one our our protocol engineers:

Honestly don't know if it'd be possible off the top of my head. Suppose you could do the fault proof off-chain and commit to the game resolution, though would also need a way to challenge the commitment to the proof on BTC which may recurse (and this makes the interactive nature of the off-chain proof not really pertinent.)

It sounds like you're trying to pull our fault proof into a non-interactive system and that raises some initial flags of concern.

Some additional resources they mentioned you can take a look at are:

• You can take a look at the Fault Proof Program specs,
• Taking a look at the op-program where "prologue, execution, and epilogue" phases are actually implemented.
• The program is run on cannon, the fault proof VM, to generate state witness hashes at any given cycle during the op-program's execution on top of it