Talk:Proof of stake: Difference between revisions - Wikipedia

Article Images

Line 1:

~~{{Wikiproject banner shell|1=~~

~~{{WikiProject Cryptocurrency |class=c |importance=high}}~~

~~{{WikiProject Computing |class=Start |importance=Low |science=y |science-importance=Mid |security=y |security-importance=Mid |software=y |software-importance=Low}}~~

~~{{WikiProject Cryptography |class=Start |importance=Low}}~~

}}

{{WikiProject banner shell|class=Start|

{{WikiProject Computing |importance=Low |science=y |science-importance=Mid |security=y |security-importance=Mid |software=y |software-importance=Low}}

}}

== Wrong information and wrong presentation ==

Line 396:

== Request edit on 13 July 2021 ==

Line 635:

:# is based on a very uncontroversial source and consists of (a) a text that says pretty much the same as the existing one (up to the words ''“nothing at stake” problem''), and (b) a text about mitigation. The (a) is already in the text, is there a need to change it? The (b) consists of a well-sourced part (up to the words ''from their position'') and then a part about Ethereum, which, at least in the source, is about mitigating a different type of attack.

:# is a preprint written by one of the very involved people (the link does not work, in the future please truncate links to something like https://eprint.iacr.org/2016/889.pdf , so that other editors can open them). As was stated multiple times on this page, this is not the best material to use for n encyclopedia.

:# is two sentences, one stating the obvious - but missing from the source ("PoS systems need to ensure that validators are incentivized to act honestly and that misbehavior is punished sufficiently"), for the three mitigations in the other one, one technique is missing in the source entirely (I did not find any "network partitioning" there), one not mentioned with regard to the briery attacks ("randomization", this is effective against multiple types of attacks, but needs to be explained, as it is explained in the source), one ("delegation") - at least in the source - is not ~~replated~~related to any mitigation, it sounds just like an implementation choice (''the block is then added in the blockchain or delegated to other validators for approval, depending on the type of proof of stake protocol in use'').

:Summing up, information from #1 can be partially used, information from #2 requires a better sourcing, information from #3 can be partially (randomization) used as a generic mitigation (directly in the section "Attacks") if an explanation is provided for the reader. [[User:Викидим|Викидим]] ([[User talk:Викидим|talk]]) 06:02, 28 February 2023 (UTC)

Indeed the first section (a) says pretty much the same, but I think it clarifies better the issue.

As for (b) the source says this:

‘’D. Bribery Attack

Bribery attack [30], also referred to as Short-Range attack relies on bribing validators or miners to work on specific blocks or forks. By doing that, the attacker can present arbitrary transactions as valid and having dishonest nodes paid to verify them. By paying them an amount equal to or more than the block rewards (in case the block is reverted by the network), it provides an incentive high enough for miners to work on the attacker’s blocks or chain. This case of bribery attacks also known as P+epsilon attack2 states that it is possible to bribe users without having to pay them, as the system will award the bribe to the dishonest nodes by making that branch the main chain. For these cases, the attacker faces a more significant problem as in case the malicious branch is reverted for some reason (attacker cannot continue the bribe, dishonest nodes stop working on that branch) the attacker would have to pay an enormous amount of bribes as the bribes will accumulate for every maliciously minted block.

In PoS systems, these kind of attacks are feasible and can be expanded to the nothing at stake problem. In both cases, PoS tackles this issue by either enforcing a slashing condition [2] or by releasing violators from their position [15].’’

The example of Eth is related with this conclusion about slashing conditions, providing additional information about it.

2. Indeed I didn’t know how to add sources since I used the automated tool until now. I am sorry about that. I won’t defend the source either. The purpose of this paragraph is to clarify where the attack is still successful. It does not provide new information, but I think it helps the reader to understand where the attack can be applied. I will search for better sources.

Indeed it is not referenced in this source, it is prior knowledge. You are right. I have to do better work on providing sources.

Network partitioning helps to control which party is responsible for which sector. It is not important and it could be omitted. Also it is not a mitigation. It is referenced as informative about the strategies used in this direction.

