RE: Blockchain Competition - the Fittest Wil Survive
In a skype chat I had with @ned way back in September, he talked about user issued assets, specifically in creating subunits that function like corporate departments, and issue their own tokens, and so forth. So it's been on the agenda for quite some time to add this feature. It also will assist in the emergence of more applications.
Yes, I think that Steem has the potential to beat out ethereum in this way. But there is one really big block in this - third party developers writing custom subchains and applications. The idea would be that they could build upon the Steem base and create their own customised schemes for rewards and distribution for posts under their section, as well as taking a cut that is used to fund the development of this subunit.
It's coming, for sure, and I agree that it will be what really pushes Steem forwards, right up into the top 3. There is also plans also very long back, to create market infrastructures, inventories, offer and acceptance, fulfilment systems and escrow schemes for payments. These are all things I envisioned back in 2013 when I first got into Bitcoin, which is why I am so attached to Steem. Ethereum is cool but after the hack and the way they dealt with the hard fork of the chain, I lost all respect for the team behind it. The fact that ETC is doing so well proves they were wrong.
@l0k1 this guy claims Ethereum with lightning speed with the "Raiden" network.
Do you think this will be as fast or could be even faster than Graphene?
Bit of topic, will Graphene based blockchain be able to reach less than second transaction times,closer to 100ms instead of 1sec in your opinion? The later is required when going into financial markets, not sure if required of payment solutions.
Again a bit of topic, I read somewhere recent stress tests with Graphene based blockchain (Bitshares?) the possibility to reach around 20k transactions per second; Although that sounds a lot, I come from the industry of SMS processing, and 20k transaction per second where already reached more than 10 years ago, using in memory processing and standard industry HDD in RAID configuration using Oracle DB and LDAP DB.
I think transactions could be processed faster, but really, how much faster than 3 (rarely 6) seconds do they need to be? Credit payment networks and national interbank payment systems rarely are faster than 5 seconds.
I also think that realistically, a global blockchain network can't really push it much under maybe 1 second anyway. Typical latency at the greatest distance between two points on the planet is between 200-400ms, which means that really, 800ms is probably the floor on possible speed increases.
I doubt that Ethereum can do it faster. Steem's code is all native, whereas a large amount of Ethereum code is in Serpent, an interpreted language, (JIT compiled) which means that it's probably got at least 400ms latency minimum and another 200ms at least to account for the slower execution via virtual machine. So, possibly, Steem could push it to even 1500ms, but again, what would be the point? It also further reduces the number of physical locations that servers can be running (next door to backbones, pretty much) which can't be a good thing.
Same goes for the hardware requirements. I am running my witnesses on KVM containers on 16 core Xeon servers with a lot of memory and SATA2 SSD drives. The price is bearable, quite low compared to many hosting services, but it will be a couple of years before this kind of capability becomes cheap as this for everyone. I don't think there is really a need to increase the block production cycle rate to below 3 seconds. We just may have to increase the block size, and unlike Bitcoin, we witnesses can do this if we develop a consensus that it is needed, no pestering Steemit, Inc. to enable this.
Aside from that, when Fabric is implemented, the blockchain will be a plurality, and possibly then, with the forum and ledger isolated from each other, the ledger schedule could be shortened to 1500-1000ms cycles.
Speed can be a differentiator. Bitcoin is to slow for payment solution, internet may be allowed a bit slower over in store payment systems. But also for instore payment system, probably 3 seconds is ok, although I find it quite slow. In the Netherlands we have a nation wide standardised in store payments solution that with the newest instore equipment will probable handle the end-2-end transaction in less than 1-2 seconds.
Where faster payments maybe required are at events and festivals where thousands to hundred thousands transactions are handled in just a matter of 10-12 hours. Today they work with physical coins, to get the speed into payment (there are other reasons as well for the physical coins, but no relevant here). When pushing these coins out for virtual coins, speed is required.
Also think of trading platforms, and do not only think of the current stock exchange or crypto currency trading platform, but any trading done from milk, grain to flowers etc. These type of trading generally requires instant reaction of the systems to get the best price, and to not get the competitor taking the goods away from you.
Yeah, I think that eventually the latency will be pushed down to 1 second. For the time being 3 seconds is enough. To squeeze that extra performance out of it will require quite a lot of work, I think. Especially things like splitting the network regionally so that transactions never have more than 100ms latency to the nearest RPC node to relay the transaction.
You make a good point about comparing it to other payment systems. It used to be until not log ago that all POS systems used freakin 56k dialup on leased lines! (ah... how secure!) but more and more they are going onto high bandwidth internet connections. And then cash? yeesh! It takes at least 10 seconds for a fast cashier to handle payments in cash. I think 3 seconds positions Steem for POS use cases for sure. But situations like you mention, festivals, with a squillion other mobile devices clogging up the channels... The problem there will not be the blockchain network but simply the latency of getting the signal out, and back through a congested channel. I don't think that there is any payment network that can solve that other than the POS devices being plugged into cables rather than using 3G/4G networks.
The big events bring their own mobile base stations in for the users, and big internet pipes for their own internet stuff. It is done more and more like that. Also at event the promoters do not want cash, since this cannot be controlled, mostly the catering is outsourced and the promoter gets a percentage of revenue, coins means: they can kind of control theft. Virtual coins would be fantastic for the promoters, no theft anymore, since all is recorded and realtime. Th realtime aspect of it provides information to re-direct flows of people to other bars. This is not only good for the commercial aspect of it, but also for safety of a crowd of for instance 100k people on a square km field. And we will get more and more of these large events!