interop: update predeploys.md

[0xParticle]

Description
Updated the predeploys.md spec to include details on the new OptimismMintableERC20Factory.
I only focused on the updates to keep it similar to the L1Block section (also an update), but did not make any comments about the actual public and external functions, or invariants. I can include all of this and turn it into a more explicit update or a full spec.

[tynes]

nit: trailing s reads strange in "OptimismMintableERC20s"

[tynes]

A quick sentence for rationale here would be good, like these are used to ensure that there is a single unique token address per set of ERC20 metadata

[tynes]

Looks good to me, one could say that the SHOULDs could be changed to MUST since its not optional, see https://datatracker.ietf.org/doc/html/rfc2119

[0xParticle]

@tynes Do you think its worth mentioning something about the external functions and invariants here? I also haven't mentioned anything about the deployments one time update with the token list, which will be part of the first update.

[tynes]

external functions and invariants here

I do think that would be useful here and keep a high bar for the specs

[tynes]

I don't think we want to go deep into the one time update for the tokenlist here, that is something we should do a design doc for and not add to the specs

[0xParticle]

external functions and invariants here

I do think that would be useful here and keep a high bar for the specs

Added both. Let me know if you agree.

[agusduha]

We are adding a new contract inheriting form OptimismMintableERC20Factory to make these updates.

Should we create a new function createWithCreate3 to be called from createOptimismMintableERC20WithDecimals so that we can add it to the new contract? Or do u prefer to directly change the code in this function?

[0xParticle]

We are adding a new contract inheriting form OptimismMintableERC20Factory to make these updates.

Should we create a new function createWithCreate3 to be called from createOptimismMintableERC20WithDecimals so that we can add it to the new contract? Or do u prefer to directly change the code in this function?

@tynes this would affect the specs. We could simply modify the existing createOptimismMintableERC20WithDecimals or adda new function that createOptimismMintableERC20WithDecimals will call (similar to how previous upgrades where extended). wdyt?

[tynes]

I thought we decided to use CREATEX and also not update the OptimismMintableERC20Factory to use it?

[tynes]

This leaks an implementation detail into the name, not a fan of this style of naming

[tynes]

I think we could get away without implementing the whole function here and instead precisely define the salt in natural language and the invariant that the mapping must be updated

[0xParticle]

perfect. Will also remove the reference implementation for the others