What is Polkadot? Polkadot Review in Detail

Polkadot being a next-generation blockchain protocol sparked a high degree of curiosity among developers. It has come with a scalability and throughput issue solution. Some even think Polkadot to be taken after Ethereum. So no more curiosity, we have tried our best to discuss every single aspect of Polkadot network so that from mango people to researchers can take a concept.  

Unlike many previous blockchain implementations, Polkadot provides no inherent application functionality at all which refers to its heterogeneousness. The data structure Polkadot maintains is known as ‘’parallelise’’ chains or parachains. Polkadot’s bedrock ‘’relay-chain’’ allows globally-coherent dynamic data structures to be hosted side by side on it.

Polkadot has been brought to light with a scalability solution which comes into sight considering a problem to be deployed on Polkadot may be substantially scaled out over a large number of parachains. All the sophistication in Polkadot is addressed at a middleware level which substantially reduces development risk.

Polkadot’s philosophy

Maybe the next wave of consensus systems through the risk spectrum from production-capable mature designs to augmentative ideas is going to be built on the foundation of Polkadot. The expected high-value chains are supposed to come together with zero or near-zero fees. Polkadot focuses on high security, communication and isolation. With all these, Polkadot is expected to allow parachains to pick from a range of properties themselves.

Polkadot has different ways for managing chain upgrades like through depending on existing stable political systems and having a bicameral aspect. The ultimate result depends on basal stakable token holders because of their referendum control. The ultimate legitimacy would be maintained by the body of token holders. Dissolving of structure and forming supermajority to augment is substantially dependant on the body of token holders.

What change to be brought? In this mammoth consensus mechanism, reparameterisation is thought to be insignificant. More qualitative changes for example augmentation and replace should take place to make the cardinal consensus mechanism take on an affluent language to recount any aspect of itself that needs to change.

Taking part in POLKADOT

Polkadot network includes collator, fisherman, nominator and validator in its maintenance.  

Validators: The core procedure of validators is to seal new blocks on the network. Bonded parties are allowed to make and nominate more validators to work for them. Validator’s act depends on deposited bonds.

As affirming a new block on a nominated parachain is difficult and competitive, a validator must operate a relay-chain client implementation with high availability and bandwidth. Who will be nominated cannot be guessed in advance. It is because a validator will nominate the task of devising a suggested new parachain block to any third party as the validator cannot maintain a fully-synchronized database of all parachains.

Validators are required to ratify the relay-chain block itself at the finish of the ratification of all new parachain blocks. A validator is punished for failing to accomplish their duty to find consensus under the rules consensus algorithm. Their rewards are kept withheld for unintentional failure and its continuing results in the cutting of their security bond.

Nominators

Nominators select good validators and staking DOT to secure Relay Chain. Earning DOT is possible in two ways among them one is to have a node that runs 24/7 and another is by nominating another validator. Nominators don’t have additional role without this. As validators contribute to the security bond of a validator, they get a reduction or pro-rata increase depending on the growth of bond.

Collators

Collators sit atop parachains and collect parachain transactions from users and yield state transition proofs for validators. And thus they assist validators indeed. They have full control on a ‘’full-node’’ for a specific parachain. The relationship among collators, validators and nominators that exist initially gets changed over time.

Collators hold all pieces of necessary information for being able to author new blocks and execute transactions. They can arrange and implement transactions in order to producing an unsealed block and with proof of state transition provide it to as many as validators accountable for proposing a parachain block.

Fishermen

Unlike aforementioned two parties, Fishermen in Polkadot network have a different role to play. Their duty is to report on noticed faults like if they see any invalid state transaction being included during producing parachain blocks or packaging then state transitions, they will report.

If it is proved that the report on misconduct that took place submitted by them is authentic, they will be rewarded handsomely. But in case it’s opposite happens, they can lose their stake. For their jobs style, they are called ‘’bounty hunters’’.

Design overview

In this part, we will write about the design overview of Polkadot.

Consensus:

As we know, consensus refers to the way for coming to agreement over a shared state. The fact is that Polkadot acquired smaller consensus over some valid blocks through a modern asynchronous Byzantine fault-tolerant (BFT) algorithm. Polkadot’s HoneyBadgerBFT, in which nodes receive transactions as input and store them in their buffers, increases efficiency and fault-tolerant consensus over an arbitrary defective network infrastructure.

