NEO vs Ethereum vs Bitcoin: Smart Contracts
NEO vs. Ethereum vs Bitcoin: Smart Contracts
Now for first time watchers of readers, I like a cold one, and I like crypto so I thought I would bring their worlds together for one cypto, beer and wine extravangza. Today’s guest on the show is from Deshutes brewery, and definitely is one of my favorite beers. Fresh Squeezed IPA
Today’s content is some juicy stuff, and if you love NEO vs Ethereum vs Bitcoin you will find this artcle fascinating. Boys and girls we are in a bear market, and you should be re-assured that your holdings of NEO vs Ethereum vs Bitcoin will return with a vengeance when the bulls return which I predict when be in quarter 1 of 2018.
This reassurance will come from a breakdown of smart contracts written by Erick Zhang and Da Hongfei the co-founders of NEO. Before NEO’s rebrand from their former name Anshares, Erick and Da wrote a series of articles for themerkle.com called reconstructing smart contracts. It’s 3 parts and if you’re a NEO fan I would definitely give them a read. For those who don’t have time, that is why I am here, to go through this article for you and break it down into easy to understand terms.
Let’s get into it, the basic design of smart contracts and the features smart contracts should hold true. The term smart contract was first proposed by cryptography scientist Nick Szabo in 1994. He defined a smart contract as a computerized transaction protocol that’s function is to execute the terms of a contract. A basic contract is made of 3 stages: negotiation, signing, and execution. Now the beauty in bitcoin, Ethereum, blockchain technology, it allowed the smart contract theory which is just as old as the internet, to be realized through a secure and accountable record vehicle and runtime environment in which smart contracts can be practically deployed.
Smart contracts, unlike traditional computer programs, must be deterministic and terminable. Basically this means number 1 they must produce the same output with a given input, even on different computers or different runs on the same computer and it must have an end. Think of it like this, since smart contracts run on multiple nodes, the smart contract needs to be deterministic, or consensus could not be achieved since there would be no consistency. Blockchain developers have a duty to be highly aware of this, and eliminate all un-deterministic factors.
Turing Complete Smart Contracts
Erick and Da explain in the Merkele article that smart contracts can be written into bitcoin, and the scripting engine built into bitcoin is the predecessor of all blockchain-based smart contract engines even Hyperledgers Fabric. Bitcoin smart contracts need extremely simple and non-turing complete. the application using smart contracts are very limited and provide no systematic function or the ability to call data.
In comparison Ethereum is designed to be turing-complete smart contract platform allowing developers to expand on the functionalities and write any arbitrary kind of program. The Ethereum virtual machine executes the contract code and programming language Solidity. In Ethereum, the smart contrancts provide no un-determentistic system function, and data is confined to on-chain information only.
Satoshi only included support for a limited range of transaction types for security reasons but I’m sure he had many ideas about how the scripting system could be used to create a wide range of interesting scripts to serve different purposes. A full turing-complete scripting system seems like a pretty dangerous idea to me. Erick and Da explain that in Ethereums call code orders are portrayed by stacks , which enables contracts to call the code of other contracts when running dynamic calls. This has the potential to make the call route of the contract to be un-deterministic. The possibility of undetermenistic call routes will cause significant performance loss on scalabilty. Dynamic calls make things complicated for Ethereum!! It is impossible to predict the behaviors and paths of Ethereum smart contracts before executing the codes, and thus it will also be impossible to know which state record the smart contracts will edit.
Sharding and Terminable
Ethereum has proposed sharding but as the article exclaims that cross calling requests will be written into the full network and requires the confirmation of another call before the first call executes. This greatly decreases efficiency as cross-section calling cannot be done in one block. The result is that people will crowd into prosperous section as calling in one section will not need cross-section calling. This will cause traffic congestion, in this section. Think of it like San Francisco, many people flock to this prosperous city as it provides a close proximity to business connections especially tech. This has attracted many people to the outskirts and suburbs which have also become congested even though they keep upgrading and building roads, the congestion has not improved.
Smart Contracts must also be terminable, which means the can’t run into endless loops or they would consume infinite resources and bring the blockchain system to a grinding halt. This is called the halting problem which describes the fundamental inability to determine whether or not a given program can complete in a finite timeframe. However, smart contracts must be guaranteed to complete in a finite timeframe or they could run into infinitely endless loops.
Da and Erick conclude that blockchain smart contracts should be deterministic, terminable, subjected to accurate resource control, and resource isolation capacities such as Dockers or Virtual Machines. Ethereum tackles the resource control issue by deploying a fee meter which charges a fee for every order execution. If the contract is not brought to completion as the contracts fee deposit is drained, it will be forced to end and not run infinitely. Bitcoin employs turing incompleteness which by definition does not allow infinite loops. When you have turing complete system, resource isolation becomes very important as malicious contracts would infect the blockchain nodes, and reproduce. Smart Contracts must be confided to isolated sandboxes such as virtual machines or dockers.
NEO Smart Contracts 2.0
Now let’s take a look at NEO Smart Contracts 2.0 and why the NEO team has built a new Smart Contract system that combines the advantages of Docker which is the language flexibility for programming and the security of virtual machine environments. NEO Smart contracts feature high certainty, high performance, and expandability.
NEO Contracts rule out any factors which may lead to non-deterministic behavior. System time is a very common system function but is non deterministic. NEO makes it deterministic by providing a block-based system call that treats the blockchain as a timestamp server, and obtains a new one whenever a new block is generated. Also NEO data sources are deterministic through the blockchain ledger, and contract storage space. Each contract deployed on the NEO network, has a private storage area that can only be accessed by the contract itself. NEO consensus mechanism ensures consistency of the storage status, of each node in the network.
In situations where access to non-blockchain data is required NEO does not provide a direct way to interact with these data. Non-blockchain data will have to be transferred to the NEO blockchain using transactions, and subsequently translated into the either of the aforementioned data sources, in order to become accessible by the smart contracts.
Now lets take a look at contract calls, which ethereum’s design leads to some undetermenistic possibilities. NEO smart contracts can call each other, but no recursively. The call relationship must also be static. This allows the behavior of the call to be fully determined before execution, and the call relationship to be defined before it can run.
NEO Execution Environment
The execution environment needs to be high performance, and NEO uses a lightweight NEO vitual machine that has a very fast startup which executes instructions quickly. It also uses up very little resources, and is of higher security than a docker.
Looking at the scalability with NEO, they have created a design for unlimited scaling in the smart contract systems by setting up two simple rules
1. A smart contract can only modify the state record of the contract that it belongs to
2. In the same transaction batch or block, a contract can only be running once
Now we know NEO can scale, but how does NEO access non-blockchain data. Well this is done through the interoperable service layer of the NEO Virtual Machine. This means that most upgrades to smart contract functions can be achieved by increasing the API of interoperable service layer.