Insights from Ujo: The Challenges of Building on Ethereum

Simon de la Rouviere is a Capetonian smart contract developer and a keen explorer of blockchain technology. He started building on Ethereum in 2015 when he joined the US-based startup ConsenSys - a company that builds decentralised applications as well as developer and end-user tools for blockchain ecosystems. His current project Ujo Music aims to decentralise music licensing and distribution through smart contracts.

Over and above his specific experience with Ethereum, Simon has also lived off and built on Bitcoin for a year. We talked to him about the reasons for building Ujo Music on Ethereum and some of the key challenges that he has faced.

Ethereum in the music industry

Ujo is an open, global, machine-readable database of music usage rights.

Popular music streaming services like Spotify and Apple Music centralise the music industry and make it harder for independent musicians to become known and earn from their work: “When you are paying $10 a month for Spotify and listen to an obscure Danish Techno DJ all the time, that $10 is still going to be split between all the listens on the platform,” Simon explains.

That’s what Ujo is trying to change: With blockchain technology it is possible to automate licensing on a global level without requiring intermediaries. These intermediaries usually add cost in a few ways: 1) they have to take fees, 2) there is a risk of them going away or disappearing (see SoundCloud) and 3) there are additional costs to transferring funds manually across the globe.

The platform serves musicians, music lovers and those developing music services: Musicians can now make more money for two reasons: On one hand, the platform allows musicians to individually licence their music. On the other, it allows music fans and devs who want to build music services to directly pay for the songs and albums they want to listen to or use for their projects. This means that application developers can easily license music without going through various complicated procedures such as negotiating with labels and sending money across the world.

In order to demonstrate the possibilities of their idea, Ujo launched a prototype featuring Imogen Heap’s Tiny Human in October 2015. After improving the overall architecture, the team has just launched the Ujo store in partnership with RAC. This demonstrates the underlying infrastructure of the upcoming “Creators Portal” that will be released within the next few months.

Ethereum vs Bitcoin

Although blockchain technology holds endless possibilities, Simon found Bitcoin difficult to play and experiment with when he first started doing it in 2014. At the time, Bitcoin lacked good documentation and the code itself was still going through several re-factors. “In order to innovate, at that point in time, your only option was to go and fork a digital currency. There were no other layers to work with. Bitcoin itself had a scripting language, but it was purposefully limited to avoid externalities from introducing complexity,” Simon recalls. This was really hard because you had to go down into the actual cryptography to understand what’s going on. Even compiling the software was made surprisingly difficult because Bitcoin used deterministic build tools called Gitian: “You had to wrestle with installation scripts and virtual machines. It was just so difficult,” Simon says.

When Ethereum came along, it promised to make all these things easier because it left the protocol-level things to the developers. Ethereum:

• Added a more flexible scripting language, called smart contracts.
• Made programming a blockchain the core feature. It was now not only a currency anymore. This is important because while Bitcoin does allow limited applications to be built on it, it can only be hacked by using the protocol in ways in which it was not intended to.
• Put emphasis on making it simpler and easy to understand (think: coding in Assembly vs coding in Javascript) .

Contrary to Bitcoin, Ethereum data blocks can contain more than just transactions related to changing balances. They can also work as autonomous contracts. This means that, in addition to sending money to an account, users can use the cryptocurrency (Ether) to inject code into the computer that will automatically be actioned when all necessary requirements are met.

Smart contracts act as the “vending machine” of Ethereum. When a transaction ordinarily requires a lawyer or, in the music industry, a record label that needs to be paid to licence the usage of a song, smart contracts circumvent this step by using blockchains and Ether. The contracts not only define the rules and penalties around an agreement but also automatically enforce these obligations (to the extent that code covers these obligations).

The challenges

Building an infrastructure on Ethereum however comes with its very own set of challenges:

• The need to build future-proof architectures,
• The importance and challenges of testing,
• The block times (and eventually consistent databases),
• Connecting Ethereum to the rest of the internet,
• Hosting metadata,
• Trade-offs between flexibility and safety.

Future-proof architecture

Ethereum, while full of possible applications, is a new technology and still developing: Everybody involved is new to the landscape and its unique challenges that keep changing as the technology evolves. That means it is quite easy to make significant mistakes.

The main reason for this is that, once uploaded, code on Ethereum can’t easily be changed or taken down unless this is specifically written into the code itself. Because Ethereum is a decentralised currency, there aren’t meant to be any backdoors.

A lack of backdoors can potentially be risky, however. It means that mistakes in the code can easily end up losing the involved parties a lot of money when the smart contracts deal with funds. Having no way of altering the code retrospectively means devs have to think way ahead: “‘Is this going to be used in 20 year’s time?’ We have to make these architecture decisions at a point when the technology is still relatively immature,” Simon explains.

Ujo has solved this conundrum with a flexible infrastructure: “Where it makes sense, we allow the team to upgrade functionality without disturbing the usage of the smart contracts,” Simon says. “At a future stage however, we will completely remove ourselves from the equation - just as intended.”

Testing

In light of this delicate dynamic, testing code in Ethereum is even more important than in other scenarios. Even if the code allows for updates, bugs could still lose funds to hackers targeting the weak spots.

Generally, a build goes through three different stages: local testing with a simulated environment, testing on a live test network (called testnet), and then finally uploading to the main Ethereum network.

The first are test clients (e.g. test RPC). Here a developer can simulate interactions of the code in a complete local blockchain on their computer. This blockchain is not connected to anything else and doesn’t have block times.