Polkadot is expected to be released soon as a network in a fully open and public situation without any trusted authority to maintain it.

Proving the Stake:

The network must have a way to measure how much stake a particular account has. The unit of this measurement is known as ‘’tokens’’ which is not ideal owing to some reasons indeed. The Polkadot blockchain will implement nominated proof-of-stake which will be used to select the validators who are allowed to participate in the consensus protocol.

Through pro-rata allocation of funds, incentivisation will be happened. No token holders need to suffer a deduction in value of their holdings and they have fair opportunity at participation, while monetary base expansion causes inflation. To meet the goal, the effective token base expansion would be adjusted through a market-based mechanism.

Thing is that, exiting validators’ bonds remain in place long after their duties get ended. If any misbehavior takes place, it results in punishment like reduction of reward or losing all the stakes. Periodic checkpointing of the chain wards off a dangerous chain-reorganisation of more than a specific chain-depth.  Regular hard forks will take place to integrate new features or fix bugs.

Parachains and Collators

Every parachain is secure in relay-chain preventing double-spending problem. Polkadot makes sure a high guarantee that the state transitions of parachains are valid. For so the set of validators get segregated into subsets. There is a necessity for these subsets of validators as they provide a parachain block candidate which is guaranteed valid. Even after having a risk of getting reduced reward, validators may provide only a null block with no external ‘’transactions’’ data. How parachain protocols will prevent spam is up to it as there is no indication by the relay-chain.

Interchain Communication

The resolution of a transaction is dispatched to a second parachain asynchronously by parachain transactions or the relay-chain itself. And origin segment and an address of interchain transactions being counted ensure minimal implementation. As a result transactions are safely passed through multiple chains. Relay-chain maintainers pass transactions from the one queue to another that makes sure tamper-proof communication. Considering the facts of tamper-proof communication, and rational and algorithmic order to fee-less transaction flow, interchain communication is thought to be a indispensable feature of Polkadot’s architecture.

Polkadot and Ethereum

It is our expectation that transactions from Polkadot can be signed by validators and insert into Ethereum where a transaction forwarding contract enact and interpret them.

Polkadot to Ethereum: Polkadot and Ethereum are sharded blockchain protocols providing scalability by executing transactions in separate shards. The shards in Ethereum have state transition function (STF) which offers an interface for smart contract execution. Contracts remain on a single shard.

In Polkadot, each shard has a unique STF, where applications can exist. Polkadot can dispatch cross-shard asynchronous messages. Polkadot has a main chain namely the Relay Chian the same way as Ethereum 2.0 has is the Beacon Chain. Parachains can define their respective logic and interface as long as they provide their STF to the Relay Chain validators so that they can execute it. Polkadot offers two-way compatibility through its bridge parachains that help interact with chains willing to use their own finalization process.

Another common thing between Polkadot and Ethereum is that both of them use hybrid consensus model. Block production and finality both have their own protocol in this model. Even after these matches, there are also some differences available between Ethereum 2.0 and Polkadot consensus indeed.

Whereas Polkadot’s finality protocol namely GRANDPA finalizes batches of blocks depending on availability and validity checks that takes place as the proposed chain grows, Ethereum 2.0 does the job as per periods of time called ‘’epochs’’. Another cardinal difference is that Polkadot ensures stronger guarantees with fewer validators per shard but Ethereum 2.0 needs a large number of validators per shard to provide strong validity guarantees.

Ethereum 2.0 being a proof-of-stake network requires 32 ETH to stake for each validator on the other hand Polkadot with its Nominated Proof of Stake (NPoS) provides strong finality and availability guarantees with much fewer validators.

Every shard in Polkadot has an abstract STF based on Wasm on the other hand every shard in Ethereum 2.0 has the same STF. But in phase 2, Ethereum will implement the eWasm execution environment, which is a restricted subset of Wasm for contracts in Ethereum.

