A call for ENS adoption!

Yo, we tried giving an ENS name to all our smart contracts!

Velodrome Development Journal

Velodrome V2 is much more than an upgrade. We redesigned the protocol entirely from the ground up to ensure we deliver a significantly improved end-user experience, developer-friendly features, and a generally more secure and simplified architecture at the smart-contract level.

One of our top goals for V2 is to move the protocol entirely on-chain. To do so, we're taking important steps to make it possible to run it as a fully decentralized public good. We'll be covering our approach in the upcoming weeks.

In this first publication, we'll start with one of the planned features that didn't make it into Velodrome V2 due to technical limitations. This is a deep-dive into the Ethereum Name Service (ENS) , how it works, and why its current implementation on a Layer 2 network like Optimism didn't align with our objectives.

We aim to cover this topic and engage with enthusiasts and partners to help build and support the efforts to improve the services available on Optimism. We will also be working with ENS and our partners to see how we can help make it happen in the near future.

Let's name our contracts!

Among our key planned features was assigning ENS names to all our contracts to make them human-readable and overall safer to interact with (e.g., router-v1.optimism.velodrome.eth instead of the unwieldy 0x9c12939390052919aF3155f41Bf4160Fd3666A6f).

Intelligible contract names allow:

  • users to quickly verify a smart contract by reading its name

  • security researchers and developers to search for any contract by a name

  • development teams to transparently release and communicate new contracts versions to all partners

ENS is for Ethereum addresses what DNS is for the Internet: instead of typing ping 8.8.8.8 to reach out to another computer on internet, you can just do ping dns.google, which is easier to remember and maintain.

Most readers will be familiar with the significantly improved user experience of interacting with a <YOUR NAME>.eth name directly instead of an error-prone raw address.

post image

However, we couldn't find any of the available services for intelligible contract names on Optimism to offer the technical support we need to meet our core goals.

Contracts claiming their own ENS

Technically, assigning an ENS name requires two steps:

  • assign a name to an address

  • claim the assigned name from an address

The second step is actually what makes it possible to resolve an address to a name.

Since an address can have multiple names, and anybody can assign a name to a contract, claiming is required to resolve which name is attached to an address.

Based on these rules, we established the following list of requirements for our factory (the PairFactory.sol) to give names to all the contracts it deploys:

  1. First we give the factory a sub-domain it will operate, eg. pairs.optimism.velodrome.eth, which would use the Registry::setSubnodeRecord()

  2. Have the factory create a new name and assign it to the new pair address using the same pair symbol

    • store the Factory reverse-registrar (which also comes with the registry) address and have a function to allow updating it in a permissioned way

    • dynamically reverse-resolve the sub-domain provided in the first step

    • use the same Registry::setSubnodeRecord() with the stored registry address and the operating sub-domain to assign newly deployed contracts new sub-domains (eg., vAMM-VELO-OP.pairs.optimism.velodrome.eth)

  3. Add a permissioned function that will let the pair claim the newly assigned name by resolving the reverse of its own address, this would use ReverseRegistrar::setName()

Note, the first step is also easily done via the ENS app and allows us to keep the main name velodrome.eth safely in our multisig.

The challenges with ENS integration

While ENS on Optimism offers functions to register and transfer the names, we didn't find the on-chain support for resolving names or reverse-resolve addresses to names.

Since we are on a Layer 2 network, the ENS support for Optimism is the next thing we started looking into. At the end, our research led us to the following list of blockers:

  • ENS documentation confirms that Layer 2 support is at best a prototype at the moment. OptiNames or a similar deployment to support the Layer 2, at the moment requires an off-chain service (which would go against our initial design goal of striving to build a decentralized protocol).

  • ENS node hashes and generally the support for direct and reverse address lookups needs an official implementation

Sadly, the work we estimated to get all these external features done, would seriously divert the time and resources from our core goals. This motivated us to share all the details in this article with the community.

Conclusion

