Interview: Nick Johnson of Ethereum Name Service on Mass Adoption & Scaling

Nick Johnson discusses how first and second layer solutions will impact ENS, how to scale teams, and more.

Chris Spannos: What is ENS and what is your role in the project?

Nick Johnson: ENS is the Ethereum Name Service. Its primary goal is to map from human-readable names, like “nickjohnson.eth”, to resources on Ethereum and elsewhere, like my account address or a smart contract or some content on SWARM and IPFS [InterPlanetary File System]. I am the founder of ENS and the lead of the now independent ENS project.

Chris: What is the ENS road map and what is its current state?

Nick: Our short-term road map over the next year or so has us building a replacement app for user interaction. All aspects of ENS, that’s buying new names, renewing them, configuring them, getting whois type information. Secondly, we are working on dispute resolution as a second layer. Determining when domains are phishing-related for instance and providing a voluntary blacklisting service for that. Thirdly, we are working on a new version of the ‘.eth’ register, a new way of registering and renewing names which will move from the current system with auction-based names to a rent-based system. We did a lot of discussion of all these yesterday at the [ENS hackathon] workshop. Finally, working on integration with DNS services. So, we’re able to verify DNSSEC secure DNS records on Ethereum and we can use that to let you import the DNS name into ENS, so that if you have “myname.xyz” you will be able to use that as an ENS domain as well. All of these plans are for the next six months to the next year depending on the project and the timeline and how quickly we get to it.

Chris: That’s very ambitious. I’m excited. ENS is more than a year old now. How would you characterize its growth to date?

Nick: I think it’s been pretty impressive. The biggest growth of course was during the launch period which was an eight week slow rollout. We’ve had over 300,000 domains registered now. Other metrics of uptake are harder to measure because we can’t see when someone resolves the name because that happens entirely off-chain.

Indications are that a reasonable fraction of those — between 10% and 25% — are actively used with resolvers set and so forth, which I think is really good even in the traditional DNS world given how many names get registered speculatively. Hopefully with all these people working on it on the improvement we planned, it will continue to grow.

Chris: What have been some of the pain points in the growth?

Nick: I think it’s probably mostly the whole network effect thing. In order to get users you have to have wallet support and wallets have no interest in adding it if there’s no users who are demanding it. It’s a whole network effect because only one wallet supporting it has very limited usefulness, but if lots of wallets support it, then it’s much more useful.

We need to reach a inflection point where including it is effectively the default and wallets that don’t support it get looked at as, “Why don’t you fix those?” rather than some fancy new feature. I think that the main pain point is just growing adoption like that and getting people to start thinking in terms of names instead of addresses primarily.

Chris: Are those pain points — wallet adoption and better usability — are those areas where you see progress being made?

Nick: Yes, absolutely. Especially now that we have funding and we have staff, we’re able to reach out to wallet providers, dApps and others. We are able to provide events like this [hackathon] and accelerate adoption. We’re also working with Gitcoin for instance to offer bounties for wallets to integrate ENS support. I think things like that help motivate people to add support, especially when basic support is so straightforward to add, and to get it out there more widely.

Chris: Once it does get out there more widely and achieve a level of mass adoption, I imagine there will be some Ethereum 1.0 blockchain problems as far as network congestion. Are those real problems? To what degree are they problems?

Nick: ENS tries to be fairly gas efficient and lightweight. The main issues that have come up so far are when there is network congestion due to other applications. Of course, anyone using the chain including people wanting to update names suffers in the form of increased gas prices. To some degree, there’s not a lot we can do about that until sharding and more scalability is available.

We can continue to try and minimize the cost of a transaction by minimizing the amount of work that needs to be done, and that’s definite focus is keeping systems as simple as possible, which is good from a security point of view as well, but our long-term solution is going to be waiting for sharding and rearchitecting ENS on top of that.

Chris: How urgent do you think the need to scale the Ethereum blockchain is?

Nick: I think it’s pretty urgent. We should consider it to be one of our top priorities for the ecosystem as a whole because what we’re seeing is adoption outgrowing scalability. We’re getting mass attention before we have the infrastructure to support that. If we were less popular, it would be less urgent, but we’re victims of our own popularity. I think it’s critical that we focus on it as a top priority.

Chris: You’ve mentioned sharding, are there any off-chain solutions like Plasma or State Channels that you see is viable candidates that may also be able to help ENS in the future?

Nick: I think things like Plasma will help reduce on-chain traffic in general. I think we will want to investigate ways we can integrate ENS with it to make Plasma using applications work better. In some instances, we can integrate that with ENS. For instance, you can write any resolver contract you want, and you could write a resolver contract that accepts updates using Plasma, so you can send multiple updates on a Plasma chain then periodically sync them to the main chain.

For the most part, I think ENS is going to benefit from Plasma and so forth because of the reduction of other people’s traffic on the chain, because a lot of the data needs to be there universally accessible in order for the naming system to be useful. I think of it as baseline infrastructure like DNS or DHCP.

Chris: That makes sense. More generally, how would you characterize the state of the Ethereum software ecosystem?

Nick: I think it’s still fairly early days, but I think it’s improving rapidly. In the two-and-a-bit years I’ve been part of the space, I’ve seen developer tooling go from dire to merely, like, needs improvement. We’re getting much better tools for development and debugging. Things like Truffle, for instance, have gone from very basic frameworks to much more complete and easy to use ones.

The Remix browser IDE has got some really useful features now that make debugging a lot easier. At the same time, it’s not at all uncommon to run into issues where your transaction failed and now you’re going to have to do print statement debugging and commenting lines out and so on in order to figure out what’s going wrong. I think we’ve got a long way to come, but I think the general direction, the general trend is in the right direction.

