Thanks, I want to clarify some differences in design intent, even though we have points of intersection in design. Actually, I’m looking for a more comprehensive and secure solution for installing arbitrary modules, which are often unverified and therefore potentially contain malicious backdoors for wallet hijacking. InvariantGuard is designed to protect users when making arbitrary external calls without unintentionally altering the storage layout. Issues related to administration and layout design (such as ERC-7201) are not the focus, although they are still important. But even so, they still can’t protect complex structures like mapping, and this would require a change from the protocol, I’ve already proposed an EIP for this problem. The module verification methods you proposed are still very valuable, but I need a more robust solution for unverified modules to maximize the potential of modular contract programming.
The modular contract design also needs further discussion because most of them are based on the diamond contract prototype. Because the diamond contract itself is already configured, it’s difficult to configure it in a way that allows it to define a new configuration, making it difficult to adapt to future upgrades. A temporary solution is to use an unconfigured, upgradeable proxy (like ERC-7229), but this makes the diamond a logic layer instead of a complete prototype. I’m currently researching a Diamond proxylation solution with the design approach described above. What do you think?