Solana Journey 6: Solana Storage Fee and Transaction Analysis

storage cost

Please refer to: https://blog.csdn.net/chhaozeng/article/details/116810006 the following paragraph

According to this information, based on the SOL price of $100, the cost of 1KB is: (100 x 364 x 0.01 )/2 = $182/year.

Reference: https://blog.csdn.net/mutourend/article/details/119776339, its calculation is more detailed

According to this information, based on the SOL price of $100, the cost of 15KB for two years should be $11. We can see later that this calculation is wrong: the above 2-year rent is an exempt rent fee.

The information consumed in the previous 1500 bytes could not be found. But the above two values, you can refer to it. The latter is the estimate of solana. We install the tool and run it once, as follows:

Since this Solana provides tools to estimate, when the amount of stored data is small, the rent fee will be exempted, but when it reaches 1.5GB, the real fee that should be paid is: 1500000000 x 0.00000348 = 52200 - 10440 = 41760 SOL. Continue to calculate: 1.5MB costs about $4176 a year (according to 1SOL = $100), and 1.5K is about $4.176, which is about ¥30 a year.

When the network is not smooth, an error will be reported:

From the above information, the following information can be seen:

1. Solana rent to access the mainnet-beta, which is the Solana mainnet;
2. The access shall be a ReadOnly request:

• There is no fee for this request, because I don't have SOL for testing.

trade

key concept or noun

Accounts

Solana internal accounts are used to store state. They are an important part of developing Solana.

Facts

• Accounts are used to store data
• Each account has a unique address
• The maximum size of an account is 10mB
• The maximum size of PDA accounts is 10kb
• PDA accounts can be used to sign programs based on interest
• Account size is static
• The data storage of the account needs to pay the storage fee
• The default account owner is a system program

further understanding

account model

On the Solana system, there are 3 types of accounts:

• Data account, used to store data;
• Program account, used to store executable programs;
• Native accounts (Native accounts), which represent many native programs in the Solana system (used to maintain system operation, pledge and vote, etc.)

In the data account, there are two types:

• system owned account
• PDA (Program Derived Address) account, that is, program derived account

