Original title: Blockchain Networks and the Human Factor: How to Know Whether They're Accessible
Original author:
Original author:
- Dieter Shirley, CTO of Dapper Labs, oversees product design, architectural code, and sustainable development. Founded CryptoKitties, the most successful collectible game on the blockchain.
- Benjamin Ebner, Technical Content Marketing Manager at Dapper Labs, oversees the creation of Flow's educational content.
Translation: Raye, Flow technology ambassador, head of Cata Labs China.
With blockchain technology rapidly gaining popularity, technical topics related to network scalability—such as transactions per second, transaction latency, and throughput—are still being discussed.
However, in order to better build the consumer experience, developers must jump out of the shackles of system performance indicators and pay more attention to the human factor: ease of use. Ease of use means whether the system can be easily used by professional cryptocurrency developers or new users. And good ease of use is also a key factor that can truly popularize the blockchain. Only those projects that commit early to usability design can win the favor of the masses in the long run.
first level title
Don't focus on scalability
For a long time, people talked about scalability as a necessary prerequisite for large-scale applications. As we all know, in 2017, Dapper Labs created CryptoKitties - encrypted cats, which introduced the first non-homogeneous token (NFT) standard, ERC-721. While CryptoKitties heralded the huge potential of consumer-grade blockchain applications for the industry as a whole, it also dealt a blow to Ethereum's technical limitations at the time.
And the biggest debate quickly became scalability — how can Ethereum and other blockchains accommodate increasing numbers of users without clogging and being less expensive?
Scalability issues eventually led to the emergence of young layer 1 networks like Flow, Solana, Avalanche, and WAX, and layer 2 or sidechain solutions like zkSync, Optimism, or Polygon. (Note: The author is from Dapper Labs - the inventor of Flow.) And Ethereum itself is focusing on higher scalability using sharding and various upgrades.
first level title
Why & Who Should Care About Usability
Accessibility describes the ability of a blockchain network to be used by the masses in a frictionless manner.The easier it is for users to participate in a project's application, protocol, or ecosystem, the more usable the blockchain will be.Ease of use applies not only to end users, but also to developers, creators, product owners, and other parties who interact with the web.
Who Should Consider Ease of Use? Developers, architects, and executives who build and manage blockchain applications should conduct a usability analysis when selecting a blockchain. And anyone utilizing the existing services of the blockchain ecosystem—including creators, artists, and intellectual property holders—should consider the ease of use of a particular project, as this will determine the size and size of the existing audience on the network. features.
Instead of just playing the numbers game, these two groups need to confront the question: What does the culture of the ecosystem look like? What type of people are building here? What are the digital goods offered by projects built on top of it? How does the economy develop on it?And most importantly: is it all accessible to the masses?
These questions should start from(1) Functional (2) Economical and (3) Technicalfirst level title
Function
FunctionEase of use (also known as usability)Describes the ability of blockchain and its ecosystem to provide simple usage guidance and good user experience, so that the way users interact with protocols or applications can be sufficiently simple and efficient. This is an important start to any assessment.
■ Use guide
Every user journey begins with onboarding: the first phase of user interaction, including account creation and recharging, up to the first online transaction. This stage should be as frictionless as possible, requiring only a limited number of steps and preferably no technical barriers.
And those guidance that require users to perform complicated procedures in some services that have not yet been integrated indicate poor usability. For example, a common scenario is: a user registers an app, downloads a browser plugin wallet, writes a 12-character mnemonic, visits an external exchange to buy cryptocurrency, waits for the exchange to perform KYC, and then returns to the app Re-authentication so you can proceed to actually do what you want to do, like swap tokens or buy NFTs — which involves at least six steps across three different services.
Instead, there are well-integrated and streamlined processes that abstract most of the complexity from the user for an experience with great ease of use. For example, users can sign up for the app and wallet at the same time, while payment platform providers integrated via iFrame would not need to visit external exchanges to fund accounts.
Between these two extremes there are a variety of applications and services that partially incorporate these processes, such as wallets that do not rely on browser plugins (removing the need for a separate download process) or that integrate fiat to Cryptocurrency payment channels.
Some applications can manage their private keys on behalf of their users. While this custodian architecture can reduce friction in the onboarding process by removing the need for external wallets, it comes at the cost of higher technical complexity and legal requirements. These implications are beyond the scope of this article -- teams choosing a managed architecture should conduct a thorough study of the tradeoffs of this model.
A good starting point for an usability analysis is to identify the three most common guided routes for a particular blockchain, recreate these scenarios from the user's perspective, and collect the steps taken into separate files. Because a single protocol often has multiple onboarding experiences, depending on the specific application or wallet the user chooses, this process should cover all common scenarios and user types.
■ wallet
Onboarding covers the user's initial interaction with the protocol. For daily use, the signing and submission of user transactions is very important. For this reason, the wallets available on a given blockchain (required for such transactions) become an important part of the ease of use analysis.
Any blockchain transaction needs to be verified by a given user with a digital signature - this prevents unauthorized actions by malicious actors. In order to create this signature, the user's private key is required. Since private keys play this extremely important role, but cannot (or should not) just reside in our memory, they need to be stored in a secure and convenient manner. This is exactly what a blockchain wallet provides, while often providing an access point for sending transactions to the network.
For functional ease of use, the signing of user transactions must be easily achievable by a given blockchain's wallet. If users have to download an external plugin or manually set the parameters of how much they are willing to pay for a certain transaction, there will be more friction involved with each subsequent transaction. This suggests that using this framework to analyze usability is both relevant and broad. Only such a holistic approach can take into account the user experience of the wallets available on a given chain.
For maximum ease of use, the wallet must not only be easy to use, but also widely accepted in various applications within the project's ecosystem. If users need to set up multiple wallets from multiple providers to access different applications, the level of ease of use is greatly reduced. For example, if an NFT marketplace doesn't support the wallet a user uses to trade tokens on a decentralized exchange, then the user essentially needs to re-program the machine for another wallet and keep track of that account in the future.
This question is directly related to application development. In most cases, developers need to add vendor-specific code to their applications to support a new wallet. This introduces a technical overhead that hinders the integration and usability of multiple wallet providers in the application.
■ Entry and exit channels for legal currency payment
While a certain percentage of users will transact almost exclusively within the cryptocurrency ecosystem, mass adoption will require traditional non-cryptocurrency users to be able to easily transfer cryptocurrency earnings to more familiar currencies. Functional ease of use, then, also includes the ease with which end users can deposit or withdraw value from the network. The entry and exit channel of fiat currency payment is crucial to this, allowing users to use credit cards or other convenient payment methods to purchase a certain amount of cryptocurrency directly with fiat currency. While external exchanges can of course be used for this purpose, dedicated integration services ensure that users do not have to leave a given app to make payments, which adds significantly to the overall ease of use.
A starting point for this part of the analysis is to be able to roughly screen the listing of network tokens on major central exchanges. In doing so, you may want to include a list of stablecoins on a given network. The next step is to systematically check whether the main wallets of the ecosystem have integrated these coin payment tools, because some user-friendly wallets have already integrated these functions. For example, the multi-chain wallet Blocto relies on payment provider Moonpay to allow users to top up their cryptocurrencies with simple payment methods such as credit cards directly in the wallet.
Finally, you can check the fiat payment options of some of the most used web apps and pay attention to the providers who offer the service. This comprehensive analysis will paint a detailed picture of how accessible the value streams to and from the network are for end users.
Putting all these elements of functional ease of use together, these are the main questions developers should ask when deciding which blockchain to build on:
How many steps are involved on average with bootstrapping? How much knowledge or technical background is required to complete them?
How many steps do users need to sign transactions, and how much knowledge or technical background is required to complete them?
Are wallet integrations seamless to the user experience, and are they universally applicable across applications?
first level title
Affordable Ease of Use - Can You Afford It?
Economic ease of use is based on the general affordability of the protocol and the digital products built on top of it.
■ Transaction fees
The blockchain is a public resource, and transaction fees prevent overuse of the network's capacity, helping to avoid the tragedy of the commons. They also protect the underlying network from spam in the form of Denial of Service (DoS) attacks.
Transaction fees can be fixed — for example, in the form of a packaging fee required when submitting a transaction — or, they can be dynamic, increasing with the complexity of a particular request. Most popular blockchain protocols use one of these fee types, or a combination of them.
Transaction fees are where functionality and economic ease of use overlap. In day-to-day use, transaction fees must be low enough for everyone to participate, but high enough for the network to be stable. Also, the predictability of these costs plays a high role. If transaction fees have high unforeseen volatility, this will discourage less equipped users from sending transactions to the network. Therefore, any usability analysis needs to consider not only average transaction prices, but also the mechanics of their determination on a day-to-day basis.
On Ethereum, transaction fees are expressed in a specialized unit called gas in order to decouple the fee from the price fluctuations of the underlying token (ether).For each transaction, the user must include two specifications: the gas limit, which describes the maximum amount of gas the user is willing to spend; and the gas price, which indicates the price the user is willing to pay for a unit of gas.
The gas limit must be chosen according to the computational complexity of the request. For a simple ether transaction, the value is 21,000 gas units, or about $6 at current gas prices (as of October 2021). If the gas limit is set insufficiently, the transaction will run out of gas and fall back.
Gas price can be freely selected. However, higher gas prices mostly result in faster execution as network validators choose which transactions they want to include in the next block. The process is essentially similar to an auction, where users bid for their transaction to be included in the next block, and some sites such as EthGasStation have grown to target transaction pricing.
There are several problems with this transaction fee model.
During times of high demand, auction schemes can cause transaction fees to skyrocket; for example, there was a time when a simple token transfer was equivalent to around $50 in gas fees on Ethereum.
Pricing transaction fees correctly is not an easy task as gas prices fluctuate rapidly. While the recently adopted EIP-1559 pricing mechanism and some user-friendly wallets may circumvent some of these issues, the high transaction fees of complex mechanisms can hinder the general ease of use of the project.
Transaction fees are (mostly) significantly lower due to layer 1 blockchain networks and layer 2 solutions typically offering higher throughput. This is why these solutions are often more usable. However, application architects must closely identify trade-offs, since in some cases faster throughput comes at the expense of less decentralization.
■ Application layer products
In addition to transaction fees, economic ease of use also concerns the products provided by the application layer of the blockchain project. A prime example is the floor price indicator for NFT collectibles in an ecosystem.The floor price is similar to the minimum price of a collectible, and this indicator is often used together with the overall quantity (that is, the sum of the prices of all collectibles) to analyze the valuation of a collectible.
The high floor price actually builds a high-cold ecosystem that only the rich can enter, which hinders real community building, thereby reducing the chance of widespread application in the future. While a huge transaction volume is certainly good for the blockchain, one always has to look farther to see what the numbers mean: if the huge transaction volume is mostly accompanied by a high floor price, then it is possible Only a few wealthy users drive the economic activity of the ecosystem.
Some might discuss the concept of sharded NFTs, where ownership of the NFT is divided among many owners. This concept will also circumvent the problems mentioned above in the long run. However, this comes at the cost of engineering overhead, increased complexity for users, and lack of legal clarity.
■ Run node
Finally, economic accessibility is also a concern for node operators (validators who maintain and validate the blockchain). Only if the operation of network nodes is feasible in terms of hardware requirements and minimum pledge amounts (for networks using proof-of-stake), will a sufficient number of validators be incentivized to participate in the network, and only then can it ensure its decentralization and integrity.
Both Bitcoin and Ethereum are networks with a large number of node operators, which speaks to a good level of protocol reliability and security. However, the analysis of usability must take a more differentiated view. For example, the requirements to run a Bitcoin node are fairly low, but a large number of blocks are mined by pools with specialized equipment rather than by individual miners, making running your own Bitcoin node not very feasible nor easy to use sex.
While Ethereum's design largely prevents the use of specialized equipment, mining still occurs in centralized pools with significantly higher hardware requirements than Bitcoin. Since ethereum stores much more data than bitcoin, it takes significantly longer for a new node to catch up to that volume — today, it takes about 17 hours to set up a full ethereum node. Since time and hardware resources are costly, these factors reduce the economic ease of use of these protocols for node operators.
One should also pay close attention to other non-technical factors of node operators when looking for alternatives. For example, if a network plans to have permanent rules and regulations on who qualifies as a node operator, which prevents those operators who do not meet those criteria from gaining access to the agreement, this could be an indicator of a less decentralized network.
Key questions for economic analysis:
How high are the average transaction fees, and can users predict them in advance?
What is the floor price of popular products offered by the application layer of this project in the primary and secondary markets?
first level title
Technical Ease of Use - Can you build applications on top of it?
Technical ease of use describes how easy it is for developers to build applications on a given chain. This concept is also known as developer engineering.
■ Programming concepts
Whether a team can quickly produce a blockchain-enabled product largely depends on the technical ease of use of the project. The first thing to check are general programming concepts. Only when they can be understood reasonably quickly can developers pick them up and start building quickly. Ideally, programming paradigms are rooted in pre-existing technologies to get developers on board.
A good starting point is to analyze the main client implementations of the blockchain. Blockchain clients are language-specific implementations of the protocol, or simply put, the actual programs run by node administrators to power the blockchain. Some blockchains may have more implementations, and this is generally a good indicator of ease of use; however, what is more important is the most commonly used client development language. Make sure it's a well-known, used and maintained language that can assume a fair number of developers' pre-existing knowledge, such as C++, Golang, Rust or Python. This will guarantee the possibility of continuous development and maintenance of these clients.
The next important consideration is the smart contract programming language. Some blockchains like Solana use existing languages (Rust and C++), while other networks like Ethereum (Solidity) or Flow (Cadence) have created their own languages. Of course, using a full-fledged language can be convenient for those experienced programmers; however, for novices, this may come at the expense of learning all the details of an entire general-purpose programming language, which is difficult for a low-level language like C++. Saying it is time consuming.Here, it might be easier to pick up a new, lightweight language designed with smart contract programming in mind.
In the case of a new programming language, analyze the language for the existence of well-known and established programming concepts and paradigms. For example, Solidity is heavily inspired by JavaScript and Java, while Cadence borrows many concepts from Swift and Rust.
Also, consider what abstractions a language provides to its developers. Like the underlying protocol, a language should abstract as much complexity from the developer as possible without sacrificing security or customizability. For example, Cadence uses a novel resource data model to automatically specify rules for the handling of numeric values, while Solidity requires manual implementation of these low-level checks.
Finally, make sure that learning materials, documentation, and reference samples are well established and readily available for all of these areas. Evaluating the ease of use of programming concepts is about considering the subtleties and trade-offs implicit in the technical details.
■ Tools
A good toolkit is the most important thing for developers to build applications quickly, safely and easily. If there are frequent problems that cannot be solved by dedicated tools, it is an indication of a poor level of technical ease of use, since developers have to deal with these problems themselves.
The software development kit (SDK) is arguably the most important of these tools. SDKs provide a language-specific abstraction layer for the protocol's underlying processes; they simplify interactions such as authentication, querying and updating status, and listening to events. Checking for SDKs for all popular programming languages shows that the project is technically easy to use.
In addition to the SDK, there are many tools that can greatly simplify the developer's onboarding and daily development process. Check for the existence of extensions for text editors (IDEs), testing frameworks, and other tools for automating, deploying, and debugging that make developing applications on a given blockchain easier, faster, and ultimately more accessible.
Key questions for technical analysis:
Are the programming concepts for the project easy to learn? Do they enable fast, secure and efficient development?
Are there enough study materials and reference codes? Are higher level concepts like best practices and patterns also covered?
Are there developer tools for the most common questions? Are the tools and the source code of the main project all open source?
In addition to the aforementioned factors, there are other considerations, including some less obvious markers of ease of use in terms of concepts, such as how well the general audience understands the general concepts of a given blockchain project. Ease of use is enhanced if users can quickly enter the space without acquiring considerable new knowledge first. In this regard, the existence of educational materials for end users and accessible language that avoids technical jargon and jargon is very beneficial, but can be difficult to analyze in a broad ecosystem.
In any case, the ease of use of blockchain is not a good thing that can be added later, but needs to be ingrained in the DNA of the project. Technical ease of use in particular has to be taken into account when first sketching out the inner workings of the protocol.
Without ease of use -- not just scalability -- it won't really take off.