We found that ENS on Optimism serves limited use-cases at its current stage, and we hope to see the ENS Foundation will consider any of the following feedback:

  1. The lack of on-chain support for resolving addresses is something crucial to help the developers adopt and develop on top of the service. We believe this will increase the adoption of ENS for critical to the community products like Etherscan and Metamask. We need an official smart-contract implementation to support the developer's needs.

  2. The Layer 2 support, while still being a work-in-progress, is an absolute requirement to help test and experiment with the new product development and adoption of ENS across the Ethereum eco-system and other Layer 1 networks. Especially now, where OP Stack and cross-chain apps are leading the narrative.

Despite the unsuccessful journey, we look forward to a future where on-chain addresses will have names!

We believe in a future where users don't have to pay/use external services to simulate a transaction at a potential cost of their privacy, and instead trust the ENS names as we trust DNS when connecting to another computer today. We want to send funds by typing our friends' names into the wallets, and where Etherscan doesn't label the contracts based on what other Web2 services have to say.

If you're interested in learning how you can help, come ping our team in our Discord, or directly Zoomer on Twitter and Stas on Farcaster.

voloshinjenya4
Commented 6 days ago

WinShark Casino to innowacyjna platforma kasynowa, która oferuje graczom z Polski szeroki wybór automatów, klasycznych gier stołowych oraz kasyna na żywo. Dzięki przejrzystemu interfejsowi, szybkim wypłatom i atrakcyjnym bonusom, serwis zyskuje coraz większą popularność. Możliwość gry na urządzeniach mobilnych sprawia, że rozrywka dostępna jest zawsze i wszędzie. Szczegóły oferty znajdziesz na stronie https://winsharkcasino7.pl/.

itai (building dynamic.xyz)Farcaster
itai (building dynamic.xyz)
Commented 9 months ago

🌎 Say hello to Global Identities 🌎 I am thrilled to introduce our newest feature. We can now auto-generate subdomain ENS names for your Dynamic-powered embedded wallets users. Memorable names = more time to connect, play, and transact onchain. Thanks to @ensdomains and a collab with NameStone, the username becomes an ENS subdomain. Setup is quick, gasless and offchain. Oh, and you can bring your own top level domain. I did a walkthrough video of how it works below. P.s - DM me for early access.

itai (building dynamic.xyz)Farcaster
itai (building dynamic.xyz)
Commented 9 months ago

We're abstracting away crypto complexity, one building block at a time. Read the full blog post here: https://www.dynamic.xyz/blog/global-identities

maxFarcaster
max
Commented 9 months ago

absolutely huge, love it 😍

🧙‍♂️Farcaster
🧙‍♂️
Commented 9 months ago

This is so sick!!

GIGAMΞSHFarcaster
GIGAMΞSH
Commented 9 months ago

very cool 👏

Chris CarlsonFarcaster
Chris Carlson
Commented 9 months ago

Just thought about doing this today

Lucas | POAP StudioFarcaster
Lucas | POAP Studio
Commented 9 months ago
Giuliano Giacaglia 🌲Farcaster
Giuliano Giacaglia 🌲
Commented 9 months ago

That's pretty cool, tbh!

Adam SpiersFarcaster
Adam Spiers
Commented 9 months ago

