|
I think you basically ask the right questions. But when you have progressed in your understanding, and you're confronted with the next problem caused by PoS, you seem to assume that PoS is flawed, because you can't immediately think of a solution (which is expected, that's quite a hard problem). The reality is that the issues you mention are well identified and they have solutions for them. About VDFs, there is a tolerance, you need to be in the same ballpark as the fastest, not _the_ absolute fastest. The more tolerance you need, the less snappy the PoS blockchain will be. They plan to make a low-power asic for that task, to be as close as the theoretical max speed for that, and have the lowest tolerance margin as a result. Also, there is a way to reduce all VDFs results so that only one of the whole set of VFS-ers need to be honest. So it's not one volunteer, but a pool of volunteers, using low powered asics so close to the theoretical max (ie speed of transistor switching) that you couldn't outrun them enough to profit from that speed up. I am not sure if they are incentivized, because it's not costing a lot, but maybe. > Edit: I suppose the VDF's input might not be "the block being computed" but instead "the previous block", and the output then used to elect participants who are then trusted to build the new block. This would allow the new block to indicate whether the VDF actually took longer than expected. Indeed, that's what I thought I was saying, but maybe I was not clear enough. |