4 ms·

> so once Ethereum finishes its switch over to proof-of-stake Isn't there a lot of uncertainty as to how well proof-of-stake will work?

danielvf 5y ago
ETH2 (proof-of-stake) already has 16 billion dollars of ETH locked into it, and has been running for months. The proof-of-stake switchover seems to be on a good track and should work form technical standpoint.
- deleted 5y ago
  [deleted]
- dvh 5y ago
  Python 3 is better than python 2 and people will soon switch.
  - chrisco255 5y ago
    Programming language upgrades are not the same as blockchain upgrades. Blockchains work on consensus, so you need a majority of nodes to agree with your changes to the chain or you risk a hard fork. At any rate, ETH2 proof-of-stake is already live, the last remaining piece is The Merge, which merges the existing proof-of-work chain into the already live and operational ETH2 proof-of-stake validator nodes.
  - viraptor 5y ago
    People have largely switched already. Py2 is gone from default installs these days. So yes, even if it takes a while, people often do switch to better solutions.
    - Judgmentality 5y ago
      https://dev.to/hugovk/python-version-share-over-time-6-1jb8 https://dev.to/hugovk/python-version-share-over-time-6-1jb8 It seems like Python 2 is still pretty prevalent, with over 40% of new downloads taking place as of last year. And people forget Python 3 was originally introduced in 2008. So the transition is taking decades, not years. The last place I worked was still using Python 2 as of last year, and they were a startup without all the bureaucracy of a big company. They also had plenty of money and engineers. Python 2 is still the default for everybody I know.
      - jreese 5y ago
        PyPI stats for "six", the second most popular package, that's used for 2/3 compatibility in tons of libraries, shows 80% of its millions of daily downloads are for Python 3. [1] The proportion for "requests", a building block for a ton of long-standing packages, is even higher. Anyone using Python 2 at this point are either supporting legacy software, getting their runtimes/packages from distros rather than PyPI, or otherwise completely checked out of the modern Python ecosystem. 1: https://pypistats.org/packages/six https://pypistats.org/packages/six
      - imtringued 5y ago
        There are people who are not using segwit on Bitcoin even though it means they spend twice as much on Bitcoin transaction fees. https://transactionfee.info/charts/payments-spending-segwit/ https://transactionfee.info/charts/payments-spending-segwit/
      - takeda 5y ago
        That statistics end at most interesting time: December 2019. Starting with January, python 2 was officially EOL, and many packages dropped support for it. Right now developing for Python 2 is kind of tough, because most dependencies won't work.
  - dcolkitt 5y ago
    Well if Python 2 had a logic bomb that literally makes it unusable after the end-of-life date, that would be true.
    - takeda 5y ago
      It kind of has. I mean if you don't touch your code it will continue to work but if you have to maintain it, you quickly realize that a lot of your dependencies will refuse to work. It might be easy to fix them to work again, but with time it will be more and more work to do.
    - Taek 5y ago
      Ethereum's original logic bomb was set to trigger in 2017. Then later it was updated to trigger in 2017. And then later it was updated to trigger in 2018, and then 2020, and currently I believe it's set to trigger in 2022. But there's no political reason to believe that they won't just push it out again. It's just a ceremony at this point.
chrisco255 5y ago
No, proof-of-stake has been live since December. The final remaining migration is The Merge, which is estimated to occur towards the end of this year, March 2022 at the absolute latest. For more info, see: https://ethmerge.com/ https://ethmerge.com/
wyager 5y ago
It's the kind of thing where if it fails, it's going to fail explosively and unexpectedly. Proof-of-stake is vulnerable to various miner collusion attacks that Bitcoin is not vulnerable to. The gist of it is that casting multiple conflicting votes (sometimes way after you cast your original vote) doesn't require any additional resources in a proof-of-stake system, whereas casting additional votes in a proof-of-work system is very expensive.
- 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 ago
    Network 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 ago
      I'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 ago
        Nodes 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.

danielvf 5y ago

ETH2 (proof-of-stake) already has 16 billion dollars of ETH locked into it, and has been running for months. The proof-of-stake switchover seems to be on a good track and should work form technical standpoint.

deleted 5y ago
[deleted]
dvh 5y ago
Python 3 is better than python 2 and people will soon switch.
- chrisco255 5y ago
  Programming language upgrades are not the same as blockchain upgrades. Blockchains work on consensus, so you need a majority of nodes to agree with your changes to the chain or you risk a hard fork. At any rate, ETH2 proof-of-stake is already live, the last remaining piece is The Merge, which merges the existing proof-of-work chain into the already live and operational ETH2 proof-of-stake validator nodes.
- viraptor 5y ago
  People have largely switched already. Py2 is gone from default installs these days. So yes, even if it takes a while, people often do switch to better solutions.
  - Judgmentality 5y ago
    https://dev.to/hugovk/python-version-share-over-time-6-1jb8 https://dev.to/hugovk/python-version-share-over-time-6-1jb8 It seems like Python 2 is still pretty prevalent, with over 40% of new downloads taking place as of last year. And people forget Python 3 was originally introduced in 2008. So the transition is taking decades, not years. The last place I worked was still using Python 2 as of last year, and they were a startup without all the bureaucracy of a big company. They also had plenty of money and engineers. Python 2 is still the default for everybody I know.
    - jreese 5y ago
      PyPI stats for "six", the second most popular package, that's used for 2/3 compatibility in tons of libraries, shows 80% of its millions of daily downloads are for Python 3. [1] The proportion for "requests", a building block for a ton of long-standing packages, is even higher. Anyone using Python 2 at this point are either supporting legacy software, getting their runtimes/packages from distros rather than PyPI, or otherwise completely checked out of the modern Python ecosystem. 1: https://pypistats.org/packages/six https://pypistats.org/packages/six
    - imtringued 5y ago
      There are people who are not using segwit on Bitcoin even though it means they spend twice as much on Bitcoin transaction fees. https://transactionfee.info/charts/payments-spending-segwit/ https://transactionfee.info/charts/payments-spending-segwit/
    - takeda 5y ago
      That statistics end at most interesting time: December 2019. Starting with January, python 2 was officially EOL, and many packages dropped support for it. Right now developing for Python 2 is kind of tough, because most dependencies won't work.
- dcolkitt 5y ago
  Well if Python 2 had a logic bomb that literally makes it unusable after the end-of-life date, that would be true.
  - takeda 5y ago
    It kind of has. I mean if you don't touch your code it will continue to work but if you have to maintain it, you quickly realize that a lot of your dependencies will refuse to work. It might be easy to fix them to work again, but with time it will be more and more work to do.
  - Taek 5y ago
    Ethereum's original logic bomb was set to trigger in 2017. Then later it was updated to trigger in 2017. And then later it was updated to trigger in 2018, and then 2020, and currently I believe it's set to trigger in 2022. But there's no political reason to believe that they won't just push it out again. It's just a ceremony at this point.

chrisco255 5y ago

No, proof-of-stake has been live since December. The final remaining migration is The Merge, which is estimated to occur towards the end of this year, March 2022 at the absolute latest. For more info, see: https://ethmerge.com/ https://ethmerge.com/

wyager 5y ago

It's the kind of thing where if it fails, it's going to fail explosively and unexpectedly. Proof-of-stake is vulnerable to various miner collusion attacks that Bitcoin is not vulnerable to. The gist of it is that casting multiple conflicting votes (sometimes way after you cast your original vote) doesn't require any additional resources in a proof-of-stake system, whereas casting additional votes in a proof-of-work system is very expensive.

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 ago
  Network 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 ago
    I'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 ago
      Nodes 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.