DeFi in Context: Dynamics and Interactions within the Blockchain Ecosystem - Lioba Heimbach

Transcript

[Music] uh yes thank you for the intro so this is more of I guess a bit of a high level talk about well the Dynamics and interactions within the blockchain ecosystem and with a bit of a focus on how this affects defi or how defi affects the rest so in general much of my research has actually in my PhD been surrounded by some vision of creating a fair decentralized and resilient defi ecosystem but when doing this what I found is really that these complex Dynamics and interactions we have in the multi-layer blockchain ecosystem or architecture really present like unique challenges on defi that are for instance not present in a traditional

finance and well I quickly just want to go through the blockchain layers that those at least those that will be relevant for what I will be talking about just know this is not like a complete enumeration of everything just sort of uh what will be relevant here so at the foundation we have the Network layer and essentially this compromise is a peer-to-peer Network that manages the com uh communication between nodes and ensures that a dissemination of transactions blogs and consensus votes then these notes at least some of them they run validators and these validate blocks and then they reach agreement on the current blockchain state in the consensus layer once validated transactions are processed and uh executed in the execution layer and

finally we have our application layer that holds many of the Defi and web free protocols that we like so one example of how sort of this interplay between the various blockchain layers um happens and the broader impact of it is um that we have value that originates from the application layer and that is a centralizing force or centralizes the consensus layer as well as a security rist to it and well by value I guess most of you will be um familiar with this what I mean or what I'm talking about is me so me stands for maximum extractable value and it essentially any value that can be

extracted by including excluding and reordering transactions in a block and common examples here are sandwich attacks which is a type of front running transaction in uh front running attack in decentralized exchanges we also have cyclic Arbitrage which is a Arbitrage sort of between various decentralized exchanges as well as liquidations which is um the which is the liquidation of lending of positions on lending protocols so me is often found in blocks on ethereum but before we go straight there I just want to Quick give a quick introduction on who is actually building blocks in etherium even though I assume most will be familiar with this as well so ethereum is currently a proof of

State cryptocurrency we have a chance for a block every 12 seconds and we have a single validator that is assigned to propose this block so now the way you might think that blocks are being built or the way it at least used to be is that we have a public peer-to-peer Network transactions are being broadcast across this network then then the validator that is chosen to propose the next block is also a note in our peer-to-peer Network observes these T actions takes them bundles them into a block and the um block gets pended to the chain so some blocks in eorum are actually still being built this way but really the majority is not being built this in most cases the validators so who's actually chosen by the consensus is not the one who actually builds the

block instead we have what is referred to as proposer Builder separation or PBS for short and essentially this is an opt-in protocol through which the vast majority of blocks on etherum are being built these days so more than 90% and essentially the basic idea is that the validators themselves um they do not propose or build the block they just propose them but this instead specialized Builders are building the block blocks so these Builders they specialize in building high value blocks so high M blocks essentially and they compete in an auction to have the highest value block so each of our Builders they put in their bits then there's a relay that connects the two so connects the builders to the validators

the relay takes the block with the highest bit passes it to the validator and if the validator chooses this block then the block gets appended to the chain and our validator receives value equal to the bit that was indicated it so you might wonder why would anyone will pay or bid for building a block well that's because these blocks can be very valuable or the right to build them can be very valuable and that's essentially a consequence of me so you can assume that sort of the bit is should be lower than the um actual value of the block because the builder needs to be or wants to be earning some money in performing this so when PBS was introduced this was already a while back there were essentially two main goals it had and

the first was to prevent hobbyist validators from being outc competed by institutional players because these institutional players what they can essentially do is they can better optimize the profitability of their block building and then the second was to prevent sensorship by essentially separating who's building the blocks from who's proposing them so a while back we did a measurement study to analyze how the scheme fails in relation to these goals and this was essentially sort of the first widescale measurement analysis of how PBS is doing and then we essentially looked at both of these goals to see how it faes in terms of them and the first one is well we looked at how value so block value um that's priority fees and direct transfers and

