When I decided to enter the Blockchain ecosystem, it was because of the promise of globally scaled distributed fault-tolerant systems and not cryptocurrencies (although I am a big fan of those as well). Many have labeled Blockchain as a transformative technology that will change the world, which created unrealistically high expectations from the industry that barely made its first steps. Years later, cryptocurrencies are still the main driving force behind Blockchain.

At Ethereum Devcon this year, most of the talks were about scaling. And similar conversations could be heard at every major Blockchain conference. Blockchain’s ability to meet growing network demand is something many worry about, and these limitations are one of the major stumbling stones on the road to mass adoption.

Right now, we are still in the Infrastructure building stage. As an industry, our biggest bet right now is on DeFi, and no one uses Decentralized Applications yet.

Problems With Current Blockchains

Currently, decentralization comes with a challenging restriction – blockchain consensus mechanisms require every participating node in the network to process every transaction (and maintain a copy of the entire state) in order to consider it valid.

This process is slow and cumbersome, considering it also makes us hold many, possibly unnecessary, copies of the data, and share bandwidth with all network participants.

As a result, public blockchains that operate in such a decentralized manner choose low transaction throughput to avoid a high degree of centralization. In other words, as the size of the blockchain increases, the requirements for computing power and storage required by the network grows. And at some point it can happen that only a handful of nodes can process transactions, leading to a higher degree of centralization.

Corporate Blockchains

On the other hand – IBM, a major player in the world of enterprise blockchain, is promoting Hyperledger Fabric as a private or permissioned blockchain, indicating that it offers features similar to those of well-known blockchains such as Monero or Zcash, while somehow eliminating any characters that might be unsuitable for the enterprise.

If we compare the core definition saying that blockchain is a decentralized immutable ledger of transactions governed by a consensus mechanism to IBM’s Hyperledger Fabric, we conclude that Fabric is not a blockchain. Instead of using a true consensus protocol, Fabric suggests using “ordering service” called Kafka. Without a decentralized consensus mechanism, users wouldn’t be able to prove that the blockchain has not been tampered with. The agenda of IBM behind this push could lie in the enabling of corporate consortiums instead of the user-controlled networks in order to keep the same level of centralized control while selling it under the disguise of decentralization.

This is not a new phenomenon. Companies were always slow to adopt ideas that were about the global sharing of information. With the development of the Internet as the all-encompassing global network where anyone could join and share information, it became easier than ever for small companies and individuals to connect to other people and share data online.

Data was always valuable and, while the global network would prove to be a huge economic success, big corporations definitely wanted to keep control of the data even back then. The idea of WWW, proposed in 1989 by Tim Berners-Lee and others was used as the prototype for the first internal networks.

These first intranets had a goal to increase productivity by giving people easy access to documents and more effective communication. Intranets copied all functions of the Internet: e-mail, group work support, audio-video communication, texts or personal data searching.

As the Internet grew and became widely adopted, companies became more and more willing to open up their closed communities. Over time, the content placed on the Internet became more important than the underlying infrastructure.

Most probably a similar course of development will happen with Web3 and blockchain too.

Interoperability Problem

Companies were always looking for better ways to collaborate between departments or between corporations while keeping control over their environment and data. Martin White explained it well in a piece about intranets’ history.

Doug Engelbart, the inventor of the computer mouse and remote database access (and many other things), was the first to consider the concept of collaborative computing in 1951. In 1987 we had the first appearance of the term “groupware” in an article written by Louise Richman and Julianne Slovak for Fortune magazine.

The late 1980s was a period of substantial development of groupware products, with Lotus Notes leading the way. Tom Peter’s book titled Liberation Management published in 1992 was centered around the shared access to computer resources and information, showcasing the widespread use of groupware applications. These web technology intranets haven’t evolved from public websites but from corporate groupware applications.

As more companies are going through digital transformation we can expect to see more interconnected systems using Blockchain to automate execution and provide an extra layer of security.

