- Each L2 ENS interface contract maintains a merkle root of the resolution status of all the names it is responsible for. This merkle tree is structured according to a standard that is identical for all L2 implementations.
So I thought about this. My main concern with it is basically that it would require all L2s to fit into the same standard in a fairly deep way, that often doesn’t naturally work well with how the L2s work. For example, a ZK rollup may want to use some special-purpose arithmetic-friendly hash function for their Merkle tree, or even abandon Merkling outright and use a Kate commitment, etc. Forcing them into a (realistically sha3-based) Merkle tree would mean that that one part of their system would either require vastly more effort to SNARK-prove than the rest of the system, or have lower security guarantees than the rest of the system.
We cannot easily use this directly, as the format is likely to be different for each L2 implementation. Instead, we could require each interface contract to expose a
resolveName(bytes32 namehash, bytes witness)
I do like this. It is definitely a good way to generalize beyond just Merkle trees; allow the rollup to specify its own witness format and verification function, and solves the problem above. And it could be generalized to not just names but also general state reading.
One challenge is that it does not generalize well to static calls that actually do require non-trivial state reading. Though I suppose you could do something clever where in a zk rollup the witness verification would just verify a ZKP of the execution, and in an optimistic rollup the “witness” would just need to include a signature from an attester with a locked balance! I guess the goal would be that ideally in the OR you would want the sequencers themselves (or other full nodes that already have deposits for whatever duties in the OR) to be providing responses to the static calls.
So this does seem like it leads in an interesting direction! Basically instead of “enshrining” the security-deposit-based mechanism, we allow L2s themselves to define a way to execute a static call given a particular state root (or in a plasma chain block index or whatever); that way could just be direct witness verification, or it could be verifying an off-chain signed message that can be challenged if false. The only thing that is “enshrined” would be the API that you would call into an L2 to verify a static-call with some witness.