Denis Pisarev discussed the uniqueness of Polkadot, CI/CD, and DevOps specialists "The ultimate goal of Parity is to cease being the community center."
2 March 2023

About the background

Previously, I was involved in testing. At my previous job, I started as a junior and ended up as the lead of the testing team.
I live in Germany and have been working at Parity Technologies for over 4 years now. I was the forty-second employee. There are now 350 people. My official title is "Do not release manager", but in reality I am a CI/CD Team Lead.
At first, my task was to test the Parity Ethereum client. About a year later, we started winding down activities on it, and I switched to DevOps. Half a year later, we created a DAO for it with 8 developer teams active in the community to maintain it. Renamed it and transferred it to a separately created GitHub organization, OpenEthereum. Unfortunately, it didn't take off. As a result, Geth is once again rightfully the most popular Ethereum client.
My team deals with CI/CD in its entirety: hosts, clusters, provisioning, deployment, security, alerting, monitoring — everything is on us. And there is a large DevOps team that deals with everything else.
I plan to change the direction of my activities. I have many ideas for new projects. I made up and am going to become a «DevOps relations», it's like DevRel. I will deal with workshops, documentation, and products for DevOps.
We have an interesting project: a universal config for running a validator. It will include our Substrate + Sidecar. This is a validator for our chains bundled with an API. The goal of the project is to improve UX so that anyone can run this validator. Ideally, it should be launched with one click. The client will be anyone who wants to have a validator. One of the most important tasks now is to lower the entry threshold into the community.

About Parity

The company was founded in 2015. At that time, it was called EthCore. Its founder, Gavin Wood, is one of the founders of the Ethereum Foundation. The main product was the Parity Ethereum client. Within the Ethereum community, it became the de facto default client. The name somehow stuck, so we rebranded. We then wrote a few more clients in Rust, for Zcash, Bitcoin, and a couple of other blockchains. Later, our own blockchains, Polkadot and Kusama, were born.
The ultimate goal of Parity is to cease being the center of the community and to step back. The aim is to achieve fair decentralization, to bring Polkadot to the point where other community companies can regularly and consistently contribute to the project's core. As soon as this happens, it can be considered that the company has fulfilled its goal and can be closed. This is not entirely a joke: it resonates very strongly in our engineering culture. By the way, employees live comfortably with this. There's a cool idea — the Polkadot Fellowship: a new hiring model, so to speak. I suggest you read about it.

About DevOps

About 3 years ago, Parity still hired techies with a mandatory knowledge of blockchains. This included DevOps. Later, of course, we gave up on this, because they ran out. 90% of the work is quite ordinary DevOps work, which does not differ much from work in any other company.
DevOps specialists in the blockchain sphere are paid one and a half to two times more. I was hiring for my team for a long time, spent a lot of time "on the market". In the blockchain sphere, DevOps specialists are highly valued, but they don't particularly favor "these your" blockchains. That's why these specialists are paid more than usual. At least in the European market.
Testing in blockchains is a huge and unresolved problem. It requires a heavy blockchain background. Such engineers do not really exist yet, and blockchain researchers are not very eager to test releases for developers. Therefore, in blockchains, the QA function is shifted to developers — they do the tests. It's their responsibility. And of course, there is an external audit.

About CI/CD

I knew and was a bit involved with CI/CD even before Parity. At my previous job, I was involved in testing and knew how to, at the very least, add new tests to the CI config.
At the same time, there are separate systems that deal only with CI, and separate ones just for CD. But if you take modern GitHub actions, GitLab, Circle CI, Drone CI, and others — they all are full-cycle and practice both schemes.
CI — continuous integration of your code. Roughly speaking, you have smoke, unit, module, integration, end-to-end, UI — it would be good to run all of this before releasing.