Each account has an address (usually a public key) and an owner (the program account's address). The full list of fields for the account store is shown below.

field	describe
lamp port	The amount of SOL native tokens owned by the account (in lamports)
owner	The account's program owner
executable	Indicates whether the account can process instructions
data	The raw (raw) byte array stored by this account
rent_epoch	The epoch when the storage fee will be paid

Here are a few important rules about ownership:

• Only the owner of the data account can modify its data and debited lamports
• Anyone can deposit lamports into a data account
• If an account has zero data , the account's owner can assign it a new owner

Program accounts do not store state .

For example, if you have a counter program that allows you to increment a counter, you must create two accounts, one to store the program code and one to store the counter.

In order to prevent account deletion, you must pay rent (storage fee).

Storage fee (Rent)

Storing data on the account requires SOL maintenance, which is obtained by paying the storage fee for the account storing the data. Your account will be rent free if you have a minimum balance equivalent to 2 years of rent in your account. You can recover the deposit on this account by closing the account and sending lamports back to your wallet.

The storage fee is settled or paid in the following two different situations:

1. When the account is referenced by a transaction
2. An epoch arrives

A portion of the storage fee charged by the system account is burned, while the remainder is distributed to voting accounts at the end of each slot.

If the account does not have enough money to pay the storage fee, the account will be released and the data will be deleted.

Programs

Any developer can write and deploy programs on the Solana blockchain. Programs (known as smart contracts on other protocols) are the basis for on-chain activity, enabling anything from: DeFi, NFTs, social media, gaming.

Facts

• Programs process instructions from end users and other programs

• All programs are "stateless": any data they interact with is stored in separate accounts that are passed to the program via instructions

• The programs themselves are stored in accounts labeled:executable

• All programs belong to BPF Loader and are executed by Solana Runtime

• Backend developers usually write programs in Rust or C++, but can choose any language as long as it conforms to BPF's LLVM specification

• All programs have a unique entry point from which instructions are processed (for example,

  process_instruction
  

  ); Parameters in directives always include:

  • program_id: pubkey
  • accounts: array,
  • instruction_data:byte array

further understanding

Unlike most other blockchains, Solana completely separates code from data . All data interacting with the program is stored in separate accounts and passed in as references through commands. This model allows a common program to operate across different accounts without requiring additional deployments. Common examples of this pattern can be seen in native programs and SPL programs.

Native Programs & Solana Libraries

Solana is equipped with many programs that serve as core building blocks for on-chain interactions. These programs are divided into native programs and solana program library (SPL) programs (SPL programs for short).

Native programs provide the basic functionality needed to operate validators. The most famous of these programs is the System Program, which is responsible for managing new accounts and transferring SOL between accounts.

The SPL program supports many on-chain activities, including creating, exchanging, and lending tokens, as well as generating stake pools and maintaining on-chain naming services. The SPL Token Program can be called directly through the CLI, while other programs like linked token accounts are usually composed of custom programs.

Write on-chain programs

Programs are typically developed in Rust or C++, but can be developed in any language that supports the LLVM BPF backend. The latest move by Neon Labs and Solang makes programs compatible with the EVM and allows developers to write programs in solidity.

Most rust-based programs follow the following architecture:

document	describe
lib.rs	Registering modules
entrypoint.rs	Entrypoint to the program
instruction.rs	Program API, (de)serializing instruction data
processor.rs	Program logic
state.rs	Program objects, (de)serializing state
error.rs	Program-specific errors

Recently, Anchor has become a popular framework for developing programs. Anchor is an opinionated framework, similar to Ruby on Rails, that reduces boilerplate and simplifies the (de)serialization process for rust-based development.

Before deploying the program to the testnet or mainnet, the program is usually developed and tested in the Localhost and Devnet environments. Solana supports the following environments:

cluster environment	RPC connection URL
Mainnet-beta	https://api.mainnet-beta.solana.com
Testnet	https://api.testnet.solana.com
devnet	https://api.devnet.solana.com
Localhost	Default port: 8899 (e.g. http://localhost:8899, http://192.168.1.88:8899)

Once the program is deployed to an environment, clients can connect to the respective cluster via RPC and then interact with the program on the chain.

Deployment program

Developers can deploy their programs via the CLI:

solana program deploy <PROGRAM_FILEPATH>

When a program is deployed, it is compiled into an ELF shared object (containing BPF bytecode) and uploaded to the Solana cluster. Programs are run based on accounts (like everything else on Solana), except those accounts are marked as "executable" and assigned to BPF Loaders. The address of this account is called 'program_id' and this address will be used to reference the program in all future transactions.

Solana supports several BPF loaders, the latest being the upgradable BPF loader. The BPF Loader is responsible for managing the program's account and making it accessible to clients via 'program_id'. All programs have a single entry point, where the client's instructions, will be processed (eg ' process_instruction '). Directives always contain the following parameters:

• program_id: pubkey
• accounts: array,
• instruction_data:byte array

Once called to request access, the program will be executed by Solana Runtime.

trade

Clients can invoke programs by submitting transactions to the cluster. A transaction can contain multiple instructions, each directed to its own program. When a transaction is committed, Solana Runtime processes its instructions sequentially and atomically. If any part of the instruction fails, the entire transaction fails.

Facts

• Instructions are the most basic unit of operation in Solana
• Each directive contains:
  • program_idcorresponds to the program
  • accountsArray, which stores the account addresses read and written
  • instruction_databyte array, which is defined and parsed specific to the associated program
• Multiple instructions can be packaged into one transaction
• Each transaction contains:
  • accountsArray, which stores the account addresses read and written
  • no less than one instruction
  • recentblockhash
  • not less than one signature
• Orders in transactions are processed sequentially and atomically
• If any part of the order fails, the entire transaction fails.
• Transactions are limited to no more than 1232 bytes

further understanding

The Solana runtime requires directives and transactions to specify a list of all accounts they intend to read from or write to. By requesting these accounts ahead of time, the runtime is able to consolidate all transactions, allowing them to execute efficiently in parallel.

When a transaction is submitted to a cluster, the runtime processes its instructions sequentially and atomically. For each instruction, the receiving program interprets its data array and operates on its specified account. The program either returns successfully or returns an error code . If an error is returned, the entire transaction will fail immediately.

Any transaction aimed at lending money from an account or modifying its data requires the signature of the account holder (the holder, not the Onwer) . Any account that will be modified is marked as "writable". Accounts can be deposited (tokens) without the holder's permission as long as the transaction fee payer pays the necessary storage fees and transaction fees.

Before committing, all transactions must refer to the most recent blockhash. blockhash is used to prevent duplication and eliminate stale transactions. The maximum usage time of the blockhash of a transaction is 150 blocks. So far, this time is about 1 minute and 19 seconds.

transaction fee

The Solana network charges 2 types of fees:

• Transaction fees, used to propagate transactions (aka "gas fees")
• Storage fees, for storing data on-chain

In Solana, transaction fees are deterministic: it has no concept of a fee market (where users can pay higher fees to increase their chances of being included in the next block). At the time of writing, transaction fees are determined only by the number of signatures required (ie: ' lamports_per_signature '), not by the number of resources used. This is because there is currently a hard cap of 1232 bytes for all transactions.

All transactions require at least one "writable" account to sign the transaction. Once committed, the writable signer account that is serialized first will be the transaction fee payer. This account will pay for the transaction whether it succeeds or fails. If the fee payer does not have enough balance to pay the transaction fee, the transaction will be cancelled.

At the time of writing, 50% of all transaction fees are earned by validators who generate blocks, while the remaining 50% are burned. This structure incentivizes validators to process as many transactions as possible within the time period of the leader's schedule.

Program Derived Addresses (PDAs)

A Program Derived Address (pda) is the location of an account designed to be controlled by a particular program. Using PDA, a program can programmatically sign certain addresses without the need for a private key . The pda serves as the basis for interprogram calls, which allow Solana applications to be combined with each other.

Facts

• pda is a 32 byte string that looks like a public key, but has no corresponding private key
• findProgramAddressWill deterministically derive a PDA from programId and seed (byte collection)
• A bump (one byte) is used to calculate the PDA based on the ed25519 elliptic curve
• A program can sign its pda by providing a seed and a bump call to invoke_signed
• A PDA can only be signed by the program that generated it
• In addition to allowing programs to sign different instructions, PDA also provides a hashmap-like interface for indexing accounts .

further understanding

The pda is an important part of developing the Solana project. Using pda, a program can sign an account while guaranteeing that no external user can also generate a valid signature for the same account. In addition to signing accounts, programs can also modify their pda's holding accounts.

Image courtesy of Pencilflip

Generate PDAs

To understand the concepts behind PDAs, it may be easier to understand them as if they were not technically created, but rather found. pda is generated based on a combination of a seed (such as the string "vote_account") and a program id. The combination of the seed and program id is then run through the sha256 hash function to see if they generate a public key that lies on the ed25519 elliptic curve.

When running our program id and seed through a hash function, we have about a 50% chance of ending up with a valid public key that lies on an elliptic curve. In this case we simply add something to spoof our input and try again. The technical term for this **fudge factor** is " bump ". In Solana, we start with bump = 255, and simply iterate through bump = 254, bump = 253, etc. until we get an address that is not on the elliptic curve. This seems fundamental, but once discovered, it gives us a deterministic way to derive the same PDA over and over again.

Interact with PDAs

When generating a PDA, ' findProgramAddress ' will return the address and the bump used to kick the address off the elliptic curve. With this bump, the program can sign any PDA's commands that require it. In order to sign, the program should be passed the command, the list of accounts, and the bump used to derive the PDA in order to get 'invoke_signed'. In addition to signing the instructions, the pda must also sign its own creation via 'invoke_signed'.

When building with pda, it is common to store the bump seed in the account data itself. This allows developers to easily authenticate PDAs without having to pass in bumps as command parameters.

dissecting transactions

Program execution begins when a transaction is committed to the cluster. The Solana runtime will initiate an on-chain program that sequentially and atomically processes each instruction contained in a transaction .

This section describes the binary format of transactions.

transaction format

A transaction consists of a compact-array of signatures, followed by a message. Each item in the signature array is a digital signature for a given message. The Solana runtime verifies that the signed number matches the first 8 digits of the message header. It also verifies that each signature is signed by the private key corresponding to the public key at the same index in the message's account address array.

The overall transaction format is as follows:

)]

