I’ve been buried deep in the knowledge archives of blockchain land. It’s a dark place. There are dungeons full of white papers and peer-reviewed papers (how many of us know there is a difference?). Caverns are stacked high with sharding theories, paths have the odd pothole with proclamations of doom and failure and a couple of hippies are skipping through whilst chewing on magic pills containing stories of a post-capitalist world order.

Ok so my reality is not as whimsical or Tim Burton-esque. But it does have just as many weird and wonderful twists to keep me busy. You can check out my (hopefully) helpful post to share a few resources that I have found particularly useful in shaping a slowly solidifying world view on this domain. For this post however, I’d like to talk about the hunt for the killer app.

Hunting for the killer app

Lots of people are talking about the search for the killer app. Looking for that one utility that brings all the people to the table and ultimately validates the benefits of this technology. There are notable examples of popular attempts, such as Cryptokitties (built on Ethereum), but many of these still serve only to demonstrate that this tech is not ready for millions of users.

There are about 2k+ ƉApps (Decentralised Apps) built on Ethereum and EOS that you can explore on a site called State of the ƉApps. There are a ton of useful and useless examples and it allows you to get a sense of the most popular. Its notable that at the time of writing this blogpost, the top 5 are for advertising, hunting goblins, token exchanges and gambling. In essence, a reflection of the stuff that makes money go round on the web today.

It’s also worth noting that for every really popular ƉApp that spikes our attention and gets people talking, daily active usage numbers are still low (top app on State of the ƉApps had about 5k average) compared to the most popular web apps we’re used to. The theory goes that with enough brains and motivation, someone will crack the problem of bringing your average joe to the blockchain and decentralisation party.

Thing is, I don’t think it will happen unless we switch our thinking from apps, to services. To many, this will feel like a purely semantic issue (yes I know I have a habit of naming and renaming stuff), but I see them as different intentions. Apps feel bounded, they meet an explicit need that can be addressed between the app and the end-user with little need for external input. I think about single-player games, note taking, photo editing etc. Focus just on an app and you limit the potential of your solutions.

Services are broader, they connect the end-user to another person or an eco-system in order to serve needs for all parties. Naturally many apps that we are hooked on today are collections of services e.g. social media, banking, shopping or even in virtual gaming networks. Often build teams don’t realise or acknowledge that they are working on a service, meaning they can easily overlook all the human challenges that will present themselves and unfortunately rely on the fallacy of ‘common sense’ when gaps in the experience are exposed.

Decentralisation makes ‘Service Design’ more important

I have a working hypothesis that one of the biggest strengths and weaknesses of decentralisation is the self-organising nature of it all. In essence, an individual has control and autonomy over all their choices, no central source is responsible for co-ordinating it on their behalf. This is what attracts the mission-oriented evangelists of this field. Clawing back control from ‘the man’ is ultimately what makes this more than just a crypto-fad.

The problem is that 20 years of web-based services has taught us all to be lazy.

It’s taught us to sit back and wait to be served with all the things we need on a platter. If someone wants our attention, they do the hard work. ‘The man’ has learned this and uses it to continuously dominate our web experiences. This is also the reason why UX and Service Design have become prolific and valued disciplines in any digital organisation. I have spent most of my career educating and advocating to product teams that you don’t get users by asking them to fill in the gaps. You have to do the hard work to make your users’ lives easier.

Service design presents the strongest design approach to solve experience challenges in blockchain. Firstly because its very nature is to consider ALL of the relevant actors and factors that affect a service user and shape their needs and interactions. Secondly, we know that the nature of decentralisation means that no single entity will own all of the touch-points that are critical to a users’ experience in this space. The ideal scenario therefore is that we use service design tools to map the needs and then examine how collaborations, standards and interoperability can be used to break down those barriers.

It follows then, that in order to design a killer app for the blockchain space, we have to address people’s current mental model; the expectation of service in its most complete sense. If you design it for them and around them, people will come. So let’s embrace the fact that we should be thinking about service design holistically in this domain if we really want a killer app.

Now, where’s my idiots guide to service design in a wholly decentralised domain? ;-p

The importance of service design for blockchain’s killer apps was originally published in Chainspace on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at www.benthamsgaze.org on August 18, 2017.