profits compare between PBS and non- PBS blocks and essentially on the slide now you can see on the left side here um each dot there is a block and on the Y AIS it's that Block's value and on the xaxis it's sort of the time at which it was proposed and essentially all PBS blocks are shown in blue and non- PBS blocks are shown in red and then on the right side you see the median proposer profit both for PBS blocks again in blue and for non PBS blocks in red and essentially the main takeaway here is that the blue stuff sits above the red stuff so PBS blocks are more valuable the proposer is getting more from it and yes so proposers that use PBS make a

greater profit than if they were to self-build their block so in the OG way that we saw and as well we didn't find any indication that sort of relays were preferring some validators over others so in regards to the first goal which is um whether PBS works at preventing hobbyist validators from being outcompeted by institutional players PBS seems to be doing a very good job at achieving this so when we go to the second goal which is does it also prevent transaction censorship this um well there we don't really see any evidence for it so the first thing being like at least a while back many relays were actively announcing that they were censoring types of transaction the landscape has um shifted a bit but still

this was the case for quite some time and also we find that in PBS blocks there actually tend to be a smaller proportion of the types of transactions that are typically censored than in non PBS blocks so in regards to the second goal there's really a question Mark whether PBS is achieving it um but all evidence we find suggests more the opposite but then again the landship has Al the landscape has also drifted in the meantime so in doing this measurement analysis what we then also notice is some other things so for one this is a centralized landscape if you have ever analyzed uh any blockchain or defi protocol this is probably one of the conclusions you always draw that we have

a decentralized system which is a quite Central Iz landscape so the plot now shows the Builder share over time but it already ends in sometime in 2023 and essentially it has gotten much worse since then so already here you see that there were only a few builders that were sort of building the majority of blocks but these days it's essentially only two builders that built 95% of eperium blocks and then another thing we noticed um is in regards to the relays so the relays are a trusted party in this PBS scheme and for one sort of the proposers they trust these relays that they will deliver the full value that was indicated by the bit but we found multiple instances where this wasn't the case importantly sort of we didn't find

any instance where um where there was any evidence to suggest that this was malicious behavior by the relay it was sort of just a failure of the things that they were checking but it raises but sort of validators that want to participate in the system they really have no choice but to place their trust in these relays so given that these realiz have so much responsibility but receive no real financial compensation in return there seems to be something or some incentives that are not aligned here and this seems to be an issue in the PBS design which is also evident by many relays really closing their operations in the meantime and also citing financial reasons for that and then the final thing that I

want to touch upon is that we also noticed that some Builders had what we call negative profits so essentially when they were entering this auction the bit they were putting in was higher than the value of the block so if this is all that they were actually earning they would have made a negative profit so you can see here the main builder for which this was the case was Beaver build we're plotting the daily profit here for Beaver build and then for the rest group together and you can see that for like a one month period Beaver build had some suspicious negative profits there so the bids it was putting in was higher than the fees it was receiving from the blocks and that led us to wanting to dig a bit deeper into

this so um this is a separate sort of based on a separate paper what I'm going to be talking about now but what you can see here is a block that was in the 16th of October in 2023 and each dot here represents a bit in this PBS auction we saw previously so in yellow you can see um many bits sort of grouped together and then in blue and red I've highlighted two particular um Builders which is aring Builder and beaver build and essentially on the y- axis you see the value of the bit and on the x-axis the time it came in so this is a 12 second interval essentially before one of these blocks and this bit what you can think of it is sort of the value of the block

at least from the perspective of The Proposal this is how much they're receiving now at the time that the proposer then chose a block to produce the highest bit was more than 10 Eve that's like 30 to 40 US doll currently and it's more than the um more 100 times more than the average value on ethereum actually so the average block value and another weird thing about this block was that there was absolutely no traditional me so traditional m is sandwich attacks cyclic Arbitrage and liquidations that's what I'm referring to and then the question is really what is going on in this block and for that we need to look at

