8. Ethereum Proof-of-Stake

Byzantine Fault Tolerance (BFT)

Example of BFT (PeerReview)

Peer Review

1. Node E stores an object for client D
2. Node E tries to hide it from client B -> E = maliciious node!
3. The two clients(B, D) broadcast the authenticators they have obtained from E
4. Later, A audits E, discovers the inconsistency, and exposes E
5. Finally, node A broadcasts its evidence against E, so the other nodes can expose E as well

👉 no leader node, overhead for braodcasting

 

Example of BFT (pBFT)

pBFT

• assumption: # of malicious nodes in the network cannot equal or exceed 1/3 of the overall nodes
  • 3n + 1 node needed (n = # malicious node)
   

1. A client sends a request to the leader node to invoke a service operation
2. The leader node multicasts the request to the backup nodes.
3. The nodes execute the request and then send a reply to the client.
4. The client awaits f + 1 (f = the maximum number of nodes that may be faulty) replies from different nodes with the same result. This result is the result of the operation.
   • f+1개 이상의 노드로부터 동일한 결과를 수신하면 해당 결과를 최종 결과로 수락한다.

 

Limitatioins of pBFT

• Scaling: works efficiently only when the number of nodes is small due to the high communication overhead that increases exponentially
• Sybil attacks: susceptible to Sybil attacks, where one entity controls many identities.

---

Consensus algorithm of Ethereum

Chain-based PoS

Consensus algorithm of Ethereum

• Ethereum users will need to stake 32 ETH to become a validator
• Validators are chosen at random to create blocks (proposing) and are responsible for checking and confirming blocks (voting) they don't create.
• penalty will be applied to maliciious behaviors: staked money will be gone
  • validators cannot get a reward if they're offline (failing to validate)
  • validators can lost their entire stake for deliberate collusioin -> Attempting 51% attack will become more dangerous as they can lose all deposit which is 51% of all staked ETH
    • in PoW, penalty is only computing power for mining

How validators work

• user must deposit 32 ETH into the deposit contract and run three separate pieces of software
  • execution client, consensus client, validator client
• On depositing ETH, user joins an activation queue that limits the rate of new validators joining the network.
• Once activated, validators receive new blocks from peers
  • The transactions delivered in the block are re-executed to check that the proposed changes to Ethereum's state are valid - execution client
  • The block signature is checked - consensus client
  • The validator then sends a vote (= attestatioin) in favor of that block across the network. - validator client

Timing of blocks

• in PoS, the tempo is fixed <-> Bitcoin: avg 10 min (probablistic, not deterministic) adjusted to mining difficulty
• Time in PoS Ethereum is divided into slots (12 seconds) and epochs (32 slots)
• One validator is randomly selected to be a block proposer in every slot
  • responsible for creating a new block and sending it out to other nodes
• In every slot, a committee of validators is randomly chosen who vote
  • dividing the validator set up into committess is important for keeping the network load manageable (for scalability)
• Comittees divide up the validator set so that every active validator attests in every epoch, but not in every slot
  • every active validator joins at least 1 slot in 1 epoch

 

How a Transaction gets executed in Ethereum PoS

Step 1

• A user creates and signs a transaction with their private key
  • usually handled by wallet or library but under the hood the user is making a request to a node using Ethereum JSON-RPC API
• The user defines the amount of gas that they are prepared to pay as a tip to validator to encourage them
• The tips get paid to the validator while the base fee gets burned

Step 2

• The transaction is submitted to an Ethereum execution client which verifies its validity
• This means ensuring that the sender has enough ETH to fulfill the transaction and they have signed it with the correct key

Step 3

• If the transaction is valid, execution client adds it to its local mempool (list of pending tx) and also broadcasts it to other nodes over t he execution layer gossip network.
• When other nodes hear about the tx, they add it to their local mempool too
• Advanced users might refrain from broadcasting their tx and instead forward it to specialized block builders such as Flashbots Auction.
• This allows them t o organize the tx in upcoming blocks for maximum profit (MEV)

Step 4

• One of the nodes on the network is the block proposer for the current slot, having previously been selected pseudo-randomly (if stake more, get more chance)
• This node is responsible for building broadcasting the next block to be added to the Ethereum blockchain and updating the global state.
• The node is made up of three parts:
  • execution client: bundles tx from the local mempool into an 'execution payload' and executes them locally to generate a state change.
  • consensus client: execution payload is wrapped as part of a 'beacon block' is passed to the consensus client
  • validator client

Step 5

• Other nodes receive the new beacon block on the consensus layer gossip network
• They pass it to their execution client where the tx are re-executed locally to ensure the proposed state change is valid
• The validator client then attests that the block is valid and is the logical next block in t heir view of the chain (meaning it builds on t he chain with the greatest weight of attestations as defined in the fork choice ruels)
• The block is added to the local database in each node that attests to it.

Step 6

• The tx can be considered 'finalized' if it has become part of a chain with a 'supermajority link' btw two checkpoints.
• Checkpoints occur at the start of each epoch and they exist to account for the fact that only a subset of active validators attest in each slot, but all active validators attest across each epoch
• Therefore, it is only btw epochs that a 'supermajority link' can be demonstrated (this is where 66% of the total staked ETH on the network agrees on two checkpoints)

---

Ethereum PoS

Fork Choice

• It is possible for validators to have different views of the head of t he chain due to network latency or because a block propsoser has equivocated.
• Therefore, consensus clients require an algorithm to decide which one to favor.

👉 LMD-GHOST

• identifying the fork that has the greatest weight of attestations in its history

Finality

• A tx has "finality" when it's part of a block that can't change without a large amount of ETH getting burned.
• In Ethereum, this is managed using checkpoint blocks: the first block in each epoch is a checkpoint
• Validators vote for pairs of checkpoints that it considers to be valid.
  • If it gets votes at least two-thirds of the total staked ETH, the checkpoints are upgraded.
• The more recent of the two (checkpoint) becomes "justified". The earllier of the two is already justified because it was the "target" in the previous epoch. Now it is upgraded to "finalized"
• Since finality requires a two-thirds majority, attacker could prevent finalizing by voting with one-third of the total stake. 👉 to solve: the inactivity leak

Inactivity Leak

• activates whenever the chain fails to finalize for more than four epochs.
• bleeds away the staekd ETH from validators voting against the majority, allowing the majority to regain a two-thirds majority and finalize the chain.

 

Cryto-Economic Security of PoS

• Validators miss out on ETH rewards if they fail to participate when called upon, and their existing stake can be destroyed if they behave dishonestly.
  • proposing multiple blocks in a single slot, voting for invalid block

Correlation penalty

• The amount of ETH slashed depends on how many validators are also being slashed at around the same time
• It is imposed halfway through a forced exit period that begins with an immediate penalty (up to 1 ETH) on Day 1, the correlation penalty on Day 18, and finally, ejection from the network on Day 36
• They receive minor attestation penalties every day because they are present on the network but not submitting votes
• this all means a coordinated attack would be very costly for the attacker.

PoS가 네트워크 전반의 보안과 데이터 검증자의 무결성을 높이는 또 다른 방법으로는 부정직한 행위에 금전적인 불이익을 주는 것이 있다. 이더리움 네트워크에서 노드는 검증자로 참여하기 위해 ETH를 스테이킹해야 한다. 따라서 해당 노드와 연관된 공격이나 참여 실패가 발생할 경우, 이 노드가 스테이킹한 ETH는 파괴될 위험에 처하게 된다. 피해를 받는 ETH의 규모는 공격이나 부정직한 행위의 정도에 달려있으며, 네트워크에서 동시에 발생하는 다른 공격의 수에 따라서도 달라질 수 있다. 이를 ‘상관관계 페널티(correlation penalty)’라고 부른다.

PoS and Security

• Threat of 51% attack still exists but it's even riskier for the attackers
  • 51% -> not finalized but can fork, will be selected as main block
• community has flexibility in mounting a counter-attack
  • honest validators could decide to keep building on the minority chain and ignore the attacker's fork because their staked ETH can be maintained in forked chain.

Reference

https://www.usenix.org/legacy/event/hotdep06/tech/prelim_papers/haeberlen/haeberlen_html/index.html

https://www.blockchaintoday.co.kr/news/articleView.html?idxno=25956