3 ms·

What do you mean by "allowed to"? In a PoW system, the PoW is a distributed timekeeping device. That's the actual operation the PoW does, and the distributed ti

What do you mean by "allowed to"? In a PoW system, the PoW is a distributed timekeeping device. That's the actual operation the PoW does, and the distributed timekeeping is then what you can build a blockchain on. PoS doesn't not do distributed timekeeping. If you sign a block now, then go back later and sign a different block with the same key, there's no distributed clock that can be used to prove which was actually signed first. The obvious argument here is "the one that was signed first will then have other blocks built on top of it". But since there's no PoW, building a parallel blockchain is trivial to compute, the only restriction is being able to produce something that's actually convincing enough. That and having people say "well, I was there at the time and I saw a different block than this", but that's just relying on authority rather than something that can be proven within the system. Basically, PoS requires something external to the system to prove that history hasn't been changed. PoW technically does too, but what it relies on is "physics" and "provable historical fact" (i.e. approximate computing power available in the past). You certainly can build a system that depends on something external to itself to ensure its consistency, but this challenges its claim to being "decentralized" and limits the amount of trust you can place in the system (and consequently the power of what it can do).

light_cone 5y ago
The clock issue is an excellent point, but the ethereum PoS have a nano scale PoW mechanism for this exact problem. Look at VFD "Verifiable Delay Functions" [1]. In short: If you take the pbkdf2 key derivation function: its job is to slow down hashing a thousand fold or so, so that hashing an entire search space becomes impractical. You give your secret in input, and it gives you a hash, let's say, in 1 second. You'll have to spend the time again to recompute the hash. With a faster machine, you can compute in maybe 100ms, but still, there is a limit in how fast you can obtain the result. Now change the cryptographic properties of pbkdf2, so that you can go back from the output to the input in constant time, so you can find the secret from the hash in O(1). Then, it becomes useless for actual secrets, but you now have an instantly verifiable proof that a certain amount of time (or serial computation) had to pass to get from the input to the output. Plug the input to the previous block hash, and embed the result in the next block, and you have your clock, based on physics and provable historical facts. [1] https://vdfresearch.org https://vdfresearch.org
- lilyball 5y ago
  The site isn’t particularly accessible for a quick discussion so I appreciate your explanation, thank you. However, I’m not sure I understand how this is supposed to help. Proving that a few seconds passed just slows down block generation a little, but this cannot be a significant barrier to block generation or else you just have a full PoW system again. And if it’s not a significant barrier then it’s not clear to me what this is supposed to do, beyond preventing me from generating and signing a new block within milliseconds of some event happening. But since the “nano scale” PoW doesn’t define the rate of block generation, it just establishes a lower bound, it feels like it’s just a speed bump for anyone trying to attack the system. If it only takes 10 seconds to rebuild the last 100 minutes worth of blocks, then it doesn’t establish a universal clock and therefore cannot prove which block came first.
  - inter_netuser 5y ago
    all VDF does is solves the problem of pseudorandomness being manipulated. Said randomness is needed to elect the new quorum who will build the new block. This does absolutely nothing with the fact that you need 66% honest stakers in the system for it to remain secure.
  - light_cone 5y ago
    With VDF you cannot rebuild the 100 minutes worth of blocks in less than 100 minutes, because with the VDF logging, you just proved that you would need at least 100 minutes to go from block n to n+(100 minutes). You can check in 10 seconds, but can only produce in 100 minutes, just like you can check in an instant that a bitcoin block starts with enough zeroes. So it defines the rate of generating blocks. Of course, nothing can stop anyone from creating parallel 100-minute long branches if that was the only thing, as, unlike PoW, it does not cost anything (except time) to create branches. So you still need a consensus mechanism, a way to, as an agent of the network, decide what is the right branch. On bitcoin, it is very simple: go to the longest chain, it's where the majority of mining power went, so that is clearly the consensus (with 1 joule = 1 vote). On ethereum, it's much more complex, involving promises with money at stake locked somewhere, so that anyone can detect cheaters, automatically unlock and take their money as punishment, and reward the whistle-blower with it. So, unless everyone is foolish enough to watch their money seized by the network, it does not happen. The exact way the correct branch is decided is by random election of one staker, where the randomness is proved to be actually random. After all, using a VDF, you can now prove that its output won't be known until x seconds have passed, if you put the most recent block hash as input. So during that time, you can agree on an fair pseudo-random election algorithm that will take this VDF output as a seed when it becomes available.

