ERC-3668 edge case for clientside http/ssl errors

I’d like recap on this topic as there is now a good solution to this problem that is both backwards compatible and does not require modifications to EIP-3668.

First, ENSIP-21:Batch Gateway Offchain Lookup Protocol (BGOLP) is now standard. It codifies the Batch Gateway implementation utilized by the Universal Resolver.

With that standardized, local BGOLP’s can be embedded into client-side frameworks (ethers, viem, etc.). ENSIP-21 defines x-batch-gateway:true as the special-purpose URL which indicates to an aware client that (1) the request is BGOLP and (2) the rest of the gateways can be ignored and the local gateway can handle the request.

viem just merged an update that has a built-in BGOLP. viem already uses the Univeral Resolver internally, and now when you call any ENS function in viem and don’t specific custom gateway(s), the local BGOLP handles the request automatically.

Second, at the bottom of ENSIP-21, I outlined a technique for fault tolerance. To be fully backwards compatible, you need to provide an external gateway too (to cover the case where the caller doesn’t have a local BGOLP) but now you can now speculatively evaluate offchain servers that may be offline or failing.

Third, @ensdomains/ens-contracts/contracts/ccipRead/ directory contains some useful helper code:

  • CCIPReader.sol makes it simple to call any CCIP-Read enabled contract.
    • ccipRead() is pretty straight forward to understand, it’s just staticcall() + callback.
  • CCIPBatcher.sol codifies interaction with a BGOLP.
    • ccipBatch() is more complicated as you provide an array of (target, call) and then ccipRead() the ccipBatch() function. There probably should be a helper function so you can just invoke ccipBatch() directly.

See the new UniversalResolver.sol or AliasResolver.sol for more examples.

It might make sense to embed a BGOLP implementation into the standard offchain server.

If this is useful for non-ENS applications, it can be turned into an EIP.

4 Likes