When the project is large, there will be a lot of tests. They can take hours. You don't want to wait that long for each commit to be able to merge into its branch. Therefore, there are different pipelines, like assembly lines. This is, in fact, what CI/CD configs are. At the beginning of the pipeline are simple tests. Everything should be designed according to the Fail Fast principle - that is, if something works incorrectly, it doesn't take that much time. First, we run some code linters that check for typos and code structure. For this, built-in compiler tools are usually used. Then quick tests - units - are run. If nothing falls even after them, then end-to-end tests follow, which require the product to be assembled.

We increase the complexity and duration of tests as we deepen into the pipeline. We build a binary (of that very Polkadot client). If a mobile application is needed, we build the application, if a website, we build the site and deploy it, then run the rest of the tests.
Suppose we deploy to a cluster with other validators on a test blockchain. There we run tests that can only be checked with a running blockchain, that is, checks of all possible attacks, smart contracts, intrinsics and also transactions - whether they are executed correctly or not.
CD, or continuous deployment (delivery) — continuous delivery. Here the same principle of the production conveyor belt works. Fully tested code can be merged into the master branch.

When the team decides that it's time, a new release branch with a version number is branched out from master. It undergoes all sorts of tests and benchmarks, then it is paused and awaits manual audit. After that, the compiled binaries, weights, and the generated changelog are published on GitHub. The new version replaces the old ones in the production blockchain. A notification is created and, for example, a push is sent to Telegram and Matrix about the need for everyone who hosts their validators to update. Almost all of this is automated and requires minimal engineer involvement.

CD (Continuous Deployment) can occur separately from CI. It's not mandatory that there will be tests before CD. Usually, something needs to be deployed and delivered somewhere. Whether it's a binary - we want to place it, bring it to a place from where it will operate, and launch it there with the necessary parameters. Thus, it will be deployed into the blockchain or, in the case of a website, into production. In the case of an app, it will be deployed, for example, into Google Play.

About Polkadot

I'll outline the architecture. The Polkadot and Kusama blockchains themselves are what we call the Relay Chain. In effect, Polkadot provides a blockchain as a service. For simplicity, imagine that it looks like a master branch in Git, and the blocks are commits into the master branch. Thus, we need to maintain and author blocks only in the Relay Chain, and our entire Nominated Proof-of-Stake revolves around it. All validators work on the Relay Chain. This ensures the security of the entire ecosystem.

And, much like a branch in Git, a parachain will not end until you want it to, and as long as the conditions are met. All your blocks synchronize metadata with the blocks on the Relay Chain through collators. This information is stored on the Relay Chain in Polkadot and Kusama themselves.

Parachains can be up to a hundred — and that's an artificial limitation. The capability is already greater. These are more economic constraints, as our algorithms are built on game theory and economics.
There's also something called a parathread — it's like one parachain for several businesses. If they all don't need whole parachains, they can asynchronously share space in one blockchain. Collators are like the validators of regular blockchains.
They collect parachain transactions from users and create transition proofs for relay chain validators. In other words, collators maintain parachains, grouping parachain transactions into parachain block candidates and creating state transition proofs (Proof-of-Validity, PoV) for validators. But they don't need to provide security guarantees, because those are provided by Polkadot.

About use cases in Web3

For instance, they didn't stick to our parents and grandparents — nobody invented use cases for them. UI and UX should work as lowering the entry barrier. These are the main topics that all blockchain companies know about. In my opinion, the only valid use case is the existence of ready-made services and websites on web3.
What is web3? Privacy and you own your data. These are new models for earning on content, new business models, and types of employment — all of this will attract people to web3, but not to blockchains. The economy on blockchains, the ability to own finances that governments cannot play with that easily. These are all problems of all blockchain ecosystems — everyone has this. Whoever comes up next with a new breakthrough use case will win a market leap for themselves.
I think it's more useful to promote web3, not blockchain. If a person becomes interested in blockchain from a technical point of view — great, a new developer has appeared. But still, no one has yet come up with good use cases for most ordinary people. I think that blockchains should turn into backend infrastructure for web3. Naturally, blockchains with bad use cases and weak communities will die out.
Blockchain is generally for developers, and let it remain so. The entire tokenomics as a mechanism that supports the security of blockchains, is also not for ordinary people. Well, maybe just for risky investors.

