Madhav GoyalHalo: A privacy layer for stablecoins
AbstractHalo is a privacy layer for stablecoins unlocking the next private neobanks and applications that were blocked by the lack of anonymity and confidentiality of networks. Halo Network introduces a new extension a a privacy-preserving EVM chain purpose-built for stablecoin use cases. Halo combines the familiarity and composability of the EVM with the confidentiality of a UTXO-based privacy layer, allowing users to transact and build privately without sacrificing interoperability or liqui...
Madhav Goyal🧊Solana::Leader schedule
I have been diving into Solana and its Validator code realizing the incredible design behind the selection of Validators and block producers, so here is a small rundownWhat are Blocks?What are POW and POS?Solana Leader ScheduleSpecial Considerations to produce the Tastiest BlockOpen QuestionsSome ResourcesBlocks wat?Blocks containing transactions and state transition data lined on top of one another with cryptography securing their computational integrity is the foundation of blockchain aka c...
Madhav GoyalMusings on Price Discovery
Musings on Price discoveryWith a fading bull run comes the pressure to do a token generation event at high valuations because otherwise if you are a VC backed project with 8 figs in funding, you are cooked without a binance listing since you definitely know your tech is only valued at the number of CEX listings and shady market makers you can get for the launch. Jokes and criticism aside, I have been diving into the price discovery for a mix of work and my own interests in the past few months...
Just a tinkerer in this wonderful world
Madhav GoyalHalo: A privacy layer for stablecoins
AbstractHalo is a privacy layer for stablecoins unlocking the next private neobanks and applications that were blocked by the lack of anonymity and confidentiality of networks. Halo Network introduces a new extension a a privacy-preserving EVM chain purpose-built for stablecoin use cases. Halo combines the familiarity and composability of the EVM with the confidentiality of a UTXO-based privacy layer, allowing users to transact and build privately without sacrificing interoperability or liqui...
Madhav Goyal🧊Solana::Leader schedule
I have been diving into Solana and its Validator code realizing the incredible design behind the selection of Validators and block producers, so here is a small rundownWhat are Blocks?What are POW and POS?Solana Leader ScheduleSpecial Considerations to produce the Tastiest BlockOpen QuestionsSome ResourcesBlocks wat?Blocks containing transactions and state transition data lined on top of one another with cryptography securing their computational integrity is the foundation of blockchain aka c...
Madhav GoyalMusings on Price Discovery
Musings on Price discoveryWith a fading bull run comes the pressure to do a token generation event at high valuations because otherwise if you are a VC backed project with 8 figs in funding, you are cooked without a binance listing since you definitely know your tech is only valued at the number of CEX listings and shady market makers you can get for the launch. Jokes and criticism aside, I have been diving into the price discovery for a mix of work and my own interests in the past few months...
Just a tinkerer in this wonderful world
Subscribe to Madhav Goyal
Subscribe to Madhav Goyal
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
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.
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
PBS pipeline
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.
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.
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
\(Gas\ paid/Compute_\ unit\)
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
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.
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
PBS pipeline
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.
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.
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
\(Gas\ paid/Compute_\ unit\)
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
No activity yet