<p>Initially, consensus protocols using Proof of Stake for sybil resistance faced several technical problems that needed to be addressed in order to provide sufficient security properties in a trustless environment. Among the most important we have:</p>
<ol>
<li>The <em>nothing at stake</em> problem</li>
<li>Long range attacks</li>
<li>The need for a decentralised and robust source of randomness</li>
</ol>
<p>The fact that &quot;stake&quot; is not tightly coupled with a physical resource (like energy in PoW) means that when a fork of the chain occurs, there is no direct incentive for a node to pick only one chain. With PoW, validating an additional chain has a significant energy cost for a node. In PoS, it's just some marginal disk, computation and bandwidth usage. Similarly, a malicious node can create an alternative chain from genesis and present it to the network as the legitimate chain, since there is no much cost involved in doing so. These two problems I just described correspond to the <em>nothing at stake</em> and the <em>long range</em> problems, respectively, and for a time were considered unsolvable.</p>
<p>Problem 3. was relatively easy to solve. <a href="https://eprint.iacr.org/2016/889.pdf" rel="noreferrer">Ouroboros classic</a> introduced publicly verifiable secret sharing (PVSS), but it was not robust to adaptive attacks (see more details in the linked paper). Then <a href="https://eprint.iacr.org/2017/573.pdf" rel="noreferrer">Ouroboros Praos</a> introduced a much more robust mechanism based on Verifiable Random Functions (VRF). In short, with VRFs the pieces of data required to compute the random beacon are computed locally by each node, and are not broadcasted to the network. This way, an attacker cannot know who the next block proposer will be.</p>
<p>The long range problem, also known as the <em>bootstrapping problem</em>, was perhaps one of the most difficult. In simple terms, it is about how to guarantee that a new node joining the network can actually reconstruct the whole blockchain history of the <em>legitimate</em> chain. PoW chains solve this issue with the simple and elegant longest chain rule, and that's probably one of the main reasons why they were considered superior in terms of security. As far as I know, <a href="https://iohk.io/en/research/library/papers/ouroboros-genesiscomposable-proof-of-stake-blockchains-with-dynamic-availability/" rel="noreferrer">Ouroboros Genesis</a> was the first PoS-based protocol that solved this analytically.</p>
<p>Finally, every blockchain design needs to meet properties such as guaranteed <em>finality</em> and <em>liveness</em>. All the Ouroboros family of protocols provide analytically proven finality and liveness properties <em>under certain theoretical conditions</em>. It is important to make this distinction because the theoretical models might not always take into account all the possible attacks and disruptions that may happen in real world conditions. Also, research results from different blockchains are typically presented over a different set of theoretical assumptions, so it's important to understand them before comparing them.</p>
<p>That being said, recent versions of Ouroboros have been studied under a rather relaxed set of conditions, and according to the results presented in the papers, their security properties are comparable to those of Bitcoin.</p>

CC BY-SA 4.0
2022-07-23T13:20:53.847Z
good explanation but problems #1 and #2 solutions are not that explicit, however #3 you address explicitly.  I would recommend editing for a more concise and explicit answer.
TheStophe
CC BY-SA 4.0
2021-05-09T14:07:19.397Z
I take it that problem 1 is no longer considered unsolvable, but has it actually been solved?  Does any of the Ouroboros variants you cited solve it?
kjo
CC BY-SA 4.0
2021-05-10T21:10:07.773Z
@kjo yes, essentially solving 1. is equivalent to guaranteeing persistence/finality. All ouroboros protocols provide a solution for this, but under different system models.
vaz
CC BY-SA 4.0
2021-05-05T23:15:10.613Z
2021-05-05T23:15:10.613Z
vaz
<p>It is generally thought of that Proof of Work is more secure than competing consensus algorithms.</p>
<p>What security guarantees does using a Bitcoin PoW provide, and how does Ouroboros Praos compare? Will future versions of Ouroboros improve the security of the network?</p>

