MEV SERIES #2. Original blog for @DeFi_LATAM at mirror here
Although MEV currently is mostly concentrated in the Ethereum ecosystem, it is not unique to the network. In various blockchains we find a world of possibilities to explore and exploit. In this second launch of the MEV Series we enter the Solana ecosystem to explore the differences with Ethereum in terms of value extraction and the possibilities offered by the construction architecture on the network.
Transaction mechanism in Solana
Solana is mempool-less, since the transactions received by the validators are executed instantly, leading to having 50,000 transactions per second. They call this mechanism Gulf Stream. Validators at Solana can handle up to 100k transactions on their local mempool. This combined with a throughput of 50k TPS, leads the validators to execute all the transactions in their mempool in a matter of seconds.
Since each validator on the network knows the order of the next leaders, clients and validators send the transactions that reach the validator that is known to be a leader before it actually is. This allows validators to execute transactions in advance.
Validators send the transactions that reach them directly to the current leader and the next leader in the schedule leader sequence to be included in their slots, instead of randomly propagating the transactions as in Ethereum. If the current leader cannot process all the transactions, he forwards them to the next validators. Detailed explanation here.
Transaction propagation: Turbine Block
Solana is divided into clusters. Clusters are a set of validators that work together to process transactions. In the network, many clusters can coexist simultaneously. Transactions sent to the wrong cluster are rejected. Detailed explanation here.
Each validator relays the transactions to a group of peers called Neighborhood. The network can be understood as a tree of neighborhoods, where each one relays what reaches the neighborhood that corresponds to it. Each node is responsible for sharing any data it receives with the other nodes in it’s neighborhood, as well as propagating the data to a set of nodes in other neighborhoods. In this way, each node only has to communicate with the nodes to which it relays the data.
Slots and transactions on thenetwork
Solana advances in epochs, which last 2–3 days, and each epoch consists of a set of blocks (~432k), with a blocktime of ~400ms. Each validator has the duty to vote in each block, and since votes in Solana are on-chain and each vote is a transaction, most of the transactions found in a block are votes of validators. For every correct vote they cast, they earn rewards.
Although the validators who will be leaders know each other well in advance on the network, specifically 2 previous epochs, the leader listens to the transactions that he will include in his block only when it is his turn, not before.
Validators are programmed to lead and validate a set of transactions. By the leader schedule, each validator can individually calculate who will be the next leader in the sequence. The leader can listen to transactions through N slots before being effectively a validator, but he’s not sure that he will validate those transactions, because they may have been included by another leader previously.
So, they knows specifically which transactions will include only on their turn.
Due to the above, there cannot be 2 leaders creating blocks at the same time. Yes: It’s possible, but since all nodes on the network know who is the next leader in the sequence, they will not vote whoever is trying to create that malicious block. If you were not ‘chosen’ as the leader to create blocks, no one will vote for you and they directly reject that block.
Costs and Profits of a Validator
The hardware required to set up a validator is very high. Some of the requirements include 128GB of RAM and a speed of 1 Gbit/s, among others.
In addition to hardware costs, validators must incur expenses to cover the costs of voting blocks from the other validators (vote credits). Validators get vote credits every time they send a vote on a completed network block, each vote correctly cast represents 1 credit. Validators who vote more frequently are rewarded with more credits. Voting incorrectly, subtracts credits.
Currently these costs are 1.1 SOL per day, yielding an expense of ~$6.6k per month at current prices; Therefore, if a validator fails to attract enough delegates to its stake and does not have a self-stake to cover this cost, it will incur losses, since the income obtained by the validator for securing the network includes the reward for votes correctly cast, and what they get for creating the block. A validator needs enough participation to earn more in rewards than it spends on voting.
In Solana, validators can earn far more rewards as a result of voting correctly on time than they do for being leaders and processing blocks on the network. For each block created, they take 50% of the transaction fees (the other 50% of SOL is burned). Thus, validators are incentivized to include as many transactions as possible within their time limit.
In this, Solana differs from other blockchains, in that if a miner/validator does not process blocks, it will not make a profit.
Skip rate: is the percentage of slots where a validator does not meet the network requirements. Basically every time a leader “loses” the opportunity to validate a block for not maintaining the standards of the network regarding speed, they will accumulate the amount of “skips” that he made in the network and this will represent the reliability that one can have in this validator. In this sense, the latency that the nodes have between them plays a fundamental role, since if a validator is very far from the majority, it probably has a higher percentage of skip rate due to the latency between them, consequently not producing blocks.
Difficulties to extract value from the Network:
Since there is no mempool, there’s no place for arbitrage bots to go looking for transactions waiting to be confirmed. Thus, the only ones who would have the power to see pending transactions are the validators, consequently they have the possibility of reordering transactions, but this entails several difficulties:
- Transactions in Solana are deterministic, this means that everyone pays the same for every transaction. While fees can vary block by block, they are deterministic in the sense that transactions specific to a blockhash are similar, and are paid according to the configuration of that particular block. Fees may vary slightly according to protocol and complexity, but generally are around $ 0.001.
- It is not possible to modify the gas artificially. This invalidates the possibility of a ‘gas war’ between searchers. It directly cancels the possibility of bribing the validator by sending a transaction with a high gasfee so that it has ordering priority over the others.
- There is (currently) no variable similar to block.coinbase in Rust that returns the address of the current leader to directly bribe the leader by sending him a transaction.
- Each leader has a time limit of 400ms to include 4 slots in the blockchain, and then the opportunity to validate blocks is immediately transferred to the subsequent leader. They have a very short window of time to arbitrage.
- Each validator is responsible for assembling its PoH sequence, completing the VDF process. At the end of the PoH sequence, the transactions (and therefore the slots) will be timestamping. The transaction processed by the validator includes the hash of the PoH of the previous transaction and the user’s signature, so it will not be possible to reorganize blocks.
Spam as an alternative
Since the operation of the auctions in the Solana blocks is effectively the opposite of Ethereum, this brings negative consequences to the network: as it is not possible to push the tx with more gasfee to gain a priority place in the blocks of the network (auction style), and since there is no way to prioritize one transaction over another, what the bots will do to try to win the liquidations/arbitrages, is spam the blockchain with duplicate txs (with the same signature) over and over again without limit, until their tx is processed.
What ends up happening as a consequence of this spam is that the validators are unable to process all the txs that arrive in their local mempool, almost completely saturating the validators’ bandwidth, causing the other txs to fail and reducing the network’s TPS. Validators do not have a mechanism capable of removing and filtering duplicate txs and processing the unique ones.
A possible solution could be to implement some kind of relayer in the network (just like Flashbots on Ethereum), which filters out duplicate/malicious txs and routes the good ones to validators. Including multiple relayers in strategically placed locations between nodes, to deal with latency between validators could help to mitigate this problem.
“Txs lifecycle in Solana
- The dapp creates a transaction to buy some tokens
- The dapp sent the transaction to your wallet to be signed.
- The user signs the transaction and sends it back to the dapp
- The dapp takes the transaction signed by the user and sends it to the node specified in the dapp
- The node sends the transactions it receives to the next validator leader in the sequence
- The leader receives the transactions to be processed, verifies the signatures and eliminates malicious transactions, processes the correct ones, marks them with a hash tick (PoH) and broadcast them to the rest of the network.”
The difference between the validator and the leader is that if a validator sees a bad transaction, it cannot just delete it like the leader would, because that would cause the PoH hash to change. Instead, reject the entire block
Actors that come into play in this scenario
The nodes that maintains the transactions that reach them on their servers. The node that receives the transactions and then sends them to the leader, has the possibility to review them. Although they do not have the power to reorder or decide which transaction is included first, they can read opportunities ahead of time and delay the propagation of transactions until they submit their own transactions. With extremely low latency with the nodes and the validator, they could send their transaction first.
As long as the validators can be known/calculated so far in advance (2 epochs), the possibility of colluding between them opens to generate strategies and extract value in multiple sequential blocks.
MEV — front running and reorgs
Bob, Alice, and Josh submit their transactions. The leader receives the batch of transactions to process, including Bob’s and Alice’s transactions that have the same blockhash, and Josh’s that have a different blockhash than Alice and Bob.
The leader can include his own transaction before, after, and between Alice/ Bob/Josh’s. When assembling the VDF, he also can reorder Alice’s transaction to happen before Bob’s, but he can’t make Josh’s transaction happen before Alice’s and Bob’s, because they have different blockhash. If the transaction is not confirmed on time (<32 blocks), it’s invalidated and will have to be signed again with a more recent blockhash.
Possible Scenarios that can happen
- A validator finds a way to deploy an arbitrage bot fast enough to extract MEV. Because of this, he offers a higher percentage of reward as an incentive, promising to extract MEV and attracting users to delegate with him, thus increasing their chances of being chosen as a leader. Users would be incentivized to delegate to their pool, being one of the few (or the only one) that has this mechanism, and therefore, it may offer a greater interest than other pools as an incentive.
His stake grows, and his chances of being elected as a validator and extracting MEV on each occasion increase → Greater centralization, ‘the rich get richer’. This could lead to large stake pools being mostly chosen as leaders to include blocks, allowing the extraction of MEV in multiple sequential blocks concentrated in a single entity.
- Right now there’s no ‘priority fee’ with which validators can be incentivized to process our transaction first over others, since as we explained above, fees are deterministic on the network.
This is a bit confusing because at the official documents state that “If the network is congested, the slot leader may prioritize the transactions offering higher fees” and that “*In the first implementation of this design, the only fee parameter is lamports_per_signature. The more signatures the cluster needs to verify, the higher the fee”
*Clearly it’s suggested that the user can include more signatures in the transactions that they send, consequently increasing the fee that they pay artificially. The fees are proportional to the signatures required to process the transaction, no matter how many instructions the transaction requires to interact with X protocol.
So, the question here would be: What is a signature for Solana? How can a user include more signatures in a tx?
SOL’s basic unit of measurement is called ‘lamports’. 1 lamport = 0.000000001 SOL.
Each signature that the user includes in the transaction is equal to 5000 lamports. Therefore: the more signatures included in the transaction → the higher the fee → the validator can choose which transaction has priority, based on their economic incentives.
- A validator detects MEV in the transactions that it must include in its slots. To appropriate it, he decide to censor it and put their transaction first.
E.g: in a context of general decline in the market, liquidations are executed in Parrot vaults after an update in the prices of the oracle. The current leader detects this and decides to process his transaction first to take over such liquidations.
- Since the validator is the last actor to decide who gets the arbitrage opportunity in their slots, and taking into account that they’re known ahead of time, an off-chain bribes mechanism could be generated where the validators sell the blockspace or a kind of dark-mempool is generated in parallel to sell that privileged information. Likewise, this would only be possible if the searchers have extremely low latency with the validator.
Special thanks to @0xPEPO, @martintriay and @josebaredes for peer review
Sources:
