https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/4NjuhHI0kqulg5DNDI87KvzmBvPQBunGthsk4Lp9W0Q

https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/WVcDX9vFOSTf8LHQnQYmkT22CBI6OQE-CNAk68m1nnY

https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/jwCKlm2bpF6Pfd1nW3t9K1U-qruH-y9848TQEPIdN-c

https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/Hx0NH-yUC5ZvV_N-_ImOJCyetubi6qE0x_sR31n-5Vc

https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/UTrSiPyxtTsLtJnf7WwMPAltOS7OdHT-xb-GII3ShGI

https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/w-z7BOZAKn_Wz94PaoEoYTHt2d-8e1YouF3MWaw8OdM

https://mirror.xyz/0x378b45251c732E190ccf74A0FC971DF73559CA67/8KWDT1GxPzT3gh9vJeVE-5-oTAaXkMgzVGHEgROUCzc

That’s a wrap! 👋

https://www.alchemy.com/dapps/banana-wallet

https://www.jiffyscan.xyz/

https://github.com/4337Mafia/awesome-account-abstraction/tree/main

I also got to discuss my project idea with the panel and identified a few more features that could be added to my wallet application to make it finer. Adding a paymaster to the wallet application makes it easier for users to make transactions using any ERC20 token. So far, contracts for a simple wallet, wallet factory and a paymaster are in place. With the basic functionality in place, the implementation of the MEV-resistant bundler and tying the different components together is the agenda for the last week. The following reference projects have been a huge help and will be a great place for beginners to start out.

https://github.com/eth-infinitism/account-abstraction

https://github.com/eth-infinitism/bundler

https://github.com/plusminushalf/demo-aa

https://github.com/eth-infinitism/trampoline

Yabba Dabba Do! 👋

Problem Statement:

The transaction-batching feature of account abstraction lets users batch multiple transactions together to save on the gas fees for a single transaction. However, when batching transactions, front-running and sandwich attacks cause a problem. Invalidation of even one transaction, though MEV attack, could lead to invalidation of the whole batch of transactions, also called mass invalidation.

This calls for MEV attack resistance on the wallet application to ensure that the multi-transaction feature cannot be exploited. For Starters, the Gnosis safe contracts serve as a reference implementation for the multisig wallet that supports social recovery and transaction batching.

https://github.com/safe-global/safe-contracts

Other reference implementations that helped me form a bare-bones multisig wallet with social recovery features are the Candide wallet and eth-infinitism.

https://www.candidewallet.com/

https://github.com/eth-infinitism

For MEV attack resistance, flashbot protect is the go-to solution. Flashbot protect receives transactions into its own mempool instead of the public mempool. Here, the transactions are evaluated to check if the transaction needs flashbot protection or not, if it does not the transaction is sent back to the public mempool otherwise it is protected from MEV attacks.

https://medium.com/flashbots/announcing-flashbots-protect-9e039e9f0aa3

Since the transactions using account abstraction use a separate mempool, the inclusion of the flashbot protect could cause a problem as it requires the transactions to be sent to the flashbot mempool instead followed by the transactions being sent to the public mempool. This piece of the puzzle needs a bit more brainstorming.

To infinity and beyond! 🚀

I got to explore Polymarket, the DeFi platform that allows users to bet on their beliefs and win for being right. Polymarket is an information market, that allows users to bet on future outcomes in a market. Information markets like these serve as a source of truth as opinions shared in these markets are backed by value and hence are more reliable.

https://polymarket.com/

Each market has YES and NO outcomes and those who wish to participate in the market can buy and sell shares to either or both shares. On resolution, the winners can redeem their winning shares at $1 per share. Users can also provide liquidity to the markets and earn from the liquidity provider (LP) fees. Users can also split their shares into both outcomes, i.e 1 USDC gives 1 YES and 1 NO share). Providing liquidity to the market attracts more participation, increasing the accuracy of the data.

The platform also helps spectators to understand the market conditions with accuracy. With the help of the graph, users can understand how opinions have changed in the past week. Cannot find a market of interest? Join the discord server and have people bet on your market!

For the project in the build phase, I have been intrigued by account abstraction and its advantages over EOAs. Projects like ArgentX and Avocado have been great resources to explore the implementation of EIP-4337. Listing a few of the resources for the curious.

https://eips.ethereum.org/EIPS/eip-4337

https://blog.instadapp.io/introducing-avocado/

