4 ms·
I may be wrong, but collusion is hard to achieve via provably random selection procedures for validators of transactions, etc.
by SubiculumCode 5y ago
I may be wrong, but collusion is hard to achieve via provably random selection procedures for validators of transactions, etc.
- wyager 5y agoNetwork participants are free to ignore the results of provably random selection procedures and “re-roll”. In general there is no known way to impose real cost on protocol violations like this. This is the genius of PoW; it uniquely associates real-world expenditures with protocol actions. It’s probably impossible to replicate this in a more efficient, but still secure and reliable, way.
- dane-pgp 5y agoI'm not sure if this is how it works, but it should be possible to avoid the "re-roll" problem: Each node picks a random value, and publishes the hash of it to the blockchain, then, when the network has reached finality on what all the hashes are, the nodes publish the random values themselves, and the network takes the XOR of all of them.
- wyager 5y agoNodes can simply choose not to publish their value if the result is unfavorable to them, and this tanks the whole procedure. This isn’t a problem unique to your scheme; they all suffer from things like this.
- SubiculumCode 5y agoUsually a double spend attacks on PoS might need a collusion reaching upwards of 66%. That seems fairly improbable to me.
- dane-pgp 5y agoIf a node publicly commits to providing a random value, but then doesn't follow the protocol by actually revealing it, then that node's stake can be distributed to the honest nodes and the procedure started again. The protocol could even increase the stake needed to be one of these random value providing nodes, every time such a failure occurred, to make such an attack more and more expensive.
- wyager 5y agoThen the node that had their stake forfeited simply allocates their resources to a competing blockchain where that didn’t happen.
- dane-pgp 5y agoI think you're suggesting that a rogue node disobeying the protocol creates a chain split, allowing the node to just orphan the chain where they got caught. That's probably true in general, but I was assuming that the random number generation would be decoupled from the process of actually building the consensus. As long as the loss of stake can happen and be finalised as part of the transaction history, then eventually the attackers will run out of money and the random number generation process can catch up and start generating more entropy.
- Taek 5y agoThis is a massive over-simplification of the problem. A strong proof of stake construction has to consider all forms of Sybil attacks, all forms of wealth concentration (a significant problem in most cryptocurrencies - the top 3 exchanges often hold more than 30% of the supply of the token), low participation rates, outsourced participation (most large crypto holders hire the same small set of groups to do the staking process on their behalf), among other significant issues. It's a hard thing to get right.