Now that we’ve learned what a blockchain is, and understand how transactions flow through the network, let’s return back to decentralized applications, or dApps. In this section, we will break down what exactly a dApp is. We’ll start by quickly reviewing the software architecture of Web2 applications then compare it to that of Web3 dApps. And, this is just the beginning of Web3 tutorials for product designers. Stay tuned for future Web3 Design Courses where we discuss emerging dApps that will disrupt the internet as we know it today.
Web2 applications are hosted on a company’s centralized server. At a high level, the web app has a frontend, backend and database associated with it. A user’s computer communicates with the company’s server using internet protocols, and frontend code (e.g. HTML, CSS, and Javascript) is sent to the user’s computer where it is then rendered into a UI within an internet browser. Because of this centralized software architecture, the company has unilateral rights to update the application’s code and modify its database. And for good reason as this is how new versions of web apps get deployed to user communities; however, companies can do a number of things like censor user content, and even outright ban users from their web apps. What’s more, Web2 companies often monetize user content and data via advertising. In other words, the companies earn massive profits while the users who generate content, and make up the site traffic, capture little of the value they create. This is counterintuitive, but has become normalized as it’s been the dominant internet business model over the past 20 years. We’ve never known of anything different until now.
Web3 disrupts this paradigm with decentralization. Like Web2, frontend code is still rendered into a UI with internet browsers, but the dApp’s backend is where things start to differ. Instead of a centralized server, Web3 dApps deploy backend code to the blockchain with smart contracts, and also utilize the blockchain as a decentralized database. No company owns the dApp, or the blockchain that the dApp leverages. As we saw before, dApps are permissionless so anyone can use them, and the blockchain database can only be updated by a user with their private key.
Now think back to our example of swapping tokens on Uniswap. We connected our wallet to Uniswap, and initiated the swap from ETH to DAI on Uniswap’s UI. On the backend, Uniswap assembles the raw transaction necessary to make this swap. We can imagine the raw transaction contains data like wallet address, how much Ether I want to swap, and how much DAI I expect in return. The transaction also points to the swap function within one of Uniswap’s smart contracts, which is stored on the Ethereum blockchain. But more on this later. We learned from the previous section that the validators will not accept unsigned transactions; therefore, Uniswap sends the raw transaction to a user’s wallet, the wallet app signs the transaction (after the user accepts a MetaMask confirmation popup) with the private key, the signed transaction is sent back to Uniswap, and Uniswap sends the signed transaction to an Ethereum validator.
Now we’re back to what we discussed in the previous section about what happens once a transaction has been sent to an Ethereum node. A validator checks the validity of the signed transaction, includes it in a new block, propagates the new block through the network, and so on. Once this block gets accepted by the other validators then the user’s Uniswap transaction goes from pending to confirmed, his/her account’s ETH balance is decreased by X plus a network fee, and increased by Y DAI. The swap is complete.
Remember dApps deploy their backend code to the blockchain in the form of smart contracts. One of the main features of Uniswap is, of course, its swap functionality, so, somewhere, in one of its smart contracts, we’d expect a swap function. When smart contracts get deployed to the blockchain, a contract address is created that looks identical to a Web3 wallet address. This is where the smart contract code lives. Once a smart contract has been deployed to the blockchain it cannot be modified or deleted – it is “immutable”. The smart contract is also permissionless in that anyone can use it, like a public utility. Also, anyone can audit the code, line by line, to ensure that it will execute in an expected manner.
You can think of smart contracts like a vending machine. You put money into a vending machine along with which snack you want, and the vending machine outputs the snack. As we saw before dApps assemble raw transactions that point to smart contract addresses, and the functions within them, to carry out whatever the user requested. ETH is also attached to this transaction to pay the validators for processing the transaction. The transaction passes in parameters to the swap function like wallet address, amount Token A, amount Token B. Finally, the smart contract updates the state of the blockchain accordingly (i.e. user’s ETH and DAI token balance).
If you enjoy videos over reading when it comes to online learning then checkout the course on YouTube. This is part 2 of 9 in the Web3 Design Course 2022. Also, make sure to stay tuned for future Web3 Design Courses where we will get into more interesting topics about emerging dApps.
0 Comments