Each of 64 shards in Ethereum 2.0 posting a crosslink in the Beacon Chain for every block will have access to each other’s state through those crosslinks. Using Cross-Chain Message Passing (XCMP) for parachains, Polkadot sends arbitrary messages to each other. If any full nodes are common in two parachains, it allows gossip messages in between through the full nodes. Polkadot is aimed at introducing an additional protocol namely SPREE that provides shared logic for cross-chain messages conveying extra level of guarantee about provenance and interpretation.

When the topic of governance comes then it is known that Polkadot uses on-chain governance with a multicameral system and Ethereum 2.0 uses off-chain governance and it is yet unresolved. There is a change in format when considering the methods of upgrades. Unlikely to Ethereum, Polkadot using the Wasm meta-protocol can enact chain upgrades and successful proposals without a hard fork.

Polkadot and Bitcoin

Between Polkadot and Bitcoin, ‘’two-way peg’’, a two way pegged blockchain is a system in which the mainchain is the blockchain that can spontaneously and directly transfer assets to another blockchain that is called sidechain, is a matter of discussion indeed. Issuing a peg safely is a significant step for Bitcoin as it has some limitations indeed. Most clients of Bitcoin accept only multi-signature, which refers to requiring multiple keys to authorize a Bitcoin transaction, with a maximum of 3 parties which is considered to be a limitation of Bitcoin. Extension of this to expected thousands cannot be thought under this protocol.  The way of using threshold signatures is raising possibility but it only goes with Bitcoin’s ECDSA. The security is ultimately dependent on a number of bonded validators and there is another option left is to cut the multi-signatures key-holders down to only a heavily bonded subset of the total validators to such extent that threshold signatures become enforceable. This setting of an upper limit of the amounts of funds can in a safe way run between the two networks. But it seems to be unrealistic.

Relay-chain Operation

The relay-chain has some states mapping address to account information. Accounts are placed here to have accounting information for which identity possesses what amount of stake in the system. To avoid application functionality on the relay-chain, contracts cannot be deployed through transactions. Instead of accounting compute resource usage, a flat fee will apply in all cases. Some listed contracts will only get special functionality.

If the relay chain has a VM, Virtual Machine based around EVM, you will see it to have a number of modifications to make sure maximum simplicity. There also would have several built-in contracts to allow handling platform-specific duties. If not so, another most likely alternative can be WebAssembly which will deduct the need for the built-in-contracts with Wasm. Another fact is like a simplification of the transaction-script format that allows for the parallel execution of non-conflicting transactions within the same block can happen that a slight departure from the existing protocol of Ethereum is.

For steering the consensus mechanism, validator set, validation mechanism, and parachains, there are many activities required. These are executed under a monolithic protocol. These are known as contracts of the relay-chain.

Staking Contract

This contract keeps up the validator set allowing an account to register a desire to become a bonded validator to nominate to some identity.

Stake-token Liquidity: As the network security is tied to the overall market capitalization of the staking token, so it’s better to have more staking tokens staked. Here the incentivisation is easy by inflating the currency and imposing it upon validators. But problem stands when someone goes under the purview of punishment how a portion would remain liquid to allow price discovery.

There can be a solution to that issue which is also tenacious to do trust freely. And the solution is allowing a straight-forward derivative contract, securing fungible tokens on an underlying staked token. Another problem catches sight of that different Eurozone government’s are not fungible leaving no opportunity to equally treat these derivatives tokens for the same reason. As a result of this, the underlying asset can be worthless indeed.

It’s wise to think of the ratio between staked and liquid tokens fairly. Those who want to become a validator from token holders are required to post an offer to the staking contract risking their token required. The validator slots would be checked at the commencement of each session. Here the algorithm would be like those with the lowest offers who represent a stake no higher than the total stake targeted divided by the number of slots and no lower than a lower-bound of half that amount.

Nominating: Through an approval-voting system, nomination acts actually. Nominators can entrust their bond to the responsibility of validators they choose. They can express who validator identities they have chosen by posting an instruction to their staking contract.

After nominators’ bonds are dispersed to be represented by validators, the dispersal algorithm takes over the burden of rearranging a set of validators of coequal total bonds. Whether validators will be rewarded or punished depends on how effectively they are performing their responsibility.

Bond Confiscation/burning: If a validator is proved to be a part of a parachain group which is unable to provide consensus over the validity of a parachain block or actively signing for the validity of an invalid parachain block, he will be brought to book for such misbehavior. Not being active during the consensus process and validating relay-chain blocks on computing forks are also taken as validator’s misbehavior.

