In the future, trusting an institution with our interests will be as archaic a concept as reckoning on an abacus is today. - Gavin Wood, Parity Technologies Founder
Parity’s history reveals the significant contributions that the company and its individuals have already made to the decentralization movement. The company has differentiated itself in its ability to identify mistakes and incorporate lessons learned into modes of operation moving forward. Moreover, they maintain great communication with the blockchain ecosystem and exercise transparency in all major projects. Indeed, Parity serves as a model for new and existing organizations in the space.
The company owes much of its success to a culture and philosophy of operation that supports autonomy. Parity’s CTO Fredrick Harrysson has said that the company strives to embody the ideals of Programmer’s Anarchy to ensure that, as an employee, “you can dive as deep as you want into that rabbit hole and geek out about something you love doing”. This approach to developer governance encourages creativity and innovation thereby fostering a very productive environment for solving complex problems.
From the beginning, Parity has made smart technical decisions to ensure their technology remains relevant for the foreseeable future. By targeting WASM, coding in Rust, and using libp2p for networking, Parity has incorporated much of the best technology into its main projects. These design decisions reveal great awareness of the cutting-edge technical development both within and outside of the blockchain space. In open source software, this awareness is imperative to success as collaboration takes on newfound importance in the context of an accelerating development environment.
Gavin Wood was Ethereum’s CTO for the first 18-24 months of the project. In this role, he was responsible for ensuring the design, development and final release of Ethereum went well. During his time as Ethereum’s CTO, Gavin Wood wrote the Ethereum Yellow Paper, which contained the specification for the Ethereum Virtual Machine (EVM) as well as the Solidity programming language. His contributions to the Ethereum project in its early stages were instrumental in enabling the initial launch of Ethereum.
ETHCore => Parity
In 2015, Gavin and a few Ethereum developers started ETHCore, which eventually became Parity. In its early days, Parity was focused on supporting Ethereum by building core infrastructure to facilitate interaction with the Ethereum blockchain.
Drawing on his expertise in Rust, Parity cofounder Robert Habermeier led the charge to build Parity’s now longest existing project, the Parity-Ethereum client. This Ethereum blockchain client provided a much needed alternative to the most popular client, Geth. Moreover, performance analysis revealed that Parity’s client achieved higher processing speeds than Geth both with respect to blocks as well as the transactions within blocks. The lessons learned from Parity’s experience building blockchain clients for Ethereum shaped many of the critical design decisions made later when building Substrate (and Polkadot).
Learning from Mistakes
Parity’s awareness of the blockchain ecosystem extends beyond recognizing and correcting for their own mistakes. Indeed, I have also been impressed by the organization’s ability to identify the shortcomings of other existing projects and incorporate these observations into their own design decisions.
Modular Approach to Transaction Signing
After nearly $100,000 USD was lost due to a security flaw in Geth/Mist in May 2016, Parity released a series of blog posts detailing the steps necessary to patch the attack vector for future clients. In the first post, Parity cited that “the solution to the Mist hack problem will always be to isolate the process of signing transactions from Dapps, keeping the security-sensitive processes both insulated from attack and well under the control of the user. Only by doing this can you keep your keys, and the increasing shades of value they represent, safe and secure.”
The DAO Hack and Ethereum Hard Fork
Two days after the infamous Attack on the DAO in June 2016, Parity released a blog post aimed at unifying the community. Parity provided a detailed, yet easily accessible explanation of the hack before encouraging a legitimate community response. In doing so, the team demonstrated the crux of decentralized governance:
Decentralized consensus networks are peer-to-peer networks where individuals acting in their own self-interest maintain consensus on an agreed upon state of the blockchain database. It is these two terms; ‘agreed upon’ and ‘self-interest’ that are most important.
Shortly thereafter, Gavin Wood published How do we find common ground and settle our differences to explain the many incentives at play in the aftermath of the DAO hack as well as necessary next steps. He noted that “a normally immutable change had been made to the blockchain which was considered undesirable/unacceptable to a (potential) majority of the people who use the network.” In trying times like these, Gavin cited the need for stakeholders to drive social consensus (and the network’s decision): “It is important to note that throughout this process the developers are not expected to remain agnostic or indifferent. They are important players in the ecosystem and will likely voice their opinions on how best to evolve the network.”
Although the DAO hack precipitated Ethereum’s first contentious hard fork, it also exemplified the breakthrough made by contemporary blockchain governance. When the intended execution of the protocol does not match the real world outcome, the community can take decisive action to agree on another state of the world. Some may not agree that this is the best approach, but it is my opinion that, by providing optionality, hard forks like the one employed after the DAO hack enable proper community governance.
Parity published In support of a hard fork in mid-July 2016, expressing their support of a hard fork with a similar rationale. A week earlier, Vlad Zamfir explained in Dear Ethereum Community why hard forks are a necessary part of the blockchain technology upgrade path.
EVM Gas-Setting Vulnerability
In September of 2016, a flaw in the EVM’s protocol for setting gas prices was exploited to construct transactions that ate up a lot of resources without requiring an appropriate cost from the transaction submitter. This attack on the Ethereum blockchain caused many implementations to crash on block number 2,283,416, but Parity continued to run. In Onwards, Gavin Wood attributed Parity’s ability to overcome the attack to “great optimization and profiling efforts, a clean codebase written for efficiency and robustness from the ground up and the use of the extremely lean Rust language.”
Multiple Problems with the Multi-sig
On July 19, 2017, the first Multi-sig Hack occurred in which attackers reset the ownership and usage parameters of Parity wallets. In response, Parity posted a comprehensive blog post the subsequent day detailing the nature of the attack as well as the actions that were being taken to mitigate the damage to users. This post described how the attack vector came about during a restructuring of the Wallet user-interface and was, in the process, overlooked by the core team. Parity noted that one reason the bug wasn’t found earlier may have been the fact that “there was no incentivization mechanism to ensure good-natured eyes from the community to inspect it.”
In response to the attack, Parity refined their development process and CI system to ensure more comprehensive reviews of critical code updates in the future. They also revisited the high-level architecture of the Multi-sig wallet by drafting a simple contract to sit between the Multi-sig and its assets (CoreVeto); this served to enable a simple veto-able time-lock contract that would provide a last defense against future black swan events. Moreover, the team vowed to incentivize greater community ownership over the code. A few days later, Parity announced that this mechanism would take the form of a bug bounty program wherein the community would be incentivized with an Ethereum reward to report any issues found in the Parity codebase.
Unfortunately, these precautions did not prevent the second Mult-sig Hack on November 6, 2017 in which 513,774.16 Ether were frozen by the infamous ‘devops199’. After this vulnerability was brought to the attention of Parity, the team released a series of blog posts describing the steps they were taking to potentially recover the frozen funds and prevent similar vulnerabilities in the future. Although this two-part Multi-sig hack damaged Parity’s reputation and negatively effected users in both instances, these events have forced the organization to undertake a number of significant changes that have bolstered development moving forward. We learn the most from our failures. Indeed, the mistakes made by Parity with their Multi-sig wallet have led to more rigorous third party audit standards as well as a long-term partnership with Trail of Bits; audits are now the norm in the space for significant projects!
Scaling with Polkadot
Around mid-2016, the Parity-Ethereum client reached version 1.0 and scaling became more of a concern. Although there were many interesting ideas being discussed at a high level, Parity’s team started to become impatient/frustrated with the lack of concrete specifications from the Ethereum Research team. At some point, they realized that Parity would need to build a scalable version of Ethereum with or without the Ethereum Foundation.
Before we continue, it is worth considering the obstacles faced by the Ethereum Research team at the time. Rather than having the flexibility of implementing an entirely new system from scratch, the Ethereum Foundation research team was forced to work under the constraints of the existing Ethereum implementation. As Gavin Wood mentions in the podcast, “uprading any system in situ is very hard; upgrading a decentralized system in situ is basically impossible.” With this in mind, Parity’s team decided the best approach would be to do it themselves: “the next chapter hadn’t been written so it was up to us to pick up the pen” - Gav.
In early October 2016, Gavin Wood revealed that recently exposed flaws in the EVM had motivated him to rethink scaling in the context of Chain Fibres, Redux as well as some related ideas that Vitalik expressed in the Ethereum Mauve Paper. Eventually, Gavin’s musings took shape as Polkadot.
In late June 2016, Gavin Wood published a post on Condition-Oriented Programming (COP), a hybrid approach between functional and imperative programming. Put simply, COP aims to ensure that function bodies have no conditional paths or, alternatively, never mix transitions with conditions. By discouraging conditional paths from state-transitions, this approach limits the complexity of state-transitions, thereby allowing for facilitated auditability and better testing. More than two years later, James Prestwich published Declarative Smart Contracts reiterating the necessity of a functional approach to smart contract code patterns. In this post, Prestwich cites that “declarative contracts align the structure of the contract implementation with the reality of the chain by defining exactly what state modifications are permissible, and letting the user modify state directly. Declarative contracts prevent unintended state changes.” This serves as just one of many examples in which Gavin Wood and, more broadly, the Parity team have identified the right approach to software engineering before the rest of the space.
Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. - Rust-Lang Website
Indeed, Rust defies the performance-safety tradeoff typically experienced with other programming languages. It is the natural choice for building the next generation of distributed networks, and instills confidence in the underlying implementation (for Parity-Ethereum, Substrate, Polkadot and the other Parity projects).
WASM expands the family of languages available to smart contract developers to Rust, C/C++, Typescript, Haxe, and Kotlin (and more soon!). Additional benefits of targeting WASM include:
- memory-safe, sandboxed, platform independent
- supported by LLVM compiler infrastructure
- continually developed by Google, Apple, Microsoft, Mozilla, and Facebook
- high performance (designed to be as close to native machine code as possible while still being platform independent)
The Parity 1.5 release mentioned a 10-day Yuletide retreat-sprint in Lipia Gora. The Parity 1.6 mentioned a similar winter-sports retreat in Castello Tesino. These retreats are very valuable in promoting a culture conducive to genuine team-building. Indeed, long-term organizational success requires a team that operates like a family; such a culture allows for the tough love necessary to push forward when things are difficult while also enjoying the journey when times are good.