My Journey with Solana India Fellowship — Week 2

Nipun Agarwal
7 min readFeb 19, 2022

“I think Web3 is not only better for the world, but it’s also going to beat Web2. It’s going to be more popular because the people get really excited when they actually get to participate.” — Chris Dixon

Hello web3 lovers. I just completed my second week of Solana India Fellowship. In this post, I will be talking about ten tips from the session by Preethi Kasireddy on transitioning from web2 to web3, getting an airdrop of 2 SOL in our wallets, making our first web3 game and building our first smart contract on Solana. If you have not read my (week 1) experience yet, I’ll encourage you to read that first to get an idea about web3, Solana, and this fellowship.

A session with Preethi Kasireddy 👩‍💻

If you are not aware of Preethi, she is an Entrepreneur, Engineer, and writer. She started DappCamp, which gives a hands-on experience in architecting, developing, and scaling a Web 3.0 app on Ethereum. Previously, she has worked with a16z, Coinbase, and Goldman Sachs. She took a session on an essential aspect: transitioning from web2 to web3 developer. The talk covered the 10 points to becoming a web3 developer and an open floor to ask questions. Here is a synopsis of the session and points to note when working with web3.

1. Forget about the client-server model:

Compared to the traditional client-server model, web3 is decentralized, and the intuition is a lot different from web2. The developer needs to let go of control, and many logics, which might seem very simple in web2, can be complicated in web3 because of its design.

To implement features in web3, we might need to think about out-of-the-box ways and make rational decisions whether it makes sense to put data in the blockchain.

2. Iterative development is out the door

In Etherium, it is tough to change contracts since they are immutable. Services like continuous delivery and other mutable stuff are out of the door. We need to be very sure about what we are deploying and sometimes need to take a step back if it’s essential to deploy on web3.

3. Traditional thinking

Since web3 involves more interaction with low-level engineering, it has to be more optimized and cost-efficient. Token economics cannot be neglected and is crucial for the DApps release.

4. Build it, and they will come

Community management, discord servers, early beta users provide an insane value in the web3 ecosystem. Some teams build community before writing code since this helps validate their idea. Thinking about the community at the beginning itself is super important.

5. Proprietary software is a no-go

The Web3 concept is all about open source. Anyone can audit the code, and everyone can build on top of it. Github, Gitlab plays a crucial role in forming the community culture, triggering discussions, and including the people’s voice in the project.

6. Building in public is a must

Web3 projects scale faster when you start talking about the project publically, even while building it. It enables the channels for feedback to help in faster releases and better growth. The community should be treated as beta users instead of competition.

7. Security > pretty code

In web3, security is of utmost importance. A single failure can make things haywire since you deal with money and transactions. Security Audits and regular checks are crucial for maintaining the system’s compliance.

8. get used to rabbit holes

Web3 is growing at a rocket pace. It is tough to keep track of all developments, but one should be aware of the basics of everything. Be willing to learn and experiment.

Learning crypto is like working with a firehose. It’s exciting and fun. Don’t feel overwhelmed, instead accept the knowledge.

9. Be willing to change your ways

Things are changing fast in web3, and you have to sync to catch stuff. Web3 is more about waterfall context than agile. It’s a much better paradigm. We are not building like web2 apps; we are managing money. be open to new things, critique, and come up with arguments for why this is good and bad. Try not to live in a fantasy world and be realistic.

10. become a master of memes

Hands-On with Solana SDK 💻

After a motivating session by Preethi, we got our weekly assignments and quests. This week was an introduction to Solana-cli, basic programs in Solana using web3js, and building our first voting smart contract.

The first quest was about creating an airdrop program in Solana. Airdrop means getting some SOL in our wallet to sign transactions and interact with local and dev blockchain. The quest was relatively simple and easy to implement. Basic knowledge about JS and Solana SDKs is sufficient to complete the quest.

The second quest was creating a fun roulette game in Solana. The idea is that a player will get an interactive screen when running the program in their terminal. They have to stake a max of 2.5 SOL with a staking ratio in the game and take a guess on a number between 1–5. If the guess is correct, the user will get back the money they have staked multiplied by the staking ratio. Otherwise, they lose. The game was exciting and fun to make. There will be a treasury wallet where the user needs to transfer the bet before starting the game. The program will transfer the win amount to the user’s wallet if the user wins. I divided the whole project into different parts.

Part 1 -> Frontend client of the project by developing an interactive CLI that will take all users’ input.

Part 2 -> Helper functions to transfer money from different wallets, airdropping balance in treasury and users wallet, generating random numbers, etc.

Part 3 -> Integrating helper functions and the client to complete the project.

I used different libraries for JS like figlet and inquirer to create an appealing terminal interface. Complete code of this project is updated here.

Building our First Smart Contract 🗳

After completing the two quests, this week’s exercises involved developing a decentralized voting mechanism through a Solana smart contract. The person who deploys the contract will be the chairperson and add voters to a ballot. Initially, each voter that is added will be given a single vote. Voters can vote for the respective candidates or delegate the votes to other candidates. The smart contract should have required checks and should be able to declare the winner after the end of the election.

At first, the problem statement felt challenging, but I broke down the problem into small functionalities to make it easy. Not knowing how smart contracts are developed, I watched videos on Solana smart contract development basics using Rust and Anchor. The contract development was not intuitive initially, but as I watched more and more videos and looked at examples, I started understanding it.

To visualize the smart contract structs and functions, I created a small diagram for respective flows.

I used anchor for all the development since it offloads a lot of boilerplate code like account serialization, de-serialization, clients for running smart contract functions, etc. I made many mistakes while developing and scratched my head for many errors and certain things that even StackOverflow couldn’t answer. I had to dive into the source code itself, but this exercise made me understand the world of Solana well. If you are interested in the source code, you can access it on GitHub.

Resources ㈾

1.https://docs.solana.com/developing/clients/javascript-api

2. https://solana-labs.github.io/solana-web3.js/ (Web3 JS functions)

3.https://www.youtube.com/watch?v=7l1P3xzr7Jo (Initial guide on smart contracts deployment and development)

4. https://www.youtube.com/watch?v=-7b9zKBwdpo (Solana Smart contract lifecycle)

5. https://bip.so/@questbook/Resources-to-learn-Solana-ngzAK (A-Z Resource for Solana)

Key Learnings 🔑

1. Initial learning curve can be challenging, but the more you practice, better you perform.

2. Same architecure mindset cant be applied everywhere. What works in web2 might be a disaster in web3.

3. Community support is underrated.

4. Real fun is when you dont find the solution of your problem on stackoverflow.

--

--