Designing Blockchain D-Apps, Part 2: Concept Development

This is part of a series of articles exploring how to design decentralised apps (D-Apps) using Ethereum. Part 2 of this series covers Concept Development and is designed for Business Analysts.

As part of our exploration of blockchain we’ve been learning the nuances of creating D-Apps, from inception to QA testing. This article is designed to act as a recording of the process, for anyone attempting to follow the same path. If we have something wrong, inaccurate or out of date, let us know in the comments!


We approached the project with a relatively blank slate. The goal of the concept development was to understand the use cases for blockchain and select an appropriate business case to match. Then define a technical specification that would result in testable application, even with limited development resource.

Blockchain Use Cases

Whilst blockchain has the potential to be transformative in some areas of technology, it is not a silver bullet. We began by exploring the concepts behind the technology and trying to define the strengths and weaknesses. You can read some of our insights here, but to summarise:

Blockchain strengths:

  • Distributed — Because computing power can come from a range of sources, with no centralised control, D-Apps are hard to stop.
  • Disintermediation — Two parties are able to make an exchange without the oversight or intermediation of a third party (e.g banks). With potential to save time and costs by removing the middle-men.
  • Increased Trust — Through shared processes and clear providence of transactions, public blockchains provide transparency.

Blockchain weaknesses:

  • Energy costs — Blockchains are inefficient due to the consensus required. Public blockchains (particularly Ethereum), also require “gas” to run D-Apps, which is currently fluctuating in price significantly
  • Data Storage Limits — Blockchains can be thought of as simple databases. Storage on them is limited and can be expensive, requiring additional services (oracles) to support.
  • Transaction Volume — As blockchain networks are young, they are sometimes sluggish when high volumes of transactions are submitted at the same time.
  • Immutable — Once it’s on a public blockchain, it’s permanent, placing higher value on QA than patchable releases

This led us to the conclusion that we needed to find an idea that fulfilled the following value statement:

“A simple D-App than can facilitate direct, Peer-to-Peer transactions, where trust is valuable and transactions can be completed on a day-to-day (rather than second to second) basis”

Business Cases

Over several meetings, we brainstormed a series of potential business cases that fulfilled our value statement, we decided to explore three ideas:

  1. Peer to Peer Lending — As a user, I want to be able to lend items to people I know, whilst holding their cryptocurrency until it is returned, so that I feel more confident that I will get my item back.
  2. Account Trust Score — As a user, I want to see a rating of trust for a crypto-currency account, before I send funds to it, so that I don’t send money to an account that it known to scam people.
  3. Managing Lost Keys — As a user, I want to set a backup account for my crypto-funds, so that if the private key to my account is forgotten, my funds will become available to someone I trust personally and are not lost.

Selection Criteria

We scored each of the concepts for feasibility, specifically looking at:

  • Technology — Whether the blockchain technology (we chose Ethereum as our base) was of the necessary maturity for us to build the concept on
  • Learning — Whether we had the knowledge to build the solution, and by building it we would learn something valuable
  • Resource — Whether the solution could be built and tested within a short enough timescale ~2 sprints
  • Value — Whether there was any value in the concept i.e. if we took it further than concept, could we list it on Product Hunt for users to try it out

After a few rounds of debate, we concluded that idea 1. Peer to Peer Lending, had the best simplicity to value ratio, as we could test the concept internally and launch the project without external resource. We were also aware of a good range of escrow projects already live on Ethereum, allowing us some prior art to learn from.

Specification

To conclude the Concept Development, we wrote out a loose specification:

  • Concept — The D-App will focus on Peer-t0-Peer lending of books (as we had them to hand and could play out the scenarios easier), allowing a transaction between a Owner and a Lender of a book without the need for a centralised arbitration from a library, where the book Owner can hold an escrow of the Lenders funds until the book is returned.
  • Technology — The D-App will be built on Ethereum, using Solidity for a Smart Contract, with a Bootstrap front end for the UI, with no use of traditional centralised databases, unless locally stored
  • Goal — The D-App must place something on the blockchain, via a smart contract and retrieve it, to be considered complete
  • Definition of Done — The D-App must be usable on the Ethereum testnet to be considered completed (a very loose definition of done)

This was then passed to the next phase for Design and Detailed Speccing.


Like what you read? Give Warren Fauvel a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.