Thanks to their resilience, integrity, and transparency properties, blockchains have gained much traction recently, with applications ranging from banking and energy sector to legal contracts and healthcare. Blockchains initially received attention as Bitcoin’s underlying technology. But for all its success as a popular cryptocurrency, Bitcoin suffers from scalability issues: with a current block size of 1MB and 10 minute inter-block interval, its throughput is capped at about 7 transactions per second, and a client that creates a transaction has to wait for about 10 minutes to confirm that it has been added to the blockchain. This is several orders of magnitude slower that what mainstream payment processing companies like Visa currently offer: transactions are confirmed within a few seconds, and have ahigh throughput of 2,000 transactions per second on average, peaking up to 56,000 transactions per second. A reparametrization of Bitcoin can somewhat assuage these issues, increasing throughput to to 27 transactions per second and 12 second latency. Smart contract platforms, such as Ethereum inherit those scalability limitations. More significant improvements, however, call for a fundamental redesign of the blockchain paradigm.

This week we published a pre-print of our new Chainspace system — a distributed ledger platform for high-integrity and transparent processing of transactions within a decentralized system. Chainspace uses smart contracts to offer extensibility, rather than catering to specific applications such as Bitcoin for a currency, or certificate transparency for certificate verification. Unlike Ethereum, Chainspace’s sharded architecture allows for a ledger linearly scalable since only the nodes concerned with the transaction have to process it. Our modest testbed of 60 cores achieves 350 transactions per second. In comparison, Bitcoin achieves a peak rate of less than 7 transactions per second for over 6k full nodes, and Ethereum currently processes 4 transactions per second (of a theoretical maximum of 25). Moreover, Chainspace is agnostic to the smart contract language, or identity infrastructure, and supports privacy features through modern zero-knowledge techniques. We have released the Chainspace whitepaper, and the code is available as an open-source project on GitHub.

System Overview

The figure above illustrates the system design of Chainspace. Chainspace is comprised of a network of infrastructure nodes that manage valid objects and ensure that only valid transactions on those objects are committed. Let’s look at the data model of Chainspace first. An object represents a unit of data in the Chainspace system (e.g., a bank account), and is in one of the following three states: active (can be used by a transaction), locked (is being processed by an existing transaction), or inactive (was used by a previous transaction). Objects also have a type that determines the unique identifier of the smart contract that defines them. Smart contract procedures can operate on active objects only, while inactive objects are retained just for the purposes of audit. Chainspace allows composition of smart contracts from different authors to provide ecosystem features. Each smart contract is associated with a checker to enable private processing of transactions on infrastructure nodes since checkers do not take any secret local parameters. Checkers are pure functions (i.e., deterministic, and have no side-effects) that return a boolean value.

Now, a valid transaction accepts active input objects along with other ancillary information, and generates output objects (e.g., transfers money to another bank account). To achieve high transaction throughput and low latency, Chainspace organizes nodes into shards that manage the state of objects, keep track of their validity, and record transactions aborted or committed. We implemented this using Sharded Byzantine Atomic Commit (S-BAC) — a protocol that composes existing Byzantine Fault Tolerant (BFT) agreement and atomic commit primitives in a novel way. Here is how the protocol works:

• Intra-shard agreement. Within each shard, all honest nodes ensure that they consistently agree on accepting or rejecting a transaction.
• Inter-shard agreement. Across shards, nodes must ensure that transactions are committed if all shards are willing to commit the transaction, and rejected (or aborted) if any shards decide to abort the transaction.

Consensus on committing (or aborting) transactions takes place in parallel across different shards. A nice property of S-BAC’s atomic commit protocol is that the entire shard — rather than a third party — acts as a coordinator. This is in contrast to other sharding-based systems with cryptocurrency application like OmniLedger or RSCoin where an untrusted client acts as the coordinator, and is incentivized to act honestly. Such incentives do not hold for a generalized platform like Chainspace where objects may have shared ownership.

Chainspace also supports transparency and auditability. Its operation is divided into time periods called epochs, and each shard maintains a hash chain that represents transactions processed in each epoch, as described below:

