add sections on peer selection and observability #59
Conversation
Signed-off-by: Roland Kuhn <rk@rkuhn.info>
| malicious peers). A solution to this problem has been formulated in the | ||
| [Ouroboros Genesis paper](https://iohk.io/en/research/library/papers/ouroboros-genesis-composable-proof-of-stake-blockchains-with-dynamic-availability/). | ||
|
|
||
| A statically configured node can avoid these issues by having a fixed |
There was a problem hiding this comment.
Well, actually you don't avoid the issue because you could also be eclipsed or tricked into believing you are connecting to a honest peer through eg. DNS cache poisoning or MitM attacks.
There was a problem hiding this comment.
One could argue the fixed topology situation is even worse because you would not have a chance to reconnect to the honest network.
|
|
||
| ## Common setups | ||
|
|
||
| A block producer run by a diligent stake pool operator will have a completely |
| by the Haskell implementation. | ||
|
|
||
| Before choosing the above strategy the expected outcomes on a whole network | ||
| level have been simulated. The churn rate of 20% per hour has been selected |
There was a problem hiding this comment.
We should probably add link to the paper/simulation here?
There was a problem hiding this comment.
Yes please. Links (sources, citations, or additional context) are amazing to have in the blueprints.
As much as we can we want the information in the blueprints themselves of course, but links are strongly encouraged
There was a problem hiding this comment.
note to self: https://engineering.iog.io/2023-06-28-p2p/
3 participants
No description provided.