planned Updates
Metropolis
July 2017 (Expected)
"Although Ethereum does not have the best of track records when it comes to hard forks, the developers are quite optimistic about Metropolis. This milestone has been on the development roadmap for quite some time now, yet the project has had to be pushed back due to The DAO hack. Metropolis will offer some significant improvements to the Ethereum ecosystem, which can only be seen as a good thing.
First of all, the Ethereum protocol will be simplified, allowing novice users to get a more hands-on approach with this technology. It will also become possible for recipients to pay the gas cost for transactions, rather than only the sender. Plus, anonymization will be improved slightly, thanks to this change in the gas payment structure.
Light clients are an integral part of any cryptocurrency ecosystem. Not all users want to run a full wallet, some prefer a solution that synchronizes with the blockchain immediately. Metropolis will make light clients more secure, or at least try to do so once the hard fork goes live. A more than welcome change that will be appreciated by many Ethereum enthusiasts.
A lot more technical features will be implemented as well, although it remains a bit unclear as to how many of these upgrades will make it to the Metropolis release. Smaller updates can be added to the protocol at a later stage, as the ones requiring the hard fork are the top priority right now. Having the most important features in place will be the goal for the Metropolis development team, although no one is entirely sure when this hard fork will be implemented.
It is evident Metropolis will bring some aspects to Ethereum the community has requested for a while now. Addressing scalability, safety, and privacy are of the utmost priority for the Metropolis team, that much is certain. Enforcing better privacy protection through zk-SNARKs is quite an intriguing development as well. Moreover, the Ethereum developers are working together with the ZCash team to implement zero-knowledge proofs in the future.
On the scalability front, Metropolis will seemingly herald the introduction of proof-of-stake consensus. That is, assuming the proof-of-work mining difficulty bomb can be addressed by the developers. This particular feature makes it impossible to mine transactions over time, effectively forcing the switch to a new algorithm. However, due to The DAO hard fork implementation, this time bomb is ticking a lot faster than originally planned. All of this makes the switch to Metropolis even more important than before."
[Source]
Benefits await
"But when all's said and done, the Metropolis update will likely allow better ethereum applications to be created.
Stefan George, CTO of ethereum prediction market Gnosis, told CoinDesk:
”Having more abstraction always allows for more flexibility.”
For example, the added flexibility could allow a recipient or middleman to pay transaction fees rather than app users, he said.
This could be beneficial for users utilizing ethereum-based based apps, such as a notebook. Normally, the user would need to buy ether to make any change, such as adding to or deleting a note, but with the Metropolis upgrades, the provider can pay the fee and users can make changes without the extra step of buying ether.
Ultimately, this moves the ethereum protocol closer to the familiar experience of a traditional app store.
“I imagine we will get a lot more users using ethereum services this way,” George said.
George added that another Metropolis change will also help iron out some kinks for off-chain technologies that allow data to be lifted off the main ethereum blockchain, improving performance and scalability of the network without compromising users' security.
This adaptability will, again, put developers in control of their application designs.
As the Parity team put it:
"Metropolis is a significant step that improves the protocol and makes a few use cases that were previously unfeasible."
Correction: An earlier version of this article incorrectly stated a fact about ethereum's Geth implementation. This has been revised."
[Source]
Proof of Work
"In the near future, Ethereum plans to switch from Proof-of-Work (PoW) based mining to Proof-of-Stake (PoS) mining. While both PoW and PoS are algorithms for reaching consensus on the blockchain, they go about it in different ways.
Since anyone can create a block, there needs to be a way that everyone on the blockchain can reach consensus, deciding together what block accurately represents recent transactions across the network. Without a central authority, trust comes from creating consensus algorithms that are very, very hard to cheat.
Proof-of-Work
Proof-of-Work happens through miners trying to solve exceptionally difficult math problems. Finding a solution is basically a guessing game, but checking if a solution is correct is easy. Miners aren’t able to cheat the system because it takes real-world resources to work out these solutions.
That’s where a main issue with PoW stems from: these real-world resources are computers and electricity. It takes a lot of power to run the computers, or clusters of computers, that calculate different potential solutions. From an ecological standpoint, this isn’t ideal. This leads miners to have high energy costs and this is bad for the environment.
The fact that you need a serious amount of computing power, more than the average person could afford, or would even be able to work with, means the mining community is getting smaller and more exclusive. This goes against the idea of decentralization, and could potentially lead to a 51% attack.
51% Attack
A 51% attack is when a miner, or more likely a mining pool, controls 51% of the network’s computational power. With that ability, they could invalidate valid transactions and double spendfunds. They’d achieve this through creating and confirming their own fraudulent blocks, and do it so quickly, the rest of the mining community creating genuine blocks would have their legitimate work invalidated.
That’s where PoS could really help. Even if someone owned 51% of a digital currency, it would not be in their interest to attack something in which they have a majority share. Also, it’s very unlikely that anyone would be interested in buying up 51% of a currency, due to it being prohibitively expensive. According to game theory, those with a larger stake in a cryptocurrency should want to maintain a secure network. Any attack would only serve to destabilize the digital currency, diminishing the value of their stake."
[Source]
Casper
Late 2017 (expected)
Background
"In this proposed spec for stage 1 Casper, Ethereum will transition from pure proof of work to hybrid PoW/PoS. In this scheme, all of the proof of work mechanics will continue to exist, but additional proof of stake mechanics will be added, and the fork choice rule (ie. the way that a client determines which chain is "the canonical chain") will be modified to take these mechanics into account.
A "Casper contract" will be published at some address CASPER_ADDR, and this contract will include functionality that allows anyone to deposit their ether, specifying a piece of "validation code" (think of this as being kind of like a public key) that they will use to sign messages, and become a validator. Once a user is inducted into the active validator pool, they will be able to send messages to participate in the PoS consensus process. The "size" of a validator in the active validator pool refers to the amount of ether that they deposited.
The purpose of the PoS consensus process is to "finalize" key blocks called "checkpoints". Every 100th block is a checkpoint. In order for a block to be finalized, a subset of validators in the active validator pool with total size of at least two thirds the total size of the active validator pool need to send "commit" messages for that checkpoint. Once a block is finalized, the theory is that "one can never go back"; even if 99% of miners start supporting a chain that does not contain that block, clients will still accept that block as finalized.
The contract implements a set of rules called "slashing conditions"; these rules were carefully designed to have the property that if two incompatible blocks are finalized (eg. A and B are finalized where A and B are both children of C), then no matter how such a situation arises, there MUST exist some set of validators, with total size equal to at least 1/3 of some recent active validator set, which sent messages that trigger some slashing condition. If a validator does this, then "evidence" of this fact can be sent into the Casper contract, and the validator's entire deposit will be destroyed (except 4%, which is given to the evidence submitter as a "finder's fee"). Hence, reverting a finalized block is extremely expensive, likely more expensive than the cost of buying enough mining hardware to repeatedly engage in 51% attacks against the current PoW-only Ethereum chain forever."
[Source]
Proof of Stake
A Brief Summary of PoS
"Proof of stake, in the beginning, sucked. It had a couple very-bad-not-so-good flaws that led to some people deciding that there were fundamental flaws with PoS that could never be fixed. Mostly, these issues were the infamous nothing-at-stake problem and long range attacks.
I'll skip long range attacks for now (though it's worth learning about them), but will give a brief summary of the nothing-at-stake problem, as it is most relevant to this question.
Essentially, if there isn't an explicit punishment for validators signing-off on two different, conflicting chains, then it is in their best interest to sign off on both of them (as they now have more coins in all futures). Obviously, this is bad. We want our validators to converge on a single chain. Thus, the nothing-at-stake problem is an issue.
I'm not sure who really came up with the idea, but right around the same time, it seems that people behind Tendermint and researchers at the Ethereum foundation came up with the idea of security deposits as a way of "solving" the nothing-at-stake problem.
Essentially, validators now had to deposit the staking currency for some bonding period. This, combined with something called "slashing," effectively allows users (the only ppl who really matter <3 ) to be sure that the validators will not be able to create multiple, conflicting version of history without being punished.
For more reading about slashing conditions, see here for a fairly technical but very interesting blog post by Vitalik. TLDR; if you try and finalize two different chains, you will lose your deposited stake.
As a result, validators being slashed for bad behavior is dependent on them actually having deposits. This means that a long deposit period (aka, withdraw time) does two things. First, if validators do something bad, it is very likely that someone will catch them before they can escape with their ill-gotten rewards. Imagine if a validator could perform some action that was worthy of slashing for, but could then immediately withdraw their money and run away. We would have no way to slash them :(.
Second, it allows users to "trust" these validators for up to the length of the deposit period. Essentially, if the users go offline for some time, they can still rely on binding messages signed by these validators to help rebuild the state of this network when they come back. If validators didn't have deposits for this time, they could just lie to the user about what had happened when the user was gone, without any repercussions.
This is, IMO, kinda the main change in the security model between PoW and PoS (though PoS makes up for it with a variety of other lovely benefits). In the case of PoS, either you have to sync to the network at least every deposit period (so you can keep these guarantees given to you by the fact that validators deposits could be slashed by lying to you), or you need to find another starting point. This could be baked into clients during updates, gotten from a friend, or a block explorer, etc.
(As a side note, someone could build a service of "extra-long-validators" that are unable to withdraw their deposits on much longer time scales, and maybe get paid by light clients for doing so :) ).
Essentially, these long withdraw periods help make sure that validators can't do bad things without getting punished, and also allow users to have some guarantees even if they go offline for some time.
As for how long it is, not sure. I read an older proposal that said about 4 months, though that very possibly has been changed since.
P.S. I copied this from an earlier thread I wrote :) Sorry for the self-plagiarism."
/u/naterush1997 on r/ethereum
[Source]