• Compute checkpoint. In every epoch, nodes in each shard agree on a checkpoint: a block (Merkle tree) of evidence including transactions processed in the current epoch, and signed promises from other nodes.
• Extend hash chain. They then extend their hash chain by hashing the root of this Merkle tree and a block sequence number, with the head hash of the chain so far, to create the new head of the hash chain. Each peer signs the new head of their chain, and shares it with all other peers in the shard, and anyone who requests it.

Threat Model and Security Properties

Chainspace supports security properties against two polynomial time bounded adversaries:

• Honest Shards (HS) may create arbitrary contracts, and input arbitrary transactions into Chainspace, however they are bound to only control up to f faulty nodes in any shard. As a result, and to ensure the correctness and liveness properties of Byzantine consensus, each shard must have a size of at least 3f+1 nodes.
• Dishonest Shards (DS) has, additionally to HS, managed to gain control of one or more shards, meaning that they control over f nodes in those shards. So its correctness or liveness may not be guaranteed.

Given this threat model, Chainspace supports the security properties below:

• Transparency. Chainspace ensures that anyone who possesses the identity of a valid object may authenticate the full history of transactions and objects that led to the creation of the object.
• Integrity. Subject to the HS threat model, when one or more transactions are submitted only a set of valid non-conflicting transactions will be executed within the system. This includes resolving conflicts — in terms of multiple transactions using the same objects — ensuring the validity of the transactions, and also making sure that all new objects are registered as active. Ultimately, Chainspace transactions are accepted, and the set of active objects changes, as if executed sequentially.
• Encapsulation. The smart contract checking system of Chainspace enforces strict isolation between smart contracts and their state — thus prohibiting one smart contract from directly interfering with objects from other contracts. Where cross-contract calls are supported, this is mediated by well defined interfaces providing encapsulation.
• Non-repudiation. In the case where conflicting or otherwise invalid transactions were accepted in honest shards (in the case of the DS threat model), then evidence exists to identify the parties or shards in the system that allowed the inconsistency to occur. As a result, failures outside the HS threat model are detectable; the guilty parties may be banned, and appropriate off-line recovery mechanisms could be deployed.

Implementation and Evaluation

We implemented a prototype of Chainspace (released as an open-source project) in about 10k lines of Python and Java code. The implementation consists of two components: a Python contracts environment and a Java node. The Python contracts environment allows developers to write, deploy and test smart contracts. The Java node implements a shard replica that accepts incoming transactions from clients and initiates, and executes, the S-BAC protocol. We developed a number of key system smart contracts (providing flexible policies about managing shards, smart contract creation, auditing and accounting) and application smart contracts (smart-meter private billing, and smart voting system) and evaluated their performance to validate support for high-integrity and high-privacy applications (see the whitepaper for details).

Here we present our evaluation of the performance and scalability of Chainspace, through deployments on Amazon EC2 containers. We launched up to 96 nodes on t2.medium virtual machines, each containing 8 GB of RAM on 2 virtual CPUs and running GNU/Linux Debian 8.1. We sent transactions to the network from a Chainspace client running on a t2.xlarge virtual machine, containing 16 GB of RAM and 4 virtual CPUs, also running GNU/Linux Debian 8.1. In our tests, we map objects to shards randomly.

The figure above measures the effect of the number of shards on transaction throughput. We see that the transaction throughput of Chainspace scales linearly with the number of shards: with 4 nodes per shard, the number of transactions per second (t/s) increases on average by 22 for 1-input transactions for each shard added. This is because as inputs are randomly assigned to shards based on their hashes, the transaction processing load is spread out over a larger number of shards.

Another important metric of scalability is the client-perceived latency — the time from when a client submits a transaction until it receives a decision about whether the transaction has been committed — under varying system loads expressed in terms of transactions received per second. The figure above shows the effect of transactions received by the system per second (all 1-input transactions) on client-perceived latency for 2 shards, each having 4 nodes. In the previous figure, we found that the average throughput for a Chainspace system with similar configuration is 75 1-input transactions per second. Consequently, we observe here that the increase in latency with varying system loads is smaller for 20 t/s–60 t/s (average 69 ms), but the values start to get bigger after 60 t/s (average 210 ms). This is when the system reaches its maximum transaction throughput, causing a backlog of transactions to be processed.

Limitations and Improvements