the cryptocurrency prices during this 12C window they were extremely volatile essentially the price of Eve Rose by 0.6% in just 12 seconds and the one of Bitcoin by even more by 1.3% so this price movement and the resulting non-atomic Arbitrage opportunities seemed to be the answer as to why this block was so valuable so what is nonatomic arbit Arbitrage I mean for those of you that saw the cross chain Arbitrage talk earlier it is very related and essentially it is we have cryptocurrencies and they trade on onchain decentralized exchanges as well on offchain centralized exchanges these two venues they're very likely to quote

different prices at different times because for instance we only have a Blog every 12 seconds so the price on a um onchain exchange can only move every 12 seconds while the price is on the offchain exchange constantly moving and then non-atomic Arbitrage is essentially any Arbitrage between these on and off train exchanges so that takes advantage of these um price differences and what we then did as we wanted to do a measurement study of this phenomenon on the ethereum blockchain to see sort of its scale and everything we first had to Define some ristics that actually allow us to identify nonatomic arbitr it is not entirely straightforward because we see all the

trades that are happening on the ethereum blockchain but we have little to no visibility into the offchain exchanges essentially but what we found is that we regardless were still able to infer with a high probability at least whether a transaction is likely to be a non-atomic Arbitrage transaction or not and essentially we just had one assumption that guided us to create the ristics that I would show in a bit and that is that these transactions they have a high value like someone is making money here so any arbitrager that is performing them is likely to protect their transaction and pay suspicious and amounts to have their seemingly simple swap included okay so based on this sort of

one assumption uh we defined five ristics that we used to identify non-atomic Arbitrage traits the first is that the transaction is a simple um transaction so just performs one swap on one decentralized exchange does nothing else and is not a sandwich attack for instance instance uh second realistic as that it was submitted privately so it did not enter this public mol but used some private channel to get in our third teristic is that it included sort of some sort of priority fee or some sort of tip that's either a priority fee or a direct payment or a coinbase transfer as they're called to the valid data and essentially these

characteristics two and three what they allow us to do is to identify that a transaction is valuable as it was submitted privately and it tips The Proposal our F fourth transaction is simple it just needs to be the first transaction in that PO in that direction because otherwise the Arbitrage opportunity might already be gone and our fifth one is just that the swap exchang is sort of two established tokens so that are likely to be traded on a centralized exchange sorry okay so these characteristics that we identified um sort of allow us to identify non-atomic

Arbitrage but it is important to note that these are neither sufficient nor necessary so there can be traits that are non-atomic arbitr that do not meet them and the same goes the other way around some transaction might meet them all and not be non-atomic Arbitrage so what we did is we did some additional testing of our ristics and essentially what we did is we measured the proportion of transactions our ristics appli to for some known arbitragers so those are beaver Arn and Manda and for all swaps overall and you can see in this pie chart essentially in blue the transactions our hortic do not apply to and in red the trans uh the transactions our hortic apply to and you

see that over all they only apply to 3% but for these known arbitragers they apply to for the vast majority but in general they should probably apply to all of them so what this leads us to conclude is that we're probably underestimating the phenomenon rather than overestimating it but we chose to stick to these hor istics to give like a conservative lower Bond of what is going on and then with the help of these her istics we also of course wanted to study the nonatomic Arbitrage landscape its drive us and its impact I'm only going through like a small subset of what we were doing here essentially but we are showing the cumulative um volume of nonatomic arbiter swaps over

time and essentially this plot divides the biggest 11 arbitragers you can see them all separately and then the rest is grouped together at the top so one thing I want to point out here is that the total volume it's really staggering it's 132 billion US dollar if you put that into proportion of the Dex volume it's a fourth of that or more than a fourth of that so also very significant then it's 10% of block value also 10 of% of the transaction fees that are not being burned and we see two periods of time where we see sort of a stock increase and these are related to the FDX collapse and the usdc dpack which are essentially periods of time where

