Hello, hello. Can you hear me?
Okay, okay. Okay. Sorry about the whole mess
Yeah, I think now the music is gone and I'm just waiting for every waiting photo room to connect
So I'll just give you give it a minute
All right, all right, right. Okay. Sorry for the delay
Nine minutes late on the clock, but hopefully we'll pick it up from here
Let me just restart on the intro side. So
invited a few oh wait is Tarun off Tarun off right now?
Yeah, I just saw Tarun was on but you see
Okay, anyway, I guess we'll start with the intro real quick and then we'll see when Tarun joins
I'm sure he will be able to catch it up on that
think one thing that I was noticing in the in the space was the
the growing conversation around the usage of SVM on top of
A lot of which have kind of led to the discussion of like, okay. Well, what's the kind of benefit that SVM brings?
and and within that one core topic was around the transaction fee mechanism that
You know people are experimenting with SVM. So today I kind of wanted to
unfold a lot of the discussions that goes into SVM's transaction fee mechanism and the kind of differences and benefits that it has
You know, especially in light of like what Ethereum has with 1559
Few experts in the space and I guess we'll let them introduce themselves maybe
Buffalo you want to start off with intro?
Yeah, thanks for us in the space. Hey everyone. My name is Lucas co-founder and CEO Gita Labs
We build some MEV infrastructure for Solana
Are pretty familiar with the SVM and the Solana core validator client and happy to
Talk with you and some of the others on the SVM fees and whatnot
I've spent a long time thinking about different parts of the fee world and I've written a lot of papers on things and around fees
Spend some time thinking about the differences between free markets on Eclipse the SVM L2 versus
Solana the L1 and also just looking at a lot of the fee market proposals
So yeah excited for this discussion
Yeah, thank you very much and also I know that we
Just finished eat Denver stuff. So I hope you guys also
Mentally recovered from that. Well, if not, please let me know
Try to go easy on on that as well
But anyway, so to kick it off the conversation of today
I think one thing that kind of caught my eyes when I was
Going through this or mirrors of papers out there around SVM TF SVM TFM
one thing that struck me that I thought was very interesting and certainly different from the theorem was around the
Right now I believe the base fee on Solana is is static meaning that
Anyone has to pay a fixed amount of base fee, which I believe was
5,000 Lamport Lamport meaning like the smallest unit of
Obviously, you know that has a lot of problems and whatnot, but if I know anyone in the
Panel want to elaborate on some of the conversation around base base fee in general and maybe introduce a little bit here. I
Guess I can start. So yeah, you're right the the current base fee. It's
5,000 Lam ports per signature and
Transactions just have one signature. Sometimes you'll have two signatures. So you pay 10,000 Lam ports in those
and I think the reasoning behind that originally was that
it was thought that SIG verify would be the
one of the more expensive pieces of the transaction processing pipeline and I think that
Hasn't necessarily shown to be true. And so
ongoing conversations to rework the the base fee to be a little more dynamic and
From like Eugene put out paper on
Some dynamic fee type things. So I kind of let Tarun talk about that
Yeah, I think the the kind of interesting thing to when you think about Solana fees versus theorem fees is
A there's sort of already a sort of fixed
A mountain burnt, but be there's also a sort of like
more kind of hard to reason about priority fee and so thinking about things from
other networks that they've
Learned to that have helped with like sort of dealing with congestion and spam on this kind of important. I think a
A base fee is a very blunt instrument if we're being honest for trying to prevent spam
Partially because you know you have to think about how to do it globally across an entire block or slot versus kind of
More granular more locally, but you know the trade-off is if you do something more local
You have a lot more complexity in both the implementation or kind of the
You know managing those fees
Versus you know, if you have a global one, it's very kind of easy
But it's also you kind of make things quite inefficient for users
And I know in Solana the you know end game is really about making fees as low as possible for users
and in in that vein, I think
Solana has sort of the best opportunity to kind of really have these kind of local
Multidimensional fee markets that make it you know are sort of responsive to to networks spikes and surges
Yeah, I agree with what turn is getting at in that Solana
Optimizing for is just a little bit more interesting than what your average single-threaded
VM is optimizing for in that they're able to separate the fees between a
Huge NFT man versus some other app that's occurring at the same
That's getting a lot of activity at the same time and what they've built right now is essentially an approximation
For folks that in the audience that might not be aware
Solana doesn't really have true local fee markets built into consensus at this point
but instead it's that the Solana
The Solana validators assumed to have four cores
And then they just don't allow any trend any specific smart contract to occupy more than 25 percent of any block
So if a smart contract really is getting spammed aggressively
Then that ensures that the remainder of the block is not totally congested
So I guess like based on that and we we kind of you know as Lucas kind of mentioned that there's like a blunt
And wasn't very like productive and have led to a lot of other issues like, you know
Just people spamming things even though they have a very different compute unit requirements and whatnot
First part of the questions I wanted to kind of explore with you guys and obviously, you know
feel free to jump in whenever is like around the design of this dynamic base feed there has been
multiple conversations around like how to
Do this like dynamic base fee thing?
There's been discussion around like oh, well, you know Solana has kind of more compute you can use with
Regards to adjusting the base feed then aetherium. So there's definitely like very different
Design space in which people are kind of exploring like alright, this is how we're gonna dynamically adjust the base fee
so I would love to hear if
anyone if one of you guys have some kind of a salt thoughts slash insights around like how should we go about this design of
this dynamic base fee for SVM
Yeah, I think the goal is to well there's a lot of things at play here
One is that you know, I think when people talk about this they talk about spam a lot
There's I think there's reasons that people are spamming beyond having low base fees
But if we can save that for another time
I've had like 20 conversations in the past two weeks about this with the people and it's a very contentious topic
Mean you probably just want to if there's some state that's getting pretty hot
then I think you want to charge more for that for basically how much of that state you're using and
how long you're holding that state and then there's also
Just say there's like this the sole USDC market on Phoenix is like super hot or some other markets extremely hot
That would kind of help back pressure that and make it take up less of the less block space and try to
Solana like really wants to be as parallel as possible. So if you can remove the
single piece of state is being touched in like if you can remove how much as a single piece of tape
State is being touched and you can parallelize the blockchain more
but then you run into this other issue where like some attacker or something is like
They have like 10,000 accounts that they're writing to and they're kind of just like taking up the entire block to Neil's point
You know a single account can take up 25 percent of the block space
what if there's like 10,000 or 100,000 accounts and someone is just writing to all of these things and
Saturating any account specifically but that during the entire block. So you probably want some type of
like global block allocation thing and then I think also like there should be
Loading I think the max account size you can have in Solana is like a megabyte or maybe it's 10 megabytes and
Right now it's all priced the same
Your transaction sizes are priced the same if it's like a transfer versus the max transaction size
I think they're working on like a 3x transaction size as well
so there's just stuff like that that is taking up more network throughput and
Taking more memory and things like that should probably be charged for
That's kind of my my take on it
Anyone else want to jump in
Yeah, I think that that's I think that's the right
Direction is starting just given that you're starting with what are the pain points or what are the the problems with the existing?
fee market mechanism, I do think that like a lot of the
fee market approaches that Solana's takes in general are generally heuristic and
That's what I liked about that paper that Tarun a few others put together
Which is that they're just taking an actual optimization approach at the same time
Recognize that the fee market is so complex and there's so many constraints for the Solana fee market
That it might not be efficient to compute that and that's also hard constraint
It's like you want it to be inside of compatible
approximately welfare maximizing, but also we have to be able to compute this in real time and the Solana blocks are produced so quickly and
transactions are received so quickly so
That's one more consideration
Yeah, I think the complexity is super important people have a lot of good ideas and like
Like the stuff that I was talking about like the memory calculation and whatnot
like that's like probably the best the way maybe it should be done, but also like
All that is just more clock cycles that could be spent just executing something with some
Like good enough heuristic and I think this will become more important with fire dancer
It's actually using every clock cycle and every
cache and whatnot as efficiently as possible and so every like every calculation that you do is like
taking up time from executing
Transaction and especially if you want to start moving more stuff into
Dedicated hardware like FPGAs or something then like you need to try to keep stuff as simple as possible
Yeah, and what it kind of implies is that any whatever heuristics the water ends up picking will inherently have some
edge case griefing attack
Just because other otherwise it'd be an exact solution rather than a heuristic
And maybe just want to drop
some some something that I was thinking at the other day and please feel free to
you know disrupt as well, but
To me it seems like the user incentive
Side of things like user incentive compatibility as they call it seems to be like a whole one big issue
With a lot of this like spamming
That is happening on on and even the state lock that is happening on Solana
seems like the minor incentive side of thing has not been that big of a issue because like
most of the miners are just earning kind of fees mostly from
Issuance not actually from the from the gas fees
I'm curious to hear some some some thoughts on that if you guys have any comments
I think there's a few things one is that
Block rewards are actually getting pretty large
with the increased trading on Solana, especially the MEV and
Currently all the fees are kind of bucketed and like treated the same way
So the base fee is treated the same way as priority fees and right now 50% of priority fees are burned
and so that's obviously not good because it
incentivizes like side channel
Right, right systems, I guess like we kind of built a side channel
There's a SIMD I think SIMD 109 and I need to split 109 into two pieces but basically
And actually there's another one where I can't remember the number
But I think it's the fastest past SIMD is basically to give a hundred percent of priority fee to valid errors
I wouldn't say it's like perfect right now, but it's easy easy enough change to fix it
On the user side, I think most users
There's definitely a lot of bots in Solana they're spamming for a multitude of reasons mainly because the
There's an insane amount of jitter and the transaction processing pipeline the scheduler doesn't actually like prioritize
Packets by the priority fee essentially random and
so yeah, I mean if you can if you can send a trade once and
Maybe have like 5% chance of success or you send it 20 times and maybe it goes up a little bit
But the opportunity is higher to spam. You just have a bunch of people spamming
I think this there's a new scheduler in 118 which
Should be released in like the next two to four months that will be optional
So you just have to pass a McManlan argument?
Andrew at Anza has been working on that. I looked at some of the blocks it produced on mainnet
And they're actually ordered by priority the
accounts and transactions
There's a few more tweaks that need to be made in my opinion, but I think that will be like way better and hopefully we'll
Eliminate some of the spam
Just to clarify when you say order by a priority that one is
Is that enforced on the client side or is that just they chose to order by a priority?
It's just a implementation detail. There's no there's nothing in Solana consensus that
enforces ordering in blocks
Guess that is one of the ways to make a very profitable block. There might be others, but uh,
if if people can actually like
accurately predict the priority fee that they need and
getting able to send their transaction once and have it land or not then
hopefully that will remove some of the spam and
Make the system just run more efficiently and validators should make more money, too
Gotcha, that's right. I see and really if you have anything to add
Yeah, I think and like, you know to kind of some of the points echoes here so far right like
transaction fee mechanism design is like half a
Science-wise or math wise but like also half a bit of an art. I think there's kind of
Last the last two months. No, maybe like last six months. They're just been a stream of like, I
What I would call personally some of the most boring papers in history that are all just like
Impossibility theorems on transaction fee mechanisms on which kind of says like, okay
Nothing you could do that's perfectly systematic will like cover every edge case like you can't make it like fully
Adversarial while also being easy to compute. There's concern this trade-off between like
adversarially resistant which is sort of this spam problem or sort of
something's closer to maybe versus kind of something that's easy to compute what the
Optimal fee is at the time you have to decide the fee
Versus if you looked back in hindsight, how well could he put it? But honestly those
Papers and like they're obviously, you know
I think they like people do a lot of work to get the results and whatever but they're kind of just like boring, right?
It's like, okay. Well, great. You're telling me that no fee model
Then no one should ever use a fucking bucket. But clearly there are millions of people doing that. So I
generally think the name of the game is a
the name of the game from a practical standpoint is a
Really understanding the heuristics you're using
What in the sense of like you have some simple rules
That you kind of use, you know, like
The Neil mentioned that that I wrote that was more just about doing it kind of heuristic thing of the form of hey
Can you do gradient descent if you had some kind of like injector functions you're willing to optimize?
Doesn't always work in every scenario
But it does have some weak guarantees
But there's a ton of other heuristics you might have right your other heuristics might be like, you know
I have a scheduler a parallel scheduler and this is something where I think the fee mechanism design is on a discourse quite dramatically
Gives you some information about how much contention you have between different threads or different resources
So, you know, I the scheduler might schedule task a before task B before task C
But then it turned out B and A and B wrote to the same place. So it has to rerun those two
transactions and actually
Fact forget who the odds I think it was both of you
But I forget who the author for have a good post that has like a very nice drawing
Kind of the old salon scheduler the new salon scheduler kind of does something more
To skid but the the crux of the plan trying to make is that the scheduler actually gives you more information about your fees
you know which parts of state are more contentious and which parts are less contentious and
Injecting some of that information from the scheduler back into the fee design gives you a bunch of a kind of set of data
that you could actually use to sort of
You know adjust your heuristics if like all of a sudden there's an entertainment and like
Literally every transaction is being blocked in the scheduler or rerun in the schedule
So I think there's a lot of extra information in
transaction fee design that like people kind of in the kind of
classical models don't think about and that's one of the places I think Solana and the SVM have a leg up in
Thinking through things. I think the move VMS also could have some kind of
Ability to take advantage of this, but I actually think that they're a little further away from that thing
And then the parallel EVM, I think they all have slightly different transaction semantics
So you would have to actually think an interesting thing is like if the SVM's
Is consistent across all these execution environments like whether it's rollups
It might make the fee mechanism kind of consistent across the ecosystem versus like in Ethereum
I actually think we're already seeing kind of like
Fragmenting in like how fees work on different rollups how fees will work in the parallel EVM world like the monads of the world
Anyway, this is a sort of a long rambling ramp
But to kind of really get at the point that the schedulering algorithm is actually quite important to thinking about how practical fees work and
Having the fee mechanism the scheduler interact with one another is like a way to get a much better throughput
Yeah, I think a quick point on that
There are a lot of there's a lot of excitement around the dynamic base fees, but I think
The data like if you you know to Turun's point and like figure out to design those fees the data right now is like
Kind of trash because the scheduler is not good. So hopefully if we can figure out
The new scheduler and get that in and then look at data. It will provide a more informed view on
Gotcha. I also want to kind of point out and you know, I kind of appreciate how
Turun kind of described this thing as like, you know art
Via heuristic. I think that's a very very
Yeah, interesting way to kind of put it and as you kind of pointed out
You know that the the Thames and Elanes of the world
You know writing papers about this impossibility theorems that obviously, you know
Seems just say alright a bit boring might as well just like try it out first and see what works that kind of seems like
How the industry is kind of approaching this entire TFM TFM problem space
Experimenting with different designs and and CC or where CC what doesn't works and I guess kind of going more from a I guess
Empirical lens that is kind of like how people are kind of like doing this experiments right now, which is again great stuff. So
Definitely, we'll be looking forward to more
guess just on a shift of topics, I I also wanted to
kind of touch on some of the things that I guess specifically Tarun was
multi-dimensional fee market for
Better pricing the compute resources and also enabling any sort of like privileged
Transactions. So right now like, you know, people have kind of thrown ideas around like oh should should Oracle at transactions be
Privileged should vote also be privileged and in the case of it Solana, I guess the vote is kind of
Not like a pretty important consensus related
Transactions, so, you know there you could make a case that okay, maybe that should be privileged transaction as well
So I guess yeah around the design of how to design this
multi-dimensional fee market and pricing better pricing those compute resources
If you guys have any kind of thoughts and comments on that
Maybe maybe to really want to take it over
Sure. Yeah, actually there was a lot there. So I guess which part of that do you want to start with question?
Okay, how about this let's just say like what are the resources that we are talking about here like sure yeah
Cool. Yeah, I think so the nice thing about the word resources
It's so abstract it could count as anything and I think it actually would behoove us to compare what resources are in
Ethereum versus resources in Solana
Because I actually think they're kind of different notions of parallelization like in the roll-up framework thinking about what resources are is sort of
different than in the kind of singly fed high parallelism version
So in Solana, I think resources are of course
You a single thread some amount of state that is either written to or read to and in Solana
I think having this explicit sort of asymmetry between reads and writes is actually much more important. I think then the theorem
Because in when you're running in parallel rights cost you so much more
Other resources which are sort of indirectly measured are things like bandwidth
In in the theory, um, you know, the resources are
Act in a lot of ways for a role from the perspective of a roll-up each of the different components
that the roll-up has to deal with so
data availability for fraud proofs
Transactions to mainnet the execution costs and storage costs, of course
In a lot of cases for instance in zero knowledge roll-ups ZK roll-ups a resource that users
You know right now are being subsidized for but in the long run will have to pay for is the zero knowledge prover network
Like the person is generating the proof and sending it to network that cost gets distributed across the users
and that's sort of a resource that has to be consumed, but
You know the different resources here are
The idea is that their demands might fluctuate at different times
So, you know like at a certain point in time say like everyone is hitting the same NFT auction
Well, that's mainly a storage resource being locked, right? Everyone is trying to write to the same account
But the actual amount of execution cost is actually quite low
It's you know update a bid in an array or it's you know
Call the mint function and do a transfer right relatively low transaction low relatively low execution throughput
Very high space throughput and at those times right you may want to make the price of space go up much faster than this
Price execution because the execution is sort of cheap and it's really the space driving the creation of the seeds
But I think one important thing to realize is that
You know while these resources also have different sort of demand generations
they also have different sort of temporal structures, right like
There could be it you might really care about a lot of space
Being demanded at the same time within one slot
But you might not care about the same amount of space being demanded over
100 slots because you can kind of load balance or spread things out
And I think a lot of the goal of this resource pricing stuff is just to figure out how to load balance and do things
of that form so that's sort of the long-winded explanation
Right and I guess like one thing that I'm I was kind of wondering is like
because I think you mentioned about
execution throughput which seems to be
Like with like each have its kind of like own definition
I'm kind of curious like when you mentioned those two terms like what do you specifically mean by that like how what's the difference between
This execution throughputs and the space throughputs
What what's the what's the kind of like the semantics here?
Like okay, so I'm gonna say something that you know is
Somewhat controversial also somewhat incorrect
But I think it will give you like the first order logic to why resource resource pricing for different resources should be different
So, you know in aetherium land you've heard a lot of people complain about the cost of storage
Especially storage that's ephemeral
So what I mean by that is there might be storage that needs to be stuck be posted to mainnet
but it's for a roll-up and
After you know the challenge period say seven days or some amount of you know, zk proofs
I don't need that data anymore
The problem is main net itself
has sort of a fixed price for
Storage versus reading versus adding two numbers versus doing XOR
But but it turns out that like maybe the majority of the cost of my roll-up is actually just doing this storage that I only
need temporarily whereas I don't really need it permanently and
The existence of data availability layers a third party like Celestia or avail or I can be a
They they're sort of a way of
Adjusting for this right? They're kind of letting the roll-up on the cheaper transaction fee for this ephemeral storage
So they're treating it as a separate resource. I see
and so there's sort of the sense in which what you're doing is you're partitioning your set of
things that are consumed when you execute production into
Components and then you're adjusting how fast and slow the increase of those prices change
I see that makes sense. That makes sense. I think that was a very
And data availability is a little bit complicated because data availability sampling and the ability to reconstruct
Those are things that are also priced into this which are not
Just like but like ignoring that's like I said, it's slightly wrong first order approximations
So don't don't don't come don't come after me with some pitch
See I see gotcha, but I think yes that it does make the point right?
I think you you're saying like look the data storage aspect. Well, the data cost itself is like a kind of different
Execution which is more of like a compute intensive which but then obviously as you mentioned, you know
da itself has some that will compute that needs to be priced in so it's not very
Yeah, that's fair. That's fair. I guess another thing that you know, again, I'll open to the floor if you guys want to jump in here
like this so basically like because you could define those resource in a way that could be potentially be
Exploited right? Like I think if you were to have some sort of let's say privileged
transactions of certain types
You you need to kind of constrain the the the definition of the privileged transactions
well enough that people can't just like try to
Exploit it try to use it for other purposes that is not intended by design
And so so I'm also kind of curious if you guys have been some thoughts around this like
multi-dimensional female cancer
Maybe Neil maybe Neil cuz he wrote a lot about this. Oh, yeah. Yeah sure, you know if you wanna if you wanna take a road
Could you say a question one more time?
so basically, I'm wondering like around the exploit of the
multi-dimensional fee market where you know, you define certain transactions to be let's say a volt transactions
but again like defining volt transactions self could be
non-trivial because you know, like if it requires certain signatures, well, can I like
Can I like disguise my transactions as if it looks like a volt transaction even though it's not
So it's all like kind of like just the thinking of like, okay. Well if we do have this kind of privileged transactions
Avoid people exploiting that or like how can how can we like, you know while preventing free free lunch?
Also be able to you know, you know what I mean? Yes
so the way that the reason why I originally put that in the
Had on it eclipses blog was because it was inspired by Sam Hart
So it's a very cosmos way of thinking about things where you want
Oracle updates to be reliable and cheap and that's good for everyone
Right, like there are positive externalities to having the correct Oracle price at the correct time on the on chain
And I think a way that they would normally do that is they would literally have governance
elect some preferred Oracle provider and only that public-private keypearer would be able to
always guarantee some amount of transactions in every block and
Of course that now now there's the risk that that guy starts posting things that are not related to the Oracle network
But then presumably you'd reelect someone else until you get like an honest actor that's willing to do this
the more sophisticated version of it would would be
We're just gonna in general try to white label or detect which
Transactions fall under some privileged transaction type
maybe we want to make sure that one quarter of the transactions are the the block basis reserved for games and
That I actually haven't thought as much about it. I don't know if that's really possible in general just because
Then it becomes inherently subjective about who's doing the categorization
See this is actually this is also interesting because and I remember I was previously
working with some thought coin guys on figuring out, you know, their
multidimensional fee type of things where the storage proof itself was a transactions
But again, you know proof is all as new mentioned
Could be as important as like providing the utility for the chains like how Oracle does and in the case of fire coin
You know, obviously storage proof is like super important to prove that the story storage of the data is actually persistent
So so having that transaction to be processed as quickly as possible
It's like more important than having some random swaps to be processed within the within the fire coin construct
So so I can I can totally understand like, you know, I like reserving. Let's say 25% of the box base
You know, I can't imagine can get into some shit show pretty pretty quickly as well
So so yeah, it can be definitely a bit tricky on that front
Lucas and Tarun if you have any thoughts on that exploit front for the multi-dimensional fee
No comment on that I guess. Yeah, hopefully configure something out. That's not
This gets back to this kind of thing. I was saying earlier, which is like hey, there's all these like formal results that like basically
Transactracy mechanism design is impossible. But yeah, you know, there's millions of people using it
So I I think there's kind of this
You know, you can show is that like hey, maybe you won't perfectly get incentive compatibility
Right some way. It's like you might be you might be you might not get like exact in terms of ability
But you can kind of show you can bound it
and and sort of like there's some way in which like the error is not like
The absolute worst and there's ways of kind of like ensuring that these multi-dimensional things don't get super spammed
We're like someone figures out by spamming one particular type of resource
I make the resource price for that resource go up but the relative price of other resources goes down
So now I can buy those more cheaply, right?
like that's kind of like the time you can kind of show those those types of things are sort of
bound in some intro but in terms of the the piece about like trying to split the block into
Particular resources having separate fully separate auctions
Generally, I I'm more than like that's kind of hard to enforce
Ironically the best example of a blockchain that had
Very very custom top of block for a bottom of block blockchain rules was Luna
Because Luna had the Oracle updates
For the stable coin as the first transaction on the block as well as it all the arbitrage against the kind of privileged
So, you know and you know, I would I would argue that I'm sure some validators look at rather at the end
Interesting version of this. However that you know, I for people since you know
I feel like for the last eight years or nine years. I've always argued that I want block space futures
But you know, there's all these practical limitations and it's like very hard to execute correctly a type of thing
but something people in the theorem have been talking about which I think might be something worth considering in Solana is
there's this notion of execution tickets where people sort of
You kind of play with the temporal top like the number of slots that a proposer gets
So there's some randomization to that
So, you know you you preserve the probability of being chosen for any single slot
But you maybe get a sequence of slots in a row
So that like the chance that you you miss more slots goes down
But in some sense you could think of this as like I'm auctioning off the next five slots to the same proposer
Proportional to those stakes probability and
Something like that is sort of a little bit, you know
You could argue that now you give the proposer the ability to kind of partition those five blocks into different
Configurations like that and and I I think like that the time dimension is the part that people haven't really played around with
Everyone kind of looks at the the single-shot game and the single-shot game
I think is like, you know, we probably know 99% of what there is to know about it at this point
Oh, that's a very interesting. So so what what basically what to ruin here saying and correct me if I'm wrong is that
just kind of why I'm back here like execution tickets for aetherium is kind of a
attempt to sort of like in try a lot of the MEV and
potentially even burn more MEV
For the protocols, right?
So so it requires the proposers to buy this thing called execution tickets and then the more you buy you have a better chance of getting
Getting the proposer seat essentially for XYZ blocks, right?
But what Tarun is saying is that look you can
Play this similar execution tickets type of things and in fact, you can even petition the blocks so that you can basically, you know
Like basically sell off like even portion of blocks is that kind of like what I'm getting here through
Yeah, yeah, and sort of like now you could talk about fees over sequences of blocks for
Like single single slot right when you have the ability of the same present forcing
Interesting in that case, it's it's kind of like it's kind of optimizing for different things
Then because you know, it's not necessarily for like, you know in trying more MEV into the protocol
But it's more like having a bit more flexible
partitioning and sequencing of the
Sequencing of the blocks that that the that the leader would be able to process
sort of right like it's more like a I
Guess more like economically driven way of of deciding who is there to schedule this block basically
Yeah, yeah. Yeah, and I think like it's a little more free market
Right, right about a middle ground between all
Mm-hmm. I see that's that's a very interesting proposals
Yeah, but but you can't can you also I mean maybe if Lucas have some comments here that perhaps
This is something that maybe could be done out out protocol
Like some sort of like a construct similar to MEV boost type of things as well. What do you think Lucas?
Yeah, that could work and to be honest I haven't read the execution tickets thing it's on my to-do list
It seems like people in the theory and ecosystem are excited about it. I
can't can't really say that much about the idea, but
Yeah, gotcha. Well, I'm sure your dog is very excited by execution tickets. So
And I guess the last theme of today
Is around the incentive compatibility problems as well as any other
Due to where the execution of the SPMs are done, so I think
today obviously as for some of you guys may not know like eclipse are running this SVM thing on
On layer two as it as a layer two while Solana obviously is running as a one
So there are things that may change right?
Like for example, they might be no like volt transactions anymore like it does on Solana, right?
But I'm I'm I'm kind of curious to see
If there's some sort of like differences between L1 SVM
Transaction fee mechanism versus L2 counterparts, maybe Neil if you want to comments on that
so some basic differences is that the L1 has some base amount of transactions that are always there just from votes and
Those vote transactions maybe should be privileged. So that's one difference
Transaction sizes are inherently a little bit bigger just because of the extra commitment bytes that are posted. So bandwidth
theoretically is slightly more constrained and
Then the last piece is that we can change our sequencer hardware requirements in a way
That's not congruent with the hardware requirements for the L1
And this is something that you can have chatted a decent amount and I posted some tweet earlier
That we will be changing the hardware requirements. The question is just
How perverse is that gonna end up looking like should it be should it be something so extreme that it's
like a hardware requirement that almost feels like unnatural or it's something that we haven't seen for a blockchains before or
Should we like generally try to keep the spec more one-to-one?
And there there's like pros and cons on either side of that
Mm-hmm, I see I see. Tarun or Lucas if you have any comments on that
I think I look forward to L2 experimenting with some of the theme mechanisms. I think
They'll just be able to move faster than
What what can happen on mainnet
There's just less coordination and all that, you know
I think that would be interesting. There's like there's a ton of changes coming to Solana over the next
like four or five years that
Will be interesting to see like obviously scheduler is one but
Request there's a feature flag that you'll get charged on the requested compute instead of the actual compute
Solana is going to change the protocol such that the
constraints on what's included in a block or not will be way more relaxed and the leader won't actually
Need to execute any of the transactions. And so if you're not executing transactions, then you can
pack blocks way faster and
You know if you don't know how much the execution costs then you need to use the requested number
there's like multiple concurrent leaders and all this other crazy stuff that is a
too long to mention on this call, but
Yeah, I think it'll be interesting to see how it all evolves over the next few years
and I think L2s are kind of an interesting spot where they can
Experiment quicker. Actually, I just had a bit of interesting
Wait, wait to think about this
But you know, I think we had a lot of cosmos chain
Experimenting the idea that aetherium, you know didn't didn't dare to to implement now
perhaps the the L2s are kind of experimenting ideas that perhaps
Sbms were kind of, you know scared to implement so that maybe you can kind of reference each other and say well
That L2 is kind of working with that mechanism. Perhaps we can also work with ours
Maybe maybe maybe that's a one way to kind of look at this as well, which again very exciting space for sure
Wrap it up because I know the time is kind of closing in short
Guess I'm almost so curious like to hear just from 20 of you guys who are very much in the weed within this SBM space
What what are you kind of like most excited about?
SBM and and for the for the coming months of developments around this transaction fee mechanism and
Yeah, just generally you would love to hear like what's something that you're super excited about
And they expect like the changes that is upcoming, etc
For me, I think people are excited about the answer it's not directly related to TFM but
Should make everything way faster
I think I'm most excited about the some of the
Or to for the valid air keep 100% of the fees
there's some other 70s as well related to your block rewards and things like that and
Hoping to see some some of the scheduler changes hit soon and gather some data and figure out how to best adopt a
dynamic base feed mechanism, I think the
The Lana world is pretty divided on if we want dynamic base fees or not. Oh, some people want some people want them
It's just better UX. Some people want the ability for validators to basically price things themselves
But you know, that's a maybe conversation for another time, but I think
Yeah, there's a there's a lot
The performance is there on Solana. I think the I tweeted about this the other day that like I think performance is an amazing mode
economics you can change reasonably fast and
So I think there's a lot of room for improvement and should start seeing those improvements pretty soon. Gotcha
Tarun do you have anything to add?
Um, yeah, I would say more from the
Partially the engineering lens partially theoretical lens. I you know, I spend a bunch of time trying to
read through a the new scheduler and be kind of how
some of the auctions are working right now and saw that and there's
Definitely like I said a lot of ways
I think the scheduler and the fee mechanism can interact that
Hopefully are like give you the best of both worlds to the debate that Lucas talked about I or just like I yeah
Yeah, I kind of got I'm not you know, like I I kind of think like
Generally the user you excite is more important, but I do understand the validator concerns
Especially in terms of sustainability and I think like yeah, there's stuff you can do that's kind of in the middle of that, you know
Solana seems to be the closest to being able to do
The move chains like in theory they could could do some of the stuff
but I don't know when I look at the code bases, I've actually found their fee mechanism implementations very hard to
To imagine changing dramatically. So I feel like Solana to me is like the best kind of testing ground for a lot of new things
Interesting interesting and just just a quickly follow-up on that when you say like the move chains
Cannot change this transaction fee mechanism very easy
Are you saying like a lot of things are super enshrined to the protocol that you know changing it would kind of have to require
Some sort of like even like consensus consensus level changes. Well, I think they haven't standardized around
In a way that makes it easy to think about how the fees could change
So I just think that they're there they're kind of probably where Solana was in 2019 or 2020
I see I see. Yeah, I guess
If you may want to also share something that you're excited about SBM, especially now that you're building SBM on L2
Oh, okay, wait, did he just go flying? Oh, yeah, he just went offline
While Neil is kind of joining back
Maybe I'll just like what ask our one last question, which is
the 1559 ethereum space kind of looking back and say look
Compared to 1559 with this with this like sort of dynamic fee mechanism
If Tarun has any preference or Lucas have any preference over like SBM should adopt this kind of 1559 type of
Mechanism or you think that 1559 is like totally shit, you know ethereum space which just like completely change it if you guys have any
Comments on that as well. I would love to hear hear from that
Okay, I was just gonna say like many things in life
neither the things that are praised as it's
Positives nor the things that are praised as negatives are completely true
I think you know, obviously different different participants have different reasons to say like oh, it's the best thing
It's like bread to oh, it's like completely horrible like
Destroying the system in reality. It's like a kind of nuanced thing. I think it's some scenarios that works and helps
I think it does help wallets
It initially was a pain in the ass for wallets, but I actually think like it does help wallets
You know require as much input from the end user
Of course on the other hand in the worst case when the chain is really congested
It like has a lot of negative a lot of negatives happen. So, you know, I think the hard part is like
The average case is probably better. The worst case is probably worse and like, you know, how much do you want to trade those too often?
I think as to mention at the beginning like it's uh, it's art at the end of the day
It's all heuristics, right? So yeah, it's just a bunch of trade-offs and see what it was you what works
And Lucas you had anything to add? I
Think something similar to it makes sense. I don't think I'll be pasting it one for one
maybe some of the parameters are different or the way that it calculates the the curve are different and
Yeah, maybe it's like a exponential moving average over like the past and blocks or you know, whatever it is
That takes in that the constraints of Solana. I think could be an interesting exploration
cut off for like few few few seconds, but
I guess well last lastly I just wanted to also wrap it up with Neil asking if
What's what's something that you're very excited about SPMs and he FM
Especially coming to L2s and experimenting you're experimenting with L2. What is something that you're most excited about it?
Think the big thing is implementing the scheduler
improvements maybe prior to when they get merged into the Solana L1 and
possibly contributing to some additional schedule improvements just because
scheduler jitter I think is that the core of a lot of the
Issues that the transaction fee mechanism is incorrectly trying to solve
Where if the scheduler were fixed then it becomes?
Possibly like an easier problem. So so that's one big thing and
Then just for SVM in general, I think I'm excited for
General purpose proving to go down. I know the Saints had sp1 and risk zeros
Proving cost or overhead is going dramatically down with different accelerators that they're putting out
So once you can get actually prove the entire canonical chain for the SVM
That I think that opens up really interesting possibilities for how it can fit into a theorem roadmap. I
Seems like there are a lot of stuff cooking up as well. Well, I think before we
Close off. I also wanted to just like give it a shout shout out to
Terrence paper that he released. Yes today. Yes yesterday
Which again another very fascinating one around the intent market?
I mostly coming from like more theory goal and side of things but you know
That there's there was a lot of interesting talk about oligopoly. So we'll definitely recommend you guys to check it out
I myself might be also coming out with some more empirical side of things with with kind of like that in 10 sash
RFQ silver side of things. So so yeah, definitely keep a keeping an eye out for that as well
Again, thank you very much for Lucas to ruin Neil to join the space today
Appreciate all of you guys joining and having such a fun conversation. Hopefully we'll see you guys again next time for different SVM discussions
But yeah again, thank you very much. Thank you again for all joining today. Thank you