Why Solana?
The Egyptians and the Vikings both had an ace up their sleeves. They possessed a technology that gave them an edge over their competitors. What was this? With wooden poles and some grease, they could move huge items overland.
For the Egyptians, it enabled the creation of the pyramids, and for the Vikings, they conquered huge swaths of Europe. But what if they could have reduced that friction further with axles and modern bearings? Not only could they have moved those items faster, but more importantly, they would have been able to build entirely new forms of structures and civilizations.
Using Solana is like having an ace up our sleeves. Solana reduces transaction ‘friction’ for smart contract applications by huge leaps — with over 50 thousand transactions per second and sub-one-cent costs.
Reducing this ‘friction’ enables a smoother user experience and opens up whole new ways that we can deliver value to our customers. At Parcl, as with many greenfield projects, transaction speed and cost are among the most important factors we considered in the selection of our Layer 1, and why we ultimately chose Solana.
How does Solana achieve this? Conceptually, it’s pretty simple: the protocol is optimized around speed. As a developer, that means you need to understand how to build applications that fit within this optimized architecture.
While there is more upfront learning, the payoff is greater. This article will walk you through the conceptual model, data structures, and implementation tools that will make you efficient at your development task.
Key Benefits of Solana
- It’s fast. It can process over 50,000 transactions per second.
- Fees of less than $0.01 per transaction enable more usage of your application.
- There’s headroom for further performance growth, with the potential of over 1 million transactions per second in the near future as the network is further improved.
- It’s composable, which means that you can break your application into modules, and other people can then build upon your libraries. You can also use other people’s application modules in your own projects.
Challenges of Developing on Solana
- Solana has a different type of architecture, which means you have to spend more time thinking about how to lay out your project.
- Smart contracts are mainly built in Rust, a memory-safe language similar to C and C++. This might seem daunting at first, but Rust has a huge and growing following, and Rust skills can be transferred to optimize other areas of your application too.
- You’ll need to learn the tooling specific to this protocol.
Although there are challenges, the increased effort in learning the protocol, language, and architecture is outweighed by the long-term performance benefits. In the next sections, we walk you through the key concepts needed to become successful at developing on Solana.
Account Architecture
Solana’s account architecture is core to providing the protocol’s performance. It does this by separating out the code and data into accounts, which allows multiple programs to operate in parallel with each other.
Let’s take Ethereum smart contracts as a comparison. An Ethereum smart contract has both the data and code built into the contract, making it easy to read and understand. In contrast, Solana is built around performance optimization with stateless programs interacting with data structures that are separated out.
With Solana, data is stored in accounts, each with its own address. These accounts can be designated either as read-only programs or as data accounts, which can be in a read-write format.
A useful way to conceptualize this is to think of accounts acting like files in a standard file system where the programs are executable files, and the data that each program needs is stored separately.
Metadata is also associated with each account, including its allocation of SOL (the native token of Solana), who owns the account, and whether the account stores a program’s code or not. Importantly, only programs can control and own an account.
However, these programs, such as the system-wide token program, can store addresses of wallets in their account data section that indicate who has authority to control those tokens. Hence, even if users don’t directly own the account, they can control or ‘own’ a token.
In summary, users of the protocol interact with stateless programs that can create and store information on behalf of them in accounts.
Hello World Coin
Now that we’ve gone over the account’s general architecture let’s apply this to a real-world example. As an example, we will use Solana’s inbuilt token program to create a ‘Hello World Coin.’
But, how does this work? Let’s take “Bob’s Wallet” as an example. Bob decides he wants to mint a Hello World Token (HWT). He calls the token program, which creates a mint account owned by the original program.
The mint account will include data on the max supply and other key information about the coin. But, it will record that the authority is Bob, allowing him to control the many different aspects of HWC data.
Suppose Bob decides he wants to allocate himself tokens. In that case, he calls the token program, which then creates another account that will store the token information for Bob, which could be 10,000 HWC’s, with the authority being Bob.
The same goes when Bob wants to allocate coins to another person, Alice. He would call the program. That would create another account owned by the program that references Alice as the authority (colloquially, we’d say she ‘owns’ these tokens) with the token data set to allocate 20 HWC’s.
In summary, the token program, which is stateless, uses separate accounts for configuration information and data specific to the different users. It’s a different model from Ethereum, but once you understand how it works, it makes it easier to start thinking about how you can use it to build your own applications.
There are other concepts that you’ll need to understand: CPI (Cross Program Invocation), which allows one program to invoke another program; and Program Derived Address (PDAs), which enables programs to control accounts, such as allowing the program to own tokens in its own right, which is useful for building things like escrow accounts with multiple steps.
Complete System
So how does this all tie together to make a full working system? It can be useful to look at how all the components of a working project connect to help cement some of the concepts.
Key components to a smart contract application:
- Smart contracts residing within the Solana blockchain
- A web application that the user interacts with (typically built in React)
- A wallet that stores the user’s private keys (e.g., Phantom Wallet)
In this example, the React-based application would allow users to connect their wallet that stores the user’s private (and hence public) key information. The application can then pull data from the Solana node via Remote Procedure Calls (RPC) and then display information about the state of the blockchain. The above example could include the amount of Hello World Tokens owned by Bob.
If the user wanted to send tokens to Alice, this would be accomplished by the React app’s javascript code creating a transaction request for the token program to a new account for Alice.
The React application would ask the Phantom wallet to sign this transaction, forcing the extension to request permission from the user. Once signed and sent, the transaction would be broadcast to the Solana network, within which the smart contract would then complete the process.
Rust & Anchor
In this section, we’ll talk about frameworks, languages, and tools needed to build your Solana smart contracts.
To start, Solana is built on Sealevel, which is the runtime for Solana. The coding languages currently used to build Solana smart contracts are C, C++, or Rust. However, with its balance of performance and memory safety, Rust is most commonly used.
That said, there’s a lot of boilerplate code involved if you write your application directly using the Solana API. This is where the magic of the Anchor comes in. You can think of Anchor as a framework similar to Ruby on Rails.
Instead of helping build web applications using Ruby, it helps you build efficient smart contract code on Solana. Anchor does this by providing a set of macros that help provide that boilerplate code so you can focus on building your core application logic.
Anchor has a few more tools to support further your smart contract development, such as a command-line interface making it easier to create anchor apps. Anchor can also create an interface definition language (IDL), which allows you to define your smart contract interfaces in a file.
This is important for making the whole process straightforward. It allows you to generate javascript libraries which will, by default, understand the structure of your smart contract, which other applications can consume.
Conclusion
We hope that this article has highlighted the key reasons we decided to build our real estate protocol on the Solana blockchain and why and how to use Solana for your own development projects.
Feel free to check out my explainer video below, which provides visual cues and a walk-through of why we chose Solana.
Join Us on Our Mission
We’re always looking for talented developers to join our team. We have positions open for blockchain engineers, React frontend development, Data Science, and Data Engineering, to name a few. If you want to join a great team that values your contribution, gives you room to innovate, and create amazing products, please reach out to us at jobs@parcl.co or DM us on Twitter @parcl
Follow us
🌐 Join our Waitlist: https://parcl.co
🐤 Twitter: https://twitter.com/Parcl
🏡 Discord: https://discord.gg/zWxp2JupNA
Shared content and posted charts are intended to be used for informational and educational purposes only. Parcl does not offer, and this information shall not be understood or construed as, financial advice or investment recommendations. The information provided is not a substitute for advice from an investment professional. Parcl does not accept liability for any financial loss or damages. For more information please see the terms of use.
