When should I find the time to explore all these languages? Most of them are barely used, making it incredibly hard to adopt them. Solidity is leading the pack, although, it’s not an easy language to get started with. This article will criticize and give new insights in the following platforms: Ethereum, Hyperledger Fabric, NEM, Stellar, iOlite, Neblio, and Lisk.
To give you an overview of all different existing smart contract platforms:
Finding The Right Smart Contract Platform
I will feature some existing smart contract platforms and some upcoming ones. I’ve selected these based on maturity, flexibility and the innovation they add to our ecosystem.
Ethereum — Old but Gold
Ethereum is always a safe bet. Ethereum is a gold standard in the world of smart contracts and has the biggest capitalization among other platforms. The majority of token sales happen on the Ethereum platform, using the ERC-20 token standard.
However, this standard has some serious bugs which have already led to major losses in the industry. Let me explain this.
ERC-20 assumes two ways of performing a token transaction:
But what if you use transfer() to send tokens to a smart contract by accident? The transaction will succeed but this transaction will not be recognized by the recipient contract.
“For example, if you send tokens to a decentralized exchange contract, then the exchange contract will receive your tokens but it will not credit these tokens to your exchange token balance. Moreover, if the decentralized exchange contract does not implement an emergency token extraction function, then it’s impossible to get your tokens back in any case, resulting in a permanent loss of the tokens. Due to this bug, the Ethereum ecosystem has lost millions of dollars already.”
This information is provided by Reddit user u/Dexaran (source article), creator of the ERC223 standard. Dexaran is the first developer who has notified the Ethereum community about the aforementioned bug. In response to this, he has created the ERC223 standard.
Most developers are not aware of this ERC223 and ERC77 standard. To give a short comparison of both standards:
ERC223: This improved standard resolves the ERC20 critical bug by making the transfer() function throw an error on invalid transfers and canceling the transaction so no funds are lost. → Focussed on security.
ERC777: Solves ERC20’s problems, such as lack of transaction handling mechanisms. → Focussed on mainstream adoption.
As you can see, the community still has to grow in terms of adopting more secure/better token standards.
NEM
Scalability is the most critical thing about NEM’s decentralized application. While ETH does a maximum of 15 transactions per second, NEM reportedly manages hundreds of transactions per second. The NEM foundation has given security and availability a priority so entrepreneurs deal with other problems and not technical difficulties.
While NEM is reportedly the faster, safer and easier technology, Ethereum provides a broader base for the creation of custom DApps. The main difference is that ETH applies its Smart Contracts on the Blockchain, while NEM uses code off the blockchain. Although this might arguably make it less decentralized, the method does have its benefits, such as better security, easier updates, faster execution times and lighter code.
Reddit user Nemario told me that the contract code can be updated at any time, all without any interaction with the chain. It is not possible to execute reverse transactions. This makes NEM less decentralized in one way, but on-chain security features like multi-sig and smart assets mitigate this ‘problem’.
NEM has customized data management apps called smart assets through which you can create tokens, data records, voting systems and other coins with just a few clicks. Where Ethereum is targeting companies intend to rebuild internal networks in the next 5 to 10 years, NEM is targeting companies looking for a fast, secure, and ready to use and handle solution that’s current. It will be interesting to see which companies adopt NEM over Ethereum.
Hyperledger Fabric --
Hyperledger Fabric (HLF) likes to call its smart contracts ‘chaincode’. HLF is an enterprise permissioned blockchain, built with great flexibility, which makes it very useful for businesses as their business rules change after approximately 7 years. Most other blockchains are not built considering flexibility.
Hyperledger Fabric itself was written on Go language, so its smart contracts support this language as well. Benefits? Golang is a very efficient language with a fast compile time.
In my opinion, writing chaincode is simple. The three most important functions are:
PutState: Create new asset or update existing one.
GetState: Retrieve asset.
GetHistoryForKey : Retrieve history of changes.
DelState: ‘Delete’ asset.
Note on DelState: HLF uses a state database that stores keys and their values. This is different from the sequence of blocks that make up the blockchain. A key and its associated value can be removed from the state database using the DelState function. However, this does not mean that there is an alteration of blocks on the blockchain.
The removal of a key and value would be stored as a transaction on the blockchain just as the prior addition and any modifications were stored as transactions on the blockchain.
The history of a key can be retrieved after the key is deleted. There is a GetHistoryForKey() function that retrieves the history and part of its response is an IsDeleted flag that indicates if the key was deleted. It would be possible to create a key, delete the key, and then create the key again; the GetHistoryForKey() function would track such a case.
Stellar Smart Contracts ---
Stellar smart contracts (SSC) are much different from Ethereum smart contracts. They are not Turing complete and are implemented as an agreement between multiple parties and enforced by transactions. Below you see a comparison between Stellar and Ethereum. Notice the huge difference in cost and confirmation time. A single transaction on the Stellar network costs only ~$0.0000002!
An SSC is expressed as compositions of transactions that are connected and executed using various constraints. The following are examples of constraints that can be considered and implemented when creating SSCs (from Stellar documentation):
Multisignature — What keys are needed to authorize a certain operation? What parties need to agree on a circumstance in order to execute the steps?
Multisignature is the concept requiring signatures of multiple parties to sign transactions stemming from an account. Through signature weights and thresholds, representation of power in signatures is created.
Batching/Atomicity — What operations must all occur together or fail? What must happen in order to force this to fail or pass?
Batching is the concept of including multiple operations in one transaction. Atomicity is the guarantee that given a series of operations, upon submission to the network if one operation fails, all operations in the transaction fails.
Sequence — In what order should a series of transactions be processed? What are the limitations and dependencies?
The concept of sequence is represented on the Stellar Network through sequence number. Utilizing sequence numbers in transaction manipulation, it can be guaranteed that specific transactions do not succeed if an alternative transaction is submitted.
Time Bounds — When can a transaction be processed?
Time bounds are limitations on the time period over which a transaction is valid. Using time bounds enables time periods to be represented in an SSC.
