thank you. So basically there is a default return value that just gives you transaction receipt information? So you're saying the return vlaue in solidity is only relevant in solidity world, but that's totally separate from the js return value. thank you.

IMO, the EIP could be improved by storing the log trace of updates off-chain in an immutable way, using arweave or pinata. Ethereum nodes are no longer required to store the full history of the blockchain, and these updates could easily be stored off-chain using for example an append-only linked list of update files.

ok, so by "does not affect the state of optimism", you don't mean the optimism layer 2 chain (which IMO is the more obvious interpretation of that statement) -- you mean the state of optimism from the perspective of the layer 1. that makes sense. but it should be clearer that the state of optimism on the actual optimism chain absolutely does change with a fraud proof, and that building on top of it in real time is virtually impossible under the assumption of frauds happening.

@VictorBjelkholm but if we are encrpyting the content before taking the hash, can we really say that the file is content addressable? There will be different "versions" of the file that have the exact same unencyprted content. While this doesn't negate many of the benefits of IPFS, you could argue that it waters them down?