-
Notifications
You must be signed in to change notification settings - Fork 4
Polkadot
Polkadot is heterogenous multi-chain architecture created by Gavin Wood. The aim is to separate canonicality and validity in consensus.
It uses parachains, ie parallelised chains, data-structures hosted on relay-chain. Polkadot is a set of independent chains with pooled-secuirty and trust-free interchain transactability.
There are four main roles in the system:
- collator - provides block candidates for validators, maintain full-node for particular parachain
- fisherman - monitors validators and reports bad behaviour to another group of validators
- nominator - approves validators. It's a stake-holidng party which contributes to the security bond of a validator.
- validator - seal new blocks on the Polkadot network. Validators must have high deposit (but it can belong to their nominators). Validators run a relay-chain client , they may be chosen to ratify a new block on a nominated parachain. They asked collatorals for data, ratify block on parachain and then ratify the relay-chain block itself. Cheating validators are punished. Firstu fialure is punished only with withholding reward. Reocurring failures are punished with burning security bond. Cheating is punished with loss of entire bond (burnt, given to informant and honest actor).
It can be also implemented differently with only two roles:
- basic validator
- availability guarantor
Nominated Proof-of-Stake (NPoS) - scheme for choosing validators. Validators shouldn't be chosen more often then once a day (in the future once per quarter).
Validators bonds remain in place long after the validators' duties cease, so if they try to cheat at the end of their validator period with short-range attacks, they are still caught.
The chain can be reorganised only to certain depth (to prevent long-range attacks). Therefore there will be regular hard forks where hard-coed checkpoint block will be hashed into clients.
Polkadot will enable interchain communication. The transaction on one chain are able to effect the dispatch of a transaction into a second parachain or relay-chain. Those transaction are inditinguishable from standard transactions.
Relay-chain is going to be state-based solution with the state mapping address to account information, balances and a transaction counter. It's going to has a VM (based around the EVM) like Ethereum, but there will be no possibility to deploy contracts (only build-in contracts) and therefore gas will not be measured.
Elements:
- Staking Contract that contains validator set (current validators, soon-to-be validators, nominators)
- Parachain Registry - "database-like construct", chain index, validation protocol identity. There should be voting for addiong / removing parachains (in voting contract?)
- Sealing Relay Blocks - aka mining. Validators votes for data availability (known or not yet known) and validity (valid, invalid, not yet known). While their vote different than "not yet known" they must vote this way for the rest of the process. All validators must submit votes. The block is valid if there are at least two thirds of positive votes and none negative and one-third votes for availability. If there is at least one positive and at least one negative vote, then all validators must vote - then we have either fork or punishment of majority.