While Chainspace shows promising results with respect to scalability, it comes with some limitations and open areas that we plan to tackle in future work:

Avoiding dishonest shards. The integrity properties of Chainspace rely on all shards managing objects being honest, namely containing at most f fault nodes each. As Chainspace allows any set of nodes to create a shard, the function mapping objects to shards must avoid dishonest shards. Our isolation properties ensure that in the worst case a dishonest shard can affect state from contracts that have objects mapped to it. For this reason, Chainspace allows the contract creator to designate which shards manage objects from their contract. This embodies specific trust assumptions where users have to trust the contract creator both for the code (which is auditable) and also for the choice of shards to involve in transactions — which is also public.

Recovery from malicious shards. In case one or more shards are malicious, we provide an auditing mechanism for honest nodes in honest shards to detect the inconsistency and to trace the malicious shard. However, it is not clear how to automatically recover from detecting such an inconsistency. Options include: forcing a fork into one or many consistent worlds; applying a rule to collectively agree the canonical version; patching past transactions to recover consistency; or agree on a minimal common consistent state.

Suitable fee structure. Checkers involved in validating transactions can be costly. For this reason, we allow peers in a shard to accept transactions subject to a Chainspace payment to the peers. However, this ‘flat’ fee is not dependent on the cost or complexity of running the checker which might be more or less expensive. Ethereum instead charges gas according to the cost of executing the contract procedure — at the cost of implementing their own virtual machine and language.

Graceful degradation under high contention. The S-BAC protocol ensures correctness in all cases. But under high contention for the same object the rate of aborted transactions rises. This is expected, since the S-BAC protocol in effect implements a variant of optimistic concurrency control, that is known to result in aborts under high contention. There are strategies for dealing with this in the distributed systems literature, such as locking objects in some conventional order — however, none is immediately applicable to the byzantine setting.

Messaging complexity of BFT. Chainspace uses BFT-SMART’s implementation of Practical Byzantine Fault Tolerant protocol as a black box, and inherits its O(n^2) messaging complexity. However, BFT- SMART can be replaced with any improved PBFT variant without breaking any security assumptions.

Summary

We presented the design of Chainspace — an open, distributed ledger platform for high-integrity and transparent processing of transactions. Chainspace offers extensibility though privacy-friendly smart contracts. We presented an instantiation of Chainspace by parameterizing it with a number of system and application contracts, along with their evaluation. Unlike existing smart-contract based systems such as Ethereum, Chainspace offers high scalability through sharding across nodes using a novel distributed atomic commit protocol called S-BAC, while offering high auditability. We presented an implementation and evaluation of S-BAC on a real cloud-based testbed under varying transaction loads and showed that Chainspace’s transaction throughput scales linearly with the number of shards by up to 22 transactions per second for each shard added, handling up to 350 transactions per second with 15 shards. As such, it offers a competitive alternative to both centralized and permissioned systems, as well as fully peer-to-peer, but unscalable systems like Ethereum.

We have released the Chainspace whitepaper, and the code is available as an open-source project on GitHub. We would be happy to receive your feedback, thoughts, and suggestions about Chainspace via comments on this blog post, or email.

The Chainspace project was originally developed, and funded, in the context of the EU H2020 Decode project, the EPSRC Glass Houses project and the Alan Turing Institute. We published and presented Chainspace at The Network and Distributed Systems (NDSS), a top peer-reviewed security conference, in 2018. We co-founded Chainspace Ltd. in Aug’18 to independently continue our exciting journey on the road to decentralised infrastructure design.

Chainspace: A Sharded Smart Contracts Platform was originally published in Chainspace on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ll be exhibiting with DECODE at the EU’s ICT Imagine Conference and Exhibition in Vienna from the 4th-6th December 2018. Find out more on the ICT 2018 Imagine Digital website.

The idea that sparked Chainspace was conceived two years ago as an exploratory exercise between friends. Can we solve the inherent limitations presented by existing blockchain technologies? We felt strongly that we could and using our networks and connections, invested in the academic research and prototyping that enabled us to validate and verify the solutions we brought to the table.

During this initial period of research incubation, we were invited to collaborate with an EU funded initiative as part of the DECODE project. DECODE provides tools that puts individuals in control of whether they keep their personal data private or share it for the public good. A fantastic initiative led by a pioneering and visionary team, it provided us with a great use-case for the design of Chainspace. Demonstrating not just the technical utility, but the real world value that comes from using a blockchain technology.

