Ethereum White Paper Explained. Part 3

Ethereum White Paper, Explained. Part 1 & Part 2 aimed to help you understand how the Ethereum ecosystem works, now let us delve into the applications of the Ethereum Platform.

Ethereum has three main applications.

  • Financial Applications

These include currencies, derivatives, contracts, wallets, wills and could even include employment contracts.

  • Semi-Financial Applications

This category involves partial inclusion of money along with a non-monetary aspect. An example would be automatic bounties on finding solutions to computational problems.

  • Governance

Online voting is a possible use case for the Ethereum ecosystem.

 

Token Systems

Tokens have numerous use cases for sub-currencies such as USD, gold, equity, property, coupons and even tokens with no conventional means of value which might be used for incentives. Token systems are quite easy to be implemented on the Ethereum platform. The logistics involved on how the tokens work is well explained in Part 1 & Part 2. The ledger subtracts units from one account and enters units into another.

You can find the basic code implemented in Serpent below:

def send(to, value):
if self.storage[msg.sender] >= value:
self.storage[msg.sender] = self.storage[msg.sender] – value
self.storage[to] = self.storage[to] + value

This is an implementation of a state transition function that works as a banking system. You enter a few lines of code to program conditions of how the currency units are distributed or for numerous other use cases.

 

Financial Derivatives and Stable-Value Currencies

Financial derivatives are one of the most common applications of smart contracts. They are quite easy to be implemented in code as well. One challenge here is implementing contracts that can refer an external price ticker.

Consider the following example:

A smart contract that hedges against the volatility of ETH with USD as the base currency. This application, however, requires one to know the value of ETH/USD traded on an exchange. This can be done by a data feed that is maintained by a third party designed such that the third party can update the price of the contract as and when needed. Other contracts can ping the data feed and get back a response that provides the price.

The contract would look as mentioned in the Ethereum white paper and is pretty much self-explanatory.

  1. Wait for party A to input 1000 ether.
  2. Wait for party B to input 1000 ether.
  3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.
  4. After 30 days, allow A or B to “reactivate” the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.

Such contracts have high impact use cases in crypto-commerce. Most users stay away from cryptocurrency due its high volatility. Users want the security and convenience of cryptocurrencies, however, the idea of losing 10%-20% of value in a single day is unpleasant. The most common solution used up until now are issuer-backed assets. The idea involves creating a sub-currency that they hold the right to issue, revoke and provide units of the currency to a seller who provides them with one unit of another asset. For example, these assets could be Gold or USD. Although they can be modified to accept a vast number of assets as well. The issuer then exchanges one unit of the sub-currency to one defined unit of the physical asset. This allows numerous different assets to be converted into cryptographic assets and exchanged for value. However, it all depends on the trust and reliability on the issuer.

Cryptographic financial derivatives act as our knight in shining armor in this scenario. They provide an alternative. Instead of a single issuer, we can use a market of traders betting on the price of a decentralised asset like ETH. Speculators do not default while trading as the smart contract holds their funds in escrow. However, this source is not fully decentralised, as we rely on a third-party source to provide the price of ETH. This is still a major improvement and reduces the potential for fraud when compared to issuers that cannot be trusted.

 

Identity and Reputation Systems

Namecoin was one of the first alternative cryptocurrencies that tried to use a Blockchain similar to Bitcoin to provide a name registration system. This allowed users to register their names in a public database with other data. Other use cases include mapping domain names to an IP Address, email authentication and advanced reputation systems.

The following code is for a Namecoin like registration system on the Ethereum network:

def register(name, value):
if !self.storage[name]:
self.storage[name] = value

The smart contract programs a simple database inside the Ethereum network where data can be added, but not modified or removed. Thus, maintaining the immutability feature of the Ethereum platform. Any registration made against a name with some value will be stored on the blockchain forever. A sophisticated program may allow other smart contracts to query and fetch data from it, it may also allow the owner to change or transfer ownership.

 

Decentralised File Storage

There are numerous popular online storage services. Services like Dropbox, Google Drive let you upload a backup of your hard drive on to their centralised servers for a monthly fee. Sure, they have a free storage facility up to a certain size limit, but most the data that we need to store on the cloud exceeds this free storage. Ethereum contracts provide a much better tradeoff for developing decentralised file storage ecosystems, where users can earn money by renting out the free space on their own hard drives.

An example of such a contract on the Ethereum network would work as follows:

  1. Data is split into blocks, encrypted and a Merkle tree is built.
  2. Every N blocks, the contract picks a random index in the Merkle tree, then gives some ether to the first entity to supply a transaction with a simplified payment verification; like proof of ownership of the block at that index, in the Merkle tree.
  3. If the user wants to download their file, they may use a micropayment protocol. This can  be as low as 1 szabo per 32 Kilobytes.
  4. To pay less gas fees, the payer would replace the transaction at the end of 32 Kilobytes with a slightly more lucrative one in order to fetch more data.

