3

In general PoS, the forgers stake their coins and then a validator chosen in a pseudorandom fashion gets the chance to validate a block. But how do the whole network validate it?

In PoW, for example, the whole network can easily verify the block by hashing the solution proposed by the miner, which takes considerably less computational power. Once verified by the network, all full nodes accept the block and work to mine the next block.

What I am confused about is what is the procedure of validation by the network in PoS? How is a forged block accepted as valid and added to the blockchain?

note: I am only a beginner in this and I could not find the answer anywhere.

| improve this question | |
2

Here is a rundown example of how validation occurs in the Ethereum 2.0 (Serenity) Consensus Protocol. There are several specifications that are required that define that elements of Serenity. I will be explaining only a few but important key elements that are used in PoS.

1) Beacon-chain

The Beacon-Chain, sometimes known as the 'beacon-node' or 'master-node' is responsible for lighting up the nodes in the network.

Nodes are classified as either validators or attestors. A random choosing mechanism is used to determine which node becomes a validator and the rest becomes attestors. This is calculated based on a form of weighting, in this case, the more amount of ether you put in the more likely you'll be chosen to propose a block. Blocks are not 'forged' like in PoW but rather 'proposed' by a validator.

Once a block has been proposed by the validator, it gets sent to the beacon-chain and is then broadcasted to the attestors who must vote in their time slot (I will explain this in sharding).

The validation comes from the attestors and the block is accepted, the block also needs to pass many pre-conditions, similarly to PoW with current hash meeting parent hash, time is greater than... you get the idea.

2) Sharding

With sharding, there are different groups of validators that propose different blocks. In Prysmatic Labs Eth 2.0 Implementation they use 1024 shard chains in which validators are continuously shuffled.

For example, each shard has 4 validators, 1 of them gets chosen to be the validator and the last 3 becomes attestors. The validator proposes a block and that block gets attested by the 3. Repeat this for 1024 shard chains and you'll end up with 1024 proposed blocks in which attestors can vote on to see which block gets pushed to the blockchain.

Attestors vote either whether the proposed block should be pushed onto the blockchain, There are a couple of rules that are implemented to counteract malicious actors that may try to vote for blocks that could mess up the network.

Attestors are pushed to vote on the right block as if they vote for the wrong block, vote on multiple blocks or vote out of their time slot, their eth staked will then be slashed from the network.

A time slot is given to each attestor to vote on the proposed block, this is done to reduce malicious actors from trying to compromise the network.

There are many more layers, protocols, rules and procedures that will be used in Serenity. You can find out more here at:

Github Ethereum 2.0 Spec - https://github.com/ethereum/eth2.0-specs

Eth Research - https://ethresear.ch/

See ProtoLambda's tweet here, which shows an Eth 2.0 schematic that is out of this world. https://twitter.com/protolambda/status/1090272649421508609

| improve this answer | |
  • thanks! For clarification, I think this is the case for BFT style PoS. What about this? Is this still valid for a more "generalized" PoS? by generalized, I mean a Nakamoto-based PoS. – tanjan Feb 12 '19 at 19:32
  • Hi! You are correct that Ethereum 2.0 is based on BFT. However, I'm not quite sure what you mean by a 'Nakamoto-based PoS'. I'm guessing it is 'chain-based' where a validator gets assigned the right to create a block? – Yanzal Feb 12 '19 at 20:43
  • Yes, precisely. In many other cryptocurrencies, a Leader is elected by some pseudorandom algo or coin-age, and often with the use of public-private key pair. As far as I could understand once the selected Leader proposes a block, the other nodes verify the block by hashing the public key of the Leader. What I wanted to ask is, is my understanding alright? If not, where am I wrong? – tanjan Feb 12 '19 at 20:49
  • Also, AFAIK validators get assigned the right to create a block in BFT style blocks as well, the network then casts vote to determine whether the block was valid or not. Please correct me if I'm wrong! – tanjan Feb 12 '19 at 20:50
  • Yes, many chain-based PoS implementations use a form of a pseudorandom algorithm that assigns the right to a validator to create a block and it must point to the previous block. There are many flavors you could say such as stake, coinage, delegations.. etc. Usually the block is verified by passing through a validation stage where the hash must point to the previous hash, the block creation time must be greater than the current time. I am not sure where blocks are verified by hashing the public key of a 'leader' could you link a reference to this? – Yanzal Feb 12 '19 at 23:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.