5 ms·

The section I particularly have a problem with is "How is the randomness for random sampling generated?" Everyone seems to think this is a solved problem but th

The section I particularly have a problem with is "How is the randomness for random sampling generated?" Everyone seems to think this is a solved problem but the reality is it is extremely difficult to solve. (The same problem exists for proof of stake schemes) There is lots of complex cryptography, game theory and economics involved in working out if a robust solution really exists. The most commonly stated solution is something called a "Threshold Signature Scheme". Threshold signatures schemes (and threshold cryptography in general) have two main problems. Firstly they don't scale well. As you add participants you need lots of extra rounds of communication and computation. Secondly they aren't resistant to Sybil attacks. The proposed way around this is to link participation to a stake of coins (yep back to proof of stake) such that launching a Sybil attack requires lots of coins. This is not trivial however because of the "Nothing at Stake" problem where stake can be used to participate in many forks of a scheme at the same time.

drcode 9y ago
Ethereum POS is already running on a test net, you're welcome to go over there and see what happens when you try to use your stake on "many forks at the same time". Spoiler: you won't be able to do so without losing your stake very quickly.
- barbegal 9y ago
  Well not quite. The test net is actually a hybrid of proof of work and proof of stake [1]. Proof of work is used as the main decider in the case of a fork, however if long forks are seen then checkpoints validated by proof of stake are used. The slashing function is in the contract [2] but there is actually no incentive to duplicate votes on the testnet since there is only rewards for voting (block rewards are given to proof of work miners). [1] https://github.com/ethereum/casper/blob/master/IMPLEMENTATION.md https://github.com/ethereum/casper/blob/master/IMPLEMENTATIO... [2] https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py https://github.com/ethereum/casper/blob/master/casper/contra...
  - drcode 9y ago
    Don't totally follow your argument, but if you're saying that we won't have a full understanding of the POS economic guarantees until we have empirical evidence from a "live network" with significant rewards at stake I agree 100%.
- cocktailpeanuts 9y ago
  If PoS fails, it will fail as a black swan event, after the system became "too big to fail", not at the level of mere testnet.
chc4 9y ago
Easy way out: Use the NIST randomness beacon. Now, if only half the pull of cryptocurrencies wasn't the rampant libertarian dream of it...
dlubarov 9y ago
Another approach is to have several parties (perhaps every block creator) contribute a number. Then we concatenate the numbers and feed them through a delay function, which should take everybody a certain minimum amount of time to compute, regardless of computational power. The result of this function becomes the random seed for some future block. An attacker cannot predict how their number will affect the result, since they would need to compute the delay function first. By the time they finish the computation, they'll have missed the window of opportunity to contribute a number. (They could add their number on a very old fork, but other clients would not accept forks beyond a certain age. This is important anyway to prevent stake-bleeding attacks.) A obvious candidate for a delay function is an iterated hash function like sha3^10000. A few researchers are looking into "verifiable" delay functions [1], so that not every client has to do the computation; most clients can download the result along with an easily-verified proof (perhaps using a SNARK) that the result is correct. Besides saving some computational resources, this would help new nodes catch up to the network quickly, without needing to compute all the historical seeds. [1] https://www.youtube.com/watch?v=qUoagL7OZ1k https://www.youtube.com/watch?v=qUoagL7OZ1k

drcode 9y ago

Ethereum POS is already running on a test net, you're welcome to go over there and see what happens when you try to use your stake on "many forks at the same time". Spoiler: you won't be able to do so without losing your stake very quickly.

barbegal 9y ago
Well not quite. The test net is actually a hybrid of proof of work and proof of stake [1]. Proof of work is used as the main decider in the case of a fork, however if long forks are seen then checkpoints validated by proof of stake are used. The slashing function is in the contract [2] but there is actually no incentive to duplicate votes on the testnet since there is only rewards for voting (block rewards are given to proof of work miners). [1] https://github.com/ethereum/casper/blob/master/IMPLEMENTATION.md https://github.com/ethereum/casper/blob/master/IMPLEMENTATIO... [2] https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py https://github.com/ethereum/casper/blob/master/casper/contra...
- drcode 9y ago
  Don't totally follow your argument, but if you're saying that we won't have a full understanding of the POS economic guarantees until we have empirical evidence from a "live network" with significant rewards at stake I agree 100%.
cocktailpeanuts 9y ago
If PoS fails, it will fail as a black swan event, after the system became "too big to fail", not at the level of mere testnet.

chc4 9y ago

Easy way out: Use the NIST randomness beacon. Now, if only half the pull of cryptocurrencies wasn't the rampant libertarian dream of it...

dlubarov 9y ago

Another approach is to have several parties (perhaps every block creator) contribute a number. Then we concatenate the numbers and feed them through a delay function, which should take everybody a certain minimum amount of time to compute, regardless of computational power. The result of this function becomes the random seed for some future block. An attacker cannot predict how their number will affect the result, since they would need to compute the delay function first. By the time they finish the computation, they'll have missed the window of opportunity to contribute a number. (They could add their number on a very old fork, but other clients would not accept forks beyond a certain age. This is important anyway to prevent stake-bleeding attacks.) A obvious candidate for a delay function is an iterated hash function like sha3^10000. A few researchers are looking into "verifiable" delay functions [1], so that not every client has to do the computation; most clients can download the result along with an easily-verified proof (perhaps using a SNARK) that the result is correct. Besides saving some computational resources, this would help new nodes catch up to the network quickly, without needing to compute all the historical seeds. [1] https://www.youtube.com/watch?v=qUoagL7OZ1k https://www.youtube.com/watch?v=qUoagL7OZ1k