https://www.argent.xyz/blog/argent-x-starknet/

https://github.com/eth-infinitism/account-abstraction

3, 2, 1, blast off! 🚀👽

With speedrun challenges wrapping up, we had more control over the direction our work took. Multisig wallets, also sometimes called multisig vaults or safes, are a type of crypto wallet that requires two or more private keys to perform certain tasks. This is done to increase the security of the funds stored in the wallet by requiring multiple parties to sign off before sending any transactions. The process of a multisig wallet works by requiring multiple signatures from a set of predetermined addresses, and if any one of these signatures is missing, the transaction will not be able to go through. Think of it as a safe with unique keys that must be used together to open it.

https://www.alchemy.com/best/multisig-wallets

For the challenge, the generation of the packed hash was done off-chain. The packed hash included transaction details like value, data, nonce, chainId, etc. We were able to add and remove signers and based on the number of signers we could also set the number of signs required to process a transaction properly. However, this exposed a bug in the contract, where one could easily set the signatures required to be more than the signers present and cause a DOS attack on the multisig contract.

https://buidlguidl.com/build/dpsOsQMS9RCSQS2INf2b

The second challenge was a fun SVG NFT challenge. SVG NFTs are NFTs with all their data on-chain, where usually NFTs store the data on IPFS. This was a great way for us to show off our own creations and here is mine!

There was a nonce too high error that I faced while working on this challenge. This is the error and here is how to solve this issue.

https://medium.com/@thelasthash/solved-nonce-too-high-error-with-metamask-and-hardhat-adc66f092cd

https://buidlguidl.com/build/kDoww0wk6KDQuE81U8Kk

Speedrun Ethereum has been a great learning experience and this is not all, there are many more resources for the curious mind to hack through!

https://docs.scaffoldeth.io/scaffold-eth/

Last but not least, keep an eye out for scaffold-eth 2.0 ✨👀

https://twitter.com/austingriffith/status/1626654919985074177

That’s all folks! 🤠

Filecoin lets users store their data on the filecoin network through storage deals. Storage providers (SPs) on the network take these storage deals, add the files onto the network and generates a proof of storage at regular intervals to prove that the data is correct. These SPs get rewards for their services and anyone with enough space on their devices and the required specs can become SP for the network.

https://filecoin.io/blog/posts/how-storage-and-retrieval-deals-work-on-filecoin/

The challenges for the week had us build our own minimum viable DEX. Learning about how liquidity pools maintain liquidity using the curve function along with the interactive front-end to see it in action was really interesting. Based on the reserves added to the pools, we calculate the number of tokens we can swap for a given token and the curve function ensures that the pool never runs out of liquidity. This knowledge could also help users make favourable trades. For a more detailed version of the DEX take a look into uniswap-solidity. The fact that anybody having the token pairs could participate in providing liquidity into the pools highlights the permissionless aspect of blockchains.

https://github.com/PhABC/uniswap-solidity

DEX: soft-grandmother.surge.sh

https://goerli.etherscan.io/address/0xfDA13f19ae9C2db505038ceaBa18DA5E0AfF4D2f

The second challenge introduces us to a major problem in blockchains, blockchain trilemma. A trilemma is a situation where there are three options, but at most only two of them are possible to achieve at the same time. In the case of the blockchain trilemma, the three options are security, scalability, and decentralization.

https://coinmarketcap.com/alexandria/glossary/blockchain-trilemma

State channels really excel as a scaling solution in cases where a fixed set of participants want to exchange value-for-service at high frequency. The canonical example is in file sharing or media streaming: the server exchanges chunks of a file in exchange for micropayments.

https://ethereum.org/en/developers/docs/scaling/state-channels/

Building the state channel application introduces all the core aspects of such layer 2 solutions. Building an application where a client/user could get off-the-cuff services in exchange for payment only for the services received was a great way to see these solutions in action. The challenge also urged me to look into other L2 solutions and how those compared to state channels.

https://ethereum.org/en/developers/docs/scaling/

While hacking the challenge, I also learned how to sign and verify signed messages using the ECDSA library. The only downside, all the off-chain services could only be passed between tabs open in the same window.

State Channel: ratty-achieve.surge.sh

https://goerli.etherscan.io/address/0x04E99ae799F6e4dAb81D0fDedB407397BEbf752b

