4 ms·

Very, very, very few people work in the cryptography or even blockchain aspects of any element of web3. The overwhelming majority of dev in the space looks exa

Very, very, very few people work in the cryptography or even blockchain aspects of any element of web3. The overwhelming majority of dev in the space looks exactly like web2. You whip up an Express/Lambda/whatever API backend that (at it's most "blockchain") uses a library like web3.js to talk to a blockchain node from a commercial service provider via HTTP or websockets. More likely than that you go further up the stack and use a really easy to consume library[0] from your API provider and don't even really get exposed to the nitty-gritty blockchain methods exposed by a lower level library like web3.js. Literally import lib, provide your API key, and do things like: const nftsForOwner = await alchemy.nft.getNftsForOwner("0xshah.eth"); I find it fascinating to meet devs in the space who say they're a "blockchain developer" and after a tiny amount of conversation you realize there's no difference whatsoever between what they're doing and wiring up a backend + frontend solution to something like Square (or whatever). So I agree with you completely - when these crypto companies or whatever start laying off left and right you can be certain the vast majority of the devs in the space can use what they've learned anywhere. [0] - https://docs.alchemy.com/reference/nft-api-quickstart#alchemy-sdk-recommended https://docs.alchemy.com/reference/nft-api-quickstart#alchem...

pcthrowaway 4y ago
My company put me on a "web3" project recently, and as someone who has done some kind of web development, at least at the hobby level, since 1999, I can tell you that there's quite a bit of difference with web3. I think the web skills from a decade ago translate better to web-dev today than web-dev today translates to web3 development. With web3 you have to consider the different ways to get on-chain data, and the state is all on the blockchain. Testing is a nightmare and the tooling around development and deployment are still immature. And that's before even getting to solidity or other languages you use for the "backend"
- kkielhofner 4y ago
  Sounds like you've been at this since I have (mid-late 90s as well)! I somewhat agree with you on the state of tooling compared to web dev today but I'm not sure it matters or is terribly relevant to the point OP is making. I've been in this space one way or another for five years so prepare for a (somewhat anecdotal) "dump" that you may (hopefully) find useful for the new project that you've been put on. You mentioned Solidity so let's assume an EVM compatible chain and ecosystem. At this point I'd call anything actually on chain the "back backend". Of course Solidity is the smart contract language but due to costs, speed, etc of the chains themselves the data is all over the place... That's how we've ended up with things like The Graph[0], Ceramic[1], etc. As you've likely already experienced interacting with the chains themselves in any capacity is remarkably creaky hence the plethora of somewhat ironically centralized API providers and solutions with many layers of insane amounts of code and backend infrastructure to make things actually work for anything beyond a toy (like the various Alchemy APIs I provided an example of). This is before you get into anything like IPFS, Filecoin, etc but once again the typical interaction with these is via heavily abstracted libraries and HTTP gateways that do their best to look like any other web2 service. Smart contracts, by their nature, are rarely written and rarely deployed. If you look at some of the biggest "apps" in the space smart contracts represent a tiny fraction of the amount of dev work compared to the overall solution. Take OpenSea (as one example) they've deployed a smart contract twice in five years of operation AFAIK. If you look at their frontend and API docs it becomes clear really quickly they've done a lot more work in areas that at the risk of deploying "No true Scotsman" I would say at least 95% of the dev work in web3 is effectively web2. Now that we're talking about smart contracts, the stakes are so high there is actually a fairly robust amount of tooling IMHO. Maybe not robust compared to the state of 30 years of web development but between OpenZeppelin[2], Hardhat[3], Truffle[4], etc there's a lot out there. From everything I've seen in the space over half my decade by the time you import a bunch of OpenZeppelin contracts there's almost always very little Solidity left to be written. As traditional cryptography devs have learned "writing your own crypto" is almost always a really bad idea. If you were to look at LOC for anything in the web3 space my original point is backup up by the data. Metmask is used by 30 million people and it's all web dev (backed by an Ethereum JSON-RPC[5] interface hosted by MetaMask sponsor Infura by default)... The rest of any user facing application is your frontend pulling in ethers[6] and MAYBE a bog standard web2 service/microservice backend. Then you're off to the races. There is SQL, NoSQL, etc all over the place in web3. From my personal experience and everything I've seen I'd venture to guess that maybe 1/50 devs in the space ever touches Solidity (likely much higher). Everyone else is doing what they've always done by reading the docs for whatever JS/TS libraries they're using. I've personally worked on many projects where web2 devs became "web3/blockchain devs" in an hour - to my original point of saying you're a "blockchain developer" because you're using ethers is really funny to me. My overall point being (and to assuage the concerns of OP) the vast majority of devs that start in web3 feel right at home in web2 and vice-versa. I know exactly one dev who I would call a serious "blockchain developer". They came from a web dev background and they're all in on Cardano which meant picking up Haskell (which would send most web devs running for the hills). If a dev were to start with Cardano + Haskell I have no idea where they would end up if they left "blockchain development". [0] - https://thegraph.com/en/ https://thegraph.com/en/ [1] - https://ceramic.network/ https://ceramic.network/ [2] - https://www.openzeppelin.com/contracts https://www.openzeppelin.com/contracts [3] - https://hardhat.org/ https://hardhat.org/ [4] - https://trufflesuite.com/ https://trufflesuite.com/ [5] - https://geth.ethereum.org/docs/rpc/server https://geth.ethereum.org/docs/rpc/server [6] - https://www.npmjs.com/package/ethers https://www.npmjs.com/package/ethers
  - pcthrowaway 4y ago
    Thanks for the very in-depth reply. I've only been doing it for ~5 months now, so definitely consider myself a "junior" in the space. What we've done is fork a popular defi protocol (think AAVE/Compound) that consists of >10 core contracts, plus additional for markets, and made a few changes. Then deployed a few custom contracts as well. I've written ~100-200 lines of solidity that are on mainnet now, the rest, as you say, are snapping together Openzeppelin legos. We're not using The Graph for our frontend (yet) though I think we want to in the future. Our current stack is Hardhat (with ethers) for both deployment and testing, and react + typescript + react-query on the frontend. We're able to get contracts deployed on a hardhat node or goerli pretty quickly now, but, for example, if deploying to goerli, the 200-300 transactions for the deployment process take ~1 hour to send through, so it's really just where we deploy right before we release (in addition to testing on a fork of mainnet). The tooling here is all kind of new though. Example: if I want to fork mainnet, test an upgrade, and then test frontend changes which use that forked net, as an account which I don't have the key for, I just.. can't right now. Hardhat lets you impersonate accounts which is amazing, but no frontend wallet lets you send unsigned transactions using an impersonated account (which effectively uses provider-managed signers). The "best" way I found to do this is forking an open-source browser wallet extension, hacking it a bit, and hardcoding the account I want to send the unsigned transaction for, to the hardcoded local RPC endpoint, which requires an extension reload, and is still finicky. Eventually I think the tooling will get there, but for right now it still seems fairly immature to me.

pcthrowaway 4y ago

My company put me on a "web3" project recently, and as someone who has done some kind of web development, at least at the hobby level, since 1999, I can tell you that there's quite a bit of difference with web3. I think the web skills from a decade ago translate better to web-dev today than web-dev today translates to web3 development. With web3 you have to consider the different ways to get on-chain data, and the state is all on the blockchain. Testing is a nightmare and the tooling around development and deployment are still immature. And that's before even getting to solidity or other languages you use for the "backend"

kkielhofner 4y ago
Sounds like you've been at this since I have (mid-late 90s as well)! I somewhat agree with you on the state of tooling compared to web dev today but I'm not sure it matters or is terribly relevant to the point OP is making. I've been in this space one way or another for five years so prepare for a (somewhat anecdotal) "dump" that you may (hopefully) find useful for the new project that you've been put on. You mentioned Solidity so let's assume an EVM compatible chain and ecosystem. At this point I'd call anything actually on chain the "back backend". Of course Solidity is the smart contract language but due to costs, speed, etc of the chains themselves the data is all over the place... That's how we've ended up with things like The Graph[0], Ceramic[1], etc. As you've likely already experienced interacting with the chains themselves in any capacity is remarkably creaky hence the plethora of somewhat ironically centralized API providers and solutions with many layers of insane amounts of code and backend infrastructure to make things actually work for anything beyond a toy (like the various Alchemy APIs I provided an example of). This is before you get into anything like IPFS, Filecoin, etc but once again the typical interaction with these is via heavily abstracted libraries and HTTP gateways that do their best to look like any other web2 service. Smart contracts, by their nature, are rarely written and rarely deployed. If you look at some of the biggest "apps" in the space smart contracts represent a tiny fraction of the amount of dev work compared to the overall solution. Take OpenSea (as one example) they've deployed a smart contract twice in five years of operation AFAIK. If you look at their frontend and API docs it becomes clear really quickly they've done a lot more work in areas that at the risk of deploying "No true Scotsman" I would say at least 95% of the dev work in web3 is effectively web2. Now that we're talking about smart contracts, the stakes are so high there is actually a fairly robust amount of tooling IMHO. Maybe not robust compared to the state of 30 years of web development but between OpenZeppelin[2], Hardhat[3], Truffle[4], etc there's a lot out there. From everything I've seen in the space over half my decade by the time you import a bunch of OpenZeppelin contracts there's almost always very little Solidity left to be written. As traditional cryptography devs have learned "writing your own crypto" is almost always a really bad idea. If you were to look at LOC for anything in the web3 space my original point is backup up by the data. Metmask is used by 30 million people and it's all web dev (backed by an Ethereum JSON-RPC[5] interface hosted by MetaMask sponsor Infura by default)... The rest of any user facing application is your frontend pulling in ethers[6] and MAYBE a bog standard web2 service/microservice backend. Then you're off to the races. There is SQL, NoSQL, etc all over the place in web3. From my personal experience and everything I've seen I'd venture to guess that maybe 1/50 devs in the space ever touches Solidity (likely much higher). Everyone else is doing what they've always done by reading the docs for whatever JS/TS libraries they're using. I've personally worked on many projects where web2 devs became "web3/blockchain devs" in an hour - to my original point of saying you're a "blockchain developer" because you're using ethers is really funny to me. My overall point being (and to assuage the concerns of OP) the vast majority of devs that start in web3 feel right at home in web2 and vice-versa. I know exactly one dev who I would call a serious "blockchain developer". They came from a web dev background and they're all in on Cardano which meant picking up Haskell (which would send most web devs running for the hills). If a dev were to start with Cardano + Haskell I have no idea where they would end up if they left "blockchain development". [0] - https://thegraph.com/en/ https://thegraph.com/en/ [1] - https://ceramic.network/ https://ceramic.network/ [2] - https://www.openzeppelin.com/contracts https://www.openzeppelin.com/contracts [3] - https://hardhat.org/ https://hardhat.org/ [4] - https://trufflesuite.com/ https://trufflesuite.com/ [5] - https://geth.ethereum.org/docs/rpc/server https://geth.ethereum.org/docs/rpc/server [6] - https://www.npmjs.com/package/ethers https://www.npmjs.com/package/ethers
- pcthrowaway 4y ago
  Thanks for the very in-depth reply. I've only been doing it for ~5 months now, so definitely consider myself a "junior" in the space. What we've done is fork a popular defi protocol (think AAVE/Compound) that consists of >10 core contracts, plus additional for markets, and made a few changes. Then deployed a few custom contracts as well. I've written ~100-200 lines of solidity that are on mainnet now, the rest, as you say, are snapping together Openzeppelin legos. We're not using The Graph for our frontend (yet) though I think we want to in the future. Our current stack is Hardhat (with ethers) for both deployment and testing, and react + typescript + react-query on the frontend. We're able to get contracts deployed on a hardhat node or goerli pretty quickly now, but, for example, if deploying to goerli, the 200-300 transactions for the deployment process take ~1 hour to send through, so it's really just where we deploy right before we release (in addition to testing on a fork of mainnet). The tooling here is all kind of new though. Example: if I want to fork mainnet, test an upgrade, and then test frontend changes which use that forked net, as an account which I don't have the key for, I just.. can't right now. Hardhat lets you impersonate accounts which is amazing, but no frontend wallet lets you send unsigned transactions using an impersonated account (which effectively uses provider-managed signers). The "best" way I found to do this is forking an open-source browser wallet extension, hacking it a bit, and hardcoding the account I want to send the unsigned transaction for, to the hardcoded local RPC endpoint, which requires an extension reload, and is still finicky. Eventually I think the tooling will get there, but for right now it still seems fairly immature to me.