ENSIP-24: Arbitrary Data Storage

[clowestab]

This ENSIP proposes a new resolver profile for resolving arbitrary bytes data.

It's development has been motivated by the the requirements of ERC-7828: Interoperable Names using ENS.

This specification is simple yet incredibly flexible. It allows for the resolution of anything using an ENS name.

[adraffy]

A consequence of this design is that you can implement a resolver that has all of the traditional profiles, but only uses data() underneath.

This greatly simplifies crosschain resolvers, since there's only 1 storage mechanism, and profiles are just last-mile logic for function → key and data → result.

eg.

keyForAddr(coinType) := "addr:${coinType}"
     keyForText(key) := "text:${key}"

          addr(node) := data(node, keyForAddr(60))
addr(node, coinType) := data(node, keyForAddr(coinType)) // ignored: ENSIP-19 default logic
     text(node, key) := data(node, keyForText(key))

          setAddr(node, value) := setData(node, keyForAddr(60), abi.encodePacked(value)
setAddr(node, coinType, value) := setData(node, keyForAddr(coinType), value)
     setText(node, key, value) := setData(node, keyForText(key), bytes(value)

IMO, this reveals there's a further abstraction for resolvers, where we separate the data translation (frontend) from the data storage (backend), but that's another discussion 😄.

[clowestab]

A consequence of this design is that you can implement a resolver that has all of the traditional profiles, but only uses data() underneath.

This greatly simplifies crosschain resolvers, since there's only 1 storage mechanism, and profiles are just last-mile logic for function → key and data → result.

eg.

keyForAddr(coinType) := "addr:${coinType}"
     keyForText(key) := "text:${key}"

          addr(node) := data(node, keyForAddr(60))
addr(node, coinType) := data(node, keyForAddr(coinType)) // ignored: ENSIP-19 default logic
     text(node, key) := data(node, keyForText(key))

          setAddr(node, value) := setData(node, keyForAddr(60), abi.encodePacked(value)
setAddr(node, coinType, value) := setData(node, keyForAddr(coinType), value)
     setText(node, key, value) := setData(node, keyForText(key), bytes(value)

IMO, this reveals there's a further abstraction for resolvers, where we separate the data translation (frontend) from the data storage (backend), but that's another discussion 😄.

Agreed. In hindsight, these abstractions would have been implemented from the get go. Stacking complexity is not going to incentivize developers to build on top of ENS.