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.
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:
First we give the factory a sub-domain it will operate, eg.
pairs.optimism.velodrome.eth, which would use theRegistry::setSubnodeRecord()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)
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.ethsafely 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:
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.
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.