DEV Community: Lara Parvinsmith

Signatures as Authentication in Web3

Lara Parvinsmith — Tue, 22 Mar 2022 01:42:08 +0000

When interacting with web3 apps, you may have seen a signature request in your wallet that looks like this. This article explains what this signature is and how it's used as authentication.

What is a signature and what does it prove?

A cryptographic signature proves that the signer has the private key to a public address. A public address on the Ethereum blockchain is a 42-character hexadecimal address derived from the public key controlling the account with 0x appended in front. e.g., 0x88c78f158cac85f17ecfc063259543c5dc345ef3. Anyone can send money to an account using the public address, or look up the account activity and assets. However, to control the assets in the account, you need to have the private key.

Ethereum wallets, such as MetaMask and Coinbase Wallet, store your public key and private key for you, and protect against apps directly accessing the private key. Instead, apps rely on a cryptographic signature that proves ownership of the address through the Elliptic Curve Digital Signature Algorithm, which allows any external party to verify the signature without knowing the private key.

Benefits of using a signature for authentication

In web3 apps, a user's Ethereum address is increasingly replacing a username or email to identify a user. And instead of a password to authenticate that a user controls the digital identity, a signature can be used.

Leveraging an existing Ethereum account is a lightweight way to onboard web3 users. It's faster than traditional account creation flows, and doesn't require the user to create and store yet another password. It also allows the user more anonymity, since they don't have to reveal private details like their email.

Unlike blockchain transactions, signature generation and verification can be done off-chain, and therefore requires no gas fees. And while it proves a user's control of an Ethereum address, future blockchain transactions will still require explicit approval through a separate wallet request.

How signatures are used in hybrid apps

