Nick Johnson is a developer for the Ethereum Foundation, a Swiss non-profit that aims to promote and support the Ethereum platform. He’s also a core developer on Go-ethereum and a lead developer at Ethereum Name Service (ENS).

We chatted to Nick about governance trade-offs, what we mean when we say decentralisation and immutability, advice for developing with Ethereum and his thoughts on the future of the blockchain space. Here’s what he had to say…

Simpleweb: How did you get into the blockchain space?

Nick Johnson: I’ve been working in tech for around 15 years now. I started back when I was living in New Zealand for a company called Niche Software. After a few years there I was hired by Google in Dublin and moved over to Ireland.

Having worked for nearly 8 years at Google, I was contacted by a recruiter in 2016 who told me about a new position at Ethereum. I found the technology really fascinating and got the feeling we were working on something interesting. I felt the way I imagine people felt when they were building the internet. Since then I’ve been working with the Ethereum Foundation, mainly with Go-ethereum and ENS which I am the founder of.

SW: How has your view changed since you started working in the Ethereum Foundation?

NJ: The maturity in the space has improved since I joined but it’s still very preliminary. There is a lot of improvement in usability and so on, and that’s what is going to determine whether we get mass adoption and whether the technology is actually useful in the real world. To me it is still very much late 1980-90s era.

There are also some ongoing challenges in the blockchain space, because there are several groups of people with different objectives, missions and aims for blockchains in general. People like myself come from a technology and software perspective, and we build infrastructure and are interested in the technology. Others see it more from a political point of view and as a tool for decentralisation and so on, that can result in some interesting conversations and people trying to argue with each other.

One demonstration of this is around recovery of lost funds. Events such as the Parity multisig-wallet attack, when people lost funds in the Javascript library, serve as an even starker and cleaner cut example of the difference in philosophy.

In the case of the DAO attack you have the complicating idea of there being a hacker and multiple issues around the code of the contract. However, when you have a bug in the Javascript library nobody is debating who the funds belong to. The debate is about whether people should be helped to recover the lost funds.

SW: Do you try to stay on the technology side and avoid the politics in the space?

NJ: Discussing governance is really important in blockchains and it’s far more present and critical than other types of software. In contrast, when you’re working on an open-source software project you can have discussions and disagreements and so on. But ultimately it’s made less critical by the fact that anyone can choose which code to run and which feature to choose.

That said, it’s a lot easier to fork an open-source project than a blockchain. Although you can fork both, there are fewer situations where it is necessary for an open-source project to have a drastic change or split. As a result, politics and governance are an inevitable part of managing a community around a blockchain. I think attempts to ignore that effectively just favours informal ad-hoc government structures which don’t always have the properties you want.

The Bitcoin community is a good example of that, as they’re naturally very conservative with changes to the chain and so forth. But by suppressing discussion around that and asserting that change isn’t possible, all they do is ensure that certain community members have implicitly more of a say in the direction of it.

Secondly, anyone wanting to argue a different point has to go off on their own and create BTC, BTG or whatever the latest one is today. I think a more inclusive process that is more amenable to open discussion leads to fewer of those disagreements. You can philosophise and learn more about another person’s viewpoint without having to take the nuclear option and create your own blockchain.

SW: So what does decentralisation really mean?

NJ: In terms of decentralisation, I think of it as a measure of how many people are required to make a decision in a system. Or how many people are required to change a system. If you wanted a mathematical definition you could look at this as the difference between the most powerful and the least powerful person in a system.

For example a dictatorship is massively centralised and the most powerful person is the dictator. Everyone else has no power or vote. On the other hand, in a maximally decentralised system every participant has equal rights and the opportunity to affect change.

However, it’s very hard to measure this. If you look at Ethereum and Bitcoin it’s clearly a lot more decentralised than a dictatorship, but you can’t really say that they have the same weight, because they don’t. Because of social and network effects, if I run a node, I then have more weight than if I don’t. Likewise if I have more funds or if I mine cryptocurrency I arguably have more weight than someone that doesn’t.

