Blockchain Usability Checklist

How have blockchains become more usable starting from the protocol layer and surrounding infrastructure.

To help censorship resistant, immutable, and permissionless blockchains gain wide spread market adoption, a lot of changes have to be made. Every individual layer of the ecosystem needs to become more usable from the base protocol to the end-user interface. These layers must leverage the unique properties of blockchain for meaningful adoption to occur. Because what’s the point of using a censorship resistant blockchain if the interface is censoring?

Today is the first piece in a series of posts detailing blockchain usability for the different blockchain layers (that we have made up completely, mildly modelled after the OSI model). Here we will focus on the base protocol, working our way up in subsequent posts.

Blockchain Layers of Abstraction

The internet follows the OSI model:

a conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard protocols. The model partitions a communication system into abstraction layers….A layer serves the layer above it and is served by the layer below it.

The layers exist as an isolation mechanism, one working on the top-most layer should have no concern for what goes on below it, and vice versa; this is complete abstraction. This is a foundational modern developmental practice. In the past the developer of a robotic arm would have to know how each hardware device communicated with the other. But now there are common APIs, so developers do not need to worry about the register format, I2C addresses, etc, allowing for code reuse, quicker development, etc. Albeit at the cost of lower performance, but the develop speed outweighs this by magnitudes. And the same applies to Blockchains.

Careful design decisions at the lower layers of the stack can greatly impact the usability of upper level layers. Without a secure foundation anything on top is shaky at the best. Users can’t trust a protocol if the cryptography is broken :).

Taxonomies can be built in many ways, these layers reflect the current mental model for UX, please reach out for suggestions. For some inspiration: Multicoin’s Web3 Stack, a Vitalik post from back in the day, Web3 Foundation, Evan Schwartz’s 5 Layed Interledger Architecture, Blockchain Application Stack and 7 layers of financial cryptography.

Figures: Blockchain layers of usability

Usability in What Context

Before we can even determine what makes a blockchain usable, we need to understand the objective of the protocol. If a protocol is intended to be used only for tracking and managing assets for the overnight market for banks then the protocol can be permissioned or federated. Whereas if the protocol is intended for permissionless infrastructure for non fungible assets the requirements for usability is much different (BFT consensus, etc)

People often say how transaction low finality time, high transaction throughput and low transaction costs are essential for any blockchain, but in reality they are independent of usability depending on what the protocol’s goals are. The same goes for consensus rules, a blockchain does not need to be byzantine fault tolerant if the network is permissioned or federated. With this in mind, we’ve been careful to only discuss common usability attributes that can transcend these different design goals.

Started From the Bottom

Starting from the bottom, we can ensure that layers built on top have the ability to inherit the usability features that have been natively integrated into the base protocol. What is built here affects both the developers and end users on top.

What are the steps a protocol designer should take to have the most positive downstream effects on everyone else? And we will admit, these reflect our opinions, and there are arguments for and against each particular feature.

Features the Protocol Should Include

Features

• SPV Proofs / Light Clients: It is unlikely for all users of a protocol to interface with the blockchain using a full node, it is more common to use a hosted node service. They work well but represent a single point of failure, censorship and lack of privacy. Using SPV proofs or light clients, a user can validate and send transactions on his or her own without having to trust others. And if these light clients take very little resources, this gives more sovereignty to the user. Coda Protocol is the leader in this space.
• Account Based Modeling: Although there are many benefits to a UTXO model, account based modeling is more user friendly as there is only one canonical account which makes key management more straightforward. Users do not need to worry about optimal UTXO selection which has concerns of privacy, fees, dust, etc. Even better if one can register multiple key pairs to the account so if they lose one set, there are others available. Near protocol is currently working on this.
• Fork Friendliness: Some protocols believe that there should be no forks and have mechanisms built in to make it difficult to fork. People will always find a way to fork a protocol, therefore protocol designers should be cognizant of malicious actors / contentious hard forks and build in tools to both signal forks and prevent transaction replays.
• Hierarchical Deterministic Wallets: Also known as HD wallets, these allow one seed or mnemonic phrase to generate an infinite amount of public private keys. Therefore instead of a user having to store all their private keys, all they need to store is the seed.
• Consensus: The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), liveness (nodes that don’t fail always produce a result), and fault tolerance (the system can survive the failure of nodes at any point). No consensus mechanism can have all features, any distributed consensus system on the Internet must sacrifice one of these features. Therefore when choosing a consensus mechanism for a protocol, designers must determine what they value and how it affects user experience. Some inspiration from Stellar on their design decisions.
• Dust Handling: There exist coins that can no longer be used by the owner as the transaction fees are greater than the value of the UTXO. From a user standpoint this is not ideal because they have been deprived of their funds, if there was a clever way to not be in this situation it would be much appreciated.

