My Journey with Solana India Fellowship — Week 3
“There’s so much going on in the crypto space that it’s hard to zoom out and see the progress. Adoption is happening.” — Tom Shaughnessy
Hello web3 lovers. I just completed my third week of Solana India Fellowship. This week was one of the most intense weeks of this fellowship, and I truly enjoyed it. This article will discuss building your decentralized crowdfunding campaigns using the Solana blockchain, decentralized calculator app to learn better about the anchor, bi-payment channels, and how you can create one in Solana. We will be diving into some snippets of code that I feel are not readily available on the web and might help build your smart contracts.
If you have not read my (week 1 and week 2) experience yet, I’ll encourage you to read that first to get an idea about web3, Solana, and this fellowship.
What are Bi-Directional Payment channels? 💸
The biggest drawback with blockchain infrastructure is its costs per transaction. Every time you need to mutate the state of the blockchain, you need to execute a transaction and pay a hefty fee for it. Now suppose you go to Starbucks daily to have your coffee in the evening breaks with your colleagues. You earn in crypto, and paying every day with crypto coins will be expensive since you need to pay a gas fee every day. There might be times when the network is congested, and you might end up paying 2–3x the gas fees. This approach is definitely not scalable, and to solve this, payment channels are introduced.
The idea is we will broadcast the minimum number of transactions on the blockchain.
A ledger can be maintained between two parties, and they deposit a certain sum in a wallet which is multisignature and can only be controlled when both parties sign the transactions. Consider a scenario where Alan and Alex opened a payment channel. When opening a payment channel, they both deposit 1 BTC each. They both will sign the transactions and are the owner of a multisignature wallet that contains 2 BTC.
Now let’s say Alan wants to give 0.1 BTC to Alex; instead of broadcasting it on the blockchain network, they both sign this transaction offline and exchange it. The other party verifies the transaction whether correct balances are maintained. In this case, the Balance of Alan will be 0.9 BTC, and Alex’s will be 1.1 BTC.
They can keep doing this as long as they want since no transaction fees are involved in signing off-chain transactions. Once they both agree to close the channel, anyone can broadcast the transaction on the network, and the last state of balances will be transferred to both parties.
You can find the solidity code for this problem statement here.
In this week’s exercise, we have to develop something similar in Solana. There are certain drawbacks with this implementation on Solana. Solana still doesn’t allow extracting metadata and verifying signatures on the smart contract end. Because of this, offline transaction signing and updating balances in just one transaction is slightly tricky. However, since Solana transaction fees are low, payment channels don’t make much sense. I created a smart contract to create a multi-signature wallet when both parties initialize an account. The account has to be signed by both parties, and they have to specify their contributions to a common treasury wallet. Anytime they have to update the balances, they can call the smart contract, and both parties need to sign the transaction to maintain the consensus.
Since money withdrawals can’t depend on both parties, leading to conflicts, any authorized person can close the channel. The contract will automatically distribute the money back to the source wallets with the last updated distribution. The biggest challenge I faced in this smart contract was transferring SOL within the smart contract environment. It’s not as straightforward as it was in Ethereum.
Solana achieves SOL transfers using CPI (cross-program invocations), which means calling other smart contracts functions within your smart contract. The critical thing to note is the owner of the account from which you are transferring SOL should always be the signer of the transaction; otherwise, it will fail. I spent three days debugging this, and some members from SuperTeam DAO helped me rectify it. I have put specific validations at many points and also implemented custom errors. You can find the complete code for the application here.
You can transfer SOL from one account to another with this just small snippet of code.
The complete code of this project can be found here
Building crowdfunding campaign in Solana 👩👩👦👦
The idea of this quest was to build a decentralized crowdfunding campaign in Solana. The beauty is we don’t have to integrate any third-party tools like Razorpay, Stripe to receive payments. We can manage all payments using Solana coins itself, and since it’s on the blockchain, the transparency is maintained. Payment processing is a part of the Solana infrastructure itself. Also, unlike any web2 program you write, all the code is public. People can see what you are doing with the money they send to your software. I used anchor to build the smart contract since it offloads lots of boilerplate code and I need to work with logic only.
Every data we want to store on the Solana blockchain is stored in accounts. Accounts are similar to files in operating systems such as Linux in that they may hold arbitrary data that persists beyond the lifetime of a program. These accounts also store metadata that tells runtime who can access the data and how. Since Solana follows rust, I created a struct to depict my campaign, and this will be used by our campaign accounts to structure the data when we create an account.
We can send money to these campaign accounts, and that’s how we will crowdfund our accounts, also called Program Derived Accounts (PDA). Like the bi-directional payment channel, we used CPI to transfer sol from user wallets to the campaign wallets.
This quest helped me understand how to solve a real-world problem using web3.We can extend this problem to many different directions, like the payments can only be withdrawn by crowdfunding managers/owners, or they need to provide the proper proofs where the money is used before withdrawals. Since the evidence will be on the blockchain, it can’t be mutated, making the process transparent.
The complete code of this quest can be found here
Building a calculator app on Solana ➗
This quest is a perfect starter quest to work with the anchor framework. The idea is to build the essential functions of a calculator that stores the final result on the chain. This quest gives you end-to-end knowledge on building, testing, and deploying your first smart contract. Anchor is like a hardhat for Solana; it offloads a lot of redundant code and makes testing easy with in-memory blockchain nodes. The quest was reasonably straightforward, and anyone who attempts should not face many challenges in working with it.
The complete code for this quest can be found here
Key Learnings 🔑
1. Solana might seem very difficult at the start, it’s not that intuitive, but you have to stick and be consistent to gain proficiency.
2. If you are stuck at some point for really long, better to ask in Solana active communities. There is a high probability someone can help you with a solution or a possible workaround.
3. It’s not guaranteed what makes sense in Etherium will also make in Solana. Bi-Directional payment channels are one example.
4. Shitposting on Twitter can help you balance the stress of development in Solana :P
5. Sometimes, you need to think about workarounds rather than the most obvious solution. It might be that workarounds can take less time to ship and might also solve your use case.
Resources ㈾
1. https://project-serum.github.io/anchor/getting-started/introduction.html (To start with an anchor)
2. https://docs.solana.com/developing/programming-model/transactions (To understand about Solana transactions)
3. https://docs.solana.com/developing/programming-model/calling-between-programs (To understand CPI in Solana)
4. https://medium.com/coinmonks/how-to-audit-solana-smart-contracts-part-4-the-anchor-framework-ef42d944f086 (Good read on security aspects of Solana)