Once these tests are completed, the testing upgrades to test networks: Here the dev is actually testing and interacting with a live blockchain. This allows them to test how the code works around idiosyncrasies such as block times (see below).

Block Time

At the moment, Ethereum has a block time of 15 seconds. While it is likely to be reduced in the future due to scalability upgrades of the main Ethereum network, this currently means a limbo of 15 seconds. Compared to Bitcoin’s 10 minute block time, this might seem negligible but it nevertheless has practical implications.

In Ujo’s case, for example, it means that when someone submits a claimant to buy an artist’s album, the payment is in limbo for 15 seconds. This is a technical challenge and also influences the user experience: “Things are supposed to be instant,” Simon says. “No one’s going on Facebook thinking: ‘Wait, you have 10 seconds before this like goes through.’ That’s not what we expect from our user experience.”

Ethereum developers thus have to write a lot of asynchronous code because the state on the front end can’t be held for 15 seconds. It has to first issue the transaction, and when the asynchronous response comes back, update the front-end. This is why frameworks like React/Redux are useful. They deal with asynchronous state changes better than other front-end frameworks.

Simon also recommends Truffle and Web3. Among others, they provide build files to easily interact with smart contracts from the front-end and offer default RPC calls to Ethereum clients.

Where it also makes sense, once a transaction is submitted, the front-end doesn’t have to wait for the transaction to be confirmed.

Connecting to the internet

Ethereum itself cannot reach out to the internet for any external data it may need. It has to be done “manually” - an additional hurdle for builds.

A classic example is pricing information. For a release on Ujo, users are paying with Ether to download the album. Because cryptocurrencies are notoriously volatile, Simon’s team had to make sure that the price stays equivalent to $10. To do that, they wrote a smart contract that contains constant pricing information, called an oracle. An oracle is a service that injects external information into Ethereum.

The oracle fetches information from an outside exchange, say Kraken, and takes the US dollar price of Ether to inject it into a contract on Ethereum.

The Ujo contract that deals with the licensing of the music, connects with this oracle and asks: “What’s the current dollar price of an Ether?” It then compares if the user has enough Ether to pay and can then transfer the license in question.

Initially, developers had to set up this entire infrastructure themselves through separate Ethereum nodes - a minefield of potential bugs: “For the Imogen Heap prototype, one day I woke up and realised the money was gone for the oracle we ran ourselves. The ether was missing,” Simon recalls. He realised that he had not made the RPC on the Ethereum client secure enough. “People were port-scanning on Ethereum for insecure RPCs, issuing RPC calls and seeing if there’s money they can take.”

Now there’s a service called Oraclize. Platforms like Ujo now just need to take their smart contracts that say what information they want updated from which URL. The service listens to the Ethereum blockchain and knows that someone fired a request and paid. Oraclize then goes back into a callback function of the on-chain oracle, injects the price and gives the result automatically. “It’s so cool. I just have to keep the smart contract topped up with money,” Simon says. “It keeps running and you’ll see it in the blockchain every two hours or so, depending on the chosen interval. It only costs about 10-40 cents per update.”

Hosting metadata

In theory, metadata like artist names and song titles can be put into Ethereum. However, it would be incredibly costly to do so because the whole blockchain is replicated across all the nodes in the system. That’s why you generally only store consensus-critical data in it - in other words, data that helps participants to agree on terms set forth in the smart contracts.

In addition, it is more difficult to get the info out if you want to use it for various purposes. For example: If you want to build an application using the metadata and have not worked with Ethereum before, you would have to build libraries that deserialise the information stored in Ethereum. “We initially started putting all the metadata into Ethereum even though it was more costly, because we wanted to have less moving parts and just build something,” Simon says. But the team quickly realised that it was not going work. The metadata had to be stored in a different network, due to costs and ease of use for application developers to build on this licensing platform. Currently, the metadata is hosted on IPFS, but they are looking at systems such as IPDB to host metadata.

Trade-off: simplicity vs. safety

Because smart contracts are still relatively new, the contract language Solidity is growing along with the needs of the ecosystem. Initially, it was designed to look similar to Javascript, but has over time come to look like something between Javascript and C. As more and more problems surface, Solidity keeps changing.

“There’s a trade-off in terms of making the contract language easy to read and understand while also making sure that it is safe,” Simon explains.

Making it easier to read or use attracts more developers who don’t necessarily understand the complexities and nuances of the language. Making it safer by default however might mean adding unintuitive guardrails.

While Solidity functions currently run public by default, Simon thinks that this is not very safe: “My personal perspective is that the language should be as secure as possible by default and then allow developers to consciously take off the training wheels for more flexibility if they know what they are doing,” he says. This would certainly avoid the issue of making sensitive elements public by accident, such as what happened with the recent Parity multi-signature wallet. Common best practices for ensuring that the code is secure are still not exhaustive. A list that Simon kickstarted showcases some of the common pitfalls to avoid.

A look forward

Blockchain systems like Ethereum provide exciting new ways to think about how we organise ourselves in the 21st century. There’s a lot of potential to reduce barriers to entry for many in the world, and, in the case of Ujo Music, making it easier to license music so artists can make more of a living. With this new world, it comes with its own unique sets of challenges for developers that not many might be aware of. Like Spiderman coming to terms with his new powers and responsibilities, weaving a new web isn’t always straightforward.

With Ethereum recently celebrating its second birthday, many developer tools have been built in this short time: such as Truffle and testRPC. As new developers are joining, the tools are maturing!