I also faced an overflow issue while making the contracts where the timeLeft function wasn’t taking into account where the deadline was already crossed and a simple if-else statement did the trick. This week I also started taking into account how to make my code gas optimized and why it was necessary when deploying contracts.

https://dev.to/javier123454321/series/14724

If you made it through the entire blog, you deserve 🙌👏

The best way to get building on your ideas is the Remix ide without worrying about the development environment setup. Remix ide comes with a bunch of plugins that help fasttrack your development cycle.

The foundry book is a great resource for contract testing in solidity language. Foundry also provides fuzzing and invariant testing to make sure the tests written for the contracts pass for a range of values. The highlight has been the mock function that lets us return a specific value for a function call and the prank function for impersonations.

https://book.getfoundry.sh/

This week’s challenges were the Token Vendor and the Dice Game. The token vendor challenge was an introduction to the approve pattern when transferring ERC20 tokens. The token contract deals with the mint, transfer, etc functionalities of the token and the vendor contract is used to list the custom ERC20 tokens and set the price for each token, per ether. The tokens are sold on the vendor contract and the profits are withdrawn by the token owner address. The interaction between contracts and the approval pattern was highlighted in this challenge.

Token Vendor: https://resolute-jail.surge.sh

https://goerli.etherscan.io/address/0x16c29F6cDabb59C87108885103A1fE78cf99dE3f

The Dice game was a fun challenge where we got to hack a dice game contract. The dice game contract used a predictable random number generation logic. Since the contracts are immutable and hold real value, predictable randomness poses a challenge. We were able to use the same randomness logic to exploit the dice game contract and only throw winning rolls.

Dice Game: https://wry-grandfather.surge.sh

https://goerli.etherscan.io/address/0xe0bca68ac813282FEc62171F0027acF57Ec84206

In real-world applications, this problem is solved in one of two ways; produce randomness off-chain or use chainlink VRF (Verifiable Random Function). The VRF generates one or more random numbers along with cryptographic proof of how these values were determined. This proof is published and verified on-chain before any application can use it.

https://blog.chain.link/random-number-generation-solidity/

Lastly, we tackled the deadman’s switch problem. A well-known problem for cryptocurrency holders is that all funds are lost if the owner is incapacitated and has not shared his/her private key with anyone else. As a solution, a contract is designed where the owner needs to call the stillAlive() function within an interval of 10 blocks, failing to do so the funds held in the contract are transferred to a pre-set successor address.

https://en.wikipedia.org/wiki/Dead_Man%27s_Switch:_A_Crypto_Mystery

Multisig wallets could be a good solution to this problem. Where a wallet would be able to make transactions even when one of the owners (signers) is incapacitated. As long as a majority of owners sign for a transaction, the funds stored in the wallet can be saved.

https://www.coindesk.com/learn/what-is-a-multisig-wallet/

Phew! Thanks for sticking until the very end. Here’s an axolotl

The first week started off with an introduction to Ethereum with none other than Austin Griffith and scaffold-eth.The secret sauce for getting started with building on Ethereum: scaffold-eth + Solidity by Example. A great place to start tinkering with solidity code and watch it come to life in real-time. Copy and paste the concepts from the examples and interact with them on scaffold-eth.

https://twitter.com/austingriffith/status/1483834810359377923

The agenda for the first week was to get our hands dirty and try out speedrun Ethereum challenges. The simple NFT example was a follow-along exercise for developers to get used to the basics of solidity language and to better understand wallet applications and testnets. The Decentralized Staking App was a bit more challenging with an introduction to concepts like fallback functions, mappings, modifiers and inter-contract communication.

For the second challenge, I used some different approaches initially like tracking some global vars for certain areas and if-else statements. Needless to say, there were more things for me to learn after reading through the page. This also forced me to look into contract testing and how events are used to communicate with the front end.

The contracts for both challenges are deployed on the Goerli testnet and the front end is hosted on Surge.

Deployment links

Simple NFT Example: https://instinctive-mom.surge.sh

https://goerli.etherscan.io/address/0xA1e36c97a561B5412e2e78DE116324e4b6781d84

Decentralized Staking App: https://hilarious-brake.surge.sh

https://goerli.etherscan.io/address/0x945933a2A81943570F44a793bBDbff7954C387C1

For the inquisitive, the Uniswap application is a great source to understand DeFi. The Uniswap series dove deep into the concepts of economic mechanisms and exposes the true potential of smart contracts.

Excited for the upcoming weeks and a lot more learning! ✨