Chris: What about the gap between research and development and research and production, is there a need to close this gap or what are your thoughts on how to do that if there is a need?

Nick: It does worry me a little bit because I see that there is a disconnect between research and development. An example would be the recent decision to postpone Casper in favor of a new approach. I understand the appeal of that from research point of view, not wanting to develop something that seems like a dead end. On the other hand, nothing that gets deployed is ever perfect the first time. It’s useful to build things even if we know they’re going to change and be discarded in order to gain valuable insight from how they work and the results.

I can’t remember whose saying it is, but any complex functional system is inevitably discovered to have evolved from a simple functional system. You can’t build something big and complex from scratch. You have to start simple and improve on it. I think that is needed. We should be working more closely between the two areas.

Chris: To dive down just briefly a bit more into that, what was the reason for the shift to discard Casper in favor of the Casper-Sharding chain full spec?

Nick: As I understand it, it is a change in the approach towards how Casper will function, that it would have a separate root chain that functions quite differently from the current Ethereum main chain. Therefore, it wasn’t really possible to have that evolutionary step from Casper on top of Ethereum to Casper as the root consensus mechanism. Therefore, they didn’t think that the Casper FFG had value there.

Chris: What about that shift in specifications, is there anything that you think developer teams could learn from that, in terms of broadcasting these types of specifications changes in different ways, or any lessons that you think might be relevant from that experience?

Nick: I think the research and the development teams need to keep in close contact about how things are evolving so that this sort of thing isn’t a blindside type of thing. Also to respect each others expertise in like, reaching out to developers and saying here is the direction we’re heading and then working together to find incremental approaches that can achieve the same goal, rather than iterating until you get the perfect design and throwing that over the wall to developers to work on.

Chris: In this environment what qualities or roles do you think might make for a good team?

Nick: I think the number one underappreciated thing really is excellent technical communication. People value rockstar developers, but underappreciate how much an amplifying effect being able to communicate effectively with workmates is. If you’re very good at what you do but you can’t communicate, then you’re only going to be effective on a small projects. I would much rather work with someone who is less efficient or less inspired but is better able to communicate their ideas with others and understand other people’s ideas. I think that leads to a much more scalable teams.

Chris: Are there any tools or aspects to development environments that you think are useful that you use or that you think other developers might benefit from? Anything Ethereum blockchain specific or more generally?

Nick: Personally, I’m quite a fan of Truffle and the ease of setting up unit tests and so forth in that. I think it needs some evolution and improvement. I use the browser Remix surprisingly frequently just because it’s currently the best or the easiest way of getting interactive feedback and actually be able to step through a trace in an intuitive fashion. It’s not nice to have to drop down to assembly instructions and try and map them mentally back to what that was in Solidity and so forth.

I’ve played a bit with proving tools like Manticore that let you send symbolic execution type transactions where you leave parameters undefined and it tries to find counterexamples that break it. They’re very cool, but they’re also very new and they tend to be both slow and a bit difficult to work with. I think the potential there is pretty amazing being able to say, “I assert that the total of all token balances is equal to total supply.” Then just have a test that asserts that and fails if that can ever not be true.

Chris: That’s sounds like a really interesting tool.

Nick: It is.

Chris: What do you think makes for a good documentation? Are there any examples that you can suggest?

Nick: Examples in the Ethereum space or in general?

Chris: In general.

Nick: I think documentation needs to be in two parts. You need tutorial type documentation and you need reference type documentation. A lot of projects with relatively good documentation misses out one or the other. If you’ve got no reference documentation, then you’d end up spending all of your time paging through all of the tutorials for that one little bit.

I would point to Solidity as an example of that. Its reference step is fairly sort of barebones, but it has excellent tutorial style “here are all the features” docs. Then on the other side if you have excellent references but no tutorial, then learning it is a huge learning curve. If you want to learn some particular topic, you really don’t know where to look. The best thing is documentation that focuses on both and also that finds new users and works with them to make sure it actually serves their needs.

Chris: How can we improve onboarding developers into the ecosystem?

Nick: The basic tutorial documentation is an excellent start. Good documentation on just how the system works as a whole and articles and so on that give people that insight they need to grock to fundamentally understand how the bits work together. I remember when I was learning, when I suddenly realized how all the pieces fit together, that was when it started to really make sense and I started to be able to be really productive. The Ethereum Frontier Docs were an excellent resource for that, but they’re now getting woefully out of date. It’s stuff like that, but kept up to date. It would be really nice if we had an alternative to the Yellow Paper that wasn’t indecipherable.

Chris: All heavy math.

Nick: Yes. And notation that optimizes for neatness and succinctness rather than for readability.

Chris: Final two questions. Do you have any advice or lessons learned that in your own experience that you think others could benefit from?

Nick: If you’re writing smart contracts, think about how much of it actually needs to happen on chain. You’d be surprised how much stuff you can rip out and do off chain. There are bad reasons for keeping stuff on-chain like, “I don’t have the infrastructure set up to share this data around.” You can do a lot by, for instance, omitting events, by storing hashes rather than the data itself, by passing data back in when you need it again, stuff like that. That not only reduces the gas cost of executing your code, it can also improve readability. It can make the code shorter and easier to audit and that’s improved security.

Chris: Finally, is there anything that you would like to add or that you would have liked me to ask?

Nick: I don’t think so.

Chris: Okay, great. Thank you very much.

Nick: My pleasure.

Chris: Cheers.

Note: Scaling Today is funded by the May 2018 Ethereum Grants Program. For more information visit: scaling.today