Analysis of Polkadot
This article explores what interoperability is, why it is needed, and how Polkadot is trying to achieve it. While doing so, the reader will get an overview of the architecture, consensus protocol, governance, and working of Polkadot. The article also tries to explore risks associated with the project and compares Polkadot with Cosmos.
Interoperability
In the early days of the crypto-ecosystem, most of the cypherpunks subscribed to the ideology that there will be “one blockchain to rule ’em all”, which will be the panacea for all the problems. This is the view of the people belonging to a constrained vision as per this article by Arjun Balaji and Yassine Elmandjra. However, with time, the other set of people, with an unconstrained vision, started to emerge. And these people were of the opinion that single chain maximalism hinders the potential upside introduced by cryptocurrency-related innovation. Tinkerers started to explore various possibilities and started building specialized blockchains.
A plethora of blockchains has been designed to cater to various needs and use cases. In the public blockchain space, all these blockchains try to negotiate a trade-off among various parameters such as security, privacy, efficiency, ease of developer use, flexibility, etc. Similarly, in the enterprise blockchain space, different blockchains exist for different industries. In such a world of public and private blockchains, it is natural that there is a need to build platforms that do much more than a simple API integration to facilitate seamless movement of data and value from one blockchain to another. And this is how cross-chain or interoperable chain projects came into existence. With interoperable chains, little effort is needed on the part of operators, as third parties can be employed for movement of assets from one platform to another, or payment-versus-payment and payment-versus-delivery schemes, or accessing information from one chain inside another.
Vitalik Buterin has illustrated three approaches to public blockchain interoperability in this paper.
- Centralized or multisig notary schemes, where a particular action on chain A can be carried out as a result of an event occurred on chain B
- Sidechains/relays, where system inside chain A can read and validate events on chain B
- Hash-locking, where certain functions on chain A and B are invoked after a common trigger
The objectives achieved by interoperability could broadly be listed as follows:
- Transferring assets from one chain to another
- Assets on chain A get locked based on an event on chain B. This is useful in situations where collateral plays a part, for example, financial derivatives, bankruptcy clawbacks
- Atomic Swap, meaning that either both transfers happen or none happens. An example is user A has to transfer asset X to user B if and only if B transfers Y to A. Atomic swaps ensure that either
- General cross chain contracts such as paying dividends on chain A to holders of an asset in case the ownership is registered on chain B
Introduction to Polkadot
Polkadot intends to build a network that connects public blockchains. It’s being built with the view to connect the past, present, as well as the future. It not only allows blockchains to connect but also allows them to pool the security together so that the individual chains can leverage the collective security without having to build from scratch to gain trust. This video by the founder Gavin Wood and this by Robert Habermeier are good introductions to Polkadot’s design principles.
When it comes to the design, Polkadot shares certain principles with Ethereum’s Casper, and some of their goals overlap as well. However, the deeper underlying designs of Polkadot and Ethereum are different. While Ethereum aims to be the platform to build dapps, Polkadot itself is designed for no purpose other than to connect other blockchains to each other. It has no inherent application functionality i.e. it is a scalable heterogeneous multi-chain.
The guiding principles propelling Polkadot design dictate the design to be minimal, simple, general, and robust. This is to ensure that the network, by itself, has no functionality and yet provides a fundamentally stable base layer for other consensus systems to build upon.
Architecture
Polkadot is made up of three major ingredients: Relay chain, Parachains, and Bridges. Relay chain acts as the coordinator of consensus and transactions between chains, Parachains are the constituent blockchains and Bridges are the links to blockchains having their own consensus methods.
Relay chain
Relay chain is called so because it provides security to the attached parachains and also guarantees secure message passing between them. It is the foundation on which other validatable data structures can be hosted side-by-side. Relay chain is broadly similar to Ethereum as it is also state-based with states mapping addresses to account information such as balance and number of transactions. However, there are three major differences between Ethereum and Polkadot’s Relay chain.
- As Polkadot’s vision demands it to have no application functionality, the Relay chain does not support the public deployment of contracts
- Ethereum charges ‘gas’ for every operation in the transaction to avoid spamming. However, this also increases the time to complete transactions and thereby invites scaling issues. To counter this, Polkadot has decided to have a flat transaction fee regardless of the number of operations. Though this allows Polkadot to be more scalable, it increases the possibility of spamming and how this problem will be taken care of is not yet clear
- A special functionality allowing auto-execution and network message outputs is supported for listed contracts
Parachain
Parachain is nothing but an existing or future blockchain connected to Polkadot. It attaches itself to the security provided by the relay-chain rather than having its own security. A key feature of parachains is the computations performed by them are completely independent. Fully generalized systems of turing-complete smart contracts may run into issues when transactions possible of colliding with each other are to be determined. Therefore, even the transactions that could be run in parallel are run sequentially, wasting valuable computing time as a result. Keeping this in mind, clear boundaries are drawn between parachains so that concurrent execution is possible thereby increasing the scalability.
Bridges
A bridge offers a connecting layer to the existing protocols that possess their own state-histories and consensus protocols. The bridge connects blockchains with smart contract capabilities to Polkadot without affecting their native protocol.
Network Participants
Polkadot has four major network participants; Validators, Nominators, Collators, and Fishermen.
1. Validators
Validator plays probably the most important role in Polkadot as they finalize new blocks on the Relay chain. In order to do so, validators have to place a significant security deposit (in the form of the native token, DOT) otherwise known as bonds. It is also possible for other actors to nominate a validator on their behalf by staking an appropriate amount. A validator is supposed to run a full Relay chain client to ratify new blocks. The process involves receiving, validating and re-publishing the candidate blocks on the relay chain. As the task to maintain a synchronized database of all the parachains is arduous, validators nominate third parties known as collators to devise new parachain blocks.
A validator not performing duties to finalize a block based on the agreed consensus mechanism is punished by withholding the reward at the beginning (validators are obviously compensated for their effort). Repeated failures result in confiscation of some of the bond amount and proven malicious behavior such as double-signing results in the loss of the entire deposit.
2. Collators
Collators maintain full node at their respective parachains i.e. they store all the necessary information needed to author new blocks and execute transactions. They gather and execute transactions and put them in an ‘unsealed block’; which coupled with a zero-knowledge proof is provided to validator/s responsible to propose new parachain blocks. Collators almost do the same work as the miners in current Proof-of-Work blockchains. Validators, with the help of collators, move transactions from the output queue of the source parachain to the input queue of the destination parachain. In case validators misbehave, they lose their security deposit.
3. Nominators
Nominators contribute to the security bond of a validator. They risk the capital and in return get to nominate a validator to act responsibly for the maintenance of the network on their behalf. They also receive a pro-rata reward or reduction depending on whether the validator nominated by them performs the desired function.
4. Fishermen
Fishermen are not directly involved in the block authoring process. They are incentivized to act as ‘bounty hunters’ with significant one-off rewards for identifying and proving malicious behavior among bonded network participants. Fishermen have to post a small bond deposit to prevent sybil attacks. This prevents wasting validators’ time and computational resources. Fishermen are free to withdraw their deposit at any time.
Substrate
Though Substrate is not a part of Polkadot per se, it is important to mention because it is used to build Polkadot. This article gives a good overview of what Substrate is. The analogy between Substrate and Polkadot can be thought of this way: if Polkadot is the Ethernet, Substrate is the Computer we use. Polkadot is a specific protocol while Substrate is a generalized technology stack. It is not used for one particular network, it is used for many chains that may have their respective tokens. Polkadot increases the execution speed within the state machines and thereby scalability using Substrate. Substrate is written in Rust, however, the core functionality that comprises the state machine is also written in Wasm (WebAssembly). This lends core functionality two benefits: Rust allows faster execution and Wasm allows improved flexibility with a lower number of operations per second. If a node is upgraded to the latest version (the version number is stored on the blockchain) of the code, it runs the code natively in rust; otherwise, it makes use of the Wasm interpreter for execution.
The substrate can be thought of as a web application framework for building distributed or decentralized systems such as cryptocurrencies. With Polkadot and Substrate, developers get three options: Solo chain, Solo chain with a bridge, and Parachain.
- Solo chain, as the name suggests, is sovereign and does not connect to the other chains
- Solo chain with a bridge to Polkadot can listen to Polkadot and is provided with a level of interconnectivity between the two. It retains the sovereignty of the chain and the bridge has to explain to Polkadot what that sovereignty means. The sovereignty is retained at the cost of pooled security of Polkadot i.e. as the chain retains its sovereignty or consensus method, it no longer is the parachain and thus cannot enjoy pooled security.
- A parachain can enjoy Polkadot’s pooled security as it gets to piggyback on the relay chain’s consensus. Therefore, there is no need to economically incentivize users of parachain.
Consensus Algorithm
Design Principles
Consensus algorithms have two main properties: safety and liveness. Safety is a property that guarantees that once a block is finalized, the canonical chain will always contain that block. Liveness means that the chain will keep on growing, i.e. valid transactions will eventually be included and finalized.
PoW and PoS algorithms approach consensus differently. In PoW chains, misbehavior is not punished actively, it is rather discouraged as there is an opportunity cost lost to behaving dishonestly. Bitcoin approaches consensus through the longest chain rule, i.e. a chain that is longest is the valid chain. In theory, this model allows creating a new longest chain if enough mining power is available. Latest block is the most vulnerable to a reversion and so on. The bitcoin whitepaper suggests that after 6 blocks the transaction is ‘practically’ confirmed. However, it is never 100% confirmed. Thus, in PoW blockchains, finality is never perfect, it is always probabilistic.
This article is a good start to understand how Polkadot is trying to achieve consensus. Polkadot considers it important that finality is deterministic and accountable. The consensus protocol is safe unless more than 1/3rd of the participants misbehave. Under the accountable safety, finality means that a block cannot be reverted unless at least 1/3rd of the stake is burned. And when a protocol has to do that, a large number of messages are to be passed within the system. With the increasing number of network participants, the messages need to be sent do not scale appropriately. This makes consensus really difficult and expensive. This is why it is beneficial to separate the liveness (block production) from safety (finality). A finality gadget that allows finalization of many blocks together thereby reducing the number of messages to be exchanged. Polkadot uses a hybrid model that has a block production layer which is probabilistically safe and finality layer capable of finalizing many blocks at once and is deterministically/absolutely safe.
Finality and weak subjectivity
The finality gadget in Polkadot is GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Arrangement). The algorithm is developed based on an assumption/intuition that the parent block of a valid child block will also be valid. Instead of voting on a single block, participants are allowed to vote on the highest/latest block that they think is valid. The algorithm transitively applies to all the ancestors of that block. The best block is determined by the supermajority (more than 2/3rd of the votes) and the proof of finality is produced. This proof is generated by taking supermajority votes and bundling them together into a single message. The next step is to use signature aggregation to make it more compact.
The voting, as well as the registration of finality, happen off-chain. However, the algorithm is secure as long as the historical participants are on the hook for violation of any rules such as double voting, hence the deposit is always on-chain and can be confiscated partially/fully based on the degree of misbehavior. This is where weak subjectivity comes into the picture. Under weak subjectivity model, the participants have to wait for long periods of time to withdraw their security deposit and rewards. This article explains what weak subjectivity is and why it is relevant for PoS algorithms. Essentially, PoW is an objective algorithm i.e. the current state is the state with the most amount expected of proof of work. New nodes joining the network or nodes coming online after a long time, only need to know the protocol definition, set of all blocks and other important messages in order to come to the same conclusion as the rest of the network. On the contrary PoS system is subjective i.e. new nodes need a large amount of information to participate in the network. To avoid long-range attacks (possible chain reorg from the genesis block), just like Ethereum’s final PoS version, Polkadot also hard-codes “checkpoints” into the clients. This way the protocol simply forbids nodes from reverting more than X blocks, X being the security deposit length.
Native Token and Governance
DOT is the token native to Polkadot platform. The token serves three main purposes: providing the governance for the network, facilitating the network operation, and creating parachains by bonding DOTs i.e. it is used as the security deposit.
DOTs are at the main layer of the governance and they entitle holders to control the governance of the platform. The governance can be influenced by determining the network fees, addition/removal of parachains, etc.
DOT holders can participate in the network by becoming validators, collators, nominators or fishermen. The DOTs required to participate in the network, the duration for which DOTs are staked, and the total number of DOTs staked will vary according to the activity undertaken.
Apart from DOTs, Polkadot plans to have a council, an on-chain entity comprising a number of actors represented as an on-chain account. This number begins with 6 members and can potentially increase to about 24 members over the course of 9 months. This mode of governance will only be a backup in case of low voter turnout.
Polkadot is also planning to add adaptive quorum biasing which avoids the need for a quorum to pass referenda. All the governance proposals are in the idea phase at the moment and will only be finalized at the time of the launch. This explains some of the ideas related to governance.
Token Sale
A total of 10 million DOTs will be allocated at the time of the genesis block launch. Polkadot raised over $145 million in October 2017 in the first round of its token sale. This round was a spend all second price dutch auction. It means that everyone received the DOTs at the same price when the ‘right price’ was found that allowed to sell 5 million DOTs. There is no predetermined upper cap on the total number of DOTs. The inflation model dictating release of new DOTs is not yet fixed.
In late 2017, a major vulnerability was discovered in Ethereum’s parity wallet library contract and funds were locked. Some of the locked funds belong to Polkadot which were raised through the token sale. As a portion of the funds was kept in accounts that were not affected, the founder Gavin Wood has assured that the development will go on as envisioned prior to the incident. According to Coindesk, Polkadot plans to raise another $60 million through the second round of token sale.
How Polkadot Works
Transaction work-flow
Here’s how a transaction takes place between two parachains on Polkadot:
- Once a transaction is created on Parachain X to be sent to Parachain Y, it is sent to collators of Parachain X
- Collators ensure that the transaction is valid and include it into a block and then present it to a validator of parachain X along with a state transition proof
- Validator declares that the received block contains only valid transactions and stakes DOTs on it
- When enough DOTs are staked by validators and nominators, broadcasting blocks to relay chain is authorized
- The transaction is then executed and data/value from Parachain X is transferred to Parachain Y
Once the general idea of how a transaction takes place is established, one needs to understand how different chains are connected to Polkadot. This write-up explores how Ethereum and Bitcoin can be connected to Polkadot.
Polkadot and Ethereum
Ethereum is the most widely used smart contract platform. Most of the private enterprise chains have also selected Ethereum as their platform of choice. Therefore, interconnectivity with Ethereum becomes very important for Polkadot.
To send a transaction from Polkadot to Ethereum, a solidity smart contract called “break-in contract” supported by Ethereum can be used. This contract can maintain up to 144 signatories and the contract is maintained by these signatories. Anyone interested in moving relay-chain data into Ethereum is incentivized for forwarding valid block data. With 144 validators, the validity of the block can be finalized with as little as 97 validators (144*⅔ + 1). Assuming a conservative estimate of the daily rotation of validators, the team estimates the cost of maintaining the network to be around 540,000 gas every day. A basic transaction forwarded over the bridge would cost $0.11 with additional contract computation costing more. This works out to be about $45 per year (gas is priced in gwei. Thus, the cost is computed as the following. 540,000*ETH_price*10^(-9)*gas_price). With further developments in Ethereum, this cost and efficiency are expected to improve.
When a transaction is to be sent from Ethereum to a particular parachain on Polkadot, “break-out contract” is used. The contract charges a necessary payment and issues a logging instruction to prove its existence, through a Merkle proof, and validity of the block header. Though it is straightforward to prove the validity, validators need to run a full node of Ethereum, which is a rather heavy dependency. Lightweight methods are conceivable which involve third parties that submit ‘SPV’ (Special Payment Verification) like proofs of invalid headers to punish malicious actors.
Polkadot and Bitcoin
Theoretically, a ‘two-way’ peg between Polkadot and Bitcoin can be established for interoperability. However, due to scripting limitation of Bitcoin, this is a non-trivial problem. A transaction from Bitcoin to Polkadot can be carried out with a similar ‘break-out’ contract as in the case of Ethereum. However, the majority of the Bitcoin clients accept multisig transactions with a maximum of 3 parties. Expanding this to several validators in future (as 144 in Ethereum’s case) would require changes in Bitcoin protocol amounting to a hard-fork which is difficult to bring about.
The problem arises as with rotation of validators, the security deposit scales up. If the system is to be operated with a smaller number of validators and a heavy security deposit, it results in the reduction of the total amount of deposit that could be deducted in reparation when validators misbehave. This essentially means that there has to be an upper cap on the funds that can be securely transacted between the two blockchains.
How hard forks are avoided
Blockchains are hard to upgrade. Traditionally there is no way to actually upgrade a blockchain; one can only create a new blockchain that retains the history of the old blockchain. There is no good answer for defining fork choice rules or rollback strategy in case of on-chain updates. The consensus algorithm can’t be changed because it could retroactively make blocks invalid, and one can only allow changing things on-chain that affect the state going forward. This article explains how Substrate and Polkadot address the problem of forking is by separating the consensus code that dictates the changes to the state from the code that maps transactions to the state changes. The consensus and networking are handled by Substrate; and the chain’s logic, authority choice, and automatic upgrading are handled by the runtime. It means that when the code that affects the consensus is separated from the rest of the code, different back ends are left. Polkadot-specific code can be shared among Validators, Collators, Nominators, and Fishermen. Though nodes perform different functions, as far as the network is concerned, they differ only in the kinds of transactions they submit to the network. Anything that takes data from the outside world is a transaction, and the state is updated as a response to that particular transaction. This method is used to upgrade Polkadot from PoC-1 to PoC-2 and so on. By separating the different layers of code, Polkadot plans to keep hard forks at bay.
Risk Assessment
Permissioned Parachain Launches may lead to concentration of power
To launch a new parachain, permission from DOT holders is needed. The reason behind this is an attack vector where Collators i.e. block producers in one parachain can affect the consensus of the other parachain. If the consensus mechanisms on Polkadot parachains are different, then there is a chance that a valid but ‘collusioned’ state on one parachain can potentially be bridged to other parachains. This, in turn, may affect the consensus of other parachains. The solution to this problem is to be very selective while allowing parachains to get attached to Polkadot.
As the launch of parachain is permissioned, members with more DOT will get more control over the process.
On-chain vs Off-chain governance
When it comes to blockchain governance, there is a perennial debate whether it should be on-chain (automated) or off-chain. On-chain governance gives power or preference to bigger token holders when it comes to changes to protocol, design, etc. Some consider this to be antithetical to the ethos of public blockchains. That said, PoS is still in nascent stages and which model of governance will work is a complex question. We will know the answer only as time passes.
Reliance on Ethereum development to reduce cost and increase speed
The cost and speed improvement related to Ethereum transactions are also dependent on development in Ethereum protocol. And as Ethereum takes a cautious approach, the development of Ethereum has been delayed multiple times in the past. Reliance on Ethereum makes Polkadot vulnerable to delays.
Allocation of capital is not clear and justified. High risk but High return?
Ethereum is probably the most used (for whatever use cases, launching ICOs, etc.) and it raised around $18 million in crowdsale. Polkadot, on the other hand, has already raised more than $145 million and plans to raise around $60 million more. Whether this kind of money is needed is uncertain. Some of the funds are also going to be used to fund other initiatives of Web3 foundation. There has to be more clarity on how the funds are going to be utilized.
Those who invested in Ethereum have been rewarded handsomely (Ethereum’s ICO price was around $0.3 and today it is around $150, that’s 1500 times!) and part of the reason is also that Ethereum raised only $18 million as against +$145 million of Polkadot. Risk profiles of Polkadot and Ethereum are similar. However, to deliver a return more than Ethereum, Polkadot’s marketcap will have to be more than $217.5 billion and this is disregarding the inflation. Polkadot, essentially, derives its value from transactions between parachains. To justify this kind of value it needs to host parachains that deliver value and are used by people. No one can predict whether this will happen or not but one can say with high certainty that it will take a long time.
Delay in deployment
As there is no time-wise breakdown of Polkadot development, there is no way to know whether the development is actually on track to launch in 3Q2019. The token sale took place in October 2017 and there might be one more sale now. In case there is a delay, the risk of capital getting stuck is not insignificant.
The PoS design is unchartered territory as of now
Unlike PoW, PoS is almost untested in live blockchains. Polkadot’s PoS design proposal is more advanced, but it also means that it is more complicated as four stakeholders are involved. And more complexity is an invitation for newer attack vectors. PoS design of Cosmos, on the other hand, is simpler. This will make it easier for stakeholders to organize a decentralized network.
Improvements in other technologies
As of now, other distributed ledger technologies such as IOTA’s Tangle, that are not blockchains, are still in infancy. There is a small likelihood that these technologies may be heavily used in the future. In that case, Polkadot will have to modify itself to incorporate interoperability between non-chain solutions as well.
Organization Structure
Parity Technologies is commissioned by Web3 Foundation to build Polkadot. Parity runs Ethereum and Bitcoin clients and aims to enable organizations to capitalize on blockchain technology. Web3 Foundation nurtures and stewards technologies and applications in the field of decentralized web software protocols, particularly those which utilize modern cryptographic methods to safeguard decentralization, to the benefit and for the stability of the Web3 ecosystem.
There are a lot of similarities among Ethereum, Polkadot, and Parity, and rightly so. Gavin Wood is the co-founder of Ethereum and founder of Parity and Polkadot. A lot of developers working at Parity have previously worked at Ethereum foundation.
Current State of Development
Polkadot has launched 2 PoCs as of now and third is in the works.
PoC-1: The bulk of work in PoC-1 was on Relay Chain. Using Substrate, the tech stack, to build blockchain Polkadot made it possible to upgrade blockchains on-chain and thereby avoid hard forks. PoC-1 runtime laid the groundwork for parachains.
PoC-2: This upgrade included co-finalization of parachains (where parachains can attach themselves to the relay chain), slashing conditions for confiscating a validator’s stake in case of misbehavior, and Libp2p networking. The networking technology was moved from Ethereum’s Devp2p to Libp2p which is a highly extensible and generic networking stack. The protocol negotiation system offered by Libp2p allows for upgrades while still supporting the older versions.
PoC-3: PoC 3 went live in January 2019. It includes the consensus protocol called GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) which is powering the new testnet “Alexander”.
As of now, the Polkadot team claims to be on track for the genesis block launch in the Q3 2019.
Team
Polkadot is actually being built by Parity team and Parity boasts of some of the most experienced members in the blockchain space.
Gavin Wood
Gavin Wood is the co-founder of Ethereum. He is also the founder of Parity Technologies, Web3 Foundation, and Polkadot. He’s the Advisor and founder of other organizations including Grid Singularity, Blockchain Capital, Polychain Capital, and Melonport. Gavin Wood is one of the leading voices in the blockchain space.
Robert Habermeier
Robert Habermeier is the co-founder of Polkadot. He was named Thiel Fellow in 2018. Currently, he’s working on the consensus protocol that powers Polkadot.
Alistair Stewart
Alistair Stewart is the research lead at Parity and Polkadot. He’s well respected in the blockchain community as he has found vulnerabilities in major public blockchains in the past.
Competition
Though the goals of Ethereum 2.0 and Polkadot are similar to some extent, at a deeper level the designs are different. Also, Ethereum has been around for a long time. Therefore, at this juncture, it does not make sense to compare Polkadot to Ethereum. In the interoperability space, Cosmos seems to be the closest competitor of Polkadot.
Interoperability. The biggest difference between them is while Cosmos allows value transfer between blockchains, Polkadot is more generalized and allows cross blockchains interactions between disparate smart contracts i.e. it allows messages as well as value to be transferred.
Consensus model. While Cosmos uses Tendermint BFT protocol for consensus Polkadot uses a hybrid model of consensus which is more sophisticated compared to Cosmos’ consensus model.
Security. While Cosmos leaves it to zones to secure their own networks, Polkadot allows a shared pool of security. This means that parachain needs to stake DOTs to get attached to the Polkadot relay chain to enjoy the benefits of pooled security. However, Cosmos plans to allow pooled security in further upgrades. A unique feature of Polkadot is that it allows the runtime to be upgraded without the need of a hard fork and this gives the network an edge over others.
Governance. Both projects use token for staking and governance. Cosmos has Validators and Nominators just like Polkadot does. However, with Collators and Fishermen, Polkadot has added more complexity to the governance process. Cosmos’ governance model is less complex and it is based on Validators, Delegators, and a constitution. Polkadot’s governance has multiple layers such as adaptive quorum biasing, a council of validators who are to vote in the event of lower stakeholder turnout, etc.
Ease of developers / Programming Language. The idea behind Cosmos-SDK and Polkadots Substrate is the same. They make developers’ job of creating their own blockchains easy. Both teams are focusing on being developer friendly and trying to open a new platform for development.
Cosmos uses Golang and Polkadot uses Rust. Also, Polkadot has committed to WebAssembly and by doing that Polkadot seems to be more future ready. WebAssembly is supported by major companies such as Apple, Microsoft, Google, Mozilla. Thus there are very high chances that it becomes widely used in the years to come.
Mainnet Launch. The Cosmos mainnet is already live while Polkadot plans to launch in 3Q2019. Cosmos has the first mover advantage over Polkadot and from Ethereum’s example, the importance of being the first to the market cannot be understated.
Conclusion
Polkadot’s design philosophy is driven by anti-chain-maximalism and it aims to connect blockchains that are built for different purposes. It offers pooled security for parachains that will be built on Polkadot, thereby allowing developers to focus on functionality. The idea of sharding i.e. allowing multiple parachains to serve one use case has been adopted in Polkadot. Though the protocol seems to be more complicated than competitors, it is designed to be as general and as neutral as possible.
Polkadot seems to be a promising step ahead towards more scalable and interoperable blockchains. However, investors must be cautious of the risks that come with such novelty. At the end of the day, these are untested waters. The technology needs a lot of time to reach the verdict about its potential. Polkadot’s success is predicated upon a number of parachains attached to it and those parachains need to be “used” by people for various use cases. And we are still far away from mainstream adoption. Any investor who is considering investing in Polkadot needs to be prepared to be in for the long haul. This, definitely, is a high-risk high-return investment.
Special thanks to Rathi Srinivas and Eliezer Ndinga for reviewing the document.