Congrats on this nice feature! If you want the rough equivalent for wallets you want to keep private, and for any other addresses (including wallets/contracts you don't own), check out https://rolod0x.io/. It works on all chains, and even on sites which don't support ENS reverse lookup.

StasFarcaster
Stas
Commented 9 months ago

I believe we still can't do that from smart contracts directly, right?

itai (building dynamic.xyz)Farcaster
itai (building dynamic.xyz)
Commented 9 months ago

you mean from an AA layer?

StasFarcaster
Stas
Commented 9 months ago

Like self naming contracts. Honestly didn't have a chance to review the latest ABI https://paragraph.xyz/@velodrome/a-call-for-ens-adoption

Adam SpiersFarcaster
Adam Spiers
Commented 9 months ago

If I understand your question right, you can do it with https://rolod0x.io/

Cosy ( Building FarFantasy ✨)Farcaster
Cosy ( Building FarFantasy ✨)
Commented 9 months ago

Send dm for early access

AkinzzyFarcaster
Akinzzy
Commented 9 months ago

Congrats, and it sounds amazing.

Pete HorneFarcaster
Pete Horne
Commented 2 years ago

This is not a criticism, but an observation as I pondered key security; the introduction of ENS names incentivising social capital aggregation to a single address has made wallet security a lot harder than with anonymous addresses that have no incentive for aggregation and hence allow many wallets to decentralise risk.

Boris MannFarcaster
Boris Mann
Commented 2 years ago

Re-using addresses for every app is the original sin. We could’ve normalized deriving a new one per app.

Pete HorneFarcaster
Pete Horne
Commented 2 years ago

The aha about this, perhaps, is that a lot of ETH based crypto is about social capital management and not financial capital management.

jamesyoung.ethFarcaster
jamesyoung.eth
Commented 2 years ago

simultaneously both

nicholas 🧨Farcaster
nicholas 🧨
Commented 2 years ago

The mistake most apps make is associating Follows with addresses, when they should be associated with ENSs or equivalents, instead. The entire "your address is your resumé" meta made no sense in a world of evolving security concerns and EOA key rotation. Smart accounts may solve this by separating Account from PK.

wijuwiju.ethFarcaster
wijuwiju.eth
Commented 2 years ago

More like a trade off, but def either option is suboptimal, thankfully we can iterate and migrate

nicholas 🧨Farcaster
nicholas 🧨
Commented 2 years ago

Yes more accurate as you put it. Can't have a follow model for ENS handles only when most addresses don't have one

moritz 💧🔑Farcaster
moritz 💧🔑
Commented 2 years ago

Agree! ENS actually solves the issue An ENS can be a static identifier resolving: 1. user.eth: the "main" address of a user, containing assets you want others to see (can be rotated) 2. pay.user.eth: a new (stealth) address is resolved every time this is queried, for privacy 2 is something we're building :)

jamesyoung.ethFarcaster
jamesyoung.eth
Commented 2 years ago

original sin was launching without account abstraction as default https://warpcast.com/boris/0x6ae05bde

Alex Van De Sande Farcaster
Alex Van De Sande
Commented 2 years ago

We’re aware of this and in fact have sponsored not one but two projects with ens for on-chain privacy.

Samuel ツFarcaster
Samuel ツ
Commented 2 years ago

lets gooo Alex on Farcaster. Welcome! love to see you here

StasFarcaster
Stas
Commented 2 years ago

I actually think we should start addressing this. Sadly ENS is still lacking the necessary dev UX to pragmatically handle such needs. We wrote about it a while ago https://paragraph.xyz/@velodrome/a-call-for-ens-adoption

🎣Farcaster
🎣
Commented 2 years ago

Decentralized public social capital aggregation is not bad? What's wrong with 6529s 3 addy vault setup? And delegatecash (would've been cool if that was built on ens). Obv u could resolve ur .eth to a new addy too

Pete HorneFarcaster
Pete Horne
Commented 2 years ago

It’s definitely not bad - I think it’s an innovation. All I’m pondering is the reality that you have one master key and that’s a single point of failure. Thinking on it - as most wallets are bip32 derived key wallets anyway, then it’s the rule to have a master key and name, anyway. So, how to help deal it?

🎣Farcaster
🎣
Commented 2 years ago

Using vault address circumvents most of the risk There's always the risk of losing individual accs too. Ppl prob more careless with m Like the idea of accruing info to broke.eth but ig this could also be done by linking addys, but how do other dapps access that Having many wallets same headache as multiple passwords

beijixiongFarcaster
beijixiong
Commented 2 years ago

that is good

A call for ENS adoption!