These misbehaviors not only risk the network’s integrity but also lead to reduction of total bond. If the case is not momentous, the validator can have a narrow escape losing a small portion of the bond.  If validators cannot identify their misbehavior, parties outside the validation process should report such misbehavior. If their report is proved to be authentic, they will be rewarded indeed. Our expectation is to balance burning with reallocation because it will increase the overall value of the token. Maybe the large amount of reward will make the verification worthwhile for the network and the claimed amount ought to be no greater than the direct bond of the errant validator.

Parachain Registry: This is a simple database that holds both static and dynamic information on each chain. The chain index with the validation protocol identity falls in the section of static information. An elementary proof-of-concept, which is a meant to ascertain the feasibility of the idea or to judge that the idea will function as envisioned, would insert the new validation algorithms into clients themselves and would require a hard fork of the protocol each time an additional class of chain were conjoined.  But it would be better for clients to work with new parachains effectively without the necessity of hard fork. What if specifying the parachain validation algorithm in a platform-neutral language paves the way for so.

On the other hand aspects of the transaction routing system that must have global agreement fall on the section of dynamic information. Through full referendum voting, the registry can have parachains added.

The suspension and removal of parachains are among other activities. Suspension is designed to protect against some reckless problems in a parachain’s validation system. Suspension would be under the auspices of the dynamic validator-voting considering it to be an emergency measure. Even though it would not be under a referendum, it could be installed both from the validators or a referendum. The removal of parachains takes place after a referendum.

Sealing Relay Blocks: Sealing refers to a basic data transform which maps the original into something fundamentally meaningful. The process of sealing is similar to the process of mining under a PoW chain, where sealing under relay-chain collects signed statements from validators over the validity of a particular relay-chain block.

There is no need of the underlying BFT consensus algorithm for the ongoing work and so it is being illustrated using a primitive. But it needs to be inspired by some promising BFT consensus algorithms in its significant parts in the ultimate. The task of this algorithm is to reach an agreement on multiple parachains in parallel and recoding of the consensus in a valid proof will come into grip once the consensus is reached.

In the relay-chain block’s header, the proof is placed along with some other fields. A single consensus-generating mechanism under which the sealing process happens addresses both the relay-chain’s block and the participant’s blocks. Parachain allows completing the entire system’s consensus in a single stage.

As we know that every participant has a set of information, which basically consists of two pieces of data, which come in the form of signed-statements from other participants.  These two pieces of data is about availability and validity.

Voting is obligatory for all voters and voting can also be resubmitted. Since several BFT consensus algorithms over each parachain are occurring at the same time, the advancement of consensus can be modeled. The entire consensus remains to develop a backstop keeping malicious attacks cases down as some malicious actors try to do harm to these.

There are rules over validating the individual blocks and these rules are like a block must have two thirds of positive voting from validators instead of negative voting and another rule is that a block must have more than one third validators voting positively to the availability of egress queue information.

But the scenario gets slightly changed if there is one positive or negative vote from any of the sides. If such scene appears, the whole set of validators need to ascertain whether there are malicious parties or accidental fork. There is another kind of voting which is tantamount to voting for both valid and invalid. Such situation appears when any node owner operates multiple implementations which create an obscurity in the protocol.

Any parachain engaged in accidental parachain fork is automatically suspended whereas accidental parachain fork is thought when the losing opinion has at least some small portion of the votes of the winning opinion. Or, thinking the minority voting for the dissenting opinion to be malicious actor, they will go punished.

Improvements for Sealing Relay Blocks: A major portion of responsibility lies on the shoulder of validators because they provide availability guarantee of every parachain’s key information. On the other hand, the sealing method provides a potent guarantee over the operation of the system indeed. The data availability problem is yet to be solved but a possible solution to the issue can be conferring the responsibility of guaranteeing availability with the validators providing a portion of interest in payment on secondary data silos. And validators must shoulder the responsibility for data availability and leave the functionality of storing and communicating the data themselves. Maybe the scalability problem is being solved but the underlying problem still remains. An untrusted network might have the inability to distribute the task of data storage across many nodes.

