This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.k_consensus:05_algorithm:start [2021/08/17 13:00] murphy |
dido:public:ra:xapend:xapend.k_consensus:05_algorithm:start [2022/01/15 18:16] (current) nick |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4.0 Consensus Platforms ====== | + | ====== K.4 Consensus Platforms ====== |
| - | [[dido:public:ra:xapend:xapend.k_consensus | Return to DIDO Consensus ]] | + | [[dido:public:ra:xapend:xapend.k_consensus:start| Return to DIDO Consensus ]] |
| <table ConsensusAlorithym> | <table ConsensusAlorithym> | ||
| <caption>Crossreference os [[dido:public:ra:xapend:xapend.a_glossary:d:dido_platform|DIDO Platforms]] with Alogrithms.</caption> | <caption>Crossreference os [[dido:public:ra:xapend:xapend.a_glossary:d:dido_platform|DIDO Platforms]] with Alogrithms.</caption> | ||
| - | ^ Consensus Alorithym ^ Platform Examples ^ Pros ^ Cons ^ Type ^ | + | ^ Consensus Algorithm ^ Platform Examples ^ Pros ^ Cons ^ Type ^ |
| ^ [[dido:public:ra:xapend:xapend.k_consensus:02_mechanism:cellular ]] | <WRAP> | ^ [[dido:public:ra:xapend:xapend.k_consensus:02_mechanism:cellular ]] | <WRAP> | ||
| //Theoretical//</WRAP> |<WRAP> | //Theoretical//</WRAP> |<WRAP> | ||
| Line 14: | Line 14: | ||
| NEO</WRAP> |<WRAP> | NEO</WRAP> |<WRAP> | ||
| * Generating a new block on the chain takes between 15 and 20 seconds. | * Generating a new block on the chain takes between 15 and 20 seconds. | ||
| - | * The transaction throughput is close to 1,000 TPS. NEO hopes to reach 100,000 TPS, which would allow the network to support large-scale commercial applications. | + | * The transaction [[dido:public:ra:xapend:xapend.a_glossary:t:thruput|throughput]] is close to 1,000 TPS. NEO hopes to reach 100,000 TPS, which would allow the network to support large-scale commercial applications.\\ |
| * No expenditure of energy needed (unlike the Proof-of-Work [[dido:public:ra:xapend:xapend.a_glossary:c:consensus_algorithm|consensus algorithm]]). | * No expenditure of energy needed (unlike the Proof-of-Work [[dido:public:ra:xapend:xapend.a_glossary:c:consensus_algorithm|consensus algorithm]]). | ||
| * Total finality for transactions after their [[dido:public:ra:xapend:xapend.a_glossary:c:confirmation|confirmation]]. | * Total finality for transactions after their [[dido:public:ra:xapend:xapend.a_glossary:c:confirmation|confirmation]]. | ||
| * There are no forks on the NEO [[dido:public:ra:xapend:xapend.a_glossary:b:blockchain|blockchain]]. | * There are no forks on the NEO [[dido:public:ra:xapend:xapend.a_glossary:b:blockchain|blockchain]]. | ||
| + | |||
| [[https://coinrivet.com/delegated-byzantine-fault-tolerance-dbft-explained/]] | [[https://coinrivet.com/delegated-byzantine-fault-tolerance-dbft-explained/]] | ||
| </WRAP> |<WRAP> | </WRAP> |<WRAP> | ||
| Line 33: | Line 34: | ||
| * Less hardware: Participants don’t need costly, specialized equipment. A regular computer is powerful enough. | * Less hardware: Participants don’t need costly, specialized equipment. A regular computer is powerful enough. | ||
| * An incentive to “behave”: [[dido:public:ra:xapend:xapend.a_glossary:b:block_producers|Block producers]] — delegates — can be voted out at any time, so the potential for loss of income and reputation provides a hedge against bad behavior. | * An incentive to “behave”: [[dido:public:ra:xapend:xapend.a_glossary:b:block_producers|Block producers]] — delegates — can be voted out at any time, so the potential for loss of income and reputation provides a hedge against bad behavior. | ||
| - | * Flexibility: Because DPoS unlinks the election of block producers from the block production itself, it allows for a more creative and flexible approach to solving problems with either, in isolation, a recent Coinmonks piece explains. It provides a foundation for implementing “interesting governance models in blockchain applications.” | + | * Flexibility: Because DPoS unlinks the election of block producers from the block production itself, it allows for a more creative and flexible approach to solving problems with either, in isolation, a recent Coinmonks piece explains. It provides a foundation for implementing “interesting [[dido:public:ra:xapend:xapend.a_glossary:g:governance]] models in blockchain applications.” |
| [[https://www.verypossible.com/insights/pros-and-cons-of-the-delegated-proof-of-stake-consensus-model]] | [[https://www.verypossible.com/insights/pros-and-cons-of-the-delegated-proof-of-stake-consensus-model]] | ||
| </WRAP> |<WRAP> | </WRAP> |<WRAP> | ||
| * It's easier to organize an attack: Because fewer people are in charge of keeping the network alive, it’s easier to organize a “51 percent” attack. | * It's easier to organize an attack: Because fewer people are in charge of keeping the network alive, it’s easier to organize a “51 percent” attack. | ||
| - | * The rich may get richer: People’s vote strength is determined by how many tokens they have, which means that people who own more tokens will influence the network more than people who own very few. | + | * The rich may get richer: People’s vote strength is determined by how many [[dido:public:ra:xapend:xapend.a_glossary:t:tokens|tokens]] they have, which means that people who own more tokens will influence the network more than people who own very few. |
| * Apathy can kill: Without a large number of engaged users, the system will not function as intended. (That’s a bit like any democracy or democratic republic.) | * Apathy can kill: Without a large number of engaged users, the system will not function as intended. (That’s a bit like any democracy or democratic republic.) | ||
| - | * Delegates could form cartels: Delegates can organize into cartels by concentrating the role of validation in a smaller number of hands. This not only makes it less decentralized, but it also makes it less resilient. | + | * Delegates could form cartels: Delegates can organize into cartels by concentrating the role of [[dido:public:ra:xapend:xapend.a_glossary:v:validation|validation]] in a smaller number of hands. This not only makes it less decentralized, but it also makes it less resilient. |
| * This notion that DPoS is not truly decentralized may be the most notable criticism of all. Yes, DPoS is less centralized than some other consensus protocols; nevertheless, power is still concentrated in the hands of a handful of users. DPoS sacrifices decentralization for scalability, critics say. | * This notion that DPoS is not truly decentralized may be the most notable criticism of all. Yes, DPoS is less centralized than some other consensus protocols; nevertheless, power is still concentrated in the hands of a handful of users. DPoS sacrifices decentralization for scalability, critics say. | ||
| [[https://www.verypossible.com/insights/pros-and-cons-of-the-delegated-proof-of-stake-consensus-model]] | [[https://www.verypossible.com/insights/pros-and-cons-of-the-delegated-proof-of-stake-consensus-model]] | ||
| Line 196: | Line 197: | ||
| Bitcoin, [[dido:public:ra:xapend:xapend.a_glossary:l:litecoin|Litecoin]], ZCash, Primecoin, Monero, Vertcoin</WRAP> |<WRAP> | Bitcoin, [[dido:public:ra:xapend:xapend.a_glossary:l:litecoin|Litecoin]], ZCash, Primecoin, Monero, Vertcoin</WRAP> |<WRAP> | ||
| * Proof of work models make blockchain networks more difficult and costly to attack. | * Proof of work models make blockchain networks more difficult and costly to attack. | ||
| - | * Proof of work models reward miners with both a block reward and a share of transaction fees. | + | * Proof of work models reward miners with both a block reward and a share of [[dido:public:ra:xapend:xapend.a_glossary:t:transaction_fees|transaction fees]]. |
| * Proof of work models often results in more decentralized networks. | * Proof of work models often results in more decentralized networks. | ||
| * Less opportunity for 51% attack | * Less opportunity for 51% attack | ||
| Line 211: | Line 212: | ||
| </table> | </table> | ||
| + | |||
| + | <color blue><todo @char> Do general review of this page </todo></color> \\ | ||
| + | <color blue><todo @char> Decide if it's worthwhile to fix the unordered lists so they look better in pdfexport </todo></color> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||