'The issue which has swept down centuries and which will have to be fought sooner or later, is The People -v- The Banks'

Saturday, 24 June 2017

#ETHEREUM DIFFERENCES & SIMILARITIES #LISK

Two of the coins the most compare.

And finally, an in-depth page, where Lisk -v- Ethereum is all laid out.

Extracted

"1. Programming Languages

Lisk: Javascript vs Ethereum: go, C++, rust, Solidity, Serpent, etc.

Lisk

One of the things that Lisk heavily promoted prior to their presale was the fact that their Dapp are in Javascript, "the most popular language in the world." In fact, they marketed (via reddit advertisement)[1] themselves as "The Ethereum Alternative for Javascript developers".

Their entire system is 100% javascript. Node.js for the backend. The frontend. They do have a database -- SQLlite, originally. Now postgresql.

Ethereum

Smart Contracts for Ethereum are in Solidity or Serpent. Solidity is very similar to Javascript, but is custom made for smart contracts. It is extremely easy to read these contracts and understand what they are doing. There are also some big reasons to use a custom language over Javascript (discussed below) when it comes to contracts that move currency, store value, and need to reach consensus. This page, while no longer being maintained, has some excellent points about what Solidity is, if you want to learn more.

I don't know as much about Serpent, but it appears to have the same goals and purpose as Solidity, but is meant to be similar to Python (and therefore be great for Python devs.) This, along with the range of clients, also showcases the dedication that Ethereum has to being appealing to a wide range of developers, not just Javascript developers.

Above only covers Smart Contracts for Etheruem; what about the more fully-encompassing "Dapp"? Well, it's pretty much Javascript for the UI of Ethereum Dapp. I recommend you read ConsenSys's writeup here, specifically Part II. Basically, you have:

Truffle (JS, Sass, ES6, JSX are built-in)

Embark (which is JS)

Meteor (web3.js + meteor (which is also JS))

and more are coming.

Conclusion

So, for Lisk to be implying that Javascript developers cannot create Dapp for Ethereum is a bit misleading. They can absolutely use primarily Javascript for the Dapp and then Solidity (which is so close to Javascript) for smart contracts. The blog post referenced above says is succinctly:

Learning a new language syntax is trivial compared to learning how to avoid the millions of ways you can shoot yourself in the foot.

The difference is that Lisk is entirely Javascript (and node.js) through and through, Ethereum has a large number clients in different languages[2], has two custom-written languages for smart contracts, and still allows for Javascript where you need it most (the UI).

2. Disadvantages of Javascript

What some people don't realize is that Javascript, while being extremely popular, does not automatically make it the best solution. As I said above, the difference between Ethereum and Lisk here is that Lisk is 100% Javascript while Ethereum has a ton of languages & lets Dapp developers use Javascript for the UI and Solidity for smart contracts on the blockchain. With that, here are some potential flaws with Javascript on the blockchain:

Javascript numbers are....not the greatest or most reliable. Additionally, when we are dealing with a crypto-currency, you really want your numbers to be on point. Basically JS uses floating point which means some things get approximated and digits get lost in certain cases. Even little things like floating point numbers can break consensus. Here's some further reading: Be careful with big numbers & Floating point appoximation. So, the fact that everything in Lisk (including Lisk itself) is in Javascript, it means there are potentially big number problems (both in terms of big numbers and big problems.)

Lisk has "rules" that they ask contract developers have to follow to avoid breaking consensus. This includes things like "don't use Math.random()". With Ethereum, you don't have to have rules. The code will not compile if you try to do something wrong. (FYI, you don't compile Javascript.) On Lisk, if you do use Math.random(), it breaks.

Javascript uses weak dynamic typing. If you are not careful, you can pass strings instead of numbers. One of the major differences between Solidity and Serpent and Javascript is that Solidity and Serpent are both strongly typed. Wikipedia on strong vs weak explains it thusly:

A strongly typed language is more likely to generate an error or refuse to compile if the argument passed to a function does not closely match the expected type. On the other hand, a very weakly typed language may produce unpredictable results or may perform implicit type conversion.

Since Ethereum is running contracts on the blockchain and Lisk is sort of running Dapp on the blockchain (sidechain?), you could see why having a weakly typed language could result in problems, specifically regarding consensus. It is much better to know the problem before it turns into an immutable thing on the chain, rather than discover all funds are trapped, or you fork the blockchain the first time someone tries to interact with it.

Additional flaws with Lisk include the fact that their "sandbox" cannot be used to run untrusted code and their framework provides no protections against non-deterministic behavior. From the blog post above:

Lisk faces can be resolved with a heavily customized JavaScript environment that removes floating point, implements software interrupts, instruction counting, and cleaner APIs for managing application state. Ultimately, creating a JavaScript compiler for the Ethereum VM might be less error prone than trying to patch a million nondeterministic leaks in JavaScript.

2b. Disadvantages of Solidity

As user Jehan pointed out, Solidity isn't perfect either.

There's little support for serialization and deserialization of any kind

It has an extremely anemic stdlib (has been recently updated significantly)

There is no way to pass an array of strings into a contract.

3. On the blockchain

In Lisk, the Dapps actually are not stored on the blockchain, like the smart contract bytecode is in Ethereum. Instead, you have external links to these Dapp. They like to compare their Dapp to the traditional "App Store" model (think Apple). Which, while appealing to some users, is less appealing when you realize they are literally using HTTP: links to .zip files.

With Ethereum, you have the code stored on the blockchain which means they can be audited and the code cannot be changed. It's kind of the entire purpose of having decentralized applications (IMO).

Lisk prefers to use a looser definition of "decentralized", meaning literally not stored in a central place, while Ethereum developers and users prefer to have decentralized mean something that cannot be corrupted, can be audited, cannot be changed, can reach consensus etc. [3]

4. Who is / was Lisk

One of the most common arguments by Ethereum lovers against Lisk is that Lisk (1) doesn't have a team of developers behind it and (2) originated as a failed alt-coin, Crypti that was abandoned by the devs (3) those devs that abandoned Crypti are the Lisk devs so (4) is this just a rebrand?

The main difference I see between Ethereum and Lisk here is that Lisk is two guys who rebranded a previous coin that had a pre-sale and delivered nothing while Ethereum has Vitalik Buterin, a large team of well-known, community-engaged, crazy talented developers, and a large community of developers working on the core code (everything is open-source), Dapps, and third-party wallets, etc.

Another key difference is Ethereum has the Ethereum Foundation, a non-profit Swiss organization and Lisk has....an unknown foundation / company associated with it.

[2] Ethereum is mind-blowing with the amount of languages / clients. At this point, we have: Geth (Go), WebThree (C++), PyEthereum (Python), Parity (Rust), EthereumJ (Java), Ethereum-Ruby (Ruby), NEthereum (.net). I see this as a major advantage for Ethereum and, as the Ethereum Team has pointed out, the fact that there are so many clients in so many languages have been invaluable in testing, bug-discovery, and ensuring consensus.