Features For Network Maintainers

• Full Node Incentives: There should be a reason for users to run full nodes, whether they have to because the network is a permissioned or because there is a crypto economic incentive to do so. Without full nodes a network has lower security and less support. Incentives should cover the most important features of a protocol, in Bitcoin’s Nakamoto consensus only the miner who mines the block on the longest chain gets rewarded. But there is no incentive to propagate blocks, which has unfortunately leads to selfish mining. Perhaps an incentive to encourage relaying of blocks will fix this, but this represents the tip of the iceberg for incentives.
• Implementation Details: There are many ways to implement a specification for a protocol, developers must be careful to check for corner cases to prevent unintended attacks and unknown inflation.

In Protocol vs Extra Protocol Features

These are some features that also should be integrated into a blockchain protocol to increase its usability. However they can be implemented on several levels, should these be native to the protocol and potentially be part of consensus rules or should they exist on a smart contract layer or even off chain? Some protocols have taken a stance on this, but we will spare you from this debate and instead discuss why these particular features are empowering no matter what part of the stack they live in.

• Fee Delegation / meta transactions: For the end user, do they even need to know they are using a blockchain? Unless transactions fees are delegated to a third party, users forever will know that they are using a blockchain and have to acquire coins, which adds a layer of friction. Ethereum is working on smart contract based fee delegation (which has 2–3x gas costs compared to normal transactions and dApps specifically have to support it), whereas other protocols (Stellar and VeChain) have it natively. Nonetheless now users can use assets on top of a protocol without even knowing what’s powering it.
• Human readable addresses: Remember that time you typed an “O” instead of a “0” and burned a bunch of money? EOS has this natively (note it is mandatory and costs tokens to register, which detracts from usability), Ethereum uses ENS which is a smart contract. Now this won’t happen anymore. But we do understand that malicious people take advantage of renaming, look at Twitter last year with many scam accounts masquerading as Vitalik Buterin asking for ether.
• Native Multi-signature: It is paramount for a protocol to have one, either native or a smart contract. They can be implemented in scripts (BTC P2SH) or cryptographic threshold signatures. Try to can’t find a reason why a protocol should not have one.
• Gas Markets / Block Space Future: Transaction fees are a first price auction, which both in theory and practice tends to lead to imperfect pricing and games between participants. Several different models has been proposed to alleviate this, such as changing the auction type or introducing gas markets or futures for block space. And should these changes be part of the protocol or exist on the contract layer?
• Native Exchange: When features are implemented natively to the core protocol and consensus, they generally are more performant as the code is written as part of the client, rather than using a higher level smart contract language. Stellar has a native distributed exchange which make sense due to the asset nature of the protocol, but note this feature should not be implemented for non asset based protocols.

Complexity Shifting

There are some features that protocols inherently need, such as multi-signature (in my opinion, feel free to disagree). However which layer it lives in: base layer or smart contract layer or layer 2, along with the particular implementation greatly changes the user experience and shifts the complexity to different layers and parties. Is there a desire to make the base protocol extremely light weight? Or should it integrate everything? Can we assume that users are okay with an interactive protocol or should we assume that behaviour is undesirable? Is this a feature or a must have? These are some of the basic questions any protocol designer has to ask themselves, they must be cognizant that complexity will always exist. And who should be the ones who interface with the complexity, who should have the responsibility?

Balance between core developers and community

For legal de-risking, protocols cannot own the entire ecosystem. If the company developing the protocol runs nearly all nodes, develops all the ancillary components, etc it is hard to not say that the protocol is centralized. And that the company could be held liable for legal action.

Therefore it is essential for there to be outside development, but how to balance their contributions against the vision of the project? It is necessary for a project to have a concrete narrative to ensure that all developments by the community have a guiding light to follow. Then what about the security or trust, is it easier to trust a wallet by the company or by outsiders, what if one is open sourced and other not? These are not easy lines to walk.

Going Forward

Be cognizant of what the design goals of the protocol are when deciding on which usability features to implement per layer.

Special thanks to Kevin Britz (Totient Capital), Martina Long (Primitive Ventures), Dan Elitzer (IDEO CoLab) for their review and / or conversations.