Why I think we’re at least two years away from mainstream blockchain adoption

and opportunities to be in the right place when it happens

I’ve spent the last three and a bit years working on blockchain / distributed ledger technology in some way, shape or form. The article below is based on my experiences and observations; if you’ve come across anything that contradicts what I’ve written I’d love to hear about it.

Things have come a long way in the ten years since Satoshi published his / her / their revolutionary whitepaper describing a new peer-to-peer electronic cash system underpinned by distributed ledger, or blockchain, technology (DLT). We’ve seen the launch of countless new protocols from Ethereum to Neo to Tezos, corporates left right and Scentre announcing blockchain pilots almost daily, and Don Tapscott’s TED talk reaching 4m of us (and counting) around the world in three years alone.

Or have they? DLT has gone through boom and bust, hard forks and soft forks, ICOs, STOs, utility tokens, altcoins, $hitcoins, stablecoins… so why has it still not gone mainstream?

From spending the last three years both working on DLT products and reviewing platforms built by others, I’ve come across two major barriers that are holding the technology back: these are poor user experience (UX) and lack of trust.

The huge community of developers, designers, engineers, regulators and everyone else involved are solving the underlying issues creating these barriers every day, but projecting forward a rough pace of change based on nothing scientific but my own experience I think we’re at least two years away from this tech really being adopted by the masses — and by that I mean being used by a large number of people at least once a day. Large is subjective yes, but I’m talking Dropbox / iTunes levels for B2C, and Microsoft Office / AWS levels for B2B, so not exactly trivial numbers of people.

So what is it about UX and trust that is so important?

Success for a new product or technology is like a secret sauce — there’s no exact recipe to getting it right but people broadly agree on what ingredients need to go in.

UX and trust are two key elements of the secret sauce, and companies have to get these two things (amongst others) absolutely nailed to go big. Look at the likes of Facebook; great UX but massive user drop off following the Cambridge Analytica scandal leading to a huge erosion in trust (60% of Americans don’t trust Facebook). Similarly Britain’s banks have been losing customers to challenger banks such as Monzo because their UX just doesn’t stack up to what is expected by the modern consumer.

Hit that sweet spot though and you’re onto a winner; Amazon’s retail and cloud computing services are two of the world’s most trusted, coupled with a great UX and you’ve got market leadership in both areas.

Where there are challenges there are also opportunities. Below I outline some of the biggest UX and trust issues I’ve come across in the last three years, and my perspective on opportunities that exist to solve them.


Issue one: Transaction speeds are too slooowww

Yes, for UX it is an issue that Ethereum can process 15 transactions per second and visa can process 1,700. And I don’t see this as an issue so much from a new monetary value / mass transaction point of view, but more from a contract function execution point of view. Designing smart contracts into applications is great and has a host of benefits covered well enough in other articles for me to need to articulate them here, but application architects need to be smart about where they are used and the depth of processing needed by each one. Every time a smart contract is executed, a modification is made to the blockchain. That modification requires verification which takes time. If your smart contract is placed at a key point in your user journey where your user doesn’t have huge amounts of time, you’re going to ruin their user experience (I’ve made this mistake).

Opportunity one: Firstly, you can work on sharding on the protocol to speed up transactions. Ethereum transaction speeds are projected to increase massively in the coming years (I won’t quote a number as there are too many contradictory opinions), so get involved and be at the forefront of this protocol’s evolution. Second, learn to become really smart at dApp design. This might be how, where and when you use smart contracts right down to an individual function choice level. Users are used to quick responses in apps, web interfaces etc., so if you can bring that experience to your DLT platform you’re already beating most…

Issue two: Smart contracts are difficult to read and write (for the layman)

Solidity became the go-to language to learn during the crypto boom of late 2017 leading to a massive market-wide skills increase, and with tools like Lorikeet making smart contract writing more accessible you’d think they’d be underpinning more dApps and consortia arrangements than they are… There is still a long way to go until layman lawyers can understand how to read and write .sol, but maybe this will become a more standard skillset expected of deal makers and breakers in the future.

Opportunity two: Create a tool that translates smart contract code into common written languages such as English. Countless conferences since 2013 have preached this new paradigm of agreement, but until your layman lawyer can easily understand code functions uptake will be stalled. Or if you’re a lawyer learn a smart contract language… Or if you’re a software engineer learn to become a lawyer… I’m not sure which is easiest.

Issue three: Public / private key pairings are (too) secure

