Solana 프로그래밍 모델에 대한 간략한 설명: ETH와의 차이점은 무엇입니까?

Original author: Foresight News, Alex Liu

Solana is a high-performance blockchain platform designed to support dApps, known for its speed and scalability, which is achieved through a unique consensus mechanism and architectural design. This article uses Ethereum as a comparison object to briefly introduce the characteristics of Solanas smart contract programming model.

Smart contracts, on-chain programs:

Programs running on Ethereum are called smart contracts, which are a series of codes (functions) and data (status) located at a specific address on Ethereum. (Oh no, the code and data are coupled) Smart contracts are also Ethereum accounts, called contract accounts, which have balances and can be traded, but cannot be manipulated by humans and are deployed on the network to run as programs.

The executable code running on Solana is called an on-chain program, which interprets the instructions sent in each transaction. These programs can be deployed directly to the core of the network as native programs, or published by anyone as SPL programs.

• Instructions: Instructions are a special term for Solana on-chain programs. On-chain programs are composed of instructions, which are the smallest unit for performing specific operations: every Solana transaction contains one or more instructions. Instructions specify the operations to be performed, including calling a specific on-chain program, passing accounts, input lists, and providing byte arrays. Instructions have computational limits, so on-chain programs should be optimized to use a small number of computational units, or split expensive operations into multiple instructions.

• Native Program: A native program that provides the functions required by a verification node. The most famous of these is the System Program, which is responsible for managing the creation of new accounts and the transfer of SOL between two accounts.
• SPL Program: defines a series of on-chain activities, including the creation, exchange, lending, creation of staking pools, maintenance of on-chain domain name resolution services, etc. Among them, SPL Token Program is used for token operations, while Associated Token Account Program is often used to write other custom programs.

You call it a smart contract, I call it a chain program. Everyone has different terms, but they all refer to the code running on the blockchain. Zhang San, Li Si, and Wang Mazi are all names of people. Their quality still needs to be examined in other aspects.

Account model and data decoupling:

Similar to Ethereum, Solana is also a blockchain based on an account model, but Solana provides a different account model from Ethereum and stores data in a different way.

In Solana, accounts can store wallet information and other data. The fields defined by an account include Lamports (account balance), Owner (account owner), Executable (whether it is an executable account), and Data (data stored in the account). Each account specifies a program as its owner to distinguish which program the account is used as state storage. These on-chain programs are read-only or stateless: program accounts (executable accounts) only store BPF bytecode and do not store any state. The program will store the state in other independent accounts (non-executable accounts), that is, Solanas programming model decouples code and data.

Ethereum accounts are mainly references to EVM states, and their smart contracts contain both code logic and the need to store user data. This is generally considered a design flaw left over from EVM history.

Don underestimate this distinction! Solana smart contracts are fundamentally harder to attack than blockchains with coupled programming models like Ethereum:

In Ethereum, the smart contract owner is a global variable that corresponds to the smart contract one by one. Therefore, calling a function may directly change the contract owner.

In Solana, the owner of a smart contract is data associated with an account, not a global variable. An account can have multiple owners, rather than a one-to-one association. For an attacker to exploit a security vulnerability in a smart contract, they not only need to find the problematic function, but also need to prepare the correct account to call the function. This step is not easy because Solana smart contracts typically involve multiple input accounts and manage the relationship between them through constraints (such as `account 1.owner==account 2.key`). The process from preparing the correct account to launching an attack is enough for security monitors to proactively detect suspicious transactions that create fake accounts associated with smart contracts before an attack.

Ethereum smart contract is like a safe with a unique password. As long as you get the password, you can get full ownership. Solana is a safe with many passwords, but in order to obtain permission, you not only have to find a way to get the password, but also figure out the number corresponding to the password before you can open the lock.

programming language

Rust is the primary programming language for developing smart contracts on Solana. Because of its performance and security features, it is suitable for high-risk environments of blockchains and smart contracts. Solana also supports C, C++ and other languages (very uncommon). Official SDKs for Rust and C are provided to support the development of on-chain programs. Developers can use tools to compile programs into Berkley Packet Filter (BPF) bytecode (files with a .so extension), then deploy them to the Solana chain, and execute the logic of the smart contract through the Sealevel parallel smart contract runtime.

Since the Rust language itself is difficult to learn and is not customized for blockchain development, many requirements require re-invention and redundant code. (Many projects in production use the Anchor framework created by Backpack co-founder Armani to simplify development) Many newly created programming languages dedicated to blockchain development are based on Rust, such as Cairo (Starknet) and Move (Sui, Aptos).

Many projects in production use the Anchor framework

Ethereum smart contracts are mainly developed in Solidity (syntax is similar to javascript, and the code file has a .sol extension). Due to the relatively simple syntax and more mature development tools (Hardhat framework, Remix IDE…), we usually think that Ethereums development experience is simpler and more refreshing, while Solana development is difficult to get started. So even though Solana is very popular now, in fact, the number of Ethereum developers is still far greater than Solana.

Under certain road conditions, a top-level racing car cannot run as fast as a modified car. Rust is like a top-level racing car, which effectively guarantees the performance and security of Solana. However, it is not designed for on-chain program development, which makes driving (development) more difficult. Using a public chain based on Rust and customizing the language for on-chain development is equivalent to modifying the racing car to make it more adaptable to road conditions. Solana is at a disadvantage in this regard.

요약하다

Solanas smart contract programming model is innovative. It provides a stateless smart contract development method, uses Rust as the main programming language, and an architecture that separates logic from state, providing a powerful environment for developers to build and deploy smart contracts, ensuring security and performance, but the development is difficult. Solana focuses on high throughput, low cost, and scalability, and is still an ideal choice for developers seeking to create high-performance dApps.

Reference Links

https://solana.com/docs

https://ethereum.org/en/developers/docs

https://www.anchor-lang.com/

This article is sourced from the internet: A brief description of Solana鈥檚 programming model: What is the difference with ETH?

관련: 룬의 인기는 암호화 기술 개발에 있어서 좌절이지만 동시에 암호화 기술의 가장 좋은 구현이기도 합니다.

Original author: @Web3 Mario Introduction: Yesterday, I accidentally learned from a friend that he had obtained a considerable return on investment in the field of BTC inscriptions, which deeply aroused the authors mentality of stepping into the void. I was anxious for two consecutive days, which was really shameful. Recalling that the Ordinals technical architecture had just been released earlier, the author studied the relevant documents, but as a developer, I was quite dissatisfied with this technical path. At that time, I judged that this was simply a reversal of encryption technology, because its design concept seemed to be similar to a distant altcoin project Color Coin, that is, how to use the technical architecture of BTC to issue some independent tokens, but the difference is that Ordinals did not…