If you follow tech news, you've probably seen crypto evangelists say that Web3 will change the world. But what is Web3?
Web3 describes applications that can interact directly with the blockchain as its database. At the time of writing, most apps, (also called 'dapps,' for 'decentralized apps') are built on the Ethereum blockchain. The reason a user would want to store their transactions on a public blockchain rather than a private, company-managed database is that it enables ownership and portability of their data and assets. The reason a developer would build an app on the blockchain is to tap into an advanced, transparent ecosystem with decentralized control.
I write from the perspective of both a Web3 developer and a crypto user to highlight key technologies and remaining user experience challenges.
The database of a Web3 app is a blockchain like Ethereum. While an app could be written to simply send Ethereum from one account to another, most apps require a more complex API. The APIs for complex interaction with the blockchain come from smart contracts. A smart contract is code that is stored and runs on the blockchain. It contains functions that allow a user to update the state of accounts on the blockchain. Examples of common functions include minting a non-fungible token (NFT), adding liquidity to a decentralized finance (defi) protocol, and voting in a decentralized autonomous organization (DAO).
One advantage of smart contracts is that all code is transparent and available on a blockchain explorer like Etherscan. This allows a user to audit contract code, the contract owner, and all transactions in a convenient web UI. However, not all users are technical or patient enough to be able to perform this type of due diligence, and scams and hacks are rampant in the community.
Another key advantage is that anyone can build another a front end app or even another smart contract that interacts with the smart contract. In this way, a decentralized ecosystem of builders can thrive, and users can have more choice. An example of this is NFTs, which are stored on the blockchain and accessible from any NFT client. At the time of writing, OpenSea is the largest NFT marketplace, but a user who buys an NFT on OpenSea is not locked into their app. Their transaction is stored on the blockchain, so they can access and sell the NFT from any other Web3 NFT app.
But how does a Web3 frontend access the blockchain data and use a smart contract's API?
The crypto wallet is another key technology that makes Web3 unique. Every Web3 app must connect to a crypto wallet to allow the frontend to interact with the blockchain. Some of the most popular wallets include MetaMask and Coinbase Wallet, which a user can install as a browser extension and as a mobile app.
A wallet allows users to create and manage accounts while isolating private keys from the Web3 app. The wallet exposes an API to interact with the blockchain and a user interface for confirming transactions. This allows a user to safely connect their account to a Web3 app and gives them control so that the Web3 app cannot write to the blockchain without the user's explicit permission.
Relying on a third party wallet has the advantage of allowing the user to have consistent, controlled interaction across all Web3 apps, from allowing the app to read the user's public account details to confirming transactions before they're sent. From the developer perspective, this allows us to focus on building what's unique about our Web3 app, and not rebuild accounts and authentication every time. However, it does require some user setup the first time they want to interact with a Web3 app, as they have to install a wallet, set up an account, and add funds.
The two most commonly used libraries at the time of writing are web3.js and ethers.js. Both of these libraries provide utilities for interacting with the Ethereum blockchain, including accounts, contracts, and transactions.
While the crypto wallet, such as MetaMask, provides an API to read and update the state of the Ethereum network, the JS library can find and abstract the smart contract so that its functions can be called asynchronously by the Web3 app.
Other than that, the usual frontend libraries are often used to build more complex apps, with React as the most popular choice. There are even some libraries that combine React with Web3 functionality, such as web3-react.
Some of the challenges I have mentioned above include requiring the user to install a wallet and fund an account before being able to interact with a Web3 app. Here are some other major user-facing challenges, that if not addressed in the ecosystem, could make Web3 unappealing to many users.
"Gas" refers to the transaction fee users pay miners with every transaction to keep the Ethereum blockchain running. It's a key part of the ecosystem, to incentivize miners to run nodes and to incentivize users not to overuse computing power. The amount the user pays is a function of the complexity of the transaction and the current demand. However, with the increased popularity of Ethereum, gas fees can rocket up to $200+ for some smart contract transactions at peak usage. What are the current solutions for high gas fees?
As a user, you can check gas fees with apps like ETH Gas.watch before you make a transaction, or sign up to be notified when gas prices drop. In general, gas prices tend to drop during U.S. sleeping hours (see Gas Price by Time of Day) so users could wait until low traffic times to make non-urgent transactions. But this is not an ideal solution for most users, and it disqualifies the use case of using it for everyday transactions such as buying a cup of coffee.
As a developer, there are some ways to optimize your smart contract code to avoid exorbitant gas fees for your users. These strategies range from storing variables as preferred data types to using third party libraries. Since this is a complex topic on its own, I won't dive into it here, but will instead refer interested readers to this article on cutting gas costs for minting NFTs. However, this optimization is still not enough for many prospective users. Going from a gas fee of $200 to a gas fee of $30 is a huge achievement, but $30 is still a big enough deterrent for new users trying to make their first transaction. Because it's not just the gas fees, but other uncertainty and complexity that could make a user even more risk adverse.
Current blockchain transactions are still very complex for users, requiring multiple steps and new concepts. This causes a lot of uncertainty, and the user may often wonder: "am I doing this right?"
I covered some of the complexity of the crypto wallet and account setup above, but we must remember a new crypto user will have to create and fund a crypto wallet. This step alone could take days, depending on how fast their fiat can be converted to crypto and transferred to their wallet. When this is complete, they can interact with Web3 apps. However, the Web3 apps themselves are often just as complex. Decentralized apps involve new concepts, including over-collateralized lending and minting non-fungible tokens. They also often involve multiple steps, and rely on a user to already know what they are doing.
There are many elements of a Web3 app that can make a user feel uncertainty. From the 42-character hexadecimal Ethereum address ("am I sending this to the right place?") to the transactions themselves ("why is gas so expensive?" "how do I know if it worked or not?") the user can be intimidated and fear losing their money from a small mistake.
More transparency around what different transaction outcomes look like, and more UI to fill in the gaps, would be helpful to guide a user through complex Web3 flows. For example, if all goes well, how do you know if your transaction is successful?
A successful transaction is defined by being added to the blockchain, but it can take up to a few minutes for the app to be confident the transaction has been included in a block. So the developer must decide how to communicate the difference between ‘your transaction was successfully sent to the pool of pending transactions,’ and ‘your transaction was successfully added to the blockchain.’
There are a few different tools to track the outcome of your transaction. One is on Etherscan: as a developer, you can have the "successfully initiated transaction" state provide a link to the transaction on Etherscan, so the user can check the status of their transaction there. You can also use client code to check whether a transaction has been mined, and indicate true "success" after 5 confirmations, or blocks created after the transaction. The latter may be a better user experience, since the user won't have to navigate away or reload the page. If the user expects their wallet balance to change as a result, or an NFT to arrive, that could be another signal of success, but on many platforms this requires waiting and refreshing.
If a transaction fails, the user will often lose some of their gas fee, and maybe their confidence in Web3. To avoid this, we need proactive measures to make sure their transactions don't error. We can achieve this by making smart contract state more transparent to the client, and by validating requirements on the client before allowing transactions to be initiated. Web3 developers should also focus on clearly communicating any errors to the user. All of these strategies will lead to more user confidence in Web3 technology.
Web3 hype is grounded in revolutionary technologies that have a thriving ecosystem of builders, and users of all levels of expertise. These technologies: the blockchain, smart contracts, and crypto wallets are key tools for building the Web3 ecosystem. Web3 already provides users and developers more freedom and transparency, but there are still some major drawbacks that could prevent mainstream adoption if unaddressed.