Decentralized naming systems are a fascinating topic and we’ve seen a lot of work in this area since Zooko’s triangle was squared by Aaron Swartz in 2011. Decentralized naming looks like a deceptively simple problem initially but actually has a lot of moving parts and design tradeoffs.
Today, I came across a bug in a new attempt at decentralized naming, called the Ethereum Name Service (ENS). ENS is built on Ethereum. The bug required ENS developers to halt the ENS launch and update/restart the ENS registrar.
Kudos to the Ethereum devs for their fast response time. Later in the day another bug was discovered and confirmed:
Ethereum’s general school of thought seems to be to move fast, try ambitious ideas, and fix bugs as they discover them and this launch seems consistent with that approach.
The design of on-chain naming made me think about decoupling state from logic. In the ENS model, the developers or “root signers” write the code and publish it as a “smart contract” that then manages processed state e.g., mappings of which address owns which domain on behalf of users. If/when a bug is discovered, the root signers have the ability to update the contract. This has a couple of issues:
a) Key compromise for root signers introduces an additional attack vector. Having root key signers is an OK assumption for a naming system, given the traditional DNS also has root signers. However, this has implications for attack vectors on the naming system. If the signers are compromised the security of the entire naming system is compromised. This is a tradeoff between practical security (as long as signers don’t lose their keys, it’s a good thing that they can issue updates without opt-in and software upgrade from users) and decentralization where any single party doesn’t have control over the naming system.
b) Bugs in the logic can write unrecoverable corrupt processed state. The bugs were discovered in the auction algorithm. If there is a bug in how the registrar selects the auction winner, then it writes invalid ownership information (processed state). There aren’t any good options to fix this: you either have to start the smart contract over from scratch, or rewrite the blockchain history. A safer alternative is to write only user inputs (user state) to the blockchain, and run an external process to read the inputs, validate them, and process them to derive the naming state. This makes it possible to recover from this type of bug: update how user-state is processed externally. Then, the patched external process will derive the correct naming state without starting over or modifying the blockchain.
The current approach of ENS is to move to a permanent registrar after two years. This fixes (a) and ENS will no longer be dependent on the root signers. However, it also means that the logic of the ENS registrar cannot be updated after 2 years and any bugs discovered after that timeline cannot be fixed.
Putting logic in the blockchain:
Taking a step back and looking at decentralized naming systems in general. We’ve seen a bunch of efforts at naming systems using blockchains so far. Namecoin was the first, which wrote naming layer logic into the core blockchain operations and ran into several issues because of that design choice. ENS is implementing naming logic at the blockchain layer again but by using “smart contracts”, which makes the success of the naming system not only depend on (a) the specific blockchain on which the contract is written (Ethereum) but also (b) on formal verification and “bug-free guarantee” of the contract itself.
I believe that the high-level design decision of putting too much logic in the blockchain layer introduces needless complexity to the design. Blockchains should be dumb and only store state transitions (just like the internet core is dumb and only delivers raw data). Logic can, and arguably should, be implemented outside of the blockchain layer.