cryptocurrency prices were highly volatile all that means is when prices are volatile they're moving much more so these price differences are essentially much more expected to happen so we would assume that non-atomic Arbitrage increases then when we look at the top 11 searches we see that they are responsible for around 80% of the volume and when we go to the top two they're responsible for around 50% of the volume so one of the conclusions that we always draw is that we again have a centralized landscape at our hands here so um what I want to do next is then say okay so what is the impact of this happening because because part of

this talk is supposed to tell you that well whatever is happening on defa here because that's where non-atomic Arbiters is sitting affects sort of the rest of the blockchain stack and the first thing to not is that this poses a risk to the consensus layer if we look at the value so this is again sort of the transaction like the priority fees and the direct transfers of non-atomic Arbitrage in relation to the rest we of sort of these me types of transaction we see that it's a bit lower than sandwich attack and significantly higher than cyclic Arbitrage and liquidations and essentially this just goes to show that these non-atomic Arbitrage transactions they are some very high value transaction they really um sandwich attacks are the only one

that compete with it and then any type of high value transaction so this is not unique to non-atomic Arbitrage poses a risk to the consensus layer and essentially sort of what is happening is that the consensus layer is vulnerable to what is known as time banded attacks so it can be rational for a block proposer to try to Fork out the previous proposal to get the profits so let's just look at a quick example here we have our blockchain and some very high value transaction sitting in one of our blocks and then the next proposal is malicious wants it for itself and could somehow try to Fork out that block to then extract uh the value so it doesn't append its block to the previous one but

to the one before and the higher the value of these transaction the more likely it is for this to be actually rational behavior and then the second thing is that this nonatomic Arbitrage it really causes congestion in the ethereum network during these times of high cryptocurrency price volatility and that affects all users so even if you want to I don't know just transfer half a e to your friend and to see how the effect is let's look at two blocks so the green one here is an overall block so the average block essentially and the red block here is an average Block in the 99th percentile of e price volatility so

essentially in the 99 percentile where the in the 12 seconds leading up to the block cryptocurrency prices were extremely volatile and our overall block 50% are overfall so they have more in them than the target size but if we go to the 99th percentile it is much more likely to the block to be over full so 80% of those blocks are actually over full and then when we go to Value we see that only 1% of blocks of the overall blocks are worth more than one E versus 50% of them being worth than more more than one e for these high volatility blocks and essentially the driver of this is nonatomic arbitrage and what it does it

create increases waiting times and fees for everyone in the network even if they have nothing to do with it and then the last thing we want to point to is well that it's a very centralizing force in this block construction market so the PBS auction as well there are actually some arbit um some builders that have their own sort of integrated arbitrageur that create that do these nonatomic Arbitrage things and then these Builders dominate non-atomic Arbitrage and thereby they dominate block construction during times of high volatility so if you remember sort of what got us onto this is that we were noticing these suspicious negative profits for Beaver build Beaver build is

actually one of these hft Builders as they're called it has its own non-atomic Arbitrage um sort of Bot that it's running and it was actually subsidizing its bot for around a one month period there that's where these negative profits were coming from they weren't actually negative profits and then also as I mentioned already uh what we see even though these lines are not really showing up here but we see that um these of T Builders they have an edge in the block auction during times of high volatility currently only one of them is still actually operating so essentially it dominates the block auction during terms of high cryptocurrency price volatility and this is then at those times a very

centralized Market okay so this is one example of this how this value from defi can really centralize and be a risk to the consensus layer then a question you might asked that I want to touch up a bit since in the meantime some proposals came out is what we can do about it and it should come as no surprise that sort of the things that are out there to address this are actually not sitting all on the application layer where this value is originating but these ideas also Target other layers some one idea is to shorten block times because these price differences there expected to be shorter when we have shorter block times however uh you should also consider the impact this

