Building Solana Programs with Solidity : Transitioning from EVM to Solana

Introduction

Whether you know about Ethereum, blockchains, or websites, or want to learn something new, this guide helps you become a Solana developer. The guide has simple steps to help you learn .

This article helps you understand Solana programming using Solidity. It also shows how to use Solidity programs on Solana. The article has two parts:

1. Basics for EVM Developers: This part is for developers who know Ethereum and want to learn about Solana. It gives you a good start for the series.

2. Practical Example: spl-token-minter: The second part has a hands-on example using a Solidity program called spl-token-minter with the Anchor framework. It teaches you how to make tokens on Solana using Solidity.

Prerequisite

Before diving in, it's helpful if you already have some coding experience in any programming language. A basic understanding of Solidity (used in Ethereum) and the Solana ecosystem will also come in handy.

Here's what you're gonna learn:

Table of contents-:

1. Introduction to Solana
2. Why build on Solana
3. Solidity basics
   • Learning resources for solidity
4. Solidity program compilation
   • Solidity on solana
   • Solidity on ethereum
5. Exploring Solang
6. Solidity For Solana vs. Solidity For Ethereum.
7. Technical architecture comparison (accounts on both platforms)
   • Account modal
8. Ethereum Smart Contracts vs. Solana Programs: A Comparative Study

Introduction to Solana

Solana is a fast and efficient blockchain platform designed for decentralized applications (DApps) and cryptocurrencies. By blending advanced technologies, Solana achieves impressive scalability and fast transaction processing.

Recognized as one of the most cost-effective and rapid public blockchains worldwide, Solana's speed and economic efficiency set it apart.

Unlike Ethereum's single-threaded execution and EOS's WASM-based runtimes, Solana introduces a groundbreaking approach called Sealevel. This innovative smart contracts runtime operates , handling thousands of contracts at once. It optimizes the Validator's infrastructure to enhance Solana's exceptional performance.

Why build on Solana

Starting in the Solana Ecosystem

If you're new to Solana, don't worry – you don't need an extensive background in smart contracts or blockchain to start building.

In Solana, smart contracts are like programs you can call, and you can use different programming languages to create them. You'll find Rust (native and through Anchor), C, C++, Python (using Seahorse), and even the new addition of Solidity (with Solang and Anchor) for building and deploying these programs on the chain.

By participating, you gain access to a sprawling community of millions, till August 2023 Solana encompassing over 11 million active accounts. This environment has facilitated the minting of more than 21 million NFTs, all at an average transaction cost of $0.00025. , Solana currently boasts a transaction throughput of 4,386 transactions per second (tps), in stark contrast to Ethereum's 24.02 tps.

As you delve into Solana's development realm, you'll find an array of tools and technologies ready to assist you, ensuring a seamless journey into the world of Solana building.

Solidity basics

Solidity is a recently developed programming language originating from Ethereum, the second-largest cryptocurrency market by capitalization. Introduced in 2015 under the guidance of Christian Reitwiessner, Ethereum's core developer, Solidity possesses a set of significant attributes:

• Solidity serves as a high-level programming language crafted for implementing smart contracts.
• It adheres to a typed object-oriented (contract-oriented) paradigm.
• The design of Solidity draws significant inspiration from programming languages like Python, C++, and JavaScript, all which function on the Ethereum Virtual Machine (EVM).
• Solidity boasts support for intricate user-defined programming constructs, libraries, and inheritance.
• As the predominant language, Solidity is the foundation for blockchain platforms.
• The capabilities of Solidity extend to creating diverse contracts such as voting systems, blind auctions, crowdfunding mechanisms, multi-signature wallets, and more.

Learning resources for solidity

solidity_by_example
youtube
cryptozombies

Solidity program compilation

Solidity on solana

Using Solidity with Solana: A Seamless Process

