Solana is one of the major players in the web3 ecosystem nowadays, especially when it comes to RWA tokenization and DeFi. This position came from the ability to run transactions fast (1.000+ TPS) and with low cost (0.000005 SOL). But how is Solana able to achieve this? The answer is its inherent account model.
In blockchains like Ethereum, the smart contract is responsible for storing both the execution logic and the data. This results in state contention, meaning we can´t run both transactions in parallel. For example, let´s say we are interacting with the USDT smart contract. That contract holds both the ledger of every token owner and the execution logic (transfer, addressOf, etc). If account A wants to transfer tokens to account B and account C wants to transfer tokens to account D, we can´t run both transactions in parallel because both of them are trying to alter the same ledger (the implementation is a mapping from address to integers).
The major shift Solana provided was a mechanism that allows parallel processing of transactions. This is achieved by separating the code execution logic from the data it alters. Everything in Solana is an account. The one who holds the execution logic is called a Program (Solana’s equivalent of a smart contract), which is an account explicitly marked as ‘executable’. The data itself is stored in a separate non-executable account. Because a transaction must explicitly state exactly which Data Accounts it intends to read or write to before it runs, Solana’s runtime can look at a batch of transactions, see which ones do not overlap, and process them all at the exact same time.
답글 남기기