Personally I am most excited for the lightweight Nim client by Status. Ethereum in an app could drive massive adoption especially if it is effortless to set up and has real capabilities for funds transfer and possibly other utility like messaging. The technology choice of Nim is also excellent. lMO If people are smart and want to fund decentralization then they will allocate to that project.
Good news from Status:
"We're moving ahead with a proof of concept beacon chain implementation for December, which should turn into a beacon chain client by the end of March 2019 - by then, we aim to have it connect to all other beacon chain clients out there."
Client diversity is pretty important, if you have one client with a bug you can easily switch out and use another one. But if you have everyone using one client only , ex : bitcoin core then if a bug appears you cant address it without breaking consensus for the whole system. This has been the case with bitcoin where bugs have been found but since everyone uses it , its not possible to fix it without breaking consensus
but the bugs dont get spotted because people dont have time to work for free and check/audit code of 8 repos for each and every fork/implementation.
honestly, ethereum (ecosystem) has been having as many bugs as the whole crypto ecosystem combined (not bashing, just making a statement).
i believe that having 8 teams is possibly a bad strategy and this should be debated.
imo another argument would be that if theres 8 implementations nobody will be looking at any code but theirs. if theres 2-3 repos max, then more eyes will be on the same code, making bugs less lkely.
possibly, parity has has bugs that havent been spotted * because* of this strategy, not in spite of it.
because nobody has time to read code of 8 repos for free as a volunteer.
other projects who have less devs than us are maing progress while we move at a snail's pace, partyi and praising ourselves as if we have achieved the big milestones... well, we have not.
it just sucks to see other projects with less devs make more progress than us because of lack of concentrated effort and the overly messy and distributed nature of the development process.
and yes, i do get it that theres endless possibilities and permutations possible in ethereum but we gotta stay focused somewhere.
You didn't read it, did you?
>Not seeing client development as a competitive process, Jordan highlighted that multiple different client implementations is a great necessity on the ethereum blockchain.
>“The reason is that when you’re working on a blockchain like this, you want as much decentralization of implementations. So for example if the ethereum blockchain is running on Prysm and there’s a bug in Prysm, everyone can just switch to \[another client\]. You have options,” said Jordan.
i didnt no..was just before sleep.
still...i am really wondering if theres something we can do to speed things up.
we have tons of very hard problems besides scaling. will take maybe 20 years to solve a decent chunk of the problems.
It's not totally solidified, but I wouldn't say this is accurate the spec so far. From a conceptual point of view, if you can bidirectionally burn an asset on 1 chain and move it to the other, then they aren't different coins, they are the same coin. Saying ETH 1.0 and 2.0 will be different coins is like saying ETH on shard 412 and ETH on shard 851 are different coins as well.
>You don't need to do it right away
Phase 0 will allow prospective validators to burn their ETH on the PoW chain which will be added to their staking balance on the beacon chain. Phase 1 will allow those validators to withdraw that ETH to a shard, and will allow people to transfer ETH between shards. The PoW will also likely be treated as a shard, so people can transfer ETH to/from it.
The process of burning ETH on 1.0 to 2.0 is done when validators send their eth the registration contract. When the beacon chain sees that transaction on the PoW chain, it adds that amount to their balance. Most people will never do this process to move their ETH
I'm kind of imagining that it would make sense for them to make the Eth 2.0 genesis block contain exactly the state of Eth 1.0 at some specific prearranged block. Obviously there would have to be some delay between taking that snapshot and starting up the new chain, but I can't imagine an instantaneous changeover with such a big set of changes (which isn't to say that it isn't possible, though.)
That's not how it'll work. In the early phases, ether is moved from the PoW chain to the beacon chain when validators send it to the staking contract for registration. When the beacon chain sees their deposit, it adds it to their balance on the beacon chain . Later on, Eth will likely be able to move to/from the PoW chain and the shards as if the PoW chain was just another shard.
Cool, thanks for the clarification! So Eth 2.0 will be a manual opt-in process, effectively? It's not a "do nothing and your ether will be fine" situation, since the PoW chain could easily go extinct after a while, and if you hadn't moved it to a PoS shard by then (via the beacon chain?), you'd be out of luck?
There are no plans to ever deprecate the PoW chain. The specs aren't finalized, but the most likely thing that'll happen is the PoW chain will exist indefinitely (likely with lower block rewards and some of the security coming from beacon chain voting from validators) and once full Casper+Sharding is available, people will be able to move their eth between the PoW shard and the other shards.
I'm eager to see the spec locked down, too! But we shouldn't rush the spec finalization out of eagerness. Also, waiting until it's final before trying to implement it would be a mistake.
A spec doesn't solidify in a vacuum, the interesting challenges happen when you try to implement it. The clients who have started implementing it are (or should be) comfortable with that flexibility, and the opportunity to give feedback to the research team. Client devs who aren't comfortable with that are blocked, wish is fine.