I think of decentralisation as a measure you can try and optimise, but I also think it is too simplistic to try and find one number to measure a whole system and say it’s decentralised. People often make that mistake and are unable to come to a decision with decentralisation. If we build a system where we can come together and build on things then it’s decentralised. It’s just where people are able to effect change with an agreement on it.

SW: And how about immutability?

NJ: Ultimately you can talk about the immutability of many things. So in a trivial way a transaction is immutable because it is enforced in the system. People mostly take this sort of immutability for granted as it forms a basic building block of a blockchain. But then people extend immutability to try and refer to the rule set or any other things which aren’t fundamental properties of a blockchain but instead are things they aspire to.

I more or less concluded that arguing about immutability is pointless. Whatever definition you have for the word, they will likely have a different one, thus you spend the entire time arguing about what the correct definition is.

SW: What advice would you give to others looking to develop on Ethereum and particularly those hesitant to release anything on the main network?

NJ: My main piece of advice for everyone is less code. Make your contracts simpler and easier to review and demonstrate correctness because the number one mistake most people make is trying to build an all-singing and dancing contract. This just provides many and various opportunities for bugs including the types that lose funds.

In my mind, a good smart contract is a short contract that has a certain set of rules that you can demonstrate, but you should also be able to demonstrate some sound conclusions about them. Or you should demonstrate that it cannot give funds to someone that isn’t authorised.

Start small, then iterate and also get as many experienced eyeballs on the project as early as possible. You should also get it audited and think about community release and bug bounty programs.

SW: What are the biggest challenges you are facing?

NJ: In terms of of the challenges facing my own project, the Ethereum Name Service (ENS), the main challenge is the network effect and generating robust user-friendly tools. Plus, the usual developer issues and the fact that if you want your tools to be useful you have to get them adopted by a lot of people.

The other issue is the relative immaturity of the platforms we’re using. Although rapidly getting better, the toolsets are still basic. This slows development and allows for more bugs, and it means you have to put more effort in getting the thing to work and writing the code that you want.

SW: And what about blockchain technologies in general?

NJ: The biggest problem in the short-to-medium term is scalability, and we’ve got several efforts under way to improve this. I really think there may be an ugly bottleneck between where the technology is now and where people want to scale-up to. If people think we can scale-up faster than the technology is ready for, it may lead to disillusionment and to some serious issues with escalating transaction prices.

Still, it’s difficult to know what the long-term scalability picture looks like.

SW: Are there any projects or technologies you think might overcome the issue of blockchain scalability in the long-term?

NJ: There are quite a few interesting projects within the side-chain space that have the potential to scale-up well in the long run. Ideas such as Plasma and projects like FunFair Technologies that use what they call fate channels for example.

I think there’s going to be a lot of bespoke projects like these where, to scale, they have to build their own implementation based on some libraries and state channels that are generic and add extra functionality.

In addition to that, robust proof-of-stake like Casper is going to have a big impact on scalability. Not so much because it enables improvements directly, but because with proof-of-stake you don’t have the issue that you can’t create a new network without new miners.

Instead you can create your proof-of-stake sidechain without any of those concerns because it’s secured by game theory and protocol rather than by mining. This will enable the development of a lot of projects that aren’t currently practical because of the nature of proof of work.

SW: Where do you see the future of Ethereum and blockchain technologies in general?

NJ: As with any bubble there’s a lot of hype, and a lot of people. Like with the dotcom bubble, people said things like ‘it’s the internet of X’, where X didn’t make any sense. Similarly now it’s ‘let’s put X on the blockchain’. Often those projects make you question what value doing it on the blockchain can actually add.

There are going to be applications that require distributed consensus but a lot of the projects we see now are just using buzzwords and irrational exuberance and sooner or later there’s going to be a winnowing out. Of course we’re still going to see the Googles and Amazons arising out of it, but a lot of the sillier ideas like put food on the blockchain are less likely to succeed.

We’d like to say a huge thank you for Nick for chatting to us. Follow Nick on Twitter for the latest updates and find out more about the Ethereum Name Service via www.ens.domains/