Introducing Latency: It is thought that better utilization of exponential data propagation can be possible by requiring 33%+1 validators voting for availability. The logical equality stands: latency=participants x chains. This model makes sure the processing is distributed as the size of the system here scales with the number of chains.

Public Participation: Enlisting public participation through a micro-complaints system is thought to be an effective step too. To oversee validators who claim availability, there could be external parties. The process helps identify those who are unable to show such availability.

Availability Guarantors: They will be a second set of validators and their responsibility will be unlikely to normal validators. They will comprise a single group to attest to the availability of all important interchain data.

Collator Preferences: If a single collator dominates a parachain, it gives birth to the possibility of some attacks. So there should be many collators who create blocks in any parachain. Favoring a large number of collators is possible by artificially weighting parachain blocks in a pseudo-random mechanism. Validators should suggest the weightiest block they find and for so they must be incentivized.

They make the specific weight of a parachain block candidate determined on fixed function tied with each collator to make sure collator’s reasonable fair chance of their winning-candidacy in consensus. Adding some inertia to collators’ address alleviates the Sybil attack of single collator ‘’mining’’ an address near to the winning ticket.

Overweight Blocks: A validator set can create and propose a valid block and it takes a long time for validation and execution leaving a problem. But if they know some piece of information, may be less time will be needed. But make sure this information is not known to a single collator because if he knows, it will be disastrous.

How will the protection be given? Well, Voting on misbehavior will fall into three camps. One is the block is surely not overweight-here two-thirds are agreed to execute the block. Another is that the block is surely overweight- here the majority denies to execute. And the final one is fairly equal split of option between validators. Here takes a decision of punishment to some proportion.

Collator insurance: In this network, validators need to execute the transactions to check a collator’s block for validity.  Validators will be aggrieved providing that malicious collators feed invalid or overweight blocks to them. Maybe there is a simple solution to a problem. There are two steps of this solution and firstly, parachain block candidates that are dispatched to validators must be signed from a relay chain account with funds and secondly, such candidates should be ordered in priority by a combination of the amount of funds in the account up to some cap.

Punishing collars is the best way to disincentivise collators from sending invalid or overweight block candidates to validators. How they can be punished? To punish them, a validator can place in the next block a transaction including the convicted block of misbehaving with the effect of transferring funds in the misbehaving collar’s account to the sufferer validator. As a result of this, a collator cannot escape punishment. On the other hand, if a validator is found randomly forfeiting collator’s funds, the validator will be fined indeed.

Interchain Transaction Routing: Interchain Transaction Routing being an essential maintenance task of the relay-chain and its validators turns a posted transaction to a non-negotiable input of another destination parachain from being a desired output from one source parachain. For doing so, there is no need of any trust requirements.

External data availability: There are some transitions in BFT system whose accuracy depends on the availability of some external data. In order to validating such transitions for BFT system, the utmost number of acceptably Byzantine nodes of the system is required to attest to the data being available.

But this way isn’t also devoid of problem. The bandwidth in here increases with the system size when a constant proportion of validators attest to the availability of the data. What do you think to be its solution? What if an isolated set of validators with their order growing sublinearly with the size of Polkadot, in general, can be a possible solution?

Another solution can be done through collators in exchange for incentives. Collators can make sure all data is available for their chosen parachain. Collators can challenge to the availability of external data for a particular parachain block to validators for a small bond. Validators must contact apparently offending validator sub-groups over the activity. These sub-groups sometimes being a bond-confiscating offence refuse to provide the data enumeration and thus the misbehaving validator will drop the connection. The collator’s bond is returned as acquiring and returning the data is among sub-validator group’s duties.

Posts Routing:

An egress-trie-root contains routing-base bins where bin is a list of egress posts. This egress-trie-root is included in the header section of each parachain. In this case, whether a particular parachain’s block had a particular egress queue for a particular destination parachain is tested through mekle proofs which are dispatched across parachain validators. Each other parachain’s egress heading for said block gets united into our block’s ingress queue at the commencement of processing a parachain block. Depending on the organon of parachain, collators clear out the egress queue and count the new queue.