Private / public key pairings are one of DLT’s big selling points for security. If you keep your private key to yourself it is effectively impossible to steal your assets. But if that key goes missing then so does access to those assets; no password reset. Just look at Quadriga to find out more about the problems that can cause. In this day and age users just aren’t ready to forego password resets yet. If you think about the number of passwords most people have across so many accounts, that ‘Forgot password’ prompt gets used all too often. Before DLT apps go mainstream there needs to be widespread education that losing your private key means losing it for good.

Opportunity three: Design a password manager style tool to manage private keys that can be recovered if forgotten. This type of technology is already in use effectively in cold storage wallets like the Ledger Nano S, but an online version that can sit on the front end of a dApp could be really powerful.

Ultimately a lot of the UX arguments come down to selecting the right use case. Blockchain isn’t ready for a rapid processing consumer facing application yet, but in its current form is more applicable to enterprise grade solutions where adding some seconds to wait for a validated contract execution doesn’t cause the user to delete the app never to be used again. Similarly as more and more software engineers climb out of their ICO cabins buried under a crypto winter snowdrift to seek warmth in larger enterprises, the solidity skillset will steadily proliferate across a broader range of industries.


Issue one: There is a fundamental lack of understanding in how the technology works

There is a distinct irony that DLTs emerged to move trust in transactions with unknown parties away from intermediaries to technology, but a lack of understanding in this technology is pushing people back to intermediaries to provide the trust they seek. This is evidenced more than most with the launch of Libra. Facebook have handpicked some of the world’s most trusted brands to provide consensus, as opposed to random pool of participants (think Ethereum, Bitcoin etc.), which adds a layer of trust over their platform that for a lot of people doesn’t exist in other protocols. Whole industries have sprung up around this issue, but it ultimately comes down to a lack of understanding in how the technology works, which I why I think there’s a way to go until people trust the algorithms.

Opportunity one: Educate your friends, colleagues, family; whoever will listen. And if you need educating then get along to a local meetup and drink the cool aid; there are some in most cities and most are free. Alternatively grab a book, some of my favourites are Blockchain Revolution by Don and Alex Tapscott, The Truth Machine by Michael Casey and Paul Vigna and The Blockchain and the New Architecture of Trust by Kevin Werbach.

Issue two: Everyone can see transactional data

One of the ways that the immutable ledger is maintained on a large number of protocols is through transparency of transactional data. Giving your competitors or companies you buy from what is essentially your bank account balance and transaction history understandably doesn’t sit too well with some, and pushes a lot of users away from mainnet protocols into the bowls of a growing number of incompatible private chains that would be much more efficiently run as central cloud databases anyway, not solving the problem in any way at all.

Opportunity two: Use or build on protocols like Monero that maintain privacy across transactions, or design a method to maintain transaction privacy across popular mainnets like Ethereum. Nightfall uses Zero Knowledge Proof mathematics to deliver the first working version of transaction privacy to Ethereum; the code is open source so jump on into the Github and get involved. Alternatively integrating a notary node into a consortium arrangement can provide parties with the confidence that transactions are executing correctly, without the need to disclose transaction details to any party other than the parties consummate to the transaction itself. See Corda.

Issue three: What if the ledger becomes an immutable record of incorrect information…?

The data that triggers smart contracts (and therefore a large number of transactions) often comes from off-chain sources. This is called oracle data. DLTs are great for keeping immutable records of data, but what if the off-chain source providing that data is wrong? Contracts requiring off-chain oracle triggers are particularly prone to exploitation and can result in large movements of value incorrectly. And moving the provision of oracle data to a ‘trusted third party’ can undermine one of the main value propositions of DLTs in the first place by just moving the intermediary control one layer up.

Opportunity three: Move consensus mechanisms to oracle data provision as well. I’ve heard some good ideas on this but am yet to see a compelling solution, and can’t think of one myself hence why the description of this opportunity is a short one… (please contact me with ideas).

It will take a while until users and enterprises alike are in a position where they are comfortable with their own understanding to place full faith in the technology. This is a well recognised issue across all industries looking to take blockchain concepts beyond just that; a proof of concept. Over time technology enablers such as regulations, testing frameworks, risks and controls best practices and governance procedures will evolve and drive uptake, but for now a healthy of dose of patience and an experimental approach will mould these enablers for the benefit of the technology’s adoption as a whole.

If you’ve got any insights I’d love to hear from you, or get in touch on LinkedIn.

Product manager. Self-titled free thinker. Rat in the race looking for a gap in the fence.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store