Ethereum Classic

What are dApps?

If you are a regular traveler, you may notice something unusual in your air or train terminals. You may or may not see vending machines. What is unique, however, is what these vending machines offer. You may find a vending machine offering hot pizza, another offering electronics goods, and a kiosk for hotel reservations. The vending machine industry in the era of Internet of Things has seemed to open up to encompass anything a developer can dream up, with some vending machines replacing traditional stores. RedBox machines, for example, have largely replaced the once ever-present Blockbuster video store, chasing the company out of the industry it helped define.

Considering the data revolution that blockchain is, one may ask why this vending machine revolution has not come to the Internet? The truth is that it has. Since the emergence of Ethereum, scriptable autonomous programs have been able to conduct transactions without the need of a third party. The possibility of this has redefined the possibilities of commerce both offline and on.

This article will look at what a dApp is and why it is important.


Smart Contracts and Ethereum

To understand why a dApp is important, one need to start by looking at smart contracts. Nick Szabo came up with the idea of a smart contract in 1997 – nearly fifteen years before its implementation.

“Many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher,” Szabo wrote. “A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a freshman computer science problem in design with finite automata, dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas.”

“Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short.”

A smart contract, in theory, allows two people to engage in a trustless transaction without the need of a third party. Typically, a transaction only involves two people – the buyer and the seller – but, without a witness or intermediary – it would be on the parties involved to officiate the transaction. If one party chooses to act in bad faith, there is little the other party can do. In such cases, transactions typically require an officiant, which would witness the transaction and enforce full compliance to the terms of the transaction.

Without the officiant, there must be some type of self-executing function for the transaction. Again, while, in the real world, most contracts are acted on by a third party only when the contract has been breached, a trustless transaction must ensure enforcement in the moment. On a blockchain, this enforcement and execution can be handed to an autonomous program to handle.

A dApp is a consensus-driven bytecode-written extension of the blockchain’s virtual environment that is designated to do a job. By this definition, a cryptocurrency is a dApp, as it is a manifestation of its blockchain. However, as envisioned with the creation of Ethereum, a dApp is a scripted solution to a real-world problem that can use and create smart contracts to achieve its goals.

“The intent of Ethereum is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that we believe will be very useful for a large class of decentralized applications, with particular emphasis on situations where rapid development time, security for small and rarely used applications, and the ability of different applications to very efficiently interact, are important,” Ethereum’s creator Vitalik Buterin wrote in his white paper. “Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic “boxes” that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.”


Understanding dApps

On Ethereum, dApps and executable distributed code contracts (EDCC) are written in Solidity, a Javascript-like language. Each scriptable blockchain goes about dApps and smart contracts differently, so – for simplicity – we will be focusing on Ethereum for this part of the article.

When you access a dApp as an end-user, you rarely contact the actual smart contracts. Instead, you access a web-based front end (it need not need to be web-based; the oracle or bridge to connecting smart contracts to external resources like other blockchains or databases could connect to a telephony system, for example). This front end – have it be made from HTML, CSS, Java, Javascript, etc. – takes the terms of the “contract” the user seeks to enter.

For example, say that a user signs into a car rental dApp system to rent a car for the weekend. He/she would sign into the system’s webpage using his/her browser and fill out some information on a provided form, such as name, car type desired, and dates the car is needed. This information would be broadcasted to a “listening” dApp.

The dApp is code that is stored on a blockchain “sidechain,” or a distributed ledger that is a part of the blockchain’s ecosystem and shares many of the dependencies that the main chain uses but is distinct from the main chain itself. The dApp is stored in a user account on the sidechain.

When a request is made from the front end, the dApp is loaded into the Ethereum Virtual Machine, or the in-memory implementation of the Ethereum code. The Ethereum Virtual Machine can be thought as the “living” blockchain or the version of the blockchain where transactions can happen.