What are the benefits of ingress queue? One of the benefits is that the parachain can be trustlessly synchronized in separation from the other parachains. Another advantage is that it expedites the data logistics should the entire ingress queue not be able to be processed in a single block. The parachain’s ingress queue is deemed to be saturated on the relay-chain when it is on top of the limit. The fairness of the collator’s operations is judged through Merkle proofs.

Hyper-cube Routing: Simply to say, it is an augmentation of the basic routing mechanism. It helps grow logarithms of parachain. Here the number of bins is folded into some ingress/egress queues. And posts bound for final delivery transit between several parachains’ queues. A hypercube of edimensions being the model of routing incorporates b possible locations in each side of the cube. Routing of messages is done here with the help of a single axis which gets changed into a round-robin fashion. Foreign-bound messages in the ingress queue are routed to the appropriate egress queue’s bin. This mechanism drives superfluous data transfer for each hop on the delivery route. It also leaves a problem because using some substitute means of data playload, the process can be alleviated.

 Maximising Serendipity: Are you thinking of any changeover? A fixed total of c²-c validators and the sub-group validators will be c-1. Validators will be assigned to different parachain sub-group on the following block. Two validators would be existed between any two blocks for any tow pairings of parachain who have exchanged parachain responsibilities. There is also sophistication in this process. As a result of this approach, you would see recognition of validator set but it must be held on a regular basis. If a validator set is small in size, multiple validators can be assigned to this.

Parachain Validation: From the aforementioned description you have already gotten aware that testifying the validity of a parachain block is the cardinal job of a validator. Other functions that a validator performs are to seal a block after testifying it and to execute any waiting posts in the ingress queue. A validator gets a parachain block candidate through a parachain collator or one of its co-validators. After receipt of the block, the validator starts validating the block.

The identity of a block is judged by its header of the previous one. The particular parachain class’s validation function can be invoked at the end of validation judgment of the header. The header-field is the target for validation function because it can be derived directly from the parent block. Coming after this, they will replenish internal data structures as essential to process posts. Enactment of the ingress posts and external transactions will be seen one the process is finished.

Parachain Collators: You can compare parachain collators as miners in the blockchain network. Their duty includes maintenance of both the relay-chain and the fully synchronized parachain. Fishing for transactions is a must sometimes for keeping two chains synchronized. Fishing for transactions can be done through maintaining a transaction queue and taking in validated transactions from the public network.   

Networking: With several types of participants with multiple requirements, Polkadot has a large number of requirements which makes the difference between Polkadot and other networks like Bitcoin and Ethereum. A novel overlay structure may be seen in future with the acceptance of newer chain.

To make sure the sort of peers is connected at the right time, a fairly tensile peer selection and discovery mechanism are required within the protocol. Another fact is that collators also try hard along with validators to hold down one or more stable connections into the availability guarantors set for fast propagation of consensus-sensitive data.  On the other hand, validators look for other validators and collators who provide them with parachain block candidates.

The problem of peer Churn: Quick alteration of each subset with each block stands as a problem in the basic protocol proposal. Separation of nodes is an issue because these nodes need to move on data between each other. Are you thinking of bringing a solution introducing longer block times? It’s actually no, because long block times on the network may render it useless for specific applications and chains. Depending on a fairly-distributed peer network isn’t also a good solution as it will result in adequate loss of bandwidth. It is assumed that a pre-existing protocol can be an effective and reasonable development effort.

Interchain Transaction Payment: The absence of holistic computation resource accounting framework raises question about the avoidance process of parachain. To safeguard against spamming with another transaction data, they need to depend on after-transaction ingress queue buffers. Making sure that the computation must be paid-for before started is possible as chains have the authority to adjoin arbitrary semantics on to the incoming transaction-post data.

Additional Chains:

Addition of more parachains is not free at all. Along with the increment of parachains, validators get distributed resulting in fewer validators in each parachain with a reduced average bond. Even though fishermen oversee the process and make sure no invalid state transitions are included, increasing validator set causes latency because of the mechanics of the underlying consensus method. Every parachain falls valifators in melancholy with over-burdensome validation algorithm. Validators or the stake-holding community will extract some ‘’price’’ for the addition of a new parachain. For adding these child chains, there should be incentives for the community of stakeholders.