Along with the DECODE partner organisations, global software consultancy ThoughtWorks prototyped a number of solutions that use the Chainspace design to deliver decentralised civic services, including a citizen-run “FairBnB” and cryptographically secure petitions platform for e-democracy. This year, DECODE will launch a pilot project for petitions in Barcelona, with more pilot projects to come next year.

We are extremely proud of the vision that drives DECODE, it allows us to really consider the kinds of problems blockchain technology can contribute to solving and it challenges us to push hard for value.

You can find out more about DECODE, its pilots and research work via their website. Alongside this, the project runs a series of symposiums, hackathons and a summer school focused on issues relating to privacy and the intersection between automation, AI and data.

We will be exhibiting with DECODE at the ICT Imagine Digital conference in Vienna from the 4th — 6th December 2018. If you’re going, please come by to say hi.

DECODE: Powering civic good with a blockchain was originally published in Chainspace on Medium, where people are continuing the conversation by highlighting and responding to this story.

Coconut: Threshold Issuance Selective Disclosure Credentials with Applications to Distributed Ledgers

Selective disclosure credentials allow the issuance of a credential to a user, and the subsequent unlinkable revelation (or ‘showing’) of some of the attributes it encodes to a verifier for the purposes of authentication, authorisation or to implement electronic cash. While a number of schemes have been proposed, these have limitations, particularly when it comes to issuing fully functional selective disclosure credentials without sacrificing desirable distributed trust assumptions. Some entrust a single issuer with the credential signature key, allowing a malicious issuer to forge any credential or electronic coin. Other schemes do not provide the necessary re-randomisation or blind issuing properties necessary to implement modern selective disclosure credentials. No existing scheme provides all of threshold distributed issuance, private attributes, re-randomisation, and unlinkable multi-show selective disclosure.

We address these challenges in our new work Coconut — a novel scheme that supports distributed threshold issuance, public and private attributes, re-randomization, and multiple unlinkable selective attribute revelations. Coconut allows a subset of decentralised mutually distrustful authorities to jointly issue credentials, on public or private attributes. These credentials cannot be forged by users, or any small subset of potentially corrupt authorities. Credentials can be re-randomised before selected attributes being shown to a verifier, protecting privacy even in the case all authorities and verifiers collude.

Applications to Smart Contracts

The lack of full-featured selective disclosure credentials impacts platforms that support ‘smart contracts’, such as Ethereum, Hyperledger and Chainspace. They all share the limitation that verifiable smart contracts may only perform operations recorded on a public blockchain. Moreover, the security models of these systems generally assume that integrity should hold in the presence of a threshold number of dishonest or faulty nodes (Byzantine fault tolerance). It is desirable for similar assumptions to hold for multiple credential issuers (threshold aggregability). Issuing credentials through smart contracts would be very useful. A smart contract could conditionally issue user credentials depending on the state of the blockchain, or attest some claim about a user operating through the contract — such as their identity, attributes, or even the balance of their wallet.

As Coconut is based on a threshold issuance signature scheme, that allows partial claims to be aggregated into a single credential, it allows collections of authorities in charge of maintaining a blockchain, or a side chain based on a federated peg, to jointly issue selective disclosure credentials.

System Overview

Coconut is a fully featured selective disclosure credential system, supporting threshold credential issuance of public and private attributes, re-randomisation of credentials to support multiple unlikable revelations, and the ability to selectively disclose a subset of attributes. It is embedded into a smart contract library, that can be called from other contracts to issue credentials. The Coconut architecture is illustrated below. Any Coconut user may send a Coconut request command to a set of Coconut signing authorities; this command specifies a set of public or encrypted private attributes to be certified into the credential (1). Then, each authority answers with an issue command delivering a partial credentials (2). Any user can collect a threshold number of shares, aggregate them to form a consolidated credential, and re-randomise it (3). The use of the credential for authentication is however restricted to a user who knows the private attributes embedded in the credential — such as a private key. The user who owns the credentials can then execute the show protocol to selectively disclose attributes or statements about them (4). The showing protocol is publicly verifiable, and may be publicly recorded.

