Why isn’t Parity splitting Ethereum to recover the lost funds?

On April 26, 2018, Parity Technologies issued a statement clarifying that they have no intention of changing the existing code, as this would result in an Ethereum chain split. The code change could have recovered lost funds in the amount of $264 million.

As a lot of effort and time have been dedicated to Ethereum ecosystem development, Parity doesn’t want to harm the built ecosystem. Rather than hard forking, they are planning to “work with the community to find a path forward.”

We had a chance to interview Ihor Pidruchny, Applicature CEO, to find out his expert opinion on the Parity case and related issues.

Q: As announced on April 26, Parity has no intention to hard fork the platform. In your opinion, what’s the current status of the Parity situation?

A: Everybody realizes that the situation is irreversible. There’s no chance that any kind of hard fork will happen. So, it’s status quo.

Q: Parity developer, Alex Van de Sande, stated that in case of recovery, a continuous hard fork would be generated. Why is this bad?

A: I think hard forks are particularly bad as a precedent. As in any other blockchain, Ethereum’s main features are irreversibility and immutability, right? So if a group of people votes to come up with a hard fork that changes rules that have been written to the blockchain, it pretty much destroys the whole idea of the blockchain. This would also create a precedent for many other people to try to also push for hard forks in their own best interest.

Q: What would you do in a situation like this?

A: Well, actually, we have a certain solution to the situation. We are going to disclose it when we get to the public release about it. Currently, we’re working internally on the solution. It should be quite a workable, partial, if not entire, remedy to the situation. So, stay tuned. Follow us on Twitter, and we’ll be coming up with the announcements!

Q: In your opinion, what should be the priority: not to harm the developed platform, or to save the clients’ costs?

A: Well, I think that when we use Ethereum, we agree with the terms and conditions which say that Ethereum is an experimental technology. In this case, people knew what they were going for. In such a situational case, there can’t be a reason for changing the way the underlying technology is organized. The blockchain system is used because it is immutable, so no one can intrude and change the course of things, but respectively change the ledger.

Q: Is there similarity between the DAO and Parity attacks?

A: I think they are different in regard to the amount of lost funds that have been stolen or frozen. The DAO was pretty much forced to hard fork back then. Ideologically speaking, we always adhere to the same rules of the blockchain as a source of tools and the immutable ledger. We take risks related to it. One of the risks is that there are business logistics in the code that have not been realized and spotted due to potential vulnerabilities or side effects. When you rely on the code, you have to take risks.

What’s interesting is that there was no criminal responsibility for hacking Ethereum back in 2016. Later, there was no legal responsibility for the Parity case. It only outlines things that are within the rules: if you have written bad code, you’re responsible for it. No one else is responsible for the fact that you have overlooked some vulnerabilities. If your clients are using your smart contracts, it only means that they automatically accept possible risks, too.

Q: Are there any chances of campaign survival?

A: Yes, I think there are solutions. They might be working on them. When we are ready, we will announce it. I do think there are other ways to remedy the situation.

Q: What lessons can be learned from the Parity example?

A: Actually, if you review the history of their releases, you will find that the library that was destroyed in November was released in July. It was attacked, as the previous version of the library had vulnerabilities. So, what I can imagine was happening, is that Parity was in a rush. They had an attack in July 2017, and had to provide a quick fix for it. They potentially didn’t follow all the standard procedures of code review, and didn’t have enough time to review the code internally or discuss it on different layers of technical management inside the company. They probably did not send it for public review.

The lesson is: when you deploy something that is presumably going to work forever, you shouldn’t rush. You should have a very thought-out approach about the processes of how you deploy code that eventually is going to be immutable.