# Notes on "A Developer's Guide to Ethereum pt 2" Editing in ghost is terrible and difficult, so I'll try to structure these notes so that you can re-read the article along with them and make the changes manually as you see fit. ## Intro / What's next I would re-phrase this bullet-point section to: >[...] If you did read Part 1, you should at least have a fuzzy idea of: >* What a blockchain is and what's in a block. >* What an Ethereum node/client is. >* How to interact with the blockchain using a web3 library. (Getting a little bit more specific will help people decide whether they want to go back, and then you don't have to explicitly tell them to do so or not). > In this article/post, we'll build on these concepts and what they mean for dapp development. We're going to take a deeper look at the participants in the Ethereum network, starting with accounts. There are some[...] ## Web2 vs Web3 I think the snippet fits better under this heading now... >It’s hard not to collect accounts in today’s web. You likely have one for each social media app, news site, delivery service, retailer, airline, etc. Each of these accounts lives on the company's servers, which makes *you* subject to *their* terms and conditions, privacy policy, and security administration. Your account can be frozen, deleted, censored, or hacked -- all at the whim and descretion of the host company. >Web3 is a paradigm shift for account management: You and you alone own and control your Ethereum accounts[...] ("the paradigm shift" is a sentence fragment :\ ) >"This exercise is for educational purposes. Don't store real value in an account unless you understand the security implications!" ## Account creation >That's really all there is to it! There is no registration process and no round-trip to the blockchain or any server. In fact, you can disconnect from the Internet altogether and still create a valid Ethereum account. >Ethereum accounts are generated from a *private key*, which is just a random 256-bit number. Conveniently, Ethereum users and app developers don't have to understand how the key generation process works, but if you're interested in a very deep dive, see my previous posts: "Ethereum 201: Mnemonics" and "Ethereum 201: HD Wallets". (I think it reads better to have the simple cryptography explanation up-front here -- no need for the quote text.) >There's no limit to the number of accounts you can generate and each time the create() method runs, a unique public address and private key are produced. You're free to use the same account for several apps, or create a new account for every app. This is what is meant when a public blockchain is described as permissionless; there is no gatekeeper between you and the network. >New accounts, however, aren't immediately useful. Remember from [part 1](link) that to submit a transaction, an account must pay a little bit of Ether to compensate the (decentralized) participants in the network for computation and security. In Ethereum, this transaction fee paid to 'miners' is called [gas](https://ethereum.org/en/developers/docs/gas/). (As a side note I'm no developer, but I imagine that thinking about gas fees is one major difference that a web2 developer is going to notice). # Web3 account implications So I feel like at this point the article really takes a left turn. While it seemed like we were going to get into something specific about accounts, now it gets quite general and jumps around for a while... I'd strike the "new business models" section unless you feel like getting more specific there. Passwords and keys and what it means for develpers seems to be getting back on track... but then we're on to a brief interlude of onboarding challenges, then private tools, then public apps, then suddenly a *bunch* of wallets -- yeah here's what I'd suggest instead: # Wallets and Users After talking briefly about passwords and accounts, I think it would make a lot more sense to just jump right into "What is a wallet, and how do developers need to think about wallets?" This is a straightforward lead-in to user interfaces and considerations for injected web3 or standalone web3 browsers, and it also ties directly into what's been discussed earlier with providers, creating accounts, and the ipython examples. Maybe there would be a simplway to demonstrate in web3.py/ipython how a web3 site might just ask for a *signature* for authentication instead of a transaction? Signatures are, IMO, really under-represented in the early dev materials, even though they are kind of fundamental... Then, if there's space, you could conclude with just what's in a properly formatted transaction and why it's important, which would lead directly to smart contracts and more complex transactions...