light_cone 5y ago

The clock issue is an excellent point, but the ethereum PoS have a nano scale PoW mechanism for this exact problem. Look at VFD "Verifiable Delay Functions" [1]. In short: If you take the pbkdf2 key derivation function: its job is to slow down hashing a thousand fold or so, so that hashing an entire search space becomes impractical. You give your secret in input, and it gives you a hash, let's say, in 1 second. You'll have to spend the time again to recompute the hash. With a faster machine, you can compute in maybe 100ms, but still, there is a limit in how fast you can obtain the result. Now change the cryptographic properties of pbkdf2, so that you can go back from the output to the input in constant time, so you can find the secret from the hash in O(1). Then, it becomes useless for actual secrets, but you now have an instantly verifiable proof that a certain amount of time (or serial computation) had to pass to get from the input to the output. Plug the input to the previous block hash, and embed the result in the next block, and you have your clock, based on physics and provable historical facts. [1] https://vdfresearch.org https://vdfresearch.org

lilyball 5y ago
The site isn’t particularly accessible for a quick discussion so I appreciate your explanation, thank you. However, I’m not sure I understand how this is supposed to help. Proving that a few seconds passed just slows down block generation a little, but this cannot be a significant barrier to block generation or else you just have a full PoW system again. And if it’s not a significant barrier then it’s not clear to me what this is supposed to do, beyond preventing me from generating and signing a new block within milliseconds of some event happening. But since the “nano scale” PoW doesn’t define the rate of block generation, it just establishes a lower bound, it feels like it’s just a speed bump for anyone trying to attack the system. If it only takes 10 seconds to rebuild the last 100 minutes worth of blocks, then it doesn’t establish a universal clock and therefore cannot prove which block came first.
- inter_netuser 5y ago
  all VDF does is solves the problem of pseudorandomness being manipulated. Said randomness is needed to elect the new quorum who will build the new block. This does absolutely nothing with the fact that you need 66% honest stakers in the system for it to remain secure.
- light_cone 5y ago
  With VDF you cannot rebuild the 100 minutes worth of blocks in less than 100 minutes, because with the VDF logging, you just proved that you would need at least 100 minutes to go from block n to n+(100 minutes). You can check in 10 seconds, but can only produce in 100 minutes, just like you can check in an instant that a bitcoin block starts with enough zeroes. So it defines the rate of generating blocks. Of course, nothing can stop anyone from creating parallel 100-minute long branches if that was the only thing, as, unlike PoW, it does not cost anything (except time) to create branches. So you still need a consensus mechanism, a way to, as an agent of the network, decide what is the right branch. On bitcoin, it is very simple: go to the longest chain, it's where the majority of mining power went, so that is clearly the consensus (with 1 joule = 1 vote). On ethereum, it's much more complex, involving promises with money at stake locked somewhere, so that anyone can detect cheaters, automatically unlock and take their money as punishment, and reward the whistle-blower with it. So, unless everyone is foolish enough to watch their money seized by the network, it does not happen. The exact way the correct branch is decided is by random election of one staker, where the randomness is proved to be actually random. After all, using a VDF, you can now prove that its output won't be known until x seconds have passed, if you put the most recent block hash as input. So during that time, you can agree on an fair pseudo-random election algorithm that will take this VDF output as a seed when it becomes available.