Solana
Solana consenus, transaction fees and scheduler
Last updated
Solana consenus, transaction fees and scheduler
Last updated
In Solanas consenus model one of the validators are chosen as a leader based on a rotating leader schedule. The leader is responsible for proposing new blocks containing transactions. Validators are then validating the blocks proposed by the leader. Slots are the fundamental units of time within the network. A slot is a fixed duration of time, currently set at 400 milliseconds, during which a validator has the opportunity to produce a block. Slots are sequential, meaning that they occur one after another in a linear fashion.
During their assigned slot, a validator (leader) proposes a new block containing the transactions it has received from users. The leader validates these transactions, packages them into a block, and then broadcasts the block to the rest of the network. This process of proposing and broadcasting a block is known as block production.
Once a block has been proposed, other validators in the network must vote on its validity. Validators examine the block's contents, ensuring that the transactions are valid by re-executing those transactions in order to be able to vote and adhere to the network's rules. If a block receives the required number of votes, it is considered confirmed and is added to the blockchain. This confirmation process is crucial for maintaining the network's security and preventing double-spending or other malicious activities.
Source: https://www.helius.dev/blog/solana-slots-blocks-and-epochs
Transaction fees on Solana are paid with the native gas token SOL. The fees paid to process instructions on the Solana blockchain are known as "transaction fees".
As each transaction (which contains one or more instructions) is sent through the network, it gets processed by the current leader validation-client. Once confirmed as a global state transaction, this transaction fee is paid to the network to help support the economic design of the Solana blockchain.
Transactions fees are calculated based on two main parts:
a statically set base fee per signature, and
the computational resources used during the transaction, measured in "compute units"
Source: https://solana.com/docs/core/fees#compute-budget
Solana's base fee is a fixed 5,000 lamports (0.000005 SOL) per signature, and most transactions have one signature. It does not account for a transaction's broader computational resources (as measured by CUs).
All transactions on Solana use Compute Units (CU), which measure the computational resources your transaction uses on the network. There is 48M CU per block, or 12M CU per thread. CU are also limited per transaction by 1,4M CU. When executed, the transaction can use up to that requested CU limit.
A Solana transaction can include an optional fee to prioritize itself against others known as a "prioritization fee". Paying this additional fee helps boost how a transaction is prioritized against others, resulting in faster execution times.
A transaction's prioritization fee is calculated by multiplying the maximum number of compute units by the compute unit price (measured in micro-lamports).
Note that this priority fee is paid against the full CUs requested (regardless of whether the transaction uses the total amount requested), unlike in Ethereum, where the fee is a function of how much gas the transaction actually uses.
Unlike ethereum Solana does not move the base fee at all. There is no concept of gwei per unit of gas spent. Everything is always static - which means that if you spent 1,2M CU, you will pay about 0,2 usd. No matter what happens 0.2 usd is what you pay.
The scheduler runs 4 threads in a Solana node/validator. The scheduler will look at the composition of the fees. It will understand that you have enough to pay the base fee: 0,2 USD. Then it will compare and sort all of the tx on priority fees.
We can see from the chart that ppl are paying 10-20X in priority fees.
So if you want to push a tx thru to the block and have scheduler accept it in a thread - if yo do 2 usd in priority fee and 20 cent in base fee = pay 2,2 usd. Everyone who is paying less, lets say 1 usd in priority fee will be scheduled to be run later or be dropped within 150 blocks/slots.
150 blocks = 0,4s/block = 75-80 secs is how long the tx will be sitting in a buffer and try to be executed by a node.
However, during the high tx time/hig fee time - if nobody ever drops below your priority fee you’ll always be the last one in a queue and eventually your tx will be dropped.
There is an auction for priority fees. I will have my client adjusted to be included and this is how ppl will actually be able too bid for to have an ability to run the miner and hit the 420 hashes that will be counted for total amount hashes found which will be multiplied with AMP that will issue solXEN.
If many miners mine at the same time they will have to specify the priority fee to be higher in order to succesfully mine solXEN. With Ethereum a user can set the gwei to be very high. However Etehruem will only charge amount of gwei based on the chains demand at the time and refund the user with the surpluss. In Solana the priority fee is a tip to the validator, which are non refundable. The whole priority fee goes to the validator (leader).
Within a block, a maximum of 12,000,000 CUs can be used for sequential writes to a single account (“piece of state”). This is roughly the amount of CUs that can be processed by a single thread per 400ms slot on reasonable node requirements. Solana’s per-block limit is then 48,000,000 CUs. The current scheduler implementation uses four threads for non-vote transactions, and 12M x 4 = 48M. In theory, this means using more cores = increasing CU limits. Scaling with hardware. The scheduler non-deterministically prioritizes transactions with higher priority fees.
Transactions are assigned randomly to one of the four threads, with each thread maintaining its own queue of transactions waiting for execution.