By the way, randomization is very important for all types of attacks, including this, because if the choice is not random, it is easier for blocks to be proposed by the same party, resulting in more feasible bribery attacks.

Delegation is indeed an implementation choice which adds centralization. This choice can help mitigate this type of attack due to economical incentives. It is not a strictly technical mitigation, and I think it could be also omitted.

[[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 10:09, 28 February 2023 (UTC)

== Explanation of the improvement proposals ==

Line 645 ⟶ 661:

:I see no bias here. The article states a simple fact that using the PoS opens many new opportunities for adversaries to exploit; this is a trivial consequence of the fact that for PoS regenerating a big piece of blockchain is near-free in computational terms. The list of these new attacks is taken from papers published in peer-reviewd journals, written by researchers who do not have a stake (in any sense) in the projects they discuss. Yes, the known attacks can be mitigated - and have been mitigated in every successful PoS scheme. Yes, the descriptions of these mitigation techniques (based on similar quality publications) are definitely worth presenting here. [[User:Викидим|Викидим]] ([[User talk:Викидим|talk]]) 05:19, 28 February 2023 (UTC)

::Wikipedia articles on blockchain topics (and sources about blockchain in general) tend to suffer from a recurring problem. Remember that Wikipedia's mission is (in part) to [[WP:5P2|document and explain major points of view]]. In practice, this means it is meant to be read and at least partly understood by laypeople. It also means critical content is covered proportionately and according to due weight, instead of being shoved into the corner of a [[WP:CSECTION]] talking about what nebulous unnamed "critics have argued".

::So the article has problems, and adding this new information will not, by itself, solve these problem.

::By all means, expand the article with reliable sources if those sources represent major points of view, but avoid furnishing the attic before the basement has been dug. The best way to explain any technical details, such as how these attacks can be mitigated etc. is to place this information in context. Right now, the article lacks this fundamental context, so this explanation is going to be much, much harder than it needs to be. [[User:Grayfell|Grayfell]] ([[User talk:Grayfell|talk]]) 11:00, 28 February 2023 (UTC)

Indeed. It is harder work than I thought to have both well documented sources and good explainability in so technical stuff. I admit that my proposals have not the intended quality to be in the article without further edit abd review. Partially this is because I was expecting to see the reactions and feedback before doing this work. By the feedback I understand that there is a potential if I improve the proposals, and now I am working on it.

As for the bias, I don't state it is intentional. The information provided is true. But if you reference on attacks on a scheme, without referencing their mitigations, someone who has no relevant knowledge can think that the whole PoS scheme is something insecure. It is all about the impression. And there is a big debate about PoS vs PoW in terms on security. Non technical audience could be affected by unbalanced impressions created by the most reliable knowledge base on earth. And you know the consequences, a single article could affect the adoption of PoW rather than PoS and this adoption contributes in increased energy consumption.

Anyway, I don't blame anyone about this, and I understand that the best way to correct this is by doing better work! Thank everyone for your feedback!

I also want to clarify that my criticism does not mean that I don't appreciate the work done here. I intend to improve things. I didn't propose to delete something just to extend it! [[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 14:41, 28 February 2023 (UTC)

:This is not as hard as it sounds: stick to articles in journals published by major bodies like IEEE and ACM and books by major science publishers, like Springer. Avoid works by the authors of the schemes, as they naturally tend to be overly optimistic. [[User:Викидим|Викидим]] ([[User talk:Викидим|talk]]) 02:02, 1 March 2023 (UTC)

== improvement proposal v2 ==

I worked on providing suitable sources, I truncated all parts of the text I couldn’t find good sources for, and I added some explanatory for clarification and better understanding for the readers. Please check the final proposal once again.

Add a sentence in the abstract, to follow where it says that it is chosen due to its energy efficiency:

Although it is generally considered to be more centralized and less secure, some argue that with the latest advances, PoS has become more safe and more decentralized than PoW, while also offering greater scalability.<ref name=":1">Proof-of-Stake Consensus Mechanisms for Future Blockchain Networks: Fundamentals, Applications and Opportunities; CONG T. NGUYEN, DINH THAI HOANG, DIEP N. NGUYEN, DUSIT NIYATO HUYNH TUONG NGUYEN1, AND ERYK DUTKIEWICZ https://ieeexplore.ieee.org/document/8746079 </ref>

In the end of the description section, or in the variants section, add the following text:

Byzantine Fault Tolerant (BFT) blockchains require a certain number of nodes, typically more than 2/3 of the total nodes in the network, to agree on a particular block before it is added to the blockchain. This ensures that the network can tolerate a certain number of malicious actors, up to 1/3 of the total nodes in the network, without compromising the network’s security.<ref name=":2"> The Security Ingredients for Correct and Byzantine Fault-tolerant Blockchain Consensus Algorithms; Amani Altarawneh, Anthony Skjellum https://ieeexplore.ieee.org/document/9297326 </ref><ref name=":4">A Comprehensive Review of Blockchain Consensus Mechanisms; BAHAREH LASHKARI AND PETR MUSILEK https://ieeexplore.ieee.org/document/9376868 </ref>

The reason for requiring 2/3 or more nodes to agree on a particular block in the BFT consensus mechanism is to ensure that there can only be one block at a given height in the chain. When more than 2/3 of the nodes agree on a particular block, it becomes mathematically impossible for another block at the same height to be signed by another 2/3 or more nodes, unless more than 1/3 of the nodes in the network are faulty and can cooperate with the 1/3 that did not sign the first block to create a second 2/3 block. Thus, BFT chains can reach consensus on the validity of transactions and add them to the blockchain without the risk of forks or double-spending attacks, as long as less than 1/3 of the nodes are faulty.<ref name=":2" />

BFT chains have the advantage of achieving consensus quickly, often in just a few seconds or less, compared to other consensus mechanisms such as longest chain protocols, based on PoW or PoS, which can take minutes or even hours. <ref name=":1" />

This fast consensus time allows BFT chains to process transactions more quickly, making them suitable for applications that require low latency.<ref name=":1" />

BFT chains are commonly used in permissioned blockchain networks, where participants are known and trusted, but can also be implemented in permissionless blockchain networks.<ref name=":3" />

One of the main challenges with Byzantine Fault Tolerant (BFT) blockchains is ensuring availability, or the ability to continuously make progress and add new blocks to the blockchain.<ref name=":2" /> Since BFT consensus requires a certain number of nodes to agree on a particular block before it can be added to the chain, it is possible for the network to become deadlocked if not enough nodes are able to participate in the consensus process. This can occur due to a variety of factors, such as network connectivity issues, node failure, or malicious behavior. <ref name=":2" /><ref name=":5">Blockchain Consensus Protocols in the Wild; Christian Cachin, Marko Vukolic https://www.researchgate.net/publication/318259899_Blockchains_Consensus_Protocols_in_the_Wild</ref>

Chain-based approaches for consensus are also used in blockchain systems, relying on proof-of-work or proof-of-stake consensus algorithms to secure the network. <ref name=":1" /> In proof-of-work, miners solve cryptographic puzzles to add new blocks to the chain, while in proof-of-stake, validators are chosen based on the amount of cryptocurrency they hold and stake as collateral. These consensus algorithms rely on the concept that the longest chain in the blockchain is the valid chain. <ref name=":1" /> Validators compete to create the longest chain, and the longest chain is considered the valid one, while shorter chains are discarded. <ref name=":1" /> To incentivize honest behavior, validators must invest their own cryptocurrency as collateral, which they may lose if they are found to be acting maliciously.<ref name=":3" />

Both BFT-based and Chain-based approaches have their own advantages and disadvantages, and each design has been implemented in various blockchain projects. .<ref name=":1" />

While BFT-based approaches provide a high degree of security and are well-suited for permissioned blockchains, they can be more complex to implement in permissionless blockchains and require a high degree of coordination among network participants.<ref name=":2" /><ref name=":4" /><ref name=":5" />

Chain-based approaches, on the other hand, are more simple to implement to provide guaranteed liveness for permissionless blockchains, but may not provide the maximum safety.<ref name=":2" /><ref name=":3" /><ref name=":5" />

In the end of the long range attacks section, remove the incomplete duplicate about bribery attacks, and add the following text:

One possible solution to mitigate long-range attacks in proof-of-stake systems is through the use of checkpoints. <ref name=":6">A Survey on Long-Range Attacks for Proof of Stake Protocols; Evangelos Deirmentzoglou; Georgios Papakyriakopoulos, Constantinos Patsakis https://ieeexplore.ieee.org/document/8653269 </ref>

Checkpoints are periodically created as blocks that include a hash of the blockchain up to a certain point. This allows users to verify the state of the blockchain at specific checkpoints and reject any chains that do not match the checkpoint. This checkpoint serves as a reference point for other nodes on the network and ensures that they are all working from the same blockchain history. Consequently long-range attacks are particularly powerful against two types of users: newcomers and disconnected users. Newcomers to the network may not have access to the full blockchain history and may not be able to distinguish between a valid chain and another chain. Similarly, disconnected users who have not been online for an extended period may not have the full blockchain history and may be vulnerable to long-range attacks. <ref name=":6" />

However, checkpoints introduce the notion of subjectivity into the system. Different nodes may have different opinions about which chain is valid based on their different blockchain histories. This is known as a subjective view. Additionally, checkpoints can introduce centralization and security trade-offs, as it requires users to trust the checkpoint authority.<ref name=":6" />

{{strike|In contrast, in the case of PoW, nodes normally choose to follow the chain with the most accumulated work, which is usually the longest chain. However, there are situations where the longest chain is not the one that is considered valid by the network. For example, in the case of the Bitcoin Cash hard fork, the chain split into two, and nodes had to choose which chain to follow. [https://www.theguardian.com/technology/2015/aug/17/bitcoin-xt-alternative-cryptocurrency-chief-scientist 8] Similarly, in the case of the Ethereum hard fork after the DAO attack, when the network was still based on PoW consensus, the community decided to fork the chain to revert the theft, while others chose to continue on the original chain.[https://medium.com/swlh/the-story-of-the-dao-its-history-and-consequences-71e6a8a551ee 9] }}

Weak subjectivity refers to the idea that there is no objective way to determine the true state of the blockchain in the long term, and users must rely on social consensus and subjective judgment to determine which chain to follow. Over time, social consensus tends to converge on a single chain, reducing the risk of conflicting views.<ref name=":7"> Exploring Sybil and Double-Spending Risks in Blockchain Systems; Mubashar Iqbal; Raimundas Matulevičius https://ieeexplore.ieee.org/document/9435780</ref><ref name=":6" />

A proposed mechanism to achieve long term objectivity on PoS chains is Cardano’s key evolving scheme in Ouroboros Genesis. By using the key-evolving scheme, Cardano ensures that even if an attacker manages to gain control of a signing key, they will not be able to use it to sign blocks outside of the current epoch. This makes long-range attacks much more difficult to execute, as the attacker would need to continuously control a majority of the stake throughout multiple epochs to carry out an attack.<ref name=":4" /><ref name=":6" /><ref name=":10">Ouroboros Genesis: Composable Proof-of-Stake Blockchains with Dynamic Availability; Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas https://eprint.iacr.org/2018/378.pdf</ref>

In the end of the Bribery attacks section add the following text:

Bribery attacks are a type of attack that relies on bribing validators or miners to work on specific blocks or forks, with the goal of presenting arbitrary transactions as valid. Bribery attacks are feasible in both Proof-of-Work (PoW) and Proof-of-Stake (PoS) systems, but they can be more effective in PoS due to the lower resource requirements and the possibility of expanding the attack to the “nothing at stake” problem.<ref name=":6" />

In PoS, bribery attacks can be mitigated by enforcing a slashing condition, where validators are penalized for behaving maliciously, or by releasing violators from their position.<ref name=":6" />

<small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas#top|talk]] • [[Special:Contributions/Touftoufikas|contribs]]) 04:08, 2 March 2023 (UTC)</small>

:Again, per above, I see several problems

:As before, blogs are not reliable. Medium posts are blog posts. While blog posts can be cited on Wikipedia in some very limited cases, this really doesn't appear to be one of those cases. The author of that blog post is neither unambiguously a reliable expert, nor notable enough to be cited for opinion. Please review [[WP:UGC]] and [[WP:SPS]].

:A second, but related problem, is that the Guardian source doesn't mention "proof of stake" at all, and doesn't even mention "proof of work". Since this source is a separate, unrelated topic, its use here is [[WP:SYNTH]]. This is not the correct approach.

:So do you understand why this is a problem?

:As I have said before, you need to look at what reliable, independent sources are saying about this topic and then summarize those sources. Those sources will tell you what is and is not a useful ''example'' for explaining the topic.

:[[User:Grayfell|Grayfell]] ([[User talk:Grayfell|talk]]) 02:47, 3 March 2023 (UTC)

Yes of course I understand, after reading WP:SYNTH. Consequently this paragraph should be removed, since only Ethereum-related blogs and sites discuss about weak subjectivity in a generalized context. A tried to reproduce this explanation relying on sources considered reliable, as guardian, but after reading WP:SYNTH I understood that this is not compatible with Wikipedia rules.

How about the rest of the text? Both problems you referenced were about a single paragraph. If the text from "In contrast..." to "...original chain [9]" is removed, along with these 2 references (8, 9), do you see any problem elsewhere? [[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 15:46, 3 March 2023 (UTC)

:I've taken the liberty of reformatting your proposal to be closer to Wikipedia's style, which will make it much easier for editors to evaluate. Please review and make sure I did not introduce any errors, or revert if you wish (per [[WP:TPG]]).

:[[Wikipedia:Citing sources]] may be helpful in the future. Wikipedia is old software (which especially shows on talk pages) and what is most comfortable for experienced editors may not be the most intuitive or obvious. Strictly from a formatting perspective, the changes I made were not necessarily sufficient for the article itself, but they are closer to what would be expected. This issue separate from the content of the proposed edits. [[User:Grayfell|Grayfell]] ([[User talk:Grayfell|talk]]) 23:18, 3 March 2023 (UTC)

:As for the content of your proposal, I have several concerns.

:One issue is the use of subtle editorializing language. As just one example, who, precisely, is saying that "ensuring liveness" is "one of the main challenges" facing Byzantine Fault Tolerant? It doesn't appear to be directly supported by the attached source. This kind of thing is why I stress the importance of looking at what sources are saying and summarizing, instead of adding your own understanding and adding sources which superficially support your own [[WP:OR]]. This project isn't the right place to add that kind of thing.

:As another of several possible examples, which source is saying that "chain-based approaches for consensus are commonly used in blockchain systems"? The citation is long enough that it might be buried in there somewhere, but it doesn't appear to be the main point that it's making, especially not regarding PoW, which is barely mentioned. That's a red flag all by itself: The entire paragraph is quite long, supported by a single source which barely mentions "proof-of-work" at all.

:As just one more example of many, the lone source for the paragraph on "checkpointing" doesn't use the term ''checkpointing''. If sources are not using this term, why are you?

:To revisit what I said previously, our goal is to summarize the main points of this topic. Generally, ''main points'' are not going to be buried in the middle of long and obscure journal articles. Look at sources which are ''about'' "proof-of-stake". Look at the introduction and conclusion of those articles. Is a ''main point'' of a source going to be confusing to readers? If so, it's okay to dig into the body to see how the source explains it. If it doesn't explain it well enough, it's sometimes okay to find other sources to clarify this, but the focus should still be on those ''main points''. If some piece of information isn't presented by the source as a main point, and it doesn't clarify specific confusion about a main point, it's probably not going to belong in a Wikipedia article.

:[[User:Grayfell|Grayfell]] ([[User talk:Grayfell|talk]]) 23:51, 3 March 2023 (UTC)

Thanx for reviewing and editing. I provided more references now to the long paragraphs and I deleted some informative sentences that are not directly supported by the sources. Some references were wrong, I assume by my mistake. I corrected them. [[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 16:19, 4 March 2023 (UTC)

I want to explain some things also.

1. Liveness and availability are synonymous terms.

I substituted the word in my text with the term provided by the source, to make the connection with the source clear, after reading your comcerns.

2. You ask where in the source checkpointing is referenced. Search for the following text in the source:

B. Moving Checkpoints

Moving checkpoints or simply checkpoints is a mitigation technique used by almost all PoS protocols. Its simplicity and ease in implementation made it one of the first mitigation techniques to be enforced in PoS powered blockchains, after of course the longest-chain rule.

[[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 16:23, 4 March 2023 (UTC)

:In generic computing source liveliness and availability are ''not'' synonymous. For example, while an application is busy processing a long job, it is alive, but unavailable. Typical terminology is availability = liveliness + readiness. [[User:Викидим|Викидим]] ([[User talk:Викидим|talk]]) 20:06, 4 March 2023 (UTC)

We are talking about blockchain consensus here. It is different in the sense that when a blockchain is busy (for example when it reaches the maximum transaction capacity), this does not affect its consensus algorithm iteration. So we often read one of these two terms in blockchain-related literature, and they almost refer to the same thing: the ability of a consensus algorithm to continue producing blocks, or that there are available validators to continue producing and validating blocks. It is the same thing from another perspective. Indeed, by the way, mathematically they are different concepts. I am talking in the context of blockchain and about the cap theorem availability vs finality or in other terms liveness vs safety. [[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 21:40, 4 March 2023 (UTC)

:Again, our goal is to explain this to readers who don't already know all this. Your interpretation of these sources may be correct, but it's still [[WP:OR]]. Summarize what sources actually say, not what they imply.

:Relatedly, to quickly clarify one of my points, "checkpoint" is a relatively common word used multiple times by the source. "Checkpointing" is not used by the source, and is rare. This is an encyclopedia, so word usage matters a great deal. It's a subtle thing, but introducing an uncommon word in an idiosyncratic way will only add to the jargon problem. [[User:Grayfell|Grayfell]] ([[User talk:Grayfell|talk]]) 22:22, 4 March 2023 (UTC)

*To echo comments of Grayfell, we need to find this content in high quality sources before we consider inclusion. [[User:Jtbobwaysf|Jtbobwaysf]] ([[User talk:Jtbobwaysf|talk]]) 02:52, 5 March 2023 (UTC)

1. I substituted the term checkpointing with the term checpoint(s), which is used in the sources.

2. The only source which is WP:OR is the paper of Ouroboros which is auxiliary. The rest of the papers are reviewing papers.

3. About sources quality. The most "controversial" topics are covered by 2 papers: 6 and 1. 6 was chosen as a source in the original article also. 1 is signed by IEEE members. I think this is more reliable than anything. And it is not primary work, it is an evaluation of others' work.

Anyway, thank you for your attention, I don't know if I can improve to meet your quality criteria. I quit the effort here for this article because I have the sense that I created more issues than those I tried to solve. I hope someone more experienced than me to continue this work and finally complete the article. [[User:Touftoufikas|Touftoufikas]] ([[User talk:Touftoufikas|talk]]) 08:59, 5 March 2023 (UTC)

== Extended-confirmed-protected edit request on 15 September 2023 ==

Examples of Proof of Stake crypto currencies are Tezos, Cardano, Solana, and Algorand and Ethereum 2.0

References:

- https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-proof-of-stake

- https://www.forbes.com/advisor/investing/cryptocurrency/proof-of-stake/

- https://www.fool.com/terms/p/proof-of-stake/ [[User:Hiraditya|Hiraditya]] ([[User talk:Hiraditya|talk]]) 14:05, 15 September 2023 (UTC)

:{{nd}} Unclear request, format requests in a "change X to Y" manner. [[User:WelpThatWorked|WelpThatWorked]] ([[User talk:WelpThatWorked|talk]]) 14:32, 16 September 2023 (UTC)