This is where we can see the growing pains of many corporations testing out Blockchain right now. We did a number of private Ethereum implementations for our clients that were looking to do Blockchain pilots in their own closed environments as prime tenants. The problem with this approach is that, after the initial testing, you need to actually move out of your walled garden and start connecting to other entities.

This is currently almost impossible to do. Throughput of the network is too low, using the network is too expensive and in many cases, we still don’t have general-purpose solutions for things like Zero-Knowledge Proofs (ZKP) which would enable us to easily connect different networks.

But the interest that was shown and the approach itself is not bad and it is showing that people want control over their own environment. This is why I am a big fan of projects that are trying to enable developers to build products that can be interconnected easily.

Developability, i.e. ease of development and deployment was the fundamental innovation of Ethereum and made it a dominant blockchain development platform.

However, Ethereum is not letting people build sidechains in any way they like.

Introducing Polkadot

At a higher level, the Polkadot project is trying to solve the problems of scalability, interoperability and shared security, while letting you keep control and decisions over your internal infrastructure.

Polkadot Network consists of a relatively large number of tightly-coupled blockchain networks, called parachains. And parachains are coordinated by one central blockchain network, called the relay chain. Polkadot also has a large, shared pool of validators tasked to provide security and trust-free interoperability for the entire system. The main difference between the two systems is that Polkadot parachains are heterogeneous and sovereign, meaning they can have different protocol configurations and can be application(or use case)-specific. The parachain development process is relatively complex and similar to that of Cosmos zones.

Cosmos, similar to Polkadot, aims to solve the problems of scalability and interoperability through the creation of “Internet of Blockchains.”

I like Cosmos very much as a project, but there is a reason why right now I would choose Polkadot. Cosmos chains can’t trust each other or do trust-free interchain communication because they do not share security. Each chain has to secure itself whereas in Polkadot all chains share security and can trust one another.

Polkadot security // Source: Parity.io

Polkadot parachains use the same source of security, allowing them to process more transactions faster, without worrying about the problem of colliding transactions. Parachains also have an excellent potential to solve scalability issues I mentioned in the introduction, as each parachain can have their own parachains and so on. This would create a tree-like structure that could be used to perform distributed computations without increasing the burden on the root relay chain.

Security is provided by the validator set. Loosely, as the number of validators grows the security of Polkadot increases. This is somewhat independent of the number of parachains. Then there are considerations for economic security. Scalability is perhaps correlated to the number of parachains: i.e. more parachains allow a greater number of transactions per second (in concurrency across all chains).

Another use case of parachains scalability could lie in Zero-knowledge proofs. As Robert Habermeier, the co-founder of Polkadot, said:

“Modern-day non-interactive ZK proofs like ZK-SNARKs or ZK-STARKs allow us to check the proof that a known program with some known inputs and some unknown inputs was executed correctly, and learn what the output of that program was without leaking any information about the private inputs.”

Besides the obvious use case in privacy protection, ZK proofs have another great quality – the time to check them is nearly constant regardless of the complexity of the program itself. This would mean that we could verify any transaction, no matter how complex, within seconds. Still, the computational costs to create ZK proofs are pretty high, making it infeasible for an average user.

To quote Robert once again:

“By allowing each parachain to define a notion of its own validity, we can seamlessly transition from our current bulky proofs to lighter, more advanced proofs in the future. As *sharding research develops, parachains can easily be added which implements the latest techniques. And that’s ultimately what Polkadot’s value proposition boils down to that it sits at the right level of abstraction to work in both the present and the future without any unnecessary overhead. The system is designed to not only accommodate arbitrary progress but also to have the extensibility to integrate the latest developments in scalability without a hitch.”

*Sharding is a way of partitioning to spread out the computational and storage workload across a peer-to-peer (P2P) network so that each node isn’t responsible for processing the entire network’s transactional load. Instead, each node only maintains information related to its partition or shard.

All of this means that, although the Main Net is not yet live, the Polkadot ecosystem is growing very fast.

Overview of Polkadot Ecosystem