Some apps, such as Snapshot and OpenSea use a hybrid of blockchain data and data from a private database. These apps will use a traditional database to store off-chain actions, such as voting (on Snapshot proposals) or favoriting NFTs (OpenSea stores users' favorited NFTs). Onboarding onto these apps is easy, because a user just has to allow it to connect to their Ethereum wallet. But to store the outcome of these actions, or any off-chain details about the user (such as profile name and photo), these apps must authenticate the user's digital identity.

For example, to change an OpenSea profile's details, the user must authenticate to prove they control this address.

For apps using signature authentication, it's important not to allow the same signature to be used twice. This is why the messages vary, and often include a nonce.

How to generate and verify signatures

On Etherscan

To sign or verify a signature right now, you can use Etherscan's Verified Signature tool.

Connect a wallet and enter any message. Those two inputs, plus your private key, generate a unique hash.

To verify this signature came from the wallet's owner, another party can input the signature hash, along with the address and message to validate.

In your frontend app

To request a signature in your web3 app, you can use a library like web3.js on the frontend. The code snippet below shows how to generate a signatureHash using a web3.js method, then an example of passing it to any signature verification API to your backend.



const signatureHash = await web3.eth.personal.sign(message, address)

someSignatureVerificationAPI(message, address, signatureHash)

Conclusion

As the Ethereum address has replaced the account username, the signature has replaced the password. Because a cryptographic signature proves the user controls the private key to the public address, it is a secure method of authentication. Apps can use this gas-less primitive of Ethereum to verify a user has control over the digital identity provided by the address, and provide authentication to do arbitrary, non-web3 actions.

web3.js vs ethers.js: a Comparison of Web3 Libraries

Lara Parvinsmith — Thu, 03 Mar 2022 01:13:13 +0000

Both web3.js and ethers.js are JavaScript libraries that enable frontend apps to interact with the Ethereum blockchain, including smart contracts. If you're building an app that reads or writes to the blockchain from the client, you'll need to use one of these libraries. They have similar functionality, but an important question is how they will be maintained and grow with the emerging dapp ecosystem.

Quantitative comparison

	web3.js	ethers.js
Date of first release	Feb 2015	Jul 2016
GitHub stars	13.4k	4k
GitHub contributors*	16**	1
Bundle size***	590.6kB	116.5kB

*GitHub contributors from March 1, 2021 to March 1, 2022
**16 contributors, but only 2 had more than 10 commits in the one year period
***Bundle size from bundlephobia, value of minified and gzipped package.

API differences

While web3.js provides a single instantiated web3 object with methods for interacting with the blockchain, ethers.js separates the API into two separate roles. The provider, which is an anonymous connection to the ethereum network, and the signer, which can access the private key and sign the transactions. The ethers team intended this separation of concerns to provide more flexibility to developers.

Side-by-side examples

Below are some examples of common functions a developer would include in their dapp. You'll see they offer the same functionality, with some slight differences of API.

Instantiating provider with MetaMask wallet

web3
const web3 = new Web3(Web3.givenProvider);

ethers
const provider = new ethers.providers.Web3Provider(window.ethereum)

Getting balance of account

web3
const balance = await web3.eth.getBalance("0x0")

ethers (supports ENS!)
const balance = await provider.getBalance("ethers.eth")

Instantiating contract

web3
const myContract = new web3.eth.Contract(ABI, contractAddress);

ethers
const myContract = new ethers.Contract(contractAddress, ABI, provider.getSigner());

Calling contract method

web3
const balance = await myContract.methods.balanceOf("0x0").call()

ethers
const balance = await myContract.balanceOf("ethers.eth")

So which should I pick for my project?

Given the details above, web3.js looks like the go-to choice, with a longer history and more maintainers. However, ethers.js seems just as reliable and includes some differentiating perks such as size and additional features. Most other articles on this subject conclude that you could easily pick either, depending on what you're looking for.

I too hesitate to recommend one over the other. But as the ecosystem evolves, it is important to me to pick the library that will be most flexible and supported by other libraries.

Ecosystem factors

Which will be the most supported by open source libraries?

As the dapp ecosystem grows, which of the two libraries will be the most compatible with other open source libraries you want to bring into your app?

In my limited experience, as this is still an emerging area for development, there are a couple libraries that require ethers.js to use the framework. Examples include web3-react and NFT Swap SDK. I have not yet seen libraries that require web3.js.

Which will have a solution for mocking for end-to-end testing?

Implementing end-to-end testing for web3 features is a challenge. This is partly because most tools, like Cypress, run your tests in a Chromium browser that does not support browser extensions. Developers need an easy way to mock Ethereum providers or the web3/ethers instance to use inside their test environments. So far, I haven't seen any libraries that help solve this. But if there were a tool that helped mock providers for testing, and only worked with ethers for example, that would be enough for me to choose ethers over web3.

Which library do you prefer, web3.js or ethers.js? Are there any tools in the ecosystem I'm overlooking? Let me know in the comments!

Web3: the unique technology and challenges behind the hype

Lara Parvinsmith — Mon, 17 Jan 2022 20:17:11 +0000

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 Stack of a Web3 app

The Smart Contract

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 Wallet

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 Client

The client is the frontend app that a user interacts with in the web browser. You can build a Web3 app with any frontend framework, or even vanilla JS and HTML, but you will need an Ethereum Javascript library to interact with smart contracts.

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.

Key UX Challenges of Web3 apps

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

"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.

Complexity

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.

Successes, errors, and loading states

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.

Conclusion

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.

Easiest way to deploy your Ethereum Smart Contract

Lara Parvinsmith — Sun, 09 Jan 2022 19:29:08 +0000

So you've written your Ethereum smart contract, and now you may be wondering how to deploy it. I recommend first deploying the contract to a Test Network (testnet), such as Rinkeby, before deploying it to Ethereum Main Network (mainnet). You can deploy to both testnet and mainnet by using the Remix web app.

Why deploy to a testnet

Testnets behave similarly to the Ethereum Main Network, but the ETH required to transact with them is free to get from a "faucet." Faucets are apps where you can input your testnet wallet address and receive testnet assets like ETH. (I like Chainlink's Faucet and refer to it in the instructions below.) Testnet ETH enables you to pay the gas to deploy your smart contract to testnet and make test transactions.

Deploy the easiest way

Paste your contract code into the Remix IDE and deploy it from the Remix web app. Step by step instructions below:

Set up a test account on your crypto wallet, such as MetaMask. Make sure to select the Testnet of your choice from the Networks dropdown.

Get ETH on Testnet from a faucet by entering the address from your test account above. You will need this in the next step to pay the gas fee for deploying your contract.

Load Remix with http rather than https to allow interaction with the wallet. Create a file in the contracts folder and paste in your smart contract.

Then compile the contract in the Compile tab.

Note: for more information on the Compiler configuration options, please read the Remix documentation. The default configuration is fine for testing.

Then go to the Deploy tab when it's compiled. In the Deploy tab, use the Environment selector to select "Injected Web3." Confirm the correct Network, account and contract are selected.

Note: if your constructor function requires any parameters, specify them in the input next to the "Deploy" button. For more on deploy configuration, see the Remix documentation.

Your wallet will confirm the transaction in a pop-up window, including a gas fee. You should still have plenty left for testing transactions.

Note: if you load Remix with https, you may get this message "You are using an https connection. Please switch to http if you are using Remix against an http Web3 provider or allow Mixed Content in your browser." This will prevent you from connecting to your wallet, so make sure to use "http" in the URL.

Optionally deploy to mainnet in the same Deploy tab by selecting "Ethereum Mainnet" from the MetaMask Network selector. This will also prompt the wallet to confirm the transaction, including a gas fee.

Congrats, you've deployed your contract! Now you can interact with it on Etherscan (on Rinkeby or Mainnet) or in your very own Web3 app.