A summary of my first week on my journey to becoming a Block chain Developer.
The classes started perfectly well, and for the fist class, I learned in general what entities make up the Blockchain ecosystem. What Distributed Ledgers Are. I learned what Consensus Mechanism was all about and how changes are made to the blockchain via consensus mechanism (proof of work and proof of stake), How data are stored in the blockchain using Cryptographic hash functions and public key cryptography.
Following up on the first day, the second class was more detailing, concepts like Ethereum (System), Ethers(currency), Nodes (computers that propose and verify blocks of transactions on the chain), Blocks(the unit of a blockchain consisting of transactions), Transactions(a proposed change to the blockchain), Accounts (holder of Ethereum currency -> ethers), Clients (implementation that verifies data against some rules and keeps the network secure), etc, were discussed.
On the third day, we were taught in-depth knowledge of the EVM, how codes are converted to bytes code and executed, types of accounts (smart contract and EOA), informations included in a transaction (from, to, nonce, input data, parent hash, gas limit, value, maxFeePerGas), types of nodes (full, light, archived), Merkel Tree (structure of how data is presented in the chain), types of networks (testnets -> goerli, sepolia, and mainet -> Ethereum Mainet) and how to get ethers from faucets for testing on testnets. Goerli is majorly used by protocols engineers to test upgrades while sepolia is mostly used by smart contract engineers to test applications.
On the fourth day, we focused on how Transactions are computed, the costs, and how the costs are calculated (transaction fee * (base fee + priority fee)). What are base fees (fees determined by previous blocks executed before the proposed block is to be executed), and what a priority fee is? (an incentive for a validator to include a transaction in a block), max fee (a max amount of gas fee a user is willing to pay for its transaction to be included in a block). Why gas fees/limits are included in transactions ( to help keep the network secure and prohibit spamming of transactions). Denominations of ethers such as gwei(10billion), weth, etc were explained as how to convert from one denomination to another. The differences between Non-Fungible Tokens (100% unique, non-replaceable and can have only one owner) and Fungible Tokens (not unique, identical, dividable and can serve as currencies). We also talked about ECDS, an algorithm that generates a public address of your account by taking the last 20 bytes of the keccak-256 hash of the public key and adding 0x to the start. Also, we got to know about the London upgrade (adding the base fee and priority fee) to a gas fee.
On the Fifth day, we went into in-depth studying of popular EIPs although our focus was on EIP type called ERCs (ERC-20 -> Tokens, ERC-721 -> NFTs, ERC-1155 -> allows creation of contracts by implementing both ERC20 and ERC721, ERC-6551 -> Token Bound Accounts, ERC-998 -> Built on ERC-1155 and ERC-721. We also discussed core EIPs such as EIP-1559. We study the scalability issue in Ethereum and how to tackle them using on-chain (sharding) and off-chain methods (using protocols such as chaining, roll-ups, channels, plasma etc.) We talked in-depth about Rollups and how it helps proffer solutions to L1 scalability issues. We focused on optimism rollups (transactions are bundled and passed to L1 without proof of validation, i.e. all transaction data on-chain are passed to L1) and ZK-rollups (where proofs are cryptographically generated and sent along to L! to validate transactions). We discussed Examples of Optimism rollups such as Arbitrum (where transactions are executed in batches until a discrepancy) and Optimism (transactions are executed as a whole). We also discussed ZK-rollups and the form in which the cryptographically generated proofs are sent to Layer 1. These proofs might come as ZK-SNARK (ZK-SNARKs are popular for their small proof sizes and constant-time verification) and ZK-STARK (the downside of it being costly than ZK-SNARK because of larger proof sizes. Although there are more scalable and transparent than ZK-SNARKS). At the end of the shift, we were teased with the task of writing a script using typescript that generates a public address, public key, and private key using a mnemonic phrase.
During the weekend, we had a scripting task to write a script that returns a contract address type, address balance, and count of transactions related to the address.
Here is a repo link to the scripting task -> https://github.com/ETIM-PAUL/web3-script