For complete development of the Parity Polkadot Platform stack, there is necessity of more and more research. There is existing a disorder in the whole system like while some are independent, the remaining are dependent on others leaving an issue. We are writing about some issues that must be brought under development periphery and these are:

Networking subsystem: There is a suspicion that whether the network topology will become structured allowing for optimal data logistics with the growth of the network. More and more research is needed to judge it. Make sure the adaptations of lipp2p, devp2p, and GNUnet before final launching.

Consensus Mechanism: As we know, Proof-of-Authority (PoA) is an algorithm used with blockchains that delivers comparatively fast transactions through a consensus mechanism based on identity as a stake. But the mechanism is yet devoid of any proof of misbehavior for the dismissal of malicious validators.

Proof-of-stake chain: Proof-of stake territory incorporates the functionalities of staking tokens, managing entry and exit from the validator pool, finalizing the approval-voting nomination mechanism and managing bond-confiscation and dismissal. So it would be better if the proof-of stake chain is extended to proof-of stake territory.

Missing materials: There is no explicit discussion about network forking where it is not a big deal to recover from the relay-chain forking. So, careful integration of this into the consensus protocol is needed.  Along with that, a profound exploration of bond-confiscation and conversely reward provision is also required.

A Brief Review of PolkaDot

Even thought the world is accepting blockchain on a gradual manner, it has still some issues to recover. PolkaDot has come into space to recover all the shortcomings of blockchains. PolkaDot being a multi-chain technology connects many different blockchains. At present, scalability and isolation are the core problems of blockchain technology.

The PolkaDot Structure

To talk about the structure of PolkaDot, we have to tell about the relay-chain, which solves interoperability issues with its smart contracts feature, the parachain, and the bridge chain. Parachains process transactions in parallel and thus solve scalability problems indeed. Shared security is another reason PolkaDot is here, and in this system, individual chains will leverage collective security.

Governance Protocols

PolkaDot has partitioned its activities on four different participants like Validators, Collators, Nominators and Fishermen. The responsibility burdened on collators is to collect parachain transactions and produce state transition proofs. After validators receiving the proofs from collators, they secure the relay chain by staking DOTs. The role of Nominators and Fishermen is to further bolster the security.

What role the DOT token plays?

Token holders belong to the right of controlling over the protocol and able to take part in the decision-making process. They also enjoy some privileges like determination of fee structures, protocol changes, and parachain additions or removals which are reserved for miners on other platforms. The underlying consensus mechanism of PolkaDot network is also benefited by DOT tokens. DOT is used as payment like those who are found active in the network are paid in DOT as a reward. The initial supply of DOTs for the PolkaDot Genesis block will be 10 million, and this initial supply is not a hard cap.

Use Case

How PolkaDot will make its place in the future landscape is unknown, but there are some possible use cases like-

-Before accepting payment in BTC, a payment processor requires verification by a private bank chain.

-A blockchain project also requires the same verification to raise ETH.

-A decentralized exchange parachain allows BTC deposits using Zero-knowledge proofs from a Zcash parachain.

Founder of PolkaDot

Gavin Wood is famed as a founder of PolkaDot. The man is also a British Computer Programmer, co-founder of Ethereum. Wood served as the Ethereum Foundation’s first chief technology officer. He co-founded Parity Technologies Ltd, which has a mission to enable businesses and organizations to capitalize on blockchain technology, right after his departure from Ethereum in 2016. He is a founder and president of the Web3 Foundation, which has a mission to nurture cutting-edge applications for decentralized web software protocols.

The final DOT price was 0.109ETH at the ICO of 2017. A total of 485,331 ETH was raised from the sale of the 5 million tokens. The price of ETH was nearly $320 when the auction was completed in 2017. But soon after that ETH went as high as $1400 at which ETH was being traded.

A setback- Frozen funds

A major issue has been noticed in Ethereum Parity Wallet library contract. A significant amount of funds is found frozen where no stealing has been reported. Parity is still trying to recover the problem. A hard fork was supposed to be held in December 2017, but the proposal got rejected by the community.

Trading or purchasing DOT tokens?

You can buy DOT tokens from nowhere. But those who purchased DOT tokens during the October auction will receive their tokens at the launch of the Genesis block. These early buyers are true believers in the vision of Polkadot.