could have on the general consensus safety if we just go ahead and reduce block times but another possible Avenue is just moving Dex volume to these l2s where block hems are already shorter a different idea is the concept of multiple concurrent proposal the intuition here just at a very high um level being that this competition between the concurrent prop uh proposers helps us get away with these negative externalities from non-atomic Arbitrage there's currently some ideas out there on how to implement this but this is all still in its early stages and then the final idea and this is one that actually more or less sits at the application layer is to do batch auction

cob is a protocol that does it and essentially what the idea is that we just aggregate all traits that want to go in a block and we execute them all at the same time so no one entity sort of can run away with it all okay so what I was going through again was an example of how this value from the application layer can really be a threat to the consensus layer and now I want to go through another example of how these forces can be acting in the opposite direction so this example being that execution layer bottlenecks that sort of um prevent us from increasing blockchain throughput can actually sort of hinder Defi and web three applications from

achieving widescale adoption because it's just simply too expensive to interact with them but if we let's say were to increase throughput by four maybe it will all go cheaper and the um these applications would achieve a wider adoption so to understand why let's start by looking how transactions are executed in ethereum currently so we have a block here with four transactions now today what the ethereum virtual machine does it takes these transactions puts them in order so in the order that they were included in and then just executes one after the other sequentially but the question is why does eorum not just allow these transactions to be executed in parallel

of course in some deterministic way so that we all still agree on this state after this happens the benefits of this would be that we could scale throughput without actually increasing Hardware requirements I mean most consumer Hardware these days comes with multiple CES so by spreading the workload across these course we would allow uh it would allow us to uh increase throughput without actually increasing any hardware requirements and other blockchains such as Solana are already doing it so this sounds like a very sort of nice thing it sounds perfect we can just paralyze and then we can increase proof it and everything will be better but we shouldn't get fully get a um we shouldn't fully get ahead of ourselves

here because we also need to ask sort of what throughput can we even achieve like imagine two transactions that trade in the same liquidity pool we cannot execute them in parallel afterward sort of things could go wrong and in etherium actually very many transactions interact with the same state so this is just a plot essentially that CHS an adders space graph representation of the transactions in one etherium block so each of these vertices is a contract and all the edges are essentially called by transactions and the main important thing to see is that we have this big connected component in the Middle where there's a bunch of D5 things going on sort of the color dots there are a lot

of D5 things and essentially these uh transactions that are part of this connected component are a bit harder to paralyze because well in the component they are all somehow connected and we cannot just fully um execute them independent from each other but despite ethereum but but despite um these etherium transactions really having a lot of dependencies there is around a fourfold speed up that we could easily get to or that is realistic um yes and then the next question is sort of like is there anything else or is there anything other that we should be aware of uh when we move to parall execution okay so we know now that we

can get a full full speed up is there anything else we should be aware of and the thing I want to focus on is that if we move to paril execution we must also have a fee Market that can actually handle it so to understand why the current fee Market wouldn't suffice let's first look at it so a transaction fee on ethereum is essentially just the amount of gas units multiplied by the gas price so the price per unit of gas and then we get our total fee the gas units here at least the part of the gas units that I'm talking about is just a measure of the computational complexity essentially of a transaction there's some other parts but they're not relevant for execution

so I will just ignore them and essentially you can think of this execution component of gas as being axy for time so it's supposed to estimate the time it takes to execute this transaction and throughout we will simply assume it's equal to time and then our total fee so this is based on the gas price is essentially compromis of a base fee that being burned and a priority fees that actually goes to the minor but the focus for me or is largely just going to be these gas units so how should we calculate these gas units in a Feed Market where we want to be handling this parallel execution and before we get there I want to uh first again sort of highlight what

