Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
spectrum.ieee.org
Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
1–10 of 301 posts
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#2Some POS chains like Avalanche have nodes that can run on little more than an RPI.
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#3Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#4It's nice that the IEEE is waking up to this fact in 2021. We've had POS, low-energy requirement for a while now. Some POS chains like Avalanche have nodes that can run on little more than an RPI.
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#5They don’t need to be, but it gives the best security guarantees. PoS is subject to threats that don’t exist for PoW, e.g. https://news.ycombinator.com/item?id=27672759 .
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#6They don’t need to be, but it gives the best security guarantees. PoS is subject to threats that don’t exist for PoW, e.g. https://news.ycombinator.com/item?id=27672759 .
what qbout zkp or vdf extensions to pos?
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#7It's nice that the IEEE is waking up to this fact in 2021. We've had POS, low-energy requirement for a while now. Some POS chains like Avalanche have nodes that can run on little more than an RPI.
avalanche is nice. but it it is solidity. afaik solidity prevents scalability by assumption of global mutable data access in single transaction.
It is currently the most visible part because most of the protocol's features are still under development.
But the Avalanche protocol itself isn't tied to the EVM or Solidity, it is designed to let you run any customized blockchain.
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#8Proof of Stake has a startup issue that Proof of Work doesn't have.
If you want to have your coin begin as proof of stake you have to have some mechanism for how the initial coins are distributed and that method is usually going to involve the creators giving themselves a lot of coins. A lot of crypto projects have all sorts of ways of obfuscating this or claiming that the intial coins will be destroyed or whatever, but I don't think that anyone has really succeeded in establishing trust on a large scale for this yet.
The other method of getting Proof of Stake going would be migrate an existing Proof of Work coin. This is like what Etherium 2.0 is trying to do.
The problem with that is that it's never going to be in the interest of the miners to actually change to it. Etherium 2.0 has been supposedly just around the corner for years and it never really arrives.
Proof of Work on the other hand doesn't have this issue. The creator has the same ability to mine coins as anyone else does, so it doesn't have the same initial trust issues as Proof of Stake does.
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#9I'm not really convinced. Proof of Stake has a startup issue that Proof of Work doesn't have. If you want to have your coin begin as proof of stake you have to have some mechanism for how the initial coins are distributed and that method is usually going to involve the creators giving themselves a lot of coins. A lot of crypto projects have all sorts of ways of obfuscating this or claiming that the intial coins will…
Miners have no way to stop a hard fork. That is entirely dependent on what client users and service providers run, and miners have no control over that.
And Ethereum 2.0 has already launched its Phase 0 (first of three phases), on December 1st, 2020.
Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive
#10It's nice that the IEEE is waking up to this fact in 2021. We've had POS, low-energy requirement for a while now. Some POS chains like Avalanche have nodes that can run on little more than an RPI.
avalanche is nice. but it it is solidity. afaik solidity prevents scalability by assumption of global mutable data access in single transaction.
https://docs.fuel.sh/v1.1.0/Future%20Roadmap/Planned%20Featu...