What was the result therefore on Q4 2019?

There was an uncertainty about what Polkadot would deliver as a majority of their funds were frozen. It would be a game-changer if they managed to deliver. After all these disappointments, their full release was finally done in May 2020. But a slight delay was noticed in the rollout of the Polkadot network.

Release of Polkadot network and Kusama Alpha

Actually the Kusama canary network was the Alpha release of Polkadot’s network. The design of Kusana left the requirement of onerous testing on Polkadot’s mainnet allowing developers and community members to quickly deploy and build decentralized application ideas. This really attracted innovators and thousands of developers.

Connecting separate blockchains together has been a hurdle to overcome which Polkadot has done successfully. The Polkadot’s interoperability solution makes it easier to exchange data and parallelize the workload between blockchains. The network increases stability across multiple blockchains and solves throughput issues. The Polkadot team is trying to deploy such solutions that allow innumerable real-world applications to be built on the platform. The successful rollout of Polkadot network is making blockchain experts think over the protocol.

Cryptocurrency Comparison Table between Polkadot and Ethereum 2

Polkadot FAQ

• What is Polkadot?

Polkadot is a name of wonder, and enthusiasts of different technologies are turning their face on this project. So, what is Polkadot? And; what does it do?- we will discuss today in brief.

We can recognize Polkadot as a scalable, heterogeneous, multi-chain technology, allowing diverse blockchains to transfer messages, values in a trustless way. The feature of heterogeneity has made Polkadot flexible. By fulfilling a set of criteria, data structures or even non-blockchain systems can also parachains.

By this time, we think you have already understood the functionalities that Polkadot does. But we are providing you some more information in this regard indeed.

What are parachains? A large number of verifiable data structures can be hosted on a Relay Chain provided by Polkadot is known as parachains. Pooled security and trust-free interchain transactability are unique additions to this space by Polkadot. Developers are able to concentrate on creating state machine with unique features as Polkadot provides a networking and consensus layer.

You can see a number of parachains in Polkadot with diverse characteristics. Numerous transactions are processed here at the same time. Polkadot ensures highly extended security. Do you know one thing that how the security is higher here? The reason is that all parachains share security and state; as a result, all chains get reverted upon one chain has a message reverted.

• What do we need Polkadot?

The motive behind designing Polkadot was to facilitate faster innovation cycles, especially at the time of experimenting with new state transition functions. It is obvious that nobody belongs to a framework that encompasses all chains, considering the number and diversity of the various Web3 Projects. But, Polkadot is igniting hope by introducing a general framework.

It’s never possible to slip the issue of interoperability when we are talking about Polkadot. Polkadot is staying at a good height just due to its interoperability issue, which lets diverse chains perform arbitrary messaging, including value. As Polkadot allows, parties can take public and private chains and plug them in to a shared connectivity layer. To get transactions verified via the Relay Chain, chains are flexible either to choose own validator set or to use Polkadot’s pooled security system.

• How many chains can Polkadot connect?

In brief reply, there is no specific limit indeed. But, it is expected that the basic Polkadot design can handle at least dozens and probably hundreds of Parachains.

• Can Polkadot connect any blockchain?

Polkadot can connect any previously existing blockchain providing that it poses the ability to form compact and fast light-client proofs over the validity of its blocks and state change information, and there is a way by which a large set of independent authorities can authorize a transaction. Polkadot is doing something where Bitcoin-like chains are unsuccessful. Both criteria are essential in their own purpose.

By managing the chain’s consensus and validation activities, Polkadot is best at connecting new blockchains plainly designed to fit the parachain model, which benefits from immediate finality and disinterested validation.

• Who is building Polkadot?

Dr. Gavin Wood and Robert Habermeier are known as the Co-Founder and Core Developers of Polkadot. Parity Technologies partnered with Web3 Foundation to develop the first implementation of Polkadot in Rust and JavaScript.

• Who is working on behalf of Polkadot?

Do you know one thing that will surprise you? Yes, if you want, you can be the person contributing to the development of the Polkadot platform. This open-source project is providing you with the opportunity. For further development and mass adoption of this platform, Web3 Foundation has appointed a group of researchers, who are experts in consensus mechanism and decentralized messaging experts, and administrators.