Implementation

We use Coconut to implement a generic smart contract library for Chainspace and one for Ethereum, performing public and private attribute issuing, aggregation, randomisation and selective disclosure. We evaluate their performance, and cost within those platforms. In addition, we design three applications using the Coconut contract library: a coin tumbler providing payment anonymity, a privacy preserving electronic petitions, and a proxy distribution system for a censorship resistance system. We implement and evaluate the first two former ones on the Chainspace platform, and provide a security and performance evaluation. We have released the Coconut white-paper, and the code is available as an open-source project on Github.

Performance

Coconut uses short and computationally efficient credentials, and efficient revelation of selected attributes and verification protocols. Each partial credentials and the consolidated credential is composed of exactly two group elements. The size of the credential remains constant, and the attribute showing and verification are O(1) in terms of both cryptographic computations and communication of cryptographic material — irrespective of the number of attributes or authorities/issuers. Our evaluation of the Coconut primitives shows very promising results. Verification takes about 10ms, while signing an attribute is 15 times faster. The latency is about 600 ms when the client aggregates partial credentials from 10 authorities distributed across the world.

Summary

Existing selective credential disclosure schemes do not provide the full set of desired properties needed to issue fully functional selective disclosure credentials without sacrificing desirable distributed trust assumptions. To fill this gap, we presented Coconut which enables selective disclosure credentials — an important privacy enhancing technology — to be embedded into modern transparent computation platforms. The paper includes an overview of the Coconut system, and the cryptographic primitives underlying Coconut; an implementation and evaluation of Coconut as a smart contract library in Chainspace and Ethereum, a sharded and a permissionless blockchain respectively; and three diverse and important application to anonymous payments, petitions and censorship resistance.

We have released the Coconut white-paper, and the code is available as an open-source project on GitHub. We would be happy to receive your feedback, thoughts, and suggestions about Coconut via comments on this blog post.

The Coconut project is developed, and funded, in the context of the EU H2020 Decode project, the EPSRC Glass Houses project and the Alan Turing Institute.

Coconut: Threshold Issuance Selective Disclosure Credentials with Applications to Distributed… was originally published in Chainspace on Medium, where people are continuing the conversation by highlighting and responding to this story.

A couple of weeks ago I started work at Chainspace. Chainspace is platform for decentralised services that allows other developers to build solutions on top. Think of it as a way of making it possible for any developer to use a blockchain. It’s one of a new cohort of infrastructure offerings, looking to normalise the use of blockchain in areas other than cryptocurrencies.

Having spent much of my career being technology agnostic and focused on the bigger picture as I saw it, its a wild departure for me to commit to working on essentially a single technology solution. For me there are two immutable factors that made the difference.

1. It’s the future yo.

The research behind Chainspace is second-to-none and comes from my alumnus UCL, headed up by the insanely smart George Danezis. George is another person I’m very excited to work with (see point 2 below) alongside the researchers in the team Shehar Bano, Mustafa-al-Bassam, and Alberto Sonnino. It’s not just a Blockchain, it’s a bloody good one backed with outstanding thinking on how to address issues like scalability, capacity and speed. That’s about as technical and marketing as I’ll get about that in this post . If you want more info, go look up the whitepapers. They’re very good.

2. Reunited with my tribe.

I believe in the power of cohesive teams. I’ve experienced what happens when you work with people who bring out the best in you and vice versa. It’s a drug and one I’m addicted to. I’ve spent the last 18months working primarily solo and it didn’t take that much to tempt me back to the heady highs of working with Dave Hrycyszyn, Penny Andrews, Andy Bennett and Ramsey Khoury. These individuals and others in the team are more than just colleagues, they’re friends I get to work with and that means a huge amount to me.

I know I’m fortunate to have achieved co-worker nirvana a couple of times now, even more so to be able to recreate it at Chainspace.

About the blockchain thing

The criticisms of Blockchain centre mainly on the argument that it is a solution in search of a problem. Its also surrounded by hyperbole of the next big thing and the bloodlust of speculators and hustlers. So let me quickly debunk theories of hype here (Decentralised Social) and here (Chainspace powered EU Data & Privacy) and here (Blockchain for Homeless ID). There are also wonderfully esoteric (but actually probably accurate future scenarios and use-cases) ideas that are worth exploring like Liberal Radicalism, a system for funding public goods and Augur, the prediction market protocol.

