In this lesson, you will:
This lesson explores the technical and architectural nuances distinguishing Solana from Ethereum. Solana's unique blockchain structure employs various programming approaches and incorporates different paradigms and patterns in its account model, rent system, Cross-Program Invocation (CPI), and Program Derived Address (PDA). These concepts are crucial to understanding Solana's framework and will be covered in detail throughout this series.
Solana's technical architecture sets it apart from Ethereum through its distinct programming methodologies. It employs diverse paradigms and patterns, shaping its account model, rent system, CPI, and PDA. This article focuses on comparing the account models of Solana and Ethereum.
is determined by their rent, paid in fractional native tokens called lamports. Accounts are stored in validator memory and depend on rent for persistence. Regular rent collection ensures maintenance, and accounts without sufficient lamports are removed. Accounts maintaining a minimum lamport balance are deemed rent-exempt.
Here's a simplified table comparing the key aspects of Solana and Ethereum in terms of technical architecture and account models:
Concept | Solana | Ethereum |
---|---|---|
Account Model | Employs accounts for storing data and bytecode. | Uses a single account type for both storage and smart contract code. |
Data and Lamports | Accounts include data and use lamports for lifespan indication. | Utilizes gas for transaction cost estimation. |
Executable and Non-executable Accounts | Features executable (bytecode) and non-executable (mutable data) account types. | Adopts a basic account model for storage and code in smart contracts. |
Storage Approach | Any account can host state; smart contract storage is confined to bytecode. | Smart contracts manage their storage. |
Ownership and Security | Each account is linked to an owner contract for secure data changes and integrity maintenance. | Ownership and control are associated with the Ethereum wallet address. |
Data Access | Contracts can access and modify data in any account, but changes are limited to the account's "owner". | Smart contracts access data through internal mechanisms or external calls. |
Storage Flexibility and Encapsulation | Offers state hosting flexibility, allowing any account to hold state data. | Provides controlled storage for contracts with segregated data storage. |
State Modification and Integrity | Ensures state changes are secured and validated through ownership contracts. | Relies on proper coding practices to maintain data integrity and avoid vulnerabilities. |
In Ethereum, token balances are typically managed using a mapping
structure:
mapping (address => uint256) private _balances;
In contrast, Solana stores token balances in unique accounts, where the storage account address is derived from the owner account's address.
Solang facilitates the integration of Solidity with Solana's account model, requiring modification of existing code patterns and the introduction of new concepts unique to Solana, making this intricate process feasible.
In the next lesson, we will delve deeper into smart contracts for Ethereum and Solana and learn how to develop a Solana smart contract using Solidity.