Solidity, the programming language for smart contracts, plays a pivotal role in Solana. It's made even more powerful with the Solang compiler. This tool is essential for converting Solidity code into a format that fits with the Solana blockchain. The compiler handles various optimization stages, transforming the code into bytecode or machine code. This bytecode is tailored for Solana's platform, making it effortless for Solidity developers to create and deploy smart contracts on Solana.

Here's a breakdown of the process:

1. Crafting in Solidity: Smart contracts are written in the Solidity programming language.
2. Compilation: The Solang compiler compiles the Solidity smart contract into BPF (Berkeley Packet Filter) or SBF (Solana Bytecode Format) bytecode using the LLVM compiler.
3. Deployment: The resulting BPF or SBF bytecode is deployed on the Solana Blockchain, becoming a Solana program.
4. Operation: The Solidity Solana program becomes functional within the Solana Blockchain.

Even though the main ideas of Solidity are the same for Ethereum and Solana, there are some small changes you should make when using Solidity on Solana. These ensure seamless compatibility. While similarities exist, Solidity on Solana requires some refinement for a smooth integration with the Solana Blockchain. This means a direct copy-paste from Ethereum might not work.

Solidity on ethereum

Creating and Deploying Solidity Smart Contracts on Ethereum

Developing smart contracts using Solidity on the Ethereum platform follows this process:

1. Crafting the Smart Contract: The process begins with crafting a smart contract using the Solidity programming language. This involves creating a .sol file that signifies the use of Solidity.
2. Compiling the Smart Contract: The Solidity compiler comes into play to compile the smart contract written in Solidity.
3. Transformation to ABI and Bytecode: After compilation, the high-level code transforms into ABI (Application Binary Interface) and bytecode formats. This transformation prepares the code for seamless integration into the Ethereum network.
4. Formation of Program Bytecode: The bytecode takes another step forward and transforms into program bytecode, a significant milestone in the process.
5. Execution or Deployment on the Ethereum Chain: The final step involves executing (deploying) the crafted smart contract onto the Ethereum blockchain. This deploys the smart contract, making it functional within the Ethereum network.

This systematic sequence encapsulates the complete journey of implementing a Solidity-based smart contract on Ethereum's platform.

Exploring Solang

Solang is a Solidity Compiler designed to enable the creation of Solana programs—referred to as 'smart contracts' in other blockchain contexts—using the Solidity programming language.

The compiler leverages the llvm compiler framework to generate WebAssembly (WASM) or Solana SBF contract code. This approach yields optimized output, resulting in reduced gas costs or compute units during execution.

Solang is crafted to maintain source file compatibility with version 0.8 of the Ethereum EVM Solidity compiler.

Moreover, it integrates with established Solana development tools and frameworks, such as Anchor, facilitating the streamlined construction and deployment of Solana programs rooted in the Solidity language.

Solidity For Solana vs. Solidity For Ethereum

Adapting Solidity for Solana's Unique Environment

When integrating Solidity's mechanics into the Solana environment, certain adjustments are necessary. Within a Solidity contract on Solana, a distinct structure emerges, comprising two separate accounts: a data account and a program account. The program account stores the contract's executable binary and controls the data account, which encompasses all storage variables. This contrasts with Ethereum's approach, where a single account manages both executable code and data.

Simplifying Technical Concepts in Solana and Ethereum

• In Solana, an account is represented by a 32-byte key, denoted as the address type, which differs from Ethereum's 20-byte address format. An address is represented using syntax like 36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D.

• It's important to note that Ethereum's address format 0xE0f5206BBD039e7b0592d8918820024e2a7437b9 isn't compatible with Solana.

• Ethereum's wallet addresses generally have 40 characters, including the 0x prefix. , Solana wallet addresses can be around 44 characters in length, without a fixed prefix.

• The use of Solana's target requires Solana version v1.8.1.

• In Ethereum, setting the gas limit while invoking a smart contract function influences resource consumption. Gas encompasses the on-chain execution expenses and permits the prioritization of execution through the allocation of extra gas. Each instruction within the Ethereum Virtual Machine (EVM) carries a unique gas value, which corresponds to real ETH costs.

