It consists of many parachains with potentially differing characteristics which can make it easier to achieve anonymity or formal verification. Transactions can be spread out across the chains, allowing many more to be processed in the same period of time. Polkadot ensures that each of these blockchains remains secure and that any dealings between the are faithfully executed. Specialised parachains called bridges can be created to link independent chains.
This is the means by which a peer network is formed and maintained. First an altered devp2p, then libp2p.
Optimistic BFT Proof of Authority consensus mechanism. The mechanism allows the proof of misbehaviour for the dismissal of malicious validators.
Parallelised candidate selection
This is allowing multiple independent items to be agreed upon under a single series based upon subjective reception of the partial set of validator statements. Used as an input to the finalization mechanism.
Proof of Stake chain
Extending the consensus mechanism into Proof of Stake territory; this module includes staking tokens, managing entry and exit from the validator pool, a market mechanism for determining.
This will include an integration with the Proof of Stake chain, allowing the parachain to gain consensus without its own internal consensus mechanism. More than likely this will include a WebAssembly-based contract execution architecture.
Transaction processing subsystem
An evolution of the parachain and relay-chain, this will allow for transactions to be sent, received and propagated. It includes the designs of transaction queuing and optimised transaction routing on the network layer.
This introduces more specifics into the relay-chains’ behaviour. Management of the ingress/egress queues and network protocol with means of directed transaction propagation, ensuring independent parachain collators are not overly exposed to transactions that are not of interest.
This is the final stage of the relay-chain, allowing the dynamic addition, removal and emergency pausing of parachains, the reporting of bad behaviour and includes implementation of the ‘fisherman’ functionality.
This is the delivery of an alternative chain-specific collator functionality. It includes proof creation (for collators), parachain misbehaviour detection (for fishermen) and the validation function (for validators). It also includes any additional networking required to allow the two to discover and communicate.