Blockchain is a very good solution to a number of problems. But like many things before it, if you are obsessed with the technology you may be missing the wood for the trees.

I’ve naturally gravitated towards this field because I truly believe that decentralisation is in the vanguard of online tech. We are living in an age of peak centralisation of services across the web. And some may argue that’s just the way the cookie crumbled. However, for civic, commercial and personal interests, we need to re-consider how we enable digital services at scale, whilst preserving transparency, agency and accountability. These are not actually technology problems, they’re societal problems that we can’t ignore.

Tim Berners Lee himself has said that he wishes the internet had lived up to the decentralised ideals it started out with, but these ideals were not baked in to the way the internet worked so it was possible for a few actors to gain control. Decentralisation is an opportunity to claw back some control. Now most of us will still need the internet to access any decentralised services, so this is not some Silicon Valley-esque sentiment (or maybe it is!). What is novel and exciting is that decentralisation can support the need for individuals and businesses to take ownership of how we access, benefit from and protect our own content.

But its not just going to happen by magic.

Decentralised solutions need design.

They need user experience research and planning, they need product strategy, they need governance (even more critical in decentralised environments), they need to be shaped around the needs and behaviours of real people. I am super interested in how we do this. Not least because UX is primarily a maternal discipline. We nurture users, anticipate their needs, guide their actions and help them when they trip up. All these intentions and actions imply a centre, they imply ownership and control.

What happens when there is no centre to nurture the experience? What happens when you have to plan the UX of a solution that is continuously designed and evolved by its users?

The Open source community have been dealing with these challenges for years, but I think to really grasp fully what needs to be done in this context, we will need to evolve a new practice I’m calling Decentralised Design

(Caveat yes I’m creating new things that sound a lot like things we already have. Please read on so I can give you some rationale. Also, I reserve the right to change my mind on this later!)

Decentralised design is a lot like the traditional interface-focused UX practice. There is a lot of work to do around proposition, the introduction of good design patterns for common tasks (e.g. on-boarding, identity, authentication, wallets etc) and importantly language (so much work for great UX writers to get involved in). But there are key differences between traditional design and decentralised design. As a starter, some of the bigger issues for me are as follows:

Designing for positive consequences: Because decentralised solutions are in the main open source, once they’re out, people will access it and build on it. You can’t always control the final expression, but you do need to design for consequences and outcomes.

Scenario: Some of the emerging use-cases for decentralisation are important but usually in underfunded and under-served areas e.g. homelessness. Rather than just assuming a paternalistic ‘saviour complex’ approach to designing these, we need to ensure we consider the agency of the individuals involved. What happens if they lose access? Can we make assumptions about their devices or if they even have any? How do we make these solutions sustainable?

In these contexts, we have to be extremely careful that we do not accidentally create marginalisation, simply because we thought we knew best and were excited to tickle our own fancy on doing good.

Designing for adoption: For many years to come, education will be a big part of decentralised services. This means that prospective users have to be willing to adopt new thinking, and this isn’t as easy as just telling people its good! Even the infamous and well trodden Reddit community for Explain it to me like I’m 5 has struggled to easily conceptualise blockchain. As I said earlier, understanding the technology shouldn’t be a requirement, but understanding the value actually is.

Scenario: Many businesses and civic organisations (charities, governments etc.) have developed their technology practices around the current online and digital trends. Any transition for a large organisation or service provider is unbelievably painful. Imagine you’re a local council running a critical service. If you make a decision to actually adopt this new technology, the overhead on educating your staff, let alone millions of constituents will be daunting. We have to make this easier.

Designing for behaviour change: This is a tricky one. Essentially, 20+ years of the web being primarily centralised has taught us all to behave in a particular way, specifically in a passive way. Decentralised services need more active behaviours to become the norm.

Scenario: Healthcare is a possible domain for decentralised services to thrive. Giving individuals more flexibility with their medical information and servicing choices. However, many of us may have instant concerns, do we trust ourselves with such important information? How do help people understand health needs in a transactional way? How do we teach people to behave differently without making them feel like they’re stupid or behind the curve? How do we ensure people feel safe?

