Ethereum

Ethereum’s Turing complete smart contracts can perform complex calculations, store data and communicate with other contracts or users on the blockchain. Contracts are written in higher level programming languages and then compiled to bytecode for the Ethereum Virtual Machine (EVM). Every node participating in the network runs the EVM and executes the same programs to achieve equal results and consensus about the state of the network. These executions are fueled by extra transaction fees which are fixed costs assigned to each operation of the EVM ², representing the computational effort of that operation. These costs are measured as gas and paid for in Ether (the native currency of the Ethereum network): for every transaction the user specifies the amount of Ether they are willing to pay for one unit of gas and a maximal amount of gas which may be spent this way. When a transaction runs out of gas before its computation is finished, it is marked as failed and all spent gas (i.e. the previously set limit) is kept as mining fee. However, if the transaction has finished successfully, only the actually used gas is kept as fee and all excess is returned to the user as Ether. This technique ensures that no malicious user can stall the network with long-running transactions while also decoupling the network from the currency fluctuation of Ether.

The versatility of Ethereum’s smart contracts seems promising for a comparably easy and feature-rich implementation of

• ISCC and metadata management
• custom token trading
• custom blockchain applications

One of the problems of the public Ethereum chain is that it is still in development and its protocol is subject to change. If two versions of the protocol are incompatible, the public chain will split. These so called hard forks have occurred multiple times already. Additionally, when large amounts of ETH were stolen through a flawed smart contract, the Ethereum community decided to perform the arguably most controversial hard fork to refund the stolen money³, which can be viewed as major loss of confidence in the finality and dependability of Ethereum smart contracts and blockchains in general. This should be kept in mind when developing an application for the public Ethereum network.

Setup

A multitude of Ethereum clients are available, from both official and third party developers. For our hands-on evaluation we have used two of the most popular clients, geth and Parity. Setting up a local testing chain in Parity is as simple as providing one parameter whereas geth requires an initial config file and multiple parameters at every restart of the client.

The geth client provides a javascript console to interact with the chain granting easy low-level access to contracts, transactions and events taking place on the chain. However, this also requires the developer to handle quite a few things: mining is not performed automatically, failing to unlock and set up the correct account can result in cryptic errors and transactions that fail silently if they run out of gas because the default amount was not enough.

In contrast, Parity lacks a built-in console but offers an appealing and intuitive GUI which helps avoiding the above-mentioned problems. The GUI is accessible through the web browser and comes with an editor featuring syntax highlighting, compilation and deployment for smart contracts written in the Solidity language.

Possible usage scenarios for the Content Blockchain project

Federated management of content identifiers and metadata

The most straightforward way to store and link content identifiers and their metadata on the Ethereum chain is a central smart contract. While this contract may become arbitrarily complex, the most basic version only needs to provide three features:

• everyone can post metadata for an ISCC
• everyone can retrieve metadata of an ISCC
• nobody can alter the metadata history of ISCC

These three requirements suffice to create a global, public and censorship-resistant database. Any additional features like an efficient search through all ISCCs could then be implemented as external programs independent of the actual Ethereum technology (and its costs).

We chose an object-oriented approach to gain some insight while building a prototypical implementation: a generic ISCC contract provides a dynamic string array as publicly readable and append-only log for arbitrary data. Concrete instances are created and can be queried through a well-known, un-administrated content blockchain contract (CBC), which prevents duplication and guarantees authenticity of all ISCC instances referenced by this central contract⁴.To eliminate potential problems with the storage size limitation of a single contract, the CBC does not store references to ISCC instances directly. Instead, an ISCCGroup contract is created on demand by the CBC and used to store references to all content identifiers with a common prefix.

Unfortunately, this approach seems to be prohibitively expensive on the public Ethereum chain even for an unrealistically small content identifier length of 4 bytes: the registration of an identifier consumes 527,807 gas and an even higher amount of 1,283,100 gas when the identifier’s prefix is new.

With a market value of $28.80 per Ether and an average gas price of 18 Gwei, registering an identifier with a new prefix would cost about $0.67 and storing 32 bytes of metadata (e.g. a URL) would cost about $0.037. It should be noted, that a block gas limit of 4.0×10⁶ gas allows at most three expensive ISCC registrations in a single block.⁵ The average block time of 15 seconds⁶ would then allow a maximum of 17,000 ISCCs to be registered per day for a total price of about $11,600. However, since this would use up most of the blockchain’s computational power, the blocks’ gas limits and gas prices of competing transactions would increase, which in turn would increase the ISCCs registration cost. (Since our tests the ETH price has already gone up from ~ $ 28 to ~ $ 90).

There are two promising alternative ways of storing larger amounts of data on the Ethereum blockchain. Firstly, transactions and their data, e.g. arguments to contract calls, are stored on the blockchain anyway so there is no need to explicitly store this data in a contract’s storage. Creating an off-chain tool which can extract these unused arguments from the blockchain would then reduce the overall Ether cost since the contracts will greatly reduce their amount of consumed gas.

Another feature of Ethereum’s smart contracts are events. These seem to utilize the aforementioned blockchain log but offer more sophisticated access: event data can be indexed so that Ethereum clients can search it, and events can be instructed to execute callbacks in the Ethereum client.

One thing to note here is that the official Solidity manual makes a statement suggesting that data stored on the chain this way might not be accessible forever⁷. This should be thoroughly researched before implementing a solution utilizing the blockchain log.

Flexible creation and transaction of custom assets/tokens

Custom token issuance and trade is one of the most common use cases for Ethereum. The official website even offers a guide for creating such a tradeable coin with a fully working example contract ⁸.

Issuing the example token on a local development chain consumed about 775,000 gas; transferring units to other users required about 36,000 gas. These actions would cost about $0.40 and $0.02 with the rates mentioned above.

Support for custom blockchain application development (smart contracts)

Even though Ethereum offers immensely versatile smart contracts, it should be noted that these contracts can only react to users (or contracts) by sending them transactions. Effectively, contracts on their own cannot be scheduled to do something at a later point in time or react to events outside of the blockchain, for example if some stock reaches a certain value, and rely on external services like alarm clocks or oracles for this.

Results

The popularity of Ethereum, and thus the security of the official blockchain, as well as the flexibility of its smart contracts make Ethereum a promising candidate for the Content Blockchain Project. There are, however, downsides, especially to the use of the official chain. First of all, the protocol’s development with scheduled milestones, backwards incompatibilities and rather frequent and controversial hard forks makes the public chain a comparably unsteady platform.

The high use of the chain’s computational power and the high price for storing data renders the public chain unusable as ISCC registry, unless the alternative storage mechanisms prove reliable and sufficiently efficient. Public alternatives to Ethereum, like Ethereum Classic or Expanse, should also be taken into consideration for their lower market value and thus overall lower transaction cost.

¹ Approximate values on 28.03.2017 according to https://coinmarketcap.com/, https://www.coingecko.com/en,https://www.cryptocompare.com/coins/#/usd 
⁵ Approximate market value and gas price and limit on 2017-03-14 
⁶ As it has been from 2015 to 2017 https://etherscan.io/chart/blocktime 
⁷ http://solidity.readthedocs.io/en/develop/contracts.html#events “These logs […] stay [on the blockchain] as long as a block is accessible (forever as of Frontier and Homestead, but this might change with Serenity).”