That’s not the case with Ethereum - devs can’t do anything if miners don’t support them, and I don’t think the miners would alter the Ethereum blockchain because feds asked them to.
Ethereum is just as mutable as any other blockchain, and every blockchain is as mutable as its community lets it be at any point in time.
Maidsafe approach is smart and conservative. Staying under the radar has many advantages. You can basically underpromise, overdeliver, and most importantly test offline, not online. ETH will have to migrate to POS, and implement extremely complex solutions while the network is live. Expect Ethereum classic, Ethereum classic 1, Ethereum classic 2… along the road, and a few flash crashes like this one: 
I agree that it’ll be tough for Ethereum to adapt while running flat out… I hope it can go relatively smoothly, but Bitcoin has shown how much of a challenge it can be once groups with a lot at stake and differing opinions are involved.
However, I’m pretty sure that ‘flash crash’ was caused by a whale pressing the wrong button / being daft rather than due to Ethereum network congestion, as it doesn’t make any sense to sell like that & take a huge hit.
Given the volume that would be more than a million dollar fat finger mistake
Indeed. Someone must be very unhappy whether it was a ‘fat finger’ mistake or complete miscalculation of how the market would react to their big dump.
I doubt many people would have joined in on selling at those prices with the price remaining strong on other exchanges?
Whatever happened, it was bad for anyone who sold at that point, and a bargain for those with stupidly low priced buys in the order book!
edit: I see from the article that it was apparently a $30m market order sell… ouch! (maybe a whale got hacked?)
If you are good enough to hack a whale, you know better than selling at 13$
You’d have thought so, but between spite, revenge, and a number of well placed buy orders on other accounts, they may still have made a success from such an endeavour if they get away with it.
Ya, it isn’t really clear to me if this was an accidental fat finger trade or something more nefarious, but anyway it turned into a cascade of margin calls and limit orders. A lot of people got wiped out completely, while a few were able to make an instant killing picking up some ETH for pennies on the dollar.
Edit: Update on GDAX (just posted)
I’ve been trying to keep up over the last year with the development of sharding on ethereum and came across this interesting quote from Vitalik
“Each unit of ETH (and each object more generally) only exists on one shard at any particular time. … For an object to be transferred to another chain, you need a cross-shard transaction. This should take a few minutes to process.” source (emphasis mine)
Is there anyone here who knows enough about ethereum to say when and why a cross-shard transaction would be needed? Is this required for all / most transactions? My understanding is yes it is required, since shards are determined by address prefix so transferring to any address with a different prefix becomes cross-shard.
I guess it’s better to ask on the ethereum forum but it’s interesting because if the speed of settlement is ‘a few minutes’ it seems extremely poor compared to close group consensus. But I’m not sure if this comparison between sharding and close group consensus is fair or not.
There’s a ludicrous amount of jargon in sharding so it’s hard to fully grasp as a casual participant, but it really seems so distant from the SAFE design that I think unfortunately there’s almost zero chance of sharding providing meaningful input to the future design of SAFE.
I agree, I also find much of the Ethereum chat uses new or made up words in no particular order, which is a shame. In saying that a lot of the blogs Vitalic does are very well researched and easy to read. I do wish the tech community as a whole and in particular, the “crypto currency” community would stop that confusing chatter and communicate more effectively. I see us trying (hard) to keep is simple and it allows people to dive deeply. It takes a lot of our time to keep up with much of the chat, but 100% worth it. I wonder if much of the lingo used in some projects is to effectively block such interaction as that is what happens.
Cross shard transactions for us in any case would be covered by “secure message relay”. The basic premise is as a message crosses the network (shards) then each hop confirms the last hope (as they are known to each other). We don’t have good timings there, but it will likely be seconds. When pasec milestone 2 is done I think we will have a much better idea of consensus speed and then we can use that multiplier to work out network size and number of hops. So in the most basic case, we can estimate a worst case scenario. Ofc then we optimise the secure message relay itself, but I suspect even worst case we will be well within a users comfort zone.
It always struck me that trying to scale blockchains is much like trying to scale transactional relational databases. Read only is easy, but when data changes, synchronizing nodes is slow. This is one of the reasons why NoSQL databases have been gaining momentum and why I believe SAFENetwork will do the same vs blockchain. However, blockchain doesn’t have a ubiquitous SQL style language, nor a simple way to present complex data, which will make SAFENetwork even more compelling.
I’m not a total expert, but will give it a shot…
As you mentioned, shards would be divided up by address space. The idea would be that a certain contact, or set of contacts as is the case in most DAPPs, would live within a given shard (along with other DAPPs sharing that shard / address space). To interact with that contact, you need to have an account balance on that shard. As long as you and the contracts you are interacting with stay within that address space, then no cross shard communication is needed as all of the state information is available within, and stays within, that same shard.
The train and hotel problem on the sharding FAQ page is illustrating the train reservation contact living in a different shard than the hotel reservation contact, and how that complicates things.
The vision, I think, is that under most common cases, users will be interacting with a given DAPP that stays within its own shard, with the overall throughput of the network increased by having these shards executed in parallel.
My response begged the question How is the address of an Ethereum contract computed? I assume this method of calculating contact address would need to be updated to include a target shard ID or something, otherwise the creator would need to send a bunch of spam transactions to get to the nonce required to hit the proper shard.
Then that makes you wonder how the number of shards could be increased in the future without breaking all of the interlinked contracts…
Yes we don’t have good timings but I would not be surprised to see subsecond start-to-end network traversal in the routing layer, and even faster client-first-hop speeds than that (which is the only speed that matters to the experience of the end user). I base this on bitcoin transaction propagation times of approx 1.5s and bitcoin block propagation times of approx 10ms. It’s not right to do a straight-up comparison but it’s still in the right ballpark of conceptual similarity.
The current speeds measured in the Profiling Vault Performance topic show there’s a lot of room for improvement, which the parsec + gossip algorithm will provide, and then within those algorithms implementing targeted performance improvements will add a second boost to speed. I’m extremely optimistic about the network speed meeting user expectations. Not so optimistic for ethereum (based on my relatively beginner opinion…)
Vitalik with some comments on sharding and “layer 2 execution engines” Layer 1 Should Be Innovative in the Short Term but Less in the Long Term
This is a key difference, we don’t see these things as layer 2, but as fundamental components. So not add-ons but core technology. I suspect this is through what it means if you do need to hard fork to add new functionality, so perhaps only a semantic difference, however, I think not.
@mav - a good rundown of the Ethereum 2.0 roadmap on this podcast: The Let’s Talk Bitcoin Network: #263 Justin Drake: Ethereum’s Audacious Roadmap to Build a True World Computer http://feedproxy.google.com/~r/TheDailyBitcoinShow/~3/BEm7HZ70gns/epicenter-263-justin-drake-ethereums-audacious-roadmap-to-build-a-true-world-computer
Vitalik presents ZK rollups and layer 2 solutions using the blockchain for data availability, but computation off-chain.
