Mark Tyneway

> Could this be handled at the dependency set selection level? It totally could, it would be a social consensus kind of thing. Because the chain operators have this ability,...

@protolambda curious how you feel about this spec - what are the next steps with it?

It would be good to have a `view` function on the contract or in another predeploy that accepts a block body and returns a bool if the block is valid...

For this to work with deposits, dropped blocks would need to be mapped to deposits only blocks per https://github.com/ethereum-optimism/design-docs/pull/20

> another idea that might help quite a lot with interoperabolity would be to add an execute instruction after the mint. i.e. "pseudo-code example" > > ```solidity > function bridgeERC20To(address...

To enable the token standard to scale, we are going to want to use a factory that uses a [create3](https://github.com/0xsequence/create3) style deployment to ensure that we don't always enforce every...

Much of the design has already been fleshed out for interop. The high level is there is a new setter function on the `OptimismPortal` for spoofing the depositor address via...

The following mermaid diagram shows the control flow: ```mermaid graph LR subgraph L1 SystemConfig -- "setConfig(uint8)" --> OptimismPortal end subgraph L2 L1Block end OptimismPortal -- "setConfig(uint8)" --> L1Block ``` The...

The specific reason why this is being descoped is due to the way that it impacts proofs. With https://github.com/ethereum-optimism/specs/issues/122#issuecomment-2293704907 as context, the L1 attributes data is in history (transaction calldata)...

Including historical context for the diff based L1 attributes tx as one attempt to deduplicate calldata from the L1 attributes tx: https://github.com/ethereum-optimism/specs/pull/375