🕰️Async program execution and SIMD-0045
What is orderflow and MEV?
The simplest way to process a transaction on a blockchain for the user is to just send it to the RPC client which routes it to the next selected block builder aka Leader. This seems easy at first but has a whole lot of drawbacks as the transactions go unencrypted through an RPC and Leader, if any of the agents find an opportunity to leverage their speed or resources to front run and make a profit out of your transactions this will lead to bad incentive alignment where block builders are hurting users for personal gain.
For eg. Let’s say there is a swap order on Orca for 1 million USDC X SOL with the maximum slippage set at +-5%, an MEV(Maximum Extractable value) bot could send a transaction with a priority fee for faster execution in the block(aka frontrunning) and buy up the sol and sell it to the buyer at a 2-3% markup which is still under the slippage <5% and the transaction will go through. 2% of a million is 20k which is a huge loss to the user who placed the order. Now Solana mitigates this to a considerable level because of its super small block times which usually hover around 400ms and don't leave much time for MEV bots to do multi-step swaps and contract interactions but what if the agents who actually help execute the transaction become value extractors? The validator could see this opportunity or copy another mev bot and execute its transaction first in the block while also taking the priority fee from the bot or agent trying to arbitrage the opportunity.
PBS
One of the biggest ways to solve this problem is to divide the tasks done by validators so it doesn't have a monopoly over the transaction inclusion and execution. Right now validators build blocks that contain the user transactions and compute the hash for them to include it in the slot, with the approach of PBS Proposer builder separation that decouples the task of Building blocks and Including them in the ledger.
This would allow different agents to build blocks and submit them to the scheduled leader, the leader of the block proposer won’t be able to append the order of transactions but can pick the one with the highest gas reward, and as many block builders are trying to get their blocks included they have to use sophisticated techniques to capture more gas and make it worthwhile for the leader. This prevents any special treatment or off-chain deals between proposers and builders while maintaining a level playing field for Builders.
One of the drawbacks of this approach is that as many agents are competing to build the better block while only one of them gets selected, there is a huge waste of computing but it this important to move away from centralized block production that can harm user experience right now
Implementing this could help the Solana order flow and Jito has done a lot of work in this area. They have published their jito Searcher and MEV client which allows searchers to pack bundled transactions in a supper efficient way and send it to the block engine which picks the best block with highest gas making it attractive for the leader to include it in the slot but Bundled blocks can only be included if the current Leader is using the Jito solana Client.
But there is a problem, Having different parties produce blocks for the Proposer could lead to higher latency but first, we need to understand different types of transactions. Solana has two types of transactions →
Vote transactions: These are executed to reach consensus on blocks by the validators as it is easier just to pack consensus data over the turbine rather than having another overhead gossip component that could increase the block times.
Around 3/4 of all transactions on the chain are vote transactions that have to pay fees like any normal txn.User transactions: Transactions submitted by users and bots on the chain that interact with smart contracts and don’t touch the vote state program
As the vote txns are packed in the normal blocks they have to be executed after the program execution which becomes a bottleneck. But there is a way to solve this.
SIMD-0045
Clients and RPC networks are all over the world but the Leader is a single entity scheduled to confirm the blocks, to make the system more efficient rather than having a single leader produce blocks that contain all kinds of votes that might not be that useful we can
Segregate Vote transactions from the regular transactions that don’t interact with the Vote Program
Allow any N number of builders to take nonvote user transactions and efficiently pack them in blocks and sent over turbine of which one could be picked up by the Leader to include in POH in the form of
Vote transactions are just executed before the user transactions.
Earlier the state transitions had to be processed first for the fork choice rule and voted upon later but that didn’t have much effect on the regular program execution which could be done async and moved to an isolated state.
This solves two big problems in block production
Latency - As there are N no builders producing blocks competing with each other, the leader could pick the one closest to them and that offers more rewards. This introduces competition for block building aligning incentives to work on more efficient blocks with better reordering.
Parallel execution of Vote accounts rather than waiting for the nonvote txn execution and then vote execution.
Note
Transactions with instructions that touch stake change accounts would prob need Vote transactions to be run for them so its open question would happen here.
Some Open questions
For a Block Builder to get their block included by the leader they have to make it attractive and incentivize the leader to do so with some kind of Fee and now with priority fee implemented on mainnet there seems to be a good economic plan to figure out the way this will go through, but here are some ways I think
Builders take MEV and Priority fee giving all the gas reward to Leader
Priority fee + Gas to the Leader and Builders try to maximize their MEV output
One of the double-edged swords of this approach is that Leaders won’t care much about the source of the block as long as it offers a good fee and maximizes
but if a builder has some kind of secret sauce that allows them to outperform all the builders it could lead to block production centralization which is kinda happening on Ethereum with over 70% blocks from 3 builders This is where SIMD might shine as the builders are rotated based on their stake weight but still it’s an open area of discussion!
If you think you can contribute feel free to head to the github link!
PS: Thanks for making it till the end dear read! I am sure there will be a lot of mistakes in this post as I am just getting my hands dirty in this space so feel free to hit me up on twitter or comment on the post for corrections!
Resources