On the face of it, because these are not interface level considerations, they feel like a mix between Service Design and UX Strategy. And maybe that combination of disciplines covers where we’ll end up. However, the context of a decentralised environment creates a tougher learning curve for designers. As well as needing to build a certain level of domain knowledge around a particular decentralised service (sometimes known as Decentralised Apps or ƉApps), designers will have to do the hard work on behalf of users and really get to grips understand why a decentralised approach is better than a classic centralised one.

There are many many new and complex use-cases for decentralised services (I’ll start talking in detail about these in future posts), but the fundamental challenge I come back to as I start learning about the potential, is that we cannot allow these use-cases to evolve as a consequence of technological possibilities.

I don’t underestimate the inherent complexity in defining new and appropriate domain models for this environment. I think it’s a tough ask, but a necessary one.

I believe we have to create a group of designers and developers that is armed with tools to design specifically for the decentralised environment. This is a responsibility, because the things that become popular and normal in the next couple of years will become the fundamental premises that affect the next generation of services.

The call is out to get more designers

There are a number of use-cases where the decentralised community is asking for design’s help to do a better job. One of the biggest problems in cryptocurrencies at the moment is that people are losing their private keys or having them stolen. Why? You could say it’s carelessness on behalf of the user. I think it’s because wallets were an incidental feature of owning crypto currency. They haven’t been through the rigour of being planned as a critical product proposition. And that lack of design, shows itself in the resulting user behaviours.

Design help is needed to look at identity, on-boarding, fundamentals of transactions and tokens and many many more. This podcast from ZeroKnowledge.fm shares some great thoughts from a UX UnConference held in Toronto earlier this year.

This challenge is what I’m doing at Chainspace.

I’m joining 2-years into the academic work, a few months into the speculative product development, one month into becoming an actual business (woohoo) and a month or so before we close our seed round.

Its a classic start-up environment. We have no real job titles right now, we’re just making this thing. We want to create the best developer experience we can for those who will build on top of it. We want to solve the inherent challenges in performance and availability of decentralised services, in a way that removes those issues from the discussions around blockchain. We want Chainspace to gracefully, elegantly and without ego, do the best job it can for the fields where we already have strong use cases like civic services, finance, healthcare, data privacy and security.

But is this really going to be about user needs?

So this is where it will get interesting. To demonstrate that we can add value, every part of the work we do needs to have a high level of rigour. I’m not talking about peer reviews and all that (although I do expect some academic papers to fall out of this). I mean rigour in that we need confidence that in a real, decentralised, peer-to-peer world, people will actually use what we’ve built. Because once it’s out, we won’t control it.

Are our UX tools fit for the job? I’m not sure. I’m going to have to blend, hack and adjust my toolkit. I’m excited about incorporating things I’ve not done before (like using Design Fiction). There are very very few designers publicly sharing in this space, although we’re tracking every blog post, podcast, article and video we can find on the subject.

I am not phased. I will fail, and I commit to sharing all of the learnings. I also expect to succeed, both in terms of finding good usable solutions, but also in building a better conversation and practice of design in decentralised services. Putting my neck on the line, I’ve already submitted pitches to two conferences, a UX one and a Blockchain one. No guarantees I’ll get into either, but both are this year, so we have to get this learning train moving.

Decentralised Design needs designers AND developers

This is about doing the groundwork to create a community that has a shared interest in solving key challenges in this space. Naturally, as a designer my home is in the design field. However I have always believed in effective collaborations with developers. And for this endeavour, I’m making extra effort to learn high geek (for understanding whitepapers you see), thus, I’d like to welcome the developer community too.

We have to collaborate in order to build the level of knowledge needed within the design community. Equally, I think its important that we acknowledge how the technological advances in the field will continue to inform and transform our design approaches. There are many cases where a mutual learning journey adds to the greater good, this is definitely one where you can get biblical with iron sharpening iron (or steel sharpens steel….FYI this is not an open call for religious discourse).

If you’ve read this far, thank you! I’d love to hear your thoughts, it takes a community to build a community and all that jazz.

Decentralised Design — My new journey was originally published in Chainspace on Medium, where people are continuing the conversation by highlighting and responding to this story.