Thanks to @Premm.eth for putting forward this highly creative draft. Introducing the IContractName and IContractNamer interfaces to solve the reverse resolution pain points for complex smart contracts (like multisigs or non-Ownable contracts) is indeed a very clever approach.
For ENS—a core piece of Web3 infrastructure—stability, security, simplicity, and ease of integration for the downstream ecosystem (like frontend libraries and data services) are the cornerstones of its long-term development.
After a cautious consideration for the overall system complexity, I have a few thoughts about this proposal.
1. Data Tracking Pressure and Spam Prevention
Currently, off-chain data tracking tools like The Graph only need to monitor a single central ENS contract to capture all name changes across the network. However, under the new draft, any smart contract on the network could trigger a name change event. This means tracking tools would have to constantly scan every corner of the entire Ethereum network to find these events.
I am a bit concerned: could this place a massive computational and storage burden on data service providers? Furthermore, could malicious actors deploy contracts at a very low cost to spam fake name-change events, thereby flooding our databases with garbage data?
2. Spoofing Prevention and Potential Resource Exhaustion Risks
To prevent a malicious contract from arbitrarily naming itself something like ”base.eth" (identity spoofing), our resolution system will inevitably need to double-check if the contract is actually the true owner of that name after reading it.
If this “two-way verification” happens on-chain, would it significantly increase the Gas cost of resolution? What worries me a bit more is: what if a malicious contract intentionally writes extremely resource-heavy code inside the function that provides the name? Could this cause frontend applications to crash due to running out of Gas when trying to read the name? Do we have any corresponding safeguards or limitation mechanisms in place?
3. The Trade-off Between Ecosystem Adaptation Complexity and Actual Adoption Rate
This is an ENS-specific improvement proposal, not a global Ethereum standard. Asking contract developers across the network to proactively implement these interfaces might require a very long adoption cycle.
My concern is that if only a small number of contracts end up implementing this interface in the future, our core resolvers, frontend base libraries (like viem/wagmi), and all data services will still be forced to permanently add a set of fallback query logic just to be compatible with them. Is the trade-off of permanently increasing the complexity of the entire ENS infrastructure worth the convenience it brings to a minority of contracts?
Hope that while we decentralize naming rights to contracts, we can ensure the ENS infrastructure remains lightweight and bulletproof.