About the difference between Polkadot and other blockchains

The root advantages of Polkadot are our great, large, and active community (I haven't heard about any hiring freezes from anyone), centralized security (but not in a custodial sense), quite mature decentralization, the ability to change root things on the fly, like, for example, the consensus algorithm. We have governance where members of the distributed community vote for changes and suggest their own. We already have good use cases.
Also, Polkadot is the most technologically advanced blockchain. To launch your own parachain, you can just come up with an idea and only implement your business logic. Therefore, when you have some use case for the blockchain, in our ecosystem, you won't need blockchain developers, auditors, and security experts for it. Also, it's not necessary to have DevOps, who would maintain validators.
We are actively working to lower the entry barrier: we conduct many conferences, workshops, and meetups, record videos for any level of beginner. Last year we launched the Polkadot Academy and tested it at the oldest faculty of Cambridge. This is a month-long deep-dive course into blockchain development in Rust. Most of the graduates were immediately hired by us and other community projects.
Everything is ready for you to come, present your idea, and get everything you need: a grant for development, help and support from the ecosystem. If needed, everything else can be assembled on Substrate — the framework for our ecosystem. But along with this, you can customize: if you want even a second level of consensus on your parachain — please, there are tools and support. It's your rules on it. You can do whatever you want (within decency).
In particular, Jutta Steiner, the co-founder of the company, actively consults the German government and institutions in the fields of blockchain and crypto economics. Much of the current sensible tax policy on crypto in Germany is thanks to Jutta.
DotSama, by the way, was recently recognized by the SEC as Software. Now we have free rein in terms of marketing. Before that, we were frankly cautious, so as not to follow in the flight of the footsteps of TON and, of course, so that we were not accidentally considered another scam. Now we are changing our strategy. The new CEO of the company, Bjorn Wagner, is actively working on this.
The joint project of Parity and United Nations — the World Food Programme — is undeservedly rarely mentioned. It's a private blockchain to support refugees, used by over a million people! Winner of the 2020 Nobel Peace Prize. The thing is, UN states cannot issue passports to refugees, cannot pay them money, tax them. All this has become possible with the help of blockchain. IDs and medical cards were issued for refugees, they got the opportunity to work normally, receive salaries and targeted humanitarian aid, make purchases on-chain. And they log in with their retinas. Isn't a Cyberpunk? It is. They will soon move to Substrate.

About Zero Knowledge

We have several projects with good ZK ideas. Personally, I believe that there should be even more ZK. It's a very cool and yet unexplored field of use cases for blockchain.
Our researchers take ZK very seriously. Jeff Burges, for example, recently talked at ZK8 about rollups and breakthrough optimization. It's just that in Polkadot Relay Chain there is no place for new ZK use cases by design. As a parachain — perfect, that's the point! As a system-parachain (free, maintained from the treasury, needed for system integrity) — also quite suitable. This thing is needed, but it definitely should not clog the main blocks.
This is a good base for launching rollups, when there is decentralization, a high level of trust quantity and the already mentioned centralized security. As a base — it is already built into the architecture.
Article image
Bootcamp: Solidity Developer
From the basics of Solidity to deployment on the mainnet.
Learn more


What is the usual learning process?
Will I be able to combine studying with working?
How much time should I devote to studying?
How long does the learning process last?
What happens when I finish the bootcamp?
What is the class schedule? What happens if I miss a stream?
I'm a complete beginner, can I study with you?
I have been writing smart contracts in Solidity for over a year now, will it be useful for me to study with you?
What is the difference between bootcamps? Which program should I choose?
What projects will I be working on? And what will I be able to do upon completing my studies?
Will I be able to get a job at a top-tier protocol in 6 months? And how do you assist with this?
I'm interested in crypto and Web3, but I don't want to become a developer.
Balaji was right