• Solana optimizes for low latency and high transaction throughput, introducing compute units like Ethereum's gas. Each smart contract function is allocated the same number of compute units (currently 200k), and every instruction of a contract consumes exactly one compute unit. Unlike Ethereum, Solana doesn't need specifying compute units for transactions, and they aren't charged. Yet, charges are based on consumed compute units for execution priority. Thus, gas concepts don't apply to Solidity on Solana.

• The msg.sender function isn't available in Solana.

• Due to different signature algorithms, Solana lacks the ecrecover() function. Yet, signatureVerify() verifies ed25519 signatures. Extracting a signer from a signature isn't workable.

• On Solana, try-catch statements lack functionality. If a call or contract creation fails, the runtime stops execution and reverts the transaction.

• Error definitions, reverts, and error messages don't work in Solana.

• The ERC-20 interface isn't currently compatible with Solana.

Here's a simplified comparison table between Solana and Ethereum various technical incompatibilities:

Technical Architecture comparison

(Accounts on both platforms)

The technical structure of blockchains sets Solana apart from Ethereum through distinct programming approaches. Solana utilizes diverse paradigms and patterns, moulding its account model, rent system, Cross-Program Invocation (CPI), and Program Derived Address (PDA). These concepts will be explored in-depth in this series. This article centers on outlining the account model and its differences from Ethereum's architecture.

Account Model:

• In Solana's runtime environment, known as Sealevel, the account model simplifies complex interactions. For preserving the transaction state, the mechanism involves accounts. These are like files in systems such as Linux, storing lasting data beyond program lifetimes.

• Unlike traditional files, an account's longevity is tied to its rent, denoted in fractional native tokens known as lamports. These accounts live in validator memory and rely on rent to persist. Regular scans are conducted to collect rent, and accounts with zero lamports are deleted. Accounts are considered rent-exempt if they maintain a smallest lamport balance.

• Solana's Sealevel, unlike Ethereum's EVM, has two distinct account types: executable (upgradeable) and non-executable (for mutable data). Unlike EVM, Sealevel allows contract data access in any account, but changes are limited to the designated "owner" for security.

• Solana's storage approach differs from Ethereum's. Any Solana account can host state. , Solana's contract state is within other accounts. Each Solana account links to an owner contract, securing state change control.

• In account-based blockchains like Ethereum and Solana, versatile on-chain data enhances decentralized applications. Yet, EVM and Sealevel differ in state storage. Ethereum's smart contracts manage storage, while Solana allows any account. Smart contract storage uses bytecode. Solana's state is in accounts, each linked to an owner contract for state changes.

Here's a simplified comparison table highlighting the key differences between Solana and Ethereum their technical architecture and account models:

• On Ethereum, token contracts have a mapping which defines the balance for each owner address:

mapping (address => uint256) private _balances;

• On Solana, token balances are stored in unique accounts where the storage account address is derived from the address of the owner account.

Solang integrates Solidity with the Solana account model by modifying existing code patterns and introducing new ones that are unique to Solana, making this complex undertaking possible.

Ethereum Smart Contracts vs. Solana Programs: A Comparative Study

Within the realm of Solana, the Anchor framework serves as the tool of choice for crafting Solana programs. A multitude of programming languages are at one's disposal for building on the Solana platform, including Rust(via native and anchor), C, C++, Python(seahorse), and most recently, Solidity via the Solang compiler. This means you can develop your Solana programs using the Solidity language through the pre-integrated Solang compiler within the Solana tools, akin to how Hardhat and Remix IDE ease Ethereum's development environment. as Ethereum features Solidity smart contracts, Solana boasts its equal: Solana programs.

First section of Foundational knowledge is over now we are
Moving to minting spl token solidity Solana program
Section second (development of spl-token-minter program).

Spl token minter-:

SPL_TOKEN_MINTER