Whitepaper
  • Introduction
  • Architecture
  • Sea Network And EVM
  • Powerful EVM Architecture Supports Defi
  • Sea Network and PoS
  • Decentralized Governance
  • Features
    • Ethereum Virtual Machine (EVM)
    • Layering
    • Voting, Witnesses & Block Validators
      • Voting
      • Delegates
      • Block validators
      • Witness
  • Consensus Protocols
    • Consensus Protocols
    • Proof-of-Work (PoW)
    • Practical Byzantine Fault Tolerance (PBFT)
    • Practical Byzantine Fault Tolerance overview
    • PBFT Proof of Authority (PoA)
    • PBFT Proof-of-Stake (PoS)
    • Consensus algorithm RAFT
  • tokenomic & roadmap
    • Tokenomic
    • Roadmap
Powered by GitBook
On this page
  1. Consensus Protocols

PBFT Proof-of-Stake (PoS)

The Proof-of-Stake (PoS) implementation is intended as an alternative to the existing PBFT PoA implementation by providing node operators with the ability to easily choose between the two at the start of the chain. . Epochs are considered to be the specific time frame (in blocks) within which a given set of validators can generate blocks. The epoch length can be changed, which means the node operators can set the length of the epoch during instance creation. An epoch block is created at the end of each epoch, and a new epoch begins after this event. The validator is updated at the end of each interval. Nodes request a set of validators from the smart contract staking during the block epoch and store the resulting data in local storage. Query and save this cycle that repeats at the end of each interval. Essentially, this allows the staking smart contract to have complete control over the addresses in the validator pool, leaving only one mandate for the nodes. Each contract query is executed once each interval to get the latest information about the validator set. This removes the responsibility of handling validator sets from individual nodes

PreviousPBFT Proof of Authority (PoA)NextConsensus algorithm RAFT

Last updated 1 year ago