the problem is with the current mechanism so in terms of gas units that are consumed by a transaction um this is sort of where the problem lies so let us consider a sample transaction here which is transaction one it takes six units of time to execute and um it accesses six different resources so you can think of this as like storage keys in the smart contract for instance the state of a liquidity pool so the reserves in a liquidity pool and essentially for us in our model this is all we will want to know about the transaction the time it takes and the resource set that it accesses it's a bit of a simplication because for instance we're not differentiating

between reads and rides but for our purposes it's a quite good approximation of the real world and then we can also draw a transaction as a rectangle so on the y axis you see the time this takes six units of time and on the x-axis you see which resources are being accessed and thereby blocked by this transaction now the current mechanism when it decides how many gas units this transaction uses completely ignores the resources that are being access it just says okay the gas that this transaction consumes is equal to the time it takes at least for our model now and this is 6 seconds so this is six units of gas that this transaction will be

charged but we have a different transaction this is transaction two takes exactly the same time to execute but only blocks two resources or only accesses to resources the current mechanism will also charge this uh transaction six units of gas this is perfectly fine when we're only doing sequential execution because well we're executing one transaction after the other so we don't really care whether we can somehow paralyze but when we move to paral ex um execution there are some problems here because one of the transactions is blocking much more off where we cannot execute things in parallel on those resources while the other one is not and then sort of one natural

question to ask is so if we're moving to parallel execution now what are the properties we want from the gas component in a fee Market or sort of to ask it a bit differently what type of transaction should cost more than some other transaction so the first property is a very natural monotonicity property and it essentially um the one that we saw already so um we call this property resource sensitivity and all it demands is that we have one transaction that requires the resource set that is a super set of another transaction so it requires strictly more resources but sort of the same resources as well while taking the same amount of time then it

uh it should consume more gas so in our example here we have tx2 uh which takes only a subset of the resources of tx1 so we would want tx2 to consume less gas it is also quite intuitive to see why this property not holding is actually a problem because then I can just add some resources and not pay or not be penalized in terms of gas units or gas consumption for this then there's another very natural monotonicity property we want and this the current gas mechanism actually satisfies and that's time sensitivity so if we have two transactions and they use the exact same resource set as a transaction one and transaction two here but one takes longer than the other that

transaction should also cost more again this is a very intuitive property otherwise I can just add computation to my transaction will sort of increase the load on the network but will not be forced to pay for it so the next property is a bit more complicated and This concerns sets of transactions so the capital T here now denotes a set of transaction and we have the set T1 and the set T2 the and what you can see here is that the set T2 is sort of a subset of the set T1 so in t one we just have an extra transaction in there and what we then demand is which is also a monotonicity property but now sort of on

sets of transactions is that collectively the transaction set one which has sort of extra transaction in it should pay more in terms of gas units than the transaction set two um you can also again sort of think of an example why um there would be problems if this doesn't hold if it doesn't hold there must be a scenario where I can add a transaction to a set of transaction and not pay for it again I'm increasing load and not paying for it in terms of gas units so now the final property that I'm actually going to go through or that I'm going to outline here is what we call transaction bundling it's a bit more complex but look at the transaction one and the transaction two on the right side of the screen there is also

highlighted um sort of when a transaction is actually doing computation on what resource that is the darker colors and then on the left we have the sequ composition on the two transactions on the right so if we take the instructions from transaction one we append the instructions from transaction two we combine them into one bigger transaction that's where we get the transaction TX and then this property demands that tx1 should consume more gas units than the other two combined because again we one intuition is it's easier to schedule the two smaller transactions than the bigger composition of them but also you

can think of a scenario where otherwise users could come together collude append all their transactions into one big transaction they have some atomicity um guarantees that they wouldn't have otherwise take probably a lot of resources block a lot of Paralympics for gas consumption are cover we have some more that are a bit more complicated but they should give you a good insight into what kinds of things we want to hold and then sort of this is a fee Market the gas component isn't all of it what else do we actually want to hold and what I'm going to now is sort of more these are properties that have been

