Rethinking Web3 Development

#ethereum #web3 #solidity

Why Most Devs Are Missing the Point

The problem here is that 80% of developers working in the industry have no idea how to think in terms of blockchain tech. What I've seen is that most developers use the blockchain as a replacement for their backend and their database, turning the blockchain into the most expensive database in the world. This, for me, is a problem not only because most developers are not using any of the virtues of blockchain tech, but because this is stopping developers from innovating and coming up with new ideas. And for most developers, it's difficult to think in terms outside of Web2 or databases. In this article, I want to go over how one can start thinking in terms of Web3 and make better use of the technology in general.

What Do I Mean by Web3 Thinking?

Now, what do I mean by Web3 thinking? Let's start with some examples to illustrate the shift from traditional approaches to ones that leverage blockchain's unique properties like decentralization, permissionlessness, and composability.

Example 1: User Login and Profiles

Let's say you've created an application that requires users to create a profile in order to access it. I'm going to give you a few seconds to think about how you can do that using Solidity... Well, most people come up with something like this:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

contract Pixelmon {
    struct User {
        string username;
        string bio;
    }

    mapping (uint256 _id => User _user) public users;

    // ...
}

They pass that to a mapping, and after that you have an indexed mapping that maps each user to an ID. Is this inherently bad? No, but it doesn't benefit from working on a blockchain. It doesn't benefit from having a decentralized ledger and autonomous code keeping it working.

What would be a better way of registering users? How about a soulbound NFT with onchain dynamic metadata-something that can easily identify the user and sell as a benefit from at least some of the properties of the blockchain**. This way, the profile becomes transferable (or not, if soulbound), verifiable across chains, and composable with other apps. For instance, imagine linking it to DeFi protocols where the NFT could accrue reputation or rewards based on user activity, all without a centralized database.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

import {ERC721} from "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract PixelmonUser is ERC721 {
    constructor() ERC721("PixelmonUser", "PIX") {}

    function tokenURI() public view (string memory) {
        // ... Dynamic profile
    }
}

Example 2: Building a Betting Application

Here's another example: Let's say you are creating a betting application. How do you represent a bet? Most people are going to create a struct similar to this:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

contract Betting {
    struct Bet {
        string description;
        uint256 in_favor;
        uint256 against;
        // ...
    }

    mapping(uint256 _index => Bet _bet) public bets;
    mapping(uint256 => mapping(address => uint256)) public betAmounts;
}

And attach some mapping to say who voted for whom, and call it a day. That is not good.

What could have been done instead? What about a pool with two tokens, one ERC1155: one represents the IN FAVOR side of the bet and the other one represents the AGAINST side. The bet becomes something more, something other people can build upon and even use.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.27;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract Betting is ERC1155
    uint256 public constant IN_FAVOR = 0;
    uint256 public constant AGAINST = 1;

    function bet(uint256 tokenId /* ... more params */) public {
        // ...
    }
}

It becomes permissionless.

For example, users could trade these tokens on a DEX, creating secondary markets around the bet’s outcome. Oracles could resolve the bet autonomously, distributing winnings based on token holdings. This turns a simple bet into a composable financial instrument that integrates with the broader Web3 ecosystem, rather than just a siloed entry in a smart contract.

Why does this matter? Because this kind of thinking, leveraging blockchain’s unique properties like permissionlessness and composability, unlocks innovation. Instead of rebuilding Web2 apps onchain, we’re creating systems that are open, interoperable, and extensible by anyone in the ecosystem.

Why Are Devs Missing This?

So why do we keep seeing the same old designs, smart contracts that mimic SQL databases or centralized apps with a blockchain sticker slapped on? Two reasons stand out. First, most developers are stuck in a Web2 mindset, trained to think in terms of SQL databases and front-end frameworks. Second, and this is the kicker, many Web3 developers don’t actually use Web3 themselves.

The Bigger Issue: Devs Not Eating Their Own Medicine

I’m not talking about the 1% of smart contract devs you see flexing on CT. I’m talking about the average developer who landed a job at a crypto company but whose only “crypto” experience is buying BTC on Coinbase or trading on Binance.

I’ve heard stories, too many stories, of developers who didn’t even know how to send USDC. No shade, but how do you innovate in a space you don’t live in?

This is why we’re stuck. If you’ve never swapped on a DEX, minted an NFT, or voted in a DAO, how can you dream up the next big thing? To break out of this rut, devs need to dive into the ecosystem headfirst. Only then will we stop building glorified databases and start pushing Web3 forward.

To fix this, you need to dive in and try to think in terms in terms of Web3. Then can see the tech's true potential.

DEV Community