signature format

Each digital signature is in ed25519 binary format and will occupy 64 bytes.

message format

The message body consists of a header , followed by a compact-array of [account-address], followed by a recent blockhash , followed by a compact-array of [instructions].

header format

The message header contains three unsigned 8-bit values. The first value is the number of signatures required to include the transaction. The second value is the number of corresponding read-only account addresses. The third value in the header is the number of read-only account addresses that do not require signatures.

Account Address Format

Addresses requiring signatures appear at the beginning of the array of account addresses, first the address requesting read and write access, followed by the read-only account. Addresses that do not require signatures follow addresses that require signatures, and there are also read-write accounts first, followed by read-only accounts.

Blockhash format

A blockhash consists of a 32-byte SHA-256 hash. It is used to indicate when the ledger was last viewed by the client. When the blockhash is too old, the validator will reject the transaction.

command format

An instruction consists of a program id index, followed by a compact array of account address indices, followed by a compact array of opaque 8-bit data. The program id index is used to identify programs on the chain that can interpret opaque data . The index in the account array is an unsigned 8-bit value, which is used to index the account address in the account address array in the message body. Each of the account address indices is an unsigned 8-bit value.

Compact-Array format

A compact array is serialized as the array length followed by each array item. The array length is a special multi-byte encoding called compact-u16.

Compact-u16 format

compact-u16 is a 16-bit multi-byte encoding. The first byte contains the lower 7 bits of the value. If the value is higher than 0x7f, set the highest bit of the byte and put the next 7 bits of the value into the lower 7 bits of the second byte. If the value is higher than 0x3fff, the highest bit of the second byte is set and the remaining 2 bits of the value are placed in the lower 2 bits of the third byte.

Account Address Format

The account address is arbitrary data of 32 bytes. When the address requires a digital signature, the runtime interprets it as the public key of the ed25519 key pair.