CC BY-SA 4.0
2021-05-04T05:03:08.693Z
There are several implementations of Ouroboros. Are you referring to any particular one? [cardano docs](https://docs.cardano.org/en/latest/explore-cardano/understanding-consensus.html).
Kristie Tom
CC BY-SA 4.0
2021-05-04T05:07:44.190Z
I suppose I'm referring to the one in place today (Ouroboros Praos), but I'm interested in what future versions may contribute to this question. Question updated.
soccer193
CC BY-SA 4.0
2021-05-04T05:52:45.977Z
[This IOHK blog post](https://iohk.io/en/blog/posts/2020/03/23/from-classic-to-hydra-the-implementations-of-ouroboros-explained/) addresses security in the various versions of Ouroboros at a high level, but doesn't really answer the question asked
Ben NOBLE
CC BY-SA 4.0
2021-05-04T19:43:31.607Z
I think that's one of the subtle things that Ergo's PoW will be able to help since both share the same EUTxO model.
Aron Neewart
<proof-of-stake><ouroboros>
How secure is Ouroboros Proof of Stake compared to Bitcoin Proof of Work?
# How secure is Ouroboros Proof of Stake compared to Bitcoin Proof of Work?

(Asked by: username_0 on 2021-05-04)

It is generally thought of that Proof of Work is more secure than competing consensus algorithms.

What security guarantees does using a Bitcoin PoW provide, and how does Ouroboros Praos compare? Will future versions of Ouroboros improve the security of the network?

**Tags:** proof-of-stake, ouroboros
> **Comments:**
> **username_1**: There are several implementations of Ouroboros. Are you referring to any particular one? [cardano docs](https://docs.cardano.org/en/latest/explore-cardano/understanding-consensus.html).  
> **username_0**: I suppose I'm referring to the one in place today (Ouroboros Praos), but I'm interested in what future versions may contribute to this question. Question updated.  
> **username_2**: [This IOHK blog post](https://iohk.io/en/blog/posts/2020/03/23/from-classic-to-hydra-the-implementations-of-ouroboros-explained/) addresses security in the various versions of Ouroboros at a high level, but doesn't really answer the question asked  
> **username_3**: I think that's one of the subtle things that Ergo's PoW will be able to help since both share the same EUTxO model.  

---

## 1 answers

### Answer by username_4 on 2021-05-05. Score: 11

Initially, consensus protocols using Proof of Stake for sybil resistance faced several technical problems that needed to be addressed in order to provide sufficient security properties in a trustless environment. Among the most important we have:

1. The *nothing at stake* problem
2. Long range attacks
3. The need for a decentralised and robust source of randomness

The fact that "stake" is not tightly coupled with a physical resource (like energy in PoW) means that when a fork of the chain occurs, there is no direct incentive for a node to pick only one chain. With PoW, validating an additional chain has a significant energy cost for a node. In PoS, it's just some marginal disk, computation and bandwidth usage. Similarly, a malicious node can create an alternative chain from genesis and present it to the network as the legitimate chain, since there is no much cost involved in doing so. These two problems I just described correspond to the *nothing at stake* and the *long range* problems, respectively, and for a time were considered unsolvable.

Problem 3. was relatively easy to solve. [Ouroboros classic](https://eprint.iacr.org/2016/889.pdf) introduced publicly verifiable secret sharing (PVSS), but it was not robust to adaptive attacks (see more details in the linked paper). Then [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) introduced a much more robust mechanism based on Verifiable Random Functions (VRF). In short, with VRFs the pieces of data required to compute the random beacon are computed locally by each node, and are not broadcasted to the network. This way, an attacker cannot know who the next block proposer will be.

The long range problem, also known as the *bootstrapping problem*, was perhaps one of the most difficult. In simple terms, it is about how to guarantee that a new node joining the network can actually reconstruct the whole blockchain history of the *legitimate* chain. PoW chains solve this issue with the simple and elegant longest chain rule, and that's probably one of the main reasons why they were considered superior in terms of security. As far as I know, [Ouroboros Genesis](https://iohk.io/en/research/library/papers/ouroboros-genesiscomposable-proof-of-stake-blockchains-with-dynamic-availability/) was the first PoS-based protocol that solved this analytically.

Finally, every blockchain design needs to meet properties such as guaranteed *finality* and *liveness*. All the Ouroboros family of protocols provide analytically proven finality and liveness properties *under certain theoretical conditions*. It is important to make this distinction because the theoretical models might not always take into account all the possible attacks and disruptions that may happen in real world conditions. Also, research results from different blockchains are typically presented over a different set of theoretical assumptions, so it's important to understand them before comparing them.

That being said, recent versions of Ouroboros have been studied under a rather relaxed set of conditions, and according to the results presented in the papers, their security properties are comparable to those of Bitcoin.

> **Comments:**
> **username_6**: I take it that problem 1 is no longer considered unsolvable, but has it actually been solved?  Does any of the Ouroboros variants you cited solve it?  
> **username_4**: @kjo yes, essentially solving 1. is equivalent to guaranteeing persistence/finality. All ouroboros protocols provide a solution for this, but under different system models.  
> **username_5**: good explanation but problems #1 and #2 solutions are not that explicit, however #3 you address explicitly.  I would recommend editing for a more concise and explicit answer.  

---