Check out PolkaProject (community-maintained) for a full list of 40+ projects building on Polkadot across DeFi, smart contract platforms, scaling, oracles, DAOs, exchanges, IoT, privacy, and more. Here are a few examples:

Data curation networks (Ocean Protocol).

networks (Ocean Protocol). Oracles that make off-chain data available to all contracts on the Polkadot network (ChainLink).

that make off-chain data available to all contracts on the Polkadot network (ChainLink). Identity chains that link accounts to a persistent identity and enable access to other parachains through fewer accounts (Speckle OS).

that link accounts to a persistent identity and enable access to other parachains through fewer accounts (Speckle OS). Financial chains that allow you to hold all your assets in one portfolio, including via bridges to Bitcoin, Ethereum, Bitcoin Cash, Litecoin and ZCash (ChainX, Katallassos).

that allow you to hold all your assets in one portfolio, including via bridges to Bitcoin, Ethereum, Bitcoin Cash, Litecoin and ZCash (ChainX, Katallassos). Payments chains with lightning-fast transactions (Blink Network).

with lightning-fast transactions (Blink Network). Internet of Things chains that set IoT standards for machine-to-machine communication (MXC Protocol).

that set IoT standards for machine-to-machine communication (MXC Protocol). Substrate EVM also makes it very easy to migrate Ethereum smart contract-based apps to Polkadot easily.

So, If you want to test Polkadot and migrate your app, Kusama Network is a great way for you to try it.

Kusama Network

Kusama is an early, unaudited and unrefined release of Polkadot. Kusama will serve as a proving ground, allowing teams and developers to build and deploy a parachain or try out Polkadot’s governance, staking, nomination and validation functionality in a real environment.

In order to get off the ground with a soft launch, Kusama has begun as a PoA (proof-of-authority) network with validator nodes run exclusively by Web3 Foundation (without compensation, of course!). During this period, much functionality of the network is disabled. In particular, balance transfers are not possible and governance is limited to the “Sudo” module for which the Web3 Foundation holds the single key. Functionality enabled is limited to usage of the Staking, Sessions and Claims modules; specifically, bonding, nominating and issuing an intention to become a validator, setting up one’s session keys and claiming KSMs will be supported.

Polkadot Ambassador Program

Another key thing that needs to be said is how diverse the Polkadot project is. Web3 Foundation already holds less than 30% of DOT tokens.

For Polkadot to be successful there need to be multiple incentivized implementation teams (ChainSafeth writing Polkadot in Golang, ParityTech writing Polkadot in Rust, Soramitsu_co writing Polkadot in C++).

Polkadot seems like the best bet against Blockchain maximalism right now. It is built on the idea of connecting chains with distinct state machines and consensus protocols, with the ability of public and private blockchains to basically run on the same network.

All this creates a very strong incentive for the developer community and Blockchain agnostic product development agencies (such as MVP Workshop) to build on top of Polkadot.

There are already 25+ teams building on Polkadot and we still have months to go before launch. So it’s safe to say Polkadot relay chain launch will bring with it dozens of new blockchains! Polkadot isn’t a normal blockchain launch. They are launching an entire ecosystem at once, a cloud of economic activity with dozens of chains interacting together. The best way to start building a blockchain for Polkadot is to learn about Substrate. Substrate is a framework that reduces the time needed to build a blockchain by weeks because you can use existing modules for consensus, governance, balances (if you want to have a token), etc.

Polkadot is definitely one of the most exciting parts of Web3 and being a part of the ambassador program lets you work with some of the most notable figures in the Web3 space while forging ties with others who are equally as passionate about architecting a better future for everyone.

I’m very proud to be a part of the Polkadot ambassador program, and MVP Workshop’s crew and I look forward to seeing the Polkadot Network project leading the way towards Web 3.0. If you would like to join the Polkadot family as an ambassador, check this article.

For any other info, visit the official Polkadot website and make sure to follow the project on social media.

Thanks for reading and let me know if you have any questions! I would be glad to answer them for you.