It might seem like trust is distributed among random nodes so that the file is not forgotten, but this risk can be reduced by splitting the file into many pieces and watching the contracts to check if each piece is still in some node’s possession. If there is enough ether in the contract and it is still paying out money, that is enough proof that the file is still stored somewhere according to the programmed protocol.

 

Decentralised Autonomous Organizations

The concept behind a DAO (“Decentralized Autonomous Organization”) is that a certain set of members or shareholders, perhaps with a 67% majority, may spend the funds of the entity and modify its code. Members will come to a collective decision on how to allocate the funds of the organization. This may range from bounties, salaries, to even more complex mechanisms like rewarding internal work. It tries to replicate the functioning of a company by using only Blockchain technology as the solution. Most discussion surrounding DAOs has focused on the capitalist model of a DAC (Decentralized Autonomous Corporation) with shareholders who receive dividends. An ideal alternative, however, is a Decentralised Autonomous Community where all members have a share in decision making and where they require at least 67% of existing members to add or remove a member.

Following is a general outline of how to code a DAO. A simple design is a piece of code that can modify itself when two thirds of members agree on a change. The code is immutable, however, there is a work around. Code can be divided into separate contracts having de-facto mutability and the addresses of each contract can be stored in mutable storage. This would allow us to mix and match code from smart contracts in order to change the code. There would be three transaction types as mentioned in the Ethereum White Paper:

  • [0,i,K,V] to register a proposal with index i is to change the address at storage index K to value V
  • [1,i] to register a vote in favor of proposal i
  • [2,i] to finalise proposal i if enough votes have been made

The contract would store clauses for each of these. It would maintain a repository of all open storage changes along with the list of people who voted for them. This would accompany a list of all members. Whenever a storage change would get the bare minimum of the members voting for it, a final transaction would execute the change. Further sophisticated features would include built in voting ability for sending transactions, adding/removing members, delegation of votes, etc. This would let DAOs grow as a decentralised community.

 

Further Applications

There are numerous applications on the Blockchain and following are a few instances:

  • Savings Wallets

Alice wants to keep her funds safe but worries that someone might hack her private key, or she might lose it. She transfers ether into a contract with Bob who will act as a bank in this scenario.

  • Alice alone can withdraw a maximum of 1% of the funds per day.
  • Bob alone can withdraw a maximum of 1% of the funds per day, but Alice can make a transaction with her key, shutting off this ability.
  • Alice and Bob together can withdraw anything.

Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice’s key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.

Such conditions can easily be programmed into an Ethereum smart contract.

 

  • Crop Insurance

A Financial Derivatives contract can be made using a data feed of the weather instead of a price index. A farmer purchases a derivative that pays out inversely based on the precipitation in any selected area. If there is a drought, the farmer gets paid and if there is rain, crops will do well which implies the farmers business is safe. Farmers can essentially hedge their businesses. This use case can be expanded to natural disaster insurance as well.

 

  • Decentralised Data Feed

There is a protocol called ShellingCoin that lets you decentralise data.

The working of SheelingCoin is mentioned below:

N number of parties enter the value of ETH/USD in a system and everyone between the 25th and 75th percentile get rewarded with a token. This way, any person will only get the incentive if they give the answer that everyone else provides. Theoretically, this protocol can create any number of values.

 

  • Smart Multisig Escrow

Multi signature transaction contracts are where, for example, at least 2 out of 3 keys are mandatory to spend the funds. On the Ethereum platform a lot of more complex conditions can be programmed. Being a Turing complete language, the programming capabilities of Ethereum are limitless.

 

  • Cloud Computing

Ethereum can also be used to create a computing environment, which will allow users to carry computations on other systems on the Ethereum Blockchain, optionally also asking for proofs for computations done at random checkpoints. This allows creation of a Cloud Computing market where anyone can participate. This kind of computing, however, is not suitable and recommended for all tasks

 

  • P2P Gambling

Peer to Peer Gambling protocols can be implemented on the Ethereum Blockchain. There are numerous Ethereum gambling websites that are already exist.

 

  • Prediction Markets

Prediction markets are also easy to implement. They allow you to bet on the prediction of a certain outcome and which is then verified on the Blockchain and those who predict correctly are rewarded.

 

  • On-Chain Decentralised Marketplaces

Such marketplaces use identity and reputation systems as a base.

 

This concludes the third part of the Ethereum White Paper series. Stay tuned for more updates on the BBOD and follow us on Twitter.