Why isn't Parity splitting Ethereum to recoup the money that have been lost?
On April 26, 2018, Parity Technologies released a statement explaining that they have no plans to change the present code because doing so would result in a split in the Ethereum chain. The coding update may have resulted in the recovery of $264 million in lost funds.
Parity does not want to jeopardise the Ethereum ecosystem's development, which has taken a lot of time and work. They intend to “work with the community to determine a route forward” rather than hard fork.
We spoke with Ihor Pidruchny to get his expert opinion on the Parity case and associated challenges.
Q: As of April 26, Parity has stated that it has no plans to hard fork the platform. What is the current state of the Parity situation, in your opinion?
A: Everyone understands that the situation is hopeless. There isn't a likelihood that a hard fork will occur. As a result, things are as they are.
Q: Alex Van de Sande, a Parity developer, claimed that if the network recovers, a continuous hard fork will be formed. What makes this so bad?
A: As a precedent, I believe hard forks are particularly awful. Isn't Ethereum's main characteristic, like any other blockchain, irreversibility and immutability? So, if a group of individuals chooses to create a hard fork that modifies the rules that have been put to the blockchain, it effectively kills the blockchain as a concept. This would set a precedent for many others to try to push for hard forks in their own best interests as well.
Q: What would you do if you were in this situation?
A: Actually, we have a plan in place to deal with the matter. When we get to the public release about it, we'll let you know. We're currently working on a solution internally. It should be a viable partial, if not complete, solution to the problem. So keep an eye out. If you follow us on Twitter, you'll be the first to know when we make an announcement!
Q: In your perspective, which should come first: protecting the developed platform or saving the clients money?
A: Well, I believe that by using Ethereum, we consent to the terms and conditions, which state that Ethereum is a research and development project. People in this scenario knew exactly what they wanted. There is no reason to change the way the underlying technology is arranged in such a situation. Because the blockchain system is immutable, no one can intervene and modify the flow of events, but they can change the ledger.
Q: Do the DAO and Parity hacks have any similarities?
A: I believe they are distinct in terms of the total amount of stolen or frozen funds. Back then, the DAO was essentially forced to hard fork. We constantly follow the same norms of the blockchain as a source of tools and an immutable ledger from an ideological standpoint. We take risks as a result of it. One of the hazards is that the code contains business logistics that have not been realised and discovered owing to potential vulnerabilities or side effects. You have to take chances when you rely on the code.
It's worth noting that there was no criminal liability for Ethereum hacking in 2016. The legal culpability for the Parity case was later absolved. It merely describes what is allowed under the rules: if you write incorrect code, you are liable for it. Nobody else is to blame for the fact that you failed to notice some flaws. If your clients use your smart contracts, it only indicates that they are willing to embrace any dangers that may arise.
Q: Does the campaign have a chance of surviving?
A: I believe there are options. They may be working on them right now. We'll let you know when we're ready. I believe there are alternative options for resolving the matter.
Q: What can be learned from the Parity case study?
A: If you look at their release history, you'll notice that the library that was destroyed in November was issued in July. It was targeted because the previous version of the library contained flaws. So, what I'm guessing happened was that Parity was in a hurry. They were attacked in July 2017 and had to respond quickly to the situation. They may not have followed all of the regular code review protocols, and they may not have had enough time to evaluate the code internally or discuss it with various levels of technical management within the organisation. They most likely did not send it to the public for approval.
The lesson is that you should not haste when deploying something that is expected to work indefinitely. You should have a well-considered approach to the processes of deploying code that will eventually be immutable.