Consensus

The OPoS (Optimized Proof of Stake) consensus mechanism possesses several distinctive features that make it an attractive option in the world of cryptocurrency. With low transaction costs, minimal transaction delays, and high transaction concurrency, OPoS delivers an efficient and user-friendly experience for crypto enthusiasts.

This consensus mechanism supports a maximum of 21 validators, which helps strike a balance between decentralization and performance. By limiting the number of validators, the network can reach consensus more quickly, resulting in faster transaction times and improved scalability. At the same time, the OPoS mechanism ensures that validators are selected through a fair and transparent process, upholding the core principles of decentralization. In summary, the OPoS consensus mechanism combines the best aspects of performance and decentralization to create a robust and efficient blockchain network.

Validators

An account becomes a validator by posting some amount of coins as a surety bond. Once the bonding transaction is committed, the validator can participate in the consensus protocol with voting power in proportion to the number of coins bonded. Bonded coins cannot be used in any transaction except for an unbonded transaction. Afterwards, the coins remain locked in the nonbonding period of X blocks. If the validator fails to meet its obligations before the nonbonding period is over, the validator can lose all of its bonded coins. The validator fails to meet its obligations if any of the following occur:

• Signing two conflicting messages at the same block height

• Signing an invalid checkpoint

Given the punitive nature of the algorithm and the long nonbonding period, validators with significant voting power are unlikely to sign conflicting or invalid messages (at least until the nonbonding period is over).

Handling Validator timeouts

The network should adapt to validator churn as they go offline for various reasons. Validators that haven’t signed for Y blocks in a row (where 1 ≤ Y nonbonding period) are considered to have timed out and are implicitly unbonded. As long as validators churn in a staggered fashion, the active validator set can ad9 just to account for a changing set of participants. Validators that need to go offline temporarily might be incentivized to sign an explicit nonbonding transaction as opposed to timing out, as that allows the active validator set to adjust immediately. For example, timeouts could result in a small penalty fee in proportion to the amount of bonded coins, or validators may need to participate for some number of blocks before earning any fees. Later, (both explicitly and implicitly) unbonded validators can become active once again by submitting another bond transaction before the nonbonding period is over.