Right, but you get exactly the same level of security from a centralized database storing those signatures. If youâre not going to verify the blockchainâs state proof, you gain no benefit from using a blockchain, and it isnât trustless.
No, they canât - because they can only produce valid proofs of L2 state; any invalid proof will be rejected by the contract that verifies the response.
No, itâs strictly more secure, because unlike an RPC endpoint, a gateway cannot lie.
My claim is that you must own a .eth or a web2 domain name to have a 2LD on an L2. 3+ is different but ENS has no control over subdomains.
We use the EVM-gateway to trustly forward any namespace from L1 to an L2 where everything can be proved (must be on-chain but content agnostic)âand then make that work with IMulticallable interface.
ENS can create the L2 registry at the standard address, setup a reverse registrar, public resolver, and associated nodes. Account holders can claim their reverse record and then build out any hierarchy they want reusing ENS infrastructure with L2 gas fees.
The L1 just needs to know the rewriter, which transforms ___raffy.eth to __51050ec063d393217b436747617ad1c2285aeeee.addr.reverseâfor example the OwnedRewriter contract (adds the ownerâs hex address). The gateway resolver contract verifies a storage proof for a Multicallable bundle.
The name 51050ec063d393217b436747617ad1c2285aeeee.addr.reverse can be claimed on an L2 w/o additional permissions or changes to ENS. From there, an entire L2 ecosystem can be built when combined with the PublicResolver. And the whole thing is immutable and trustless.
An underscored UUID registrar could mint base32-encoded names (z34ad._id) for same purpose, except these basenames could be transferred, whereas the OwnerRewriter transfers trust from the L1 (since the owners match).
I made a helper contract that offers the IExtendedResolver.resolve(name, request) interface that does the following:
resolve().request is a IMulticallable.multicall() wrapper, decode it and call those functions directly on the resolver, then return the results encoded.request directly on the resolver.This makes it so, for any name thatâs dns-encodable (under 256 bytes per label, 99.98% of known names), you can call it like IExtendedResolver and you can give it any request, including multicall(), and it only does 1 CCIP request.
I made a simple demo that resolves both "adraffy.eth" (onchain, PublicResolver) and "raffy.gmcafe.eth" (wildcard, that supports multicall()) via the same call to the helper contract.
For this to work, servers must implement the multicall() interface (which is really simple since you just call your own resolver recursively.)
I think if the recursive CCIP limit was higher (ethers uses MAX_CCIP_REDIR = 10, but that code could be unrolled), in the case where the server doesnât implement multicall(), you can encode an iterator into extraData, but I havenât tested this yet.
While implementing this, I noticed that my own CCIP implementation was too strict, as I was only allowing requests originating from my own resolver contract. To support recursive CCIP, you need to accept requests from any contract.
Nick, can you clarify was was meant by EIP-3668 âUnsuccessful requests MUST return the appropriate HTTP status code - for example, 404 if the sender address is not supported by this gatewayâ. I originally interpreted this to mean, sender = my contract, but I feel like the sender should only be used to block malicious senders (otherwise recursive canât work.)
Fortunately, even if recursive calls arenât supported due to restricted sender logic, the client can always call the wildcard resolver directly. The helper contract just makes this more universal.
Creating an EVM gateway contract that can do similar decoding and prove the entire request, including a bounce through a L2 registry, is the next step.
I think weâre mixing up multiple typesâŠ
a) web2 gateway+db with gateway signer
b) web2 gateway+db or L2 with managerâs signature
c) web2 gateway with L2 state/storage proof
d) L2 RPC with managerâs signature
(a) & (b) are similar but (a) is depending on gateway signer not to lie/sign & return bad data.
(d) is dependent on CAIP22 like format & currently thereâs no way to access L2 RPC endpoints directly.
(c) canât use CAIP22 âlikeâ formats? as itâs a web2 gateway reading L2 state/storage proof from L2 RPC endpoints on backend. ?some extra works on client side can unlock do that too?
To extend (b) weâre requesting CCIP gateway urls to support ipfs://⊠ipns:// bzz://⊠protocols so ccip can access web3 storage providers from client side without any web2/ccip gateway in middleâŠ
state/storage proof is best option and I guess ENS will run official gateways to multiple L2s ⊠still thereâs 2 minor benefits for supporting wb3 data/caip22 like formats, we donât have to run a web2 gateway in the middle⊠&& we get extra privacy by not requesting data from random web2 gateway used by different domainsâŠ
As itâll be backwards compatible both can still be used as fallback mechanism.
@raffy I think you changed addr() in normalization/resolver page recently? & I see addr(60) in your example page too.
There are two addr() returns (address) & addr(node, 60) returns(bytes) for ETH address⊠As addr() is from original resolver our wildcard/offchain data is using addr() format but our data is stored in addr(60) space *as address instead of bytes(address)âŠ
So I was wondering if we should skip using addr()/address and always use addr(60)/bytes format?
What name is this? Ah freetib.eth, Iâll look into this.
Your addr(60) isnât encoded correctly, and I wasnât doing normal addr() during wildcard. Fixed.
Over the last week Iâve had a play with this and published a pull request for this (in the context of L1 multi target resolution for now) here: Initial implementation of multi-target CCIP read by clowestab · Pull Request #28 · ensdomains/evmgateway · GitHub
Iâd be appreciative of feedbackâŠ
Iâm rereading everything trying to get context/understanding of the ideas being put forward here.
This reads as being unnecessarily complex. The evmgateway code as is caters for this need anyway in that you can query multiple pieces of data from a resolver you just need to know the base storage slot of each value you want. Once youâve discerned the resolver address and chain this can be done on any EVM compatible chainâŠ
What do you mean? 0x123 reverse resolves on an L2 to sub.raffy.eth. If the user has the private key for 0x123 so as to have set the reverse resolver on that L2 in this case do we care about L1?
Yup, I see this.
?? What do you mean. You do discern (and can keep track of) the node that is resolving a subnameâŠ
Iâve re-read this multiple times and Iâm getting lost in its complexity when in reality I donât think it is actually that complex
It really depends what is going on behind the scenes - you can have 1 CCIP fetch request but then the gateway be sending off multiple RPC calls behind the scenes. OR the gateway could use multicall behind the scenes OR the gateway provider could implement their own middleware contract that batches these data requests and returns them as packed data (Iâve done this before with some of my tooling).
Oh I see, youâre basically implying it should be provided by ENS natively? Iâm not convinced - theres a lot of pros to keeping the core contracts as simple as possible, and middleware providers can simply build on top of ENS. If you really wanted to directly you could do this in a hacky manner through the resolve method of ENSIP-10.
Iâm in this camp. A well reputed service provider storing signed data in a centralised database offers the same security guarantees. The core concern would be that provider not responding (or disappearing completely) so the key is the well reputed bit. An L2 could also disappear.
Again, Iâm confused. This doesnât seem to follow the ENSIP-10 specâŠ?
Clients are meant to recursively iterate through the name tree until they find a resolver that implements at which point they call resolve. This seems to be a resolver that finds a resolver in its resolve�
This might be more performant than a client (JS for example) discerning the resolver but iâd imagine in reality unless we are talking 10 levels of nested subdomains the performance difference would be negligible, but yeh⊠crucially this isnât an implementation of the specification?
More generally whilst this thread is super informative (and definitely needed) there seems to be a lot of different tangents being discussed and it is not particularly easy to follow (IMO). Iâm also not sure that a level of agreement has been reached whereby a summary of current thoughts could easily be collated 
Sorry this thread is all over the place. You can ignore the original idea of switching chains.
This looks good to me. For the use case above, I want to read the resolver address from L2 registry, switch to that target, and read multiple records.
The existing IMulticallable interface is sufficientâI didnât know it existed. I think wildcard servers should be encouraged to handle this request.
My thinking is this resolve() function should also process IMulticallable.multicall.selector.
To benefit from multicall() (single fetch) ENS clients need to be issuing requests in this style.
There are (5?) possible schemes for reading records of a name:
(m = registry reads, n = resolver reads)
resolve() per recordresolve(multicall) all recordseth_call per recordsupports(multicall) â call multicall() (internal multicall)My example above was just an experiment to provide a common interface that is O(1-2) for all types. Itâs not a resolver itself per se. It does implement ENSIP-10. It lets you multicall an on-chain resolver from 2017 using IExtendedResolver interface.
I think CCIP fetches need to be bundled for complex dapps. For example, a social site will want to query multiple records per user per page load.
For querying âall your recordsâ, like viewing an user profile, I suggested doing a single multicall() with common records + a record that indicates (here are my rare records), which collapses many requests to 1-2.
This is cool! Would you consider contributing it to the universal resolver?
This is a really obvious thing to do, and I donât know why I didnât think of it.
Would you be happy to open a PR against GitHub - smartcontractkit/ccip-read to add this to the base gateway implementation?
Thatâs correct. Though I wonder if the correct solution here would be to implement multicall on the resolver too, having it just call multicall on the server?
Yes, I understand what youâre asking for. What you donât seem to understand is that if you just call a public RPC provider, and donât verify its responses in any way, itâs exactly equivalent to just storing those responses in a centralized database, from a security POV. The only thing you gain is the convenience of not having to host your own server, and instead relying on using an L2 as your database.
Gateway authors and contract authors can choose their security model for CCIP read; they can do anything from just trusting the gateway response at one extreme, to verifying everything against the L2âs state root onchain at the other extreme. With the scheme you are proposing, however, the latter becomes effectively impossible; the upper limit of security that can be achieved with it is simply trusting the public RPC node the client is using.
I honestly donât understand why you think this is a beneficial addition to the protocol.
Someone has to run a public endpoint in either case; whether itâs a JSON-RPC server for the L2, or a CCIP-Read gateway is immaterial. Itâs certainly not worth throwing away all security guarantees for the convenience of not hosting a server somewhere.
There are no privacy benefits here either, because the JSON-RPC server the client uses can also log their requests.
Iâm talking here about the case where a user wants to start on L2, and do forward resolution of a name. The L2 would provide a wildcard resolver that fetches state proofs from L1 - but what if the user is using a custom resolver implementation on L1?
Quick input:
I think there is a clear difference in the trust assumptions of Nick and C0de. C0de trusts public gateways more than the ability of end users to verify CCIP gateways of their service providers; Nick is diagonally opposite on the trust spectrum. Both have valid points.
if you just call a public RPC provider, and donât verify its responses in any way
@nick.eth Verification can be built cheaply for some storage types and their public endpoints. For example, if I query ipfs/Qmbla from any public IPFS gateway, I can verify its contentâs legitimacy by calculating CID(content) = Qmbla. In that sense, CCIP-Read providers can blindly query any IPFS public gateway and relatively easily verify the contentâs validity before resolving the result of a direct RPC call. This can be done for any immutable storage (= unique CID) with relatively cheap verification method(s). This came to my mind while reading this conversation but I havenât thought too deeplyâŠ
PR. Although, this is multicall() not resolve(name,multicall()).
Sure.
I like that, except it only works where you donât need the preimageâunless you multicall a bunch of resolves(), which I guess also works.
resolve(name, multicall[addr(60),text(url)]name once, ENSIP-10 compatmulticall[resolve(name,addr(60)), resolve(name, text(url))]a.[cb.id] and b.[cb.id].I was under the impression that content hashes arenât necessarily integrity hashes due to chunking. Although, maybe that can be ignored for data below the minimum chunk?
The other issue is that integrity != latest, so like signatures, you need an additional channel to indicate youâre seeing the newest version.
An improvement might be: after youâve made updates to an L2 resolver, you commit a merkle root of all your nameâs records. Then the gateway just needs to provide 1 storage proof for the root (1 slot), the raw record data, and the links in the tree to locally prove it.
Correct, we are looking at tiny data due to limitations of CCIP-Read itself. Pretty sure it is impossible to pass more than few KB of payload between resolve() and callback(). All chunking issues can be ignored; it is essentially hashing at that amount of data.
Thatâs correct. IPFS CIDs need to be wrapped in a namespace (say IPNS) which then requires some indexer to break degeneracy among versions. This is however a very simple task for an L2 EVM-Gateway Indexer which stores nothing more than latest version for an IPNS key in an extremely rudimentary contract. This L2 EVM-Gateway Indexer + Public RPC is a tightly secure CCIP-Read infra without a dedicated CCIP Gateway. We think it is worth considering; in fact an ENSIP standard for âNo-Gateway CCIP-Read for Immutable & Calculable NameSpaced Verifiable Storagesâ would be nice. Arweave + ArNS falls neatly into the same category, maybe more like Swarm as well bar some caveats. We can derive more value from the implicit trust in the public gateways and it may even push them to be more security oriented; thatâs not our concern but a good side-effect.
I wrote my comment before reading this part and we have ended up saying the same thing. We briefly entertained precisely this (= Index-on-L2 + Store Off-Chain) for NameSys v1 but gave up in interest of simplicity at that point; it is still in our To-Do list for NameSys v2 a little further down the line.
Users do not have to verify CCIP gateways - the gateways are designed such that they cannot return inaccurate results. Any inaccurate results will be detected and rejected by the client.
I played around with this idea and created MerkleResolver.sol â Goerli Contract
The idea is that you create a shape using createShape(bytes32[]) -> bytes32 , which expects an array of cells, which are hashes of record fields, like contenthash, addr(60), text(avatar). You then assign a shape to a node using setShape(node, shape).
After that, everything works normally. When you edit a record, it clears the merkle root. When youâre done editing records, you can commit(node) and it will compute and store the merkle root. You can only set records that exist on your shape.
MerkleResolver r = new MerkleResolver();
bytes32[] memory cells = new bytes32[](3);
cells[0] = r.CELL_CONTENTHASH();
cells[1] = r.cellForAddr(60);
cells[2] = r.cellForText("avatar");
bytes32 shape = r.createShape(cells);
bytes32 node = namehash("merkle.eth");
r.setShape(node, shape);
r.setText(node, "avatar", "https://...");
r.setAddr(node, 0x51050ec063d393217B436747617aD1C2285Aeeee);
r.setContenthash(node, hex"1234");
bytes32 root = r.commit(node);
If you have a shape for cells [A,B,C], you can upgrade your shape to [A,B,C,D,âŠ] without changing the storage layout. Shapes can be shared between nodes. A âStandardâ shape could contain the records typically shown.
The root is computed as a right-padded tree with nulls. If you set a shape with 6 cells, it will delete the values for [7, 8] and then only allow storing 1-6 by mapping from setText/setAddr/setContenthash â cell â index of cell
/ \ / \ / \ / \
1 2 3 4 5 6 X X
Instead of manual commit(), there could be a boolean, which when true, auto-commits after a change is made. It needs multicall(), a few other features like expandShape(), and some gas analysis.
This is cool, but Iâm not sure I really understand the purpose. Wouldnât proving the merkle root plus proving the branches in that subtree be at least as much overhead as just proving the storage slots directly?
I think you only need to prove the merkle root in L2Resolver (1 slot) and then the CCIP server can provide the L2 record data unverified (as full data or branches depending on the request) and the receiving contract can verify the root is valid and use that to verify the supplied data is valid.
Right, but wouldnât:
All add up to more proof data than just doing the last two, even if that meant more values in the L2 contractâs storage?
I think it depends on the size of the data and the type of tree (radix).
Ignore the merkle example and just assume a storage contract that writes hash-prefixed byte arrays:
set(bytes32 key, bytes value) stores keccak256(value) + value
1 storage proof + N slots of data + hash check is more efficient than N storage proofs.
And this brings me to my question:
I would classify the ENS EVMGateway as open (because the gateway itself can be substituted with another) and general (because it plucks slots from L2 without any additional assumptions.)
There also exists open gateways that only operate with specific L2 contracts. Gateways of this type are reliant on L2 contract functionality to extend their chain of trust. In my example above, each set()-stored value would only need itâs hash proven and the actual data could be supplied unmodified. The L1 verifier would verify the proofs of the hashes, and then verify the hash of the data. Since this requires that the hash written to L2 corresponds to the hash of the data, only contracts that obey this mechanic would be supported.
Instead of a set of trusted signers, theyâd have a set of trusted storage contracts.
Would gateways of this type be acceptable? I think in essence, itâs the difference between:
From the POV of a user, I feel like these are actually equivalent, since you need to trust both the L1 and L2 contracts are functioning correctly. For example, an L2 contract that allows anyone to write anywhere can be read using an open gateway but the chain of trust is broken simply because the L2 implementation is flawed.
The advantage of a general gateway is that you can apply it to existing L2 contracts.
The disadvantage of a specific gateway is that it only operates on a trusted set of contracts, but it enables a huge amount of optimizations because you can use the EVM on both sides to enforce logic.
Thatâs true, but given weâre talking O(1) overhead vs O(log n) overhead, and verifications are done in a read context, is it worth the extra complexity?