The dApp would calculate how much “gas” is needed to run the requested smart contract. “Gas” is the cost to run instructions on a node running EVM. This can be thought of as the courtesy fee one would pay to use someone else’s computer. An end user must allocate enough gas to complete a smart contract, as the gas is collected automatically from the user’s wallet. A smart contract that does not have enough gas will still run; like a car without enough gas to make a trip, the smart contract will use the gas available and stop once the gas is exhausted.

Ethereum’s code is a basic algebraic system, so code is limited in complexity to counting, adding, subtracting, multiplying, and dividing, as well as basic memory and record manipulation. This is to limit the energy demands of repeated calculations. To supplement this, there is a gas limit per block, meaning that a single block can only support so many calculations.

This forces developers to simplify their smart contracts as much as possible. This is somewhat problematic, because developers tend to copy existing smart contracts instead of developing new contracts. This homogeneous nature means that if a smart contract pattern has a critical flaw, that flaw is likely to be repeated throughout the ecosystem.

The dApp will “look” at the broadcasted data and will create a smart contract to complete the required tasks. This may be checking the blockchain records to see what cars are available, checking a user list to see if the user has an account or is banned, or accessing a location list to see what areas the system serves.

In computer terms, a smart contract is a procedure. It takes in terms as variables, perform some discrete operation, and return a value to the dApp. The returned value could be null or it could be actual data, but once the smart contract completes its purpose, it terminates. Inactive smart contracts are not held in memory.

The dApp would either pass the return value to another smart contract or send it back to the front end. Eventually, the dApp will need to open a smart contract that would need to communicate with the outside world, such as contacting a bank to process a credit card payment, contacting the DMV to verify a driver’s license, or communicating with a key manager to inform that a car has been rented. To do this, the smart contract needs to contact an oracle.

“An oracle, in the context of blockchains and smart contracts, is an agent that finds and verifies real-world occurrences and submits this information to a blockchain to be used by smart contracts,” Blockchain Hub reports. “Smart contracts contain value and only unlock that value if certain pre-defined conditions are met. When a particular value is reached, the smart contract changes its state and executes the programmatically predefined algorithms, automatically triggering an event on the blockchain. The primary task of oracles is to provide these values to the smart contract in a secure and trusted manner.”

“Blockchains cannot access data outside their network. An oracle is a data feed – provided by third party service – designed for use in smart contracts on the blockchain. Oracles provide external data and trigger smart contract executions when pre-defined conditions meet. Such condition could be any data like weather temperature, successful payment, price fluctuations, etc.”

“Oracles are part of multi-signature contracts where for example the original trustees sign a contract for future release of funds only if certain conditions are met. Before any funds get released an oracle has to sign the smart contract as well.”

Oracles can be software-based (such as a real-time commodity feed) or hardware-based (such as real-time monitoring of RFID chips). They can be in-bound (such as an exchange’s automatic buy order) or outbound (like a smart lock controlled by a smart contract, such as a key locker for the rental car system). Regardless of the configuration, smart contracts cannot contact the real world without oracles.


A Changing World

The reality of all this should not be underestimated. Basically, this system of connected autonomous and semi-autonomous programs means that any transaction that can be reduced to basic algebra can be automated. This could mean real-time monitoring of package delivery and opening. This could mean real-time inventory management. This could mean cashier-less stores, system-independent record-keeping, and banking processes that can happen automatically.

But this is not a perfect system. Take, for example, the DAO. The DAO, or Decentralized Autonomous Organization, is a dApp-based venture capital firm that existed wholly on the Ethereum blockchain. A hacker exploiting the withdrawal provision of the DAO managed to lock up much of the organization’s Ethers, leading to a fight about should the stolen coins be returned and the hard forking of the chain.

When you allow automatic code to act without human intervention, it becomes difficult to stop it. Should the code be flawed, one can expect human nature to eventually take advantage if it. The true test of the capability of dApps is the same as it is for most technologies: is it human-proof?

While dApps have been tested in the case of the DAO and has failed, the potential for dApps to revolutionize data management is still there. The potential, however, for this possibility to become a reality will depend on its robustness to withstand the worst of man while inspiring the best.

Leave A Reply

Your email address will not be published.