Ethereum Smart Contracts and DApps vs. Bitcoin Smart Contracts.

The Ethereum platform manages every single interaction between the users taking part in it, without the involvement of a controlling body. In an interaction between two parties on the network, the terms and conditions for both parties to fulfil are pre-programmed into the smart contract. The completion of these terms and conditions then trigger a transaction or some other specific action. As at the time of writing, many Ethereum enthusiasts believe that smart contracts are the future and will eventually replace all other contractual agreements, and are of the view that the implementation of smart contracts provides security that is superior to traditional contract law, reduces transaction costs associated with contracting, and establishes trust between two parties. This particular belief is a point of contention, and not one that we support.

The Ethereum platform provides its users with the Ethereum Virtual Machine (EVM), which essentially serves as a runtime environment running on each Ethereum node that is capable of executing more sophisticated smart contracts, as opposed to the simpler smart contracts in Bitcoin. The stance of the Ethereum developer community is that even though the Bitcoin protocol does facilitate smart contracts, it only enables weak smart contract capability. The Ethereum community sees the scripting language for the implementation of smart contracts in Bitcoin as having several important limitations. Below is a summary that has been extracted from the more detailed paper, which can be found at https://github.com/ethereum/wiki/wiki/White-Paper#scripting:

• Lack of Turing-completeness – that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops.
• Value-blindness – there is no way for a UTXO (unspent transaction output) script to provide fine-grained control over the amount that can be withdrawn. UTXO’s are all or nothing.
• Lack of state – There is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to create multi-stage options contracts or more complex “stateful” contracts.
• Blockchain-blindness – UTXOs are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.

The most well-known difference between Bitcoin and Ethereum smart contracts is that the code for Ethereum smart contracts is Turing-complete, which means that literally everything can be calculated as long as there is enough computing power and time to do so. Bitcoin does not have this capability. While a Turing-complete code provides Ethereum users with practically unlimited possibilities, its complexity has increased its attack surface and makes it vulnerable to attacks. Here is a list of the various planned and unplanned forks, some of which resulted from denial-of-service attacks.

So even though Ethereum is based on Bitcoin’s protocol and its blockchain design, it is tweaked so that applications beyond money and payments can be supported. The two blockchains both store the entire transaction histories of their respective networks. However, Ethereum’s blockchain does more than that. In addition to storing the history of transactions, every full node on the Ethereum network also needs to download the most recent state (the current information) of each smart contract within the network, every user’s balance and all the smart contract codes.

The DApp operates in a similar fashion. However, instead of having the application (and all the logical functions that makes it work) running on a central server, the application has smart contracts that are running on multiple nodes of the Ethereum network. Hence the term Decentralized Application. Furthermore, the smart contracts contain the logical functions for the application and reads data from, or writes data to the blockchain. Each full node of the network contains a copy of the smart contract, and the smart contract has a particular address on the blockchain. The front-end that enables the user to interact with the smart contracts can be any front-end, or simply just a web-based browser type interface. So the DApp is simply the combination of the user front-end system, and the combination of its logical components together with the smart contracts relevant for its purpose. When a user executes a task on the DApp front-end, a particular smart contract’s functionality will be invoked, and if the resulting execution of that function is successfully validated by the nodes, it’s results are written to the blockchain, and all nodes on the blockchain update their states to remain in sync.

As you can surmise, the DApp is the whole package, from the back-end (logic in the background) to front-end (what the user can see). The smart contract is just one part of the DApp. A DApp can be completely decentralised or just partially. It is simply a matter of what architecture is chosen by the development team. Developers can choose to rely on fewer smart contracts and complement the functionality with custom functionality built on a traditional web application server.

The term ‘smart contract’ is just a term used to describe computer code that can facilitate the exchange of digital tokens that represent money, content, property, shares, or anything of value. When running on the blockchain, a smart contract behaves like a self-executing computer program that automatically executes instructions encoded into it when specific conditions are met. Smart contracts are how things get done in the Ethereum ecosystem. When someone wants to get a particular task done in Ethereum they initiate a smart contract with one or more people. Smart contracts contain the series of instructions, usually written using the Solidity programming language, to enforce obligations between parties. The following illustration is frequently seen to demonstrate the execution of a smart contract:

Every single step in a smart contract is a transaction or a complex computation and would have a cost that is measured in “gas”. This gas is paid for by the requester in Ether. Ether is the currency with which everything runs in the Ethereum. Every piece of code has a specific gas limit to ensure that it does not end up depleting your entire ether wallet if for some reason it takes up too much computational power.

DApps are partially or completely decentralized and not owned by an individual. They are owned by people who ‘buy into’ or ‘invest’ in the DApp. The way this happens is usually by a crowd-sale called the “ICO” (Initial Coin Offering), whereby the ‘investor’ purchases tokens of that DApp in exchange for Ether. Golem is a good example of this. If you want to use the services in Golem then you will need Golem Network Tokens (GNT). And you would obtain your GNTs by paying for them with your Ether. A very simplified smart contract that enables the purchase of a token (myToken) is now illustrated.

The standard token contract can be quite complex. But in essence a very basic token boils down to this:

Smart contracts have data and code that can manipulate data. If you inspect the code of a contract that is used to facilitate the sale of a token in exchange for Ether, you will notice that

• Only the creator of the contract can issue the currency, and
• The creator can specify the amount of currency to issue.

The code will also contain functions that shows how the creator can send a specific number of tokens to an investor in exchange for the Ether that they are investing into the DApp. Other parameters such as the gas limit will also be specified.

This demonstrates how you can create currency ‘out of thin air”. The creator of the DApp has to create its own token or currency, and can issue to itself any amount of currency. The ERC20 standard for tokens was established to ensure interoperability of different smart contracts that need to interact with different DApps. Anyone can become invested in a project they are interested in by purchasing the tokens of that particular DApp and becoming a part of the project themselves. This leads us to the the process of Initial Coin Offerings, or ICOs.

Our perspective of which smart contract platform is better is based on an entirely different set of criteria to those criteria that are generally favoured within the Ethereum and general development communities. Yes, Ethereum provides a more complete and functionally-rich platform for smart contract development, as opposed to Bitcoin’s very basic Script capability. On the other hand though, Bitcoin’s simplicity makes it safer and gives it a smaller attack surface than Ethereum contracts (which has been borne out by several attack events in Ethereum’s shorter life-span). It can also be argued that the decentralized processing of Ethereum smart contracts is computationally expensive and frankly, unnecessary.

However, arguments such as those above are technical arguments. Technology advances so quickly that technical advantages or superiority of one platform vs. another is temporary and soon becomes irrelevant.

In light of the above, one of our key criteria is the extent to which a cryptocurrency network creates reliable and trustless peer-to-peer commerce, in addition to being censorship-resistant. In addition to Bitcoin being decentralized (and we would argue that Ethereum and all the DApps built on it are not truly decentralized), Bitcoin is also secure. It is the most cryptographically secure network to date and has never been hacked. Even after nearly a decade of operation.

We, therefore, prefer the security of Bitcoin smart contracts for this reason. It is a platform that will come to be more trusted in and of itself, for bitcoin-related transactions. However, it also enables much more, and similarly secure commercial applications in the traditional domain of fiat money. For more detail about our views, please feel free to contact us for a consultation session.