Unless

you have been living under a rock, or perhaps you are new here, you may know that the main architect of Steem quit in a quite spectacular way working for Steemit, saying that he felt that working on a project with the type of licence that Steem used to have was a mistake.

Note that this has changed now. In theory, there is nothhing stopping anyone forking Steem and starting a new Steem blockchain. Just like that. Well, this is what Dan is now up to, and he's about where Steem was around february or so last year: http://www.coindesk.com/eos-unpacking-the-big-promises-behind-a-possible-blockchain-contender/ Of course Tone Vays has weighed in with his expert skepticism about it - he says that both Bitshares and Steem were really just ways for a small clique to get rich... and it is my view that the outcome of Larimer's design, not the central parts but more peripheral parts indeed did this - the old rewards curve before HF19 *did* make the power of the small group of early big investors excessively powerful on the platform. This idea about the rewards is 100% Larimer, and I think Steem had to be rid of him before it was going to get fixed. Because this subject is very interesting to me, I am going to read the EOS whitepaper, in order to understand his parallelisation protocol. I am working on my own design, as my readers would know, although I've put it on the backburner, and I think that Eric Freeman's masters thesis https://brage.bibsys.no/xmlui/handle/11250/2413908 - which uses reliable message passing systems (with multiple nodes processing gossip and voting on whether every validator participating for processing a transaction), must arrive at a very strong consensus, very quickly, mainly by ensuring the same transaction is not being forked across the network). Basically taking the high tempo of block production similar to steem, except throwing out the 'block' concept and distributing the database both from logs, periodic recaps of the recent past transactions, as well as the backend databases directly synchronising with each other, instead of downloading and replaying a blockchain into the database. ### So what do I think about this? Well, Larimer's two previous projects turned out pretty good, although they have not been without problems. But personally, I think that smart contracts are a dead end, in terms of their robustness and resilience. It simply is not smart to be running so much potentially malicious software in a distributed way like this, without really good testing. In my opinion, smart contract blockchains will never get out from underneath the DAO hack issue, because the design specifically permits anyone to distribute code that other machines will run. This is extremely naive, in my view, because there still is not really useful artificial intelligence code for analysing code for what is called 'Correctness' in computer science, and letting just anyone put code which potentially could be a trojan for a mass robbery, and run it willy nilly... it's stupid, really, I don't think it will work. It's too enthusiastic in a field where precision and accuracy is vital. Do you really want to trust your money to a system where anyone can just write code that might potentially find a hole in the execution environment that allows it to perform any number of malicious acts upon the accounts of other users? It was bad enough when it started to beecome clear that there seemed to be 'unintentional' agendas behind parts of the Steem consensus, to have this kind of mischief going on with my quite hard earned tokens - but at least with Steem, because a number of folks with integrity were running witnesses, and had a lot of clout so much so they could temporarily suspend the distorted rewards scheme, that eventually forced this bad code to be removed and replaced with good code that represented what the majority of users wanted. Much better are, in my opinion, the type of 'hard coded' smart contracts like the Steem network consensus. These are much better tested, and do not seek towards an excessively fast development of new variants. I am waiting, but I don't think I will have to wait that long, to read about malware on the Ethereum blockchain, and while Larimer's concept of minimum balances and zero fee transactions is definitely an advancement, exposing your server to running random other people's software, in my view, it's like a windows machine, with no firewall, and more than a year out of date, just waiting for some hacker to hijack it and turn it to nefarious purposes. This is something that can't happen with the witness-activated-hard-fork protocol that Steem uses when the code changes. It is possible that someone may attempt to inject malicious code into an open source codebase, but if it is found, and it is likely to be, especially when the project is young and exciting, the worst that might happen is a hardfork has to be rolled back. Smart contract systems, like ethereum, on the other hand, are automatically accepting new, untested, untrusted code, and there is no guarantee that they have nailed all the hidden bugs that could turn into exploits. Lastly, in general, businesses generally develop forms that embody protocols for executing some kind of multi-party activity, that is to say, there is no reason why there can't be smart contracts, I am just saying that we don't need infinite possibilities in them, all the time, but rather, that you can build proforma contracts, with code that you initially sandbox more strongly, or at least, allow a second phase to the Witness Activated Hard Forks, where they can optionally reverse their consent within some specified cooling down period during which it is expected that glitches can be spotted and these faults halted and reversed in order to fix the code. I was hoping that Larimer had the sense to realise that a content monetisation system was where the future of this was, just like Steem's initial concept, but instead he's going 'me too' on ethereum, because he thinks he's smarter than Vitalik Buterin. I think they are both silly. ## PS I have just been reading through the EOS whitepaper, and there is nothing new to see regards to the consensus protocol compared to Steem and Bitshares. There was a little hint that maybe they would change the block reward to be proportional to votes, but not a direct statement to that effect at least in the beginning parts of the document. After reading a little so far, I can see that there is not any substantial new ideas in EOS, it's just, mostly, from an architecture perspective, cut and paste from Steem. However, I am just started reading it, and I will read the whole thing. I am not convinced that the ability to run arbitrary code on witnesses is a necessary thing, the consensus code in the core is far better tested than smart contracts that anyone can code, and new applications are simply additions to the data types and queries in the database, nothing more. My personal direction in this area is instead to break the chain down as much as possible into interconnected components that stand largely by themselves. Account registry, consensus protocol, cluster membership protocol, and a back-end database that can be replicated, even with version changes, unlike for example the graphene database underpinning Steem, which must regenerate the database from the chain, when it would be much quicker to synchronise if the shared memory structure did not change with versions, and a bittorrent-like distribution mechanism could allow an out of date version to be very quickly updated, without the overhead of downloading a block log. I also want to throw out the idea of blocks, and I believe this will be possible, by using gossip and epidemic protocols for distributing the data. The issue I want to resolve is that there is 'hidden' parts in the system that I think should be exposed, like the shared memory data format, for example, and I believe I can eliminate as much latency as is possible, below 1.5 seconds even, by using a protocol that requires clients posting transactions to send the identical tx to every validator in the network, or some defined consensus subset based on geography, and confirming a transaction requires 3 messaging cycles, followed by propagation to non-privileged nodes that provide database query services. and lastly, I want to have the backend database accelerated by GPU's. The cost of providing database query services is not accounted for in Steem, and probably not EOS either, and as an experienced operator of `steemd` I can assure you, the cost in terms of time, resources, of providing a Steem RPC node - without any way to directly monetise this, it's always going to be a chokepoint for scaling the network. But I'll reserve my full commentary on it to after I finish reading the whole text. ### finished! Yes, I finished reading through the whole whitepaper. It basically is like taking Steem, removing the blog, and adding ethereum style smart contracts, running on virtual machines. I don't think that Dan has really covered the cost of delivering the service of running those scripts in his concept, and I think, personally, that he's leaving the space he is good in, to try and one-up Vitalik Buterin and his scheme. I think it probably will work pretty well, but I don't think that implementing smart contract script execution is really that high up down in the hierarchy of what is important in distributed systems used by people to benefit their situation. We'll see how it goes, and I wish him well, but I personally think this kind of intensive generalisation is really going to be as secure or stable, or resource efficient, than highly focused, binary code that is (ostensibly) running on all nodes involved in replicating the state of the database. I believe that Dan made a big error in leaving Steemit, but at the same time, I was there, I saw what was going on (not in steemit, i mean here, in the community) when it happened, and I shortly afterwards had a hissy fit over a number of unresolved issues that were not just my own opinion. Well, I'm back now... and my witness is back up and running, in a fairly meagre capacity, but enough to do the job, so, if you don't know how to do it, and want to support my work, visit my updated #witness-category post https://steemit.com/witness-category/@l0k1/how-to-vote-for-l0k1-s-witness and if you have any issues, feel free to email me at l0k1@null.net or message l0k1 on the steemit chat.