outlined already and the transaction fee mechanism properties and essentially what we want a transaction fee mechanism or a TFM to have is that it's incentive compatible for the users and the block producers so incentive compatibility just means that no one one party should be able to deviate from the intended protocol and increase their outcome by doing that we also wanted to have some good welfare guarantees and it to be proof against offchain agreements so this is agreements between uh users and a Blog producer where they can collude with each other and then increase the expected outcome so these are as I said very standard TFM properties we actually

know that it's not possible to achieve them all but still we have some tfms that get us at least to a decent State and yes so what I put forth until now is essentially just a wish list of properties that we want a fee Market to have that supports parallel execution and the next question is well what sort of fee Market can achieve this and essentially you can think of the total fee again as the gas units times the gas price and the way we then approach it is that we take a transaction we feed it into what we call a gas computation mechanism that outputs how many gas uses a gas units a transaction consumes then we feed that a long uh to a transaction

fee mechanism and finally we get the fee that this transaction is supposed to be paying so now the type of gas computation mechanism we envision um uh sort of what we were doing this is still a bit of preliminary work but uh what we think is that weighted area is actually a good candidate or what we call all weighted area so essentially the gas that a transaction consumes is the time it takes multiplied by the sum of the weights of resources it consumes and these weights so we have one weight per resource and it essentially approximates the demand that there is on this resource so for instance if you're using the most popular pool on etherium there

should be a higher way than will some pool that no one else is using that date uh on that same day and then for the transaction fee mechanism you can use whatever you want but for instance EIP 1559 could be a good candidate here and with that you have your fee Market that can support parallel execution um well I mentioned I think already this is sort of still work in progress we're still finalizing some things but we think sort of that this mechanism that I'm showing right now has many of the properties that we desire to support parallel execution and then to help scale sort of throughput on the execution layer that then unlocks this uh well processible widescale adoption

in defy and this is actually work that's supported by the ethereum foundation yes so essentially this is already what I said this is just some example where execution layer bottl next can then be a problem for the application layer but the main takeaway I want to wanted to bring across in this talk or the main message I want to convey is that essentially when we're working on one of these blockchain layers it's really important to also look at these others because these interactions they are there and often to improve on let's say something in the application layer maybe we have to go one or two layers deeper to then really be able to do it uh yes I'm finished thank you very much for your speech questions as

[Applause] usual yeah thank you for that that was um an incredibly good presentation um it was explained some very complicated things really well um just more generally so thank you for that two questions completely separate parts the first part of the talk you mentioned a specific interesting block did you ever kind of go back to that block and discern exactly kind of which transaction or which transactions were specifically the ones of interest um I do I did look back at it I don't know

all of it at the top of my head but I believe there were like 20 to 30 non-atomic arbitr swaps in there they were except for three of them they were all done by the same arbiture and that was the arbiture that was associated with the builder that won the auction okay um and you mentioned uh there was only one remaining hft Builder yeah who is that out of Interest Beaver buil okay and then in terms of the second part of the presentation what are the stepping stones in your mind to make uh that a reality and timelines for it potentially is it realistic um I think I've been hearing a

lot of talk that ethereum sort of wants to move back to actually doing something on the L1 Solana for instance at least has some parallel execution already but it doesn't have a fee Market that is suited for it it just uses essentially sort of the fee Market as if it were um executing things sequentially so I'm not entirely sure like what the timeline is at least for ifum it's difficult to estimate but maybe for some other blockchains that are already using paral executions but don't necessarily have a fee market for it yet maybe that's like a quicker timeline there thank you very much unfortunately we are running out of time I see we have lots of questions but I will welcome you just to come directly to the speaker and discuss with you I'm really sorry but we

are running out of schedule thank you very much thank you thanks a lot [Music]