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 them are faithfully executed. Specialised parachains called bridges can be created to link independent chains.
Coordinates consensus and transaction delivery between chains
Constituent blockchains which gather and process transactions
Link to blockchains with their own consensus such as Ethereum
Enjoyed by all parachains. In Polkadot making a new parachain does not require building a community from scratch to provide secure execution.
Communication between parachains. These are exchanged on every block and enable data including tokens to be transferred.
Secure the relay chain by staking DOTs, validating proofs from collators and participating in consensus with other validators.
Secure the relay chain by selecting good validators and staking DOTs
Maintain parachains by collecting parachain transactions from users and producing state transition proofs for validators
Final security frontier, they monitor the network and prove bad behaviour to validators
Govern the network by voting on the relay chain.
Make use of the features provided by the parachains.
Optimistic BFT proof-of-authority consensus mechanism.
The mechanism allows the proof of misbehaviour for the dismissal of malicious validators.
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.
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 is the means by which a peer network is formed and maintained. First an altered devp2p, then libp2p.
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.
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.