Making Arbitrage Work

Transcript

Mhm. >> Mhm.

>> do rather than a minimization, you do a root search problem. You say f of a p vector equals zero. Um and then you find the price vector in the n minus one dimensional space that sets all these boundary conditions to zero. And then if these are all zero, this one whatever comes out there is going to be your arbitrage profit. Yeah? And so rather than having an m 2m variable um uh 2m variable uh convex optimization problem,

you now have an n minus one dimensional root finding problem, and you can solve it um with various things. Specifically, we are mostly solving it with gradient descent uh for reasons that I will explain in a moment. And so this is how I looked at a lot of those graphs. So these are yeah, x * y equal constant curves. These are two unlevered curves, so you go in the whole thing. This is a levered curve that only goes from here to here.

And this is where the current prices are. And after the algorithm, all the prices need to be on a straight line, because this is where you have no arbitrage except if this curve was here, yeah? Then you can't go to this marginal price. Then it would go as far as it can go. So it can either be an interior solution or a border solution. solution. And this is essentially Uh this is what we call the Radon problem. This is what makes the numerical conditioning of this thing so hard.

So let's quickly talk about convex optimi- convex optimization. So the problem that I want you to think about is you have any convex shape, and you can rotate this convex shape in space, and you want to find the highest point of this uh um of this uh shape. That's a convex optimization problem. And you can have two There There are two different things. In the theory, they're sort of oriented differently, but somehow chat GPT didn't quite do that.

So you can have polytopes. So polytopes are Well, you see what they are. They're defined as intersection of half spaces and finite volumes. So yeah, you kind of have these things. And so Platonic solids when they're symmetric, but they can be all kind of um asymmetric. But they either though they have edges, they have vertexes, and then they're flat. Or you can have differential shapes like, I don't know, this egg here. And they need two different algorithms.

On a differentiable shape, you can find the optimum with a gradient descent. So you just go along the derivative, and then you find uh where you go. On polytopes, gradient descent doesn't get you anywhere because the gradient is either not defined or it's going to go it's going to push you to infinity. But on the polytopes, you know that almost always, and I'm going to discuss this in a moment, always always you're going to be at a vertex, and almost always in the measure theoretic sense.

So what you do the that's called linear programming. You just jump along the vertices, and you identify the vertex that is the optimal solution. So slight problem. So um So the likelihood of finding a solution to this hate problem increases with convexity. The more convexity you have, the more directions you have per space, and the more likely it is that this is the highest point.

Now a vertex is an infinite convexity point. And so this is why in polytopes, all the mass the all the probability mass is at the vertex. So you know that is sort of and this is why you use linear programming because you know the optimal point is going to be at the vertex. Except that obviously assumes that you're using some continuous measure on your space of rotations. Sometimes you don't do that, yeah? Here you have what some people call a cube, but uh everyone else calls it a D6, and this is what a D11 or whatever.

Um If you say you have a D6 or a D11 on a flat surface, suddenly your measure is different. So here your measure is there is only six different directions. Here is only 11 or whatever. These are different directions. And then suddenly your probability your maximum point suddenly is a surface, yeah? Just the saying is you can depending how you constrain your your probability space, um the you can find another solution.

And the other thing is also when you have finite finite number of states in a computer, you always have a finite number of states. Depending how your problem is conditioned, even though you have a polytope, you may still have a non-corner solution. And now it gets even worse. And this is where we end up. So it's called the Radon problem. So if you think about the Well, we call it the Radon problem. Think about the Platonic solid, but then you put a balloon a Platonic solid grid, but you put a balloon on top of it. And then you blow a little bit of air in it.

And so that the the surfaces slightly [snorts] go outwards. So the whole thing is still convex, um but suddenly you don't have straight you you don't have straight surfaces anymore. So suddenly you have finite mass in the vertex, and you have finite mass in in any of the surfaces. So finite mass in terms of the probability of finding solution here. So you have you can have interior solutions or you can have border solutions depending on your nature of the problem.

What's even worse, you need to know where you are. When you when your solution is here, your gradient descent is going to work here, but if you start here, it's going to catapult you to infinity. Yeah? So when you're trying to do a standard convex solver on on a geometry that is like this, you first need to figure out which is the surface that I'm going to You could First you need to figure out is my solution going to be on a vertex? Is it going to be a corner solution? Or is it going to be in the middle of the the surface?

Then you need to figure out which surface is it on, and then you can do a gradient descent to find the exact point where you are. And so long story short, your standard solvers, they just completely crap out on this one. And you kind of you just get well, didn't converge. And this sucks. Um and so but now we understand why they don't do, and we don't have this problem with with our algorithm. But this is like using convex optimization because So I was going to say, we have this Why do we have this problem? And I think I may have a slide afterwards or not. I actually see that. Yeah, I I've actually okay, that's the what I just said. Yeah, see, the problem

is here is that on this curve here here it's at the corner solution. Now here we are still fine because we have two more curves that still make this whole thing an interior solution. But imagine something where you have a curve here and a curve here and a curve here. You have these price ranges here in the middle where um you can't have the marginal price. There's holes in the marginal price area. The holes in the marginal price area correspond to the vertex, yeah? So whenever your price is in a hole, you're going to have a corner solution.

And whenev- whenever your price is in the middle, you are on one of these surfaces. And as I say, a convex solver a normal convex solver can't deal with these problems very well. At least I couldn't make it work, and they don't have They They There's a few open source solvers, and then they're very expensive ones that you need to So anyway, so that was the first thing. Why? And I think the takeaway there is even if it's a convex problem, there's standard that solvers sometimes you need to be really careful in understanding why it doesn't converge, and other things might work a little bit better.

So here this is our claim to fame. Log scale, normal scale. Um That's marginal price. That's our method. And that's Clarabel, which is actually interesting. Clarabel is the latest solver that has been added to the CVS system. Um it's actually on this problem it performs much worse than ECOS and SCS, which are older solvers. So, for some reason the latest solver that they added on this problem is even worse than the older ones. But yeah, you see this in um you either see this it in log scale, even in log scale we are

two orders of magnitude better than than the standard solver in speed and consistently. Except and there sorry for the confusion with the colors, this and this is the same graph. So, before was number of curves. Now we do number of tokens. And there suddenly choo, that's us. We're getting even worse than Clarabel. What happened? So, that's the exercise.

This is how we do our price response function. So, this is the delta X as a function of P. >> [snorts] >> So, as every good programmer would do, oh the price response function is the sum of the price response function of the individual curves. Everything is linear. So, we just sum it up and our market looks like a single curve. Beautiful. Same interface. Very nice information technology.

And then on the Jacobian I just do a perturbation. Any ideas what the problem with this is? Any takers? Why does this crap out when I have a lot of tokens? Yeah, took us a moment to figure this out as well. The thing is that your when you have two tokens in a curve your Jacobian has four entries. Yeah? Um so, you may have 100 tokens. So, this was when we started getting really into problems. Yeah, here we're getting into 100 tokens.

You have a 100 by 100 matrix where everything is zero and four armed. Yeah? And when you calculate it the way we do here then it's a really expensive way to calculating 10,000 zeros at every time. Yeah, because you're calculating a number and then you multi- just subtracting the same number to get zero. And so, this is where it gone. So, what we then figured out nice commutative diagram, everyone likes those.

So, if you do the sum first and the Jacobian then that's what we were doing. It's the performance sucks. If you do the Jacobian first, smartly, yeah only on these four things, and then you sum it up smartly, you don't have this problem at all. So, it's like one of these interesting gotchas where you kind of you need to really run this thing and see what is a problem there because it's very obvious once you thought about it, but initially it's like, yeah look it's a smart thing to do. I can just put this in the nice nice interface and it's it's beautiful.

And here just to say not too long, but cal- so, that's the percentage of time that it spends in calculating the Jacobian. That's really the critical step in this algorithm. So, the gradient descent is not that bad, but sort of the calculating the Jacobian um is really um the worst one. So, finally convergence. We still have convergence issues. Um but and but we understand them and they're uh they're manageable.

So, the first thing is we're using a gradient descent. So, we cannot actually have anything with with vertices and edges. What does it mean? We can't have a constant price curve. Uh so, we can't have a curve where the thing is flat, which makes sense. Yeah, if you have a curve where you put $10 or $10,000 at a price of 100 by changing the price the volume your your price response function becomes a step function and you can't do this by changing the price. But this you can deal with relatively easily. You just normal- you just normalize a bit, you make your ranges a little bit wider and

you do need to run a fine-tuning afterwards anyway to get way level precision. So, essentially you just smooth your curve a little bit. You make rather than saying it's $10,000 at 100, you say it's $10,000 between 99.9 and 100.1. And the other thing is as I said, we need to start on the right face of the ray dome. Yeah? If you're on the wrong face, your gradient descent is is completely going to disappear. That for us is not such a hard problem because a good starting point is actually the current prices. Yeah, you kind of because markets are mostly arbitrage, you're not starting from a market that is completely out of whack.

You're starting from a market that is mostly arbitrage. So, if you have an estimate what the current prices are, this generally works pretty well. You're then on the right face of the ray dome most of the time. However, there are a number of places where things well, sometimes they converge well and sometimes they don't. So, here fine. Yeah, and I'm it's if you want to have a look at the paper it says sort of in the paper you have this gradient descent how it kind of yeah, it goes here then goes here and goes goes closer. This converges well.

This conver- this converge also well. This one doesn't converge and remember we're not trying to minimize, we're trying to find a root. So okay. Um but we don't need to we don't need to find a root here. Uh we can't have a root here and this is actually a real that's a real thing. Why? Uh there is no root and we can't find it and typically this is the case where there's not enough liquidity or no liquidity for the token that you've chosen. Yeah, if you can't you you want to trade out into Dogecoin and there's no Dogecoin liquidity then even if there arbitrages, you can't find a way to there and you get something like this.

Now, that is the harder problem where you can get in situations where your gradient descent here gets you here and then here it gets you back here and you just run into an infinite cycle. And this you just need to detect and you somehow need to deal with it. If we had it from time to time, but it's like we had this once every few weeks. So, it's kind of it sometimes happens um and it's just something it didn't happen often enough that we cared about massively.

Thank you. So, any questions? Yeah, happy to accept questions. Is Is Amit here? Do you want to come and set up your computer while um Yeah. Everyone flatten? Oh. Actually I have two questions, but maybe let me start with this one. So, how can it even be that on an N um curve or an N-shape N-dimensional cube you would have the solution not on an edge or a vertex. I can't think of why this would be the case. Well, if you

restrict the if you restrict the sometimes there there are things that restrict the configuration. You can't yeah, if you're if you if your rotation if you have the full rotation group and you put the measure of the full rotation group then obviously it's always a vertex. But if you say I have a dice and the dice you restrict it to six different configurations because you know the dice is flat on a surface, then your symmetry group gets smaller and then you have the measure yeah the the the the allowed locations on your on your measure on the rotations is different. And something so, sometimes you can have these your system can be constrained to certain configurations. The bigger problem, this

is not really a problem that we have that we face here. The bigger problem is that um things that should be measure zero in continue when you have real numbers sometimes aren't measure zero when you actually use computer approximations of real numbers. So, this can happen. Um but these are more theoretical problems here. So, here for the the the here we generally have if it's a real vertex then the mass is at the at the boundary um or close to the boundary because in any ways the boundary is yeah, a vertex is smeared anyway, smeared out. And when it's smeared out, the mass is also

smeared out a little bit. Okay, so and maybe just like to confirm my understanding. So, you mentioned that like all the solutions in the arbitrage scenario should be on one line, right? But I was actually expecting a statement that would say that all tangent lines would be parallel and for this solution is are those equivalent statements? >> Take care in the XY graph. Right. The constant price is a diagonal. It's not the tangent to the other constant price. So, you have like curves. You have multiple curves with different Yeah, you have K equal X times Y. So, if and the this direction is a volume.

Yeah. And but the price is X over Y equal constant. So, all these Yeah, on on the in the constant product, the price is always the X over um X over Y. So, the constant price curve on these things is Right. is the is a straight line through the origin. Right. Yeah, it's not a tangent. That's the uh But it's it In a general curve, it would be the tangent.

But for the K equal X times Y, because of this specific form, Right. it is true that it So, generally, you would say the tangent if it was generic curves, but we use K equal X times Y curves, the price is on a straight line. But you're right on non on other curves, so on the on some kind of curves that we're working uh now, it wouldn't be that. And on curve curves, for example, it wouldn't be on X equal Y if constant. But you would also have a the tangent would also be parallel in your case. The tangent Yeah, the tangent is always is always correct in the in the tangent, but it's obviously much harder to to see. Yeah. So, the tangent is it's a good point. The tangent would

always be uh uh be the same. And but you Well, we don't have the graph obviously anymore, but uh you would see that on this line, this is also where all the tangents line up on these particular curves. Right. Yeah, thank you. All right. Thank you. Okay. Uh while the uh AV systems committee is uh working on this, um Amit, would you like to uh present your >> researcher, strategist, have been uh yeah, have earlier led uh uh the cryptoeconomics and the uh the cryptoeconomics and the DeFi team

for Polygon. And then, you know, my interest is cryptoeconomics, mechanism design, financial system, and also how to make this coordination layer. Uh I think we are all set. Uh Yeah. Yeah, all right. Let's wait. So, once the screen comes up, hopefully very shortly, uh you're up. Um I'll just start maybe uh the background of Yeah, it's it's up there.

Oh perfect. Okay. So, one of the paper which I'm presenting talks about how to stabilize the staking rate, why it is super important. Um Because uh um if you see uh any cryptocurrency prices, and the first thing which uh um anyone, not even in the crypto domain, tells like it's volatile. It's it's volatile up to that extent that people are scared to trade on it. We know that. And uh one of the people have presented various reasons why it is volatile, but one of the strong correlation of the volatility with the prices of the cryptocurrencies around its staking

rate. And the idea is that like uh as the staking rate goes up and down, uh the prices becomes more volatile. And the fundamentally, if you say think of it as an uh the design what uh cryptocurrency, and especially proof-of-stake chains, has brought in that like inherently, it induces the oscillations in the uh staking rate, and that travels to the cryptocurrency prices. And that's that's one of the base foundational thing. Like you could think of it like that's an external motivation to start this project. Uh and that's what it talks. So, you know, the staking rate needs to be combined to the optimal

level, because that's what's the how the cryptoeconomics work. Everybody wants uh the the staking rate to be at an optimal level. But how do the how do we design it? The design is typically follow the standard process in which there is some curve around inflationary regime, and it increases the yield kind of increases when the staking rate is below target, and it decreasing the yield when the staking rate is above the target. That's a standard design for most of the proof-of-stake chains. Um The problem with here is this. One of the bigger problem is that that it's volatile. Why it is volatile? Because economic literature has identified that

all of this is financial dynamics related to some reactivity. There are like stakers who maintain the staking rate according to some external yield properties, and also there is decisional lags. Like one of the biggest decisional lags in cryptocurrency staking is that validators needs to stake unstake due to some external factors. And by default, if you look at the um the the chain design or the economics design of it, you'll see that uh it does have some kind of a delayed withdrawal period. Most of them has like you And that if you add this up, this increases the volatility. And the key finding to our uh research uh is

that like there is if there is an high sensitivity to the yield, and if there is inherent delay in the staking rate, uh delay in the staking rate or the decision-making that can generate uh um inherent oscillation. What we propose here is uh a mechanism uh which we call stability corridor, and try to prove using simulations and some um uh mathematical uh linearity nonlinearity around the system is that it's it's better than the current design. So, that's where um you know, the motivations or the problem statement come. I I would like this is like external looking, but the most uh you know, the why we started this

project because when um I started uh my own project Paliora, which is actually uh multiparty uh compute nodes are there where you can monetize the data confidentially and securely. That's a different kind of a system. Think of it like it's something uh different than Ethereum, which has this definitive validator framework, which has consensus. It has this arbitrary node. So, when we were doing this, we uh when we ran the simulations on our own design, the oscillations were like around 10 to 20 times. So, that's where you know, where the number of parties increases exponentially, and their interactions with the economic system uh system increases exponentially, this

makes the system more volatile. So, I'll start with uh some of the naive uh cases or some of the uh examples where uh you know, uh we'll see what the curve characteristics are. Then we'll talk about like what are the changes around that. Like it's like one of the example is Polkadot like reward. Many people are familiar with that. It's uh it's a it's a it's an example of dynamic reward mechanism. Um and where there is a piecewise piecewise inflationary function. And one of the one of the key one of the key characteristics of this is like people want to stabilize staking rate at some target level. In this case, one of the

example like that's an uh white paper example. Generally, governance move it here and there. It's around 50%, and there is some annual inflation rate which in our simulations and our design we set up to 0.03. Um there is something of a curve where it reaches some inflation and it goes dynamically down. There is a decay parameter. Um The the equation looks like uh this, but the most important part here, if you will see, uh is that uh it increases up to certain point, and that's what the max inflation, and then it decreases exponentially. Uh it follows the same design, right? The where we uh say that

uh if the inflation rate is below some target, we need to incentivize people, and it depends upon us how uh vastly the economic system incentivizes, maybe linearly nonlinearly, but there is a progressively stronger uh incentive to stake. And on the other side, if we fall onto the other side, there is a disincentivization created. Um now, um Polkadot created the disincentivization in a more exponential decay format. Uh we'll see uh you know, the next curve, Ethereum. We'll see it it follows a different methodology. Um but the idea remains same.

Uh I'll I'll just go through the chart. The first chart, actually, if you see in here, uh the Polkadot like inflation, this is what I was talking about. Like it's it goes it increases linearly linearly the inflation, and then there's this an exponential decay, and this follows the staking rate uh some staking rate equation where there's a kink around the system. Uh the another interesting um the constant inflation, this is exactly what how Ethereum has modeled the proof-of-stake dynamics. You'll see it's nearly constant inflation with uh uh inflation yield uh follows some kind of a follow some kind of a curve. I'm I'm I'm sure you would have followed the big discussions around moving this curve

here and there because the yields of in pretty low sometimes, but that's that's actually a different discussion. But the first one is the Polkadot and second one is like generic rather than closing into Ethereum. It's like a very generic curve. >> [clears throat] >> So we talk now we try to this is just an example which I wanted to show in the simulation. We can run many you know variations of this the stability corridor. It's just a way to mathematically and simulation wise show that this has better fundamentals. So

the idea behind this is to create instead of that sharp kink around the stable around the inflation curve. The idea is to have a stable corridor. That means the stability corridor. So if you see the curve is designed in such a way I'll go through you know how like the sample design and then we can you know talk about the variations and various executions which we can do. But the target staking rate is defined if you see on that around kink bit of a 40 to 60% a regime is created in the staking rate and the inverse inflationary curve is calculated so that it follows this

stability regime and the characteristics are made in such a way that it somehow resembles the curve the Polkadot like curve which we have shown. We can as I can say we can have multiple variations, but the idea is to create this inverse mapping where the staking rate remains flat and the inflation is matched according to that. Maybe it's algorithmically, maybe it's through the governance, but we'll see like you know our objective is to show that you know how does the oscillations behave around this point. So yeah, so this is one of the schematic as I said changing it the stability corridor around 40 to 60 trying to keep the inflationary regime

as 3% and 10%. And then making the curve like this. >> [clears throat] >> Now I'll just show you the schematic of what the model inherent model is. The paper is online. We I presented it recently at financial cryptography conference. So you know the manuscript is online. It would be there on the Springer series as well, but the intuition of the model is very important like you know how [snorts] we do it. Some of the artifacts right now if you see there are changeable. For example, one thing which staker can

decide to increase or decrease the staking according to target yield parameter. I kept it very high 16.6. It's an arbitrary number right now with our match matches the our curve. We can do anything. There is also a representation of sensitivity like how the mean staker mean staker deviates if the yield deviates. This the fundamental beta can also be related to this financial like how much of your sensitivity towards any beta of the market. You are multi multi-dimensional portfolio. You don't only invest in cryptocurrencies. You

have multiple other things going around. So this is the sensitivity around that. It's taken from the system as a parameter because we are not designing the whole portfolio management side of it. Though that would be very interesting as a market wide phenomena. So and the other thing in the model which is taken which is very important is that kind of a 7-day delay. And this is what when I started as a motivation that that in most of the proof-of-stake chains there is you cannot withdraw your you know staked amount immediately.

There is something inherent decision lag which is enforced in the system. We took a 7 days delay to model the parameters in the equation. It's an empirical observation of nearly all the proof-of-stake system. We can change it. The more severe it becomes like you know the 10-day 30-day withdrawal time the more severe sometimes the oscillations are, but it does have a great sensitivity around that. The idea is that the critical idea is that if if you want to have a change your staking rate you need to follow some of the sensitivities. That's a parameter

beta B which we are saying and also you have to follow the change staking rate according to your T minus one time period, right? And then adjust it according to the mean staking rate of your withdrawal time which is like 7 days average which we have taken. And this this is what will be able to change your target staking rate. Then it's it's again like this is a this is a time series equation which is being modeled. The important part is like you know the reduced form third equation which I was just telling you the staking you know is clamped around the valid range n minus one and n minus seven is

what just has explained. It's an 7-day withdrawal kind of decision parameters and then there is a sensitivity around that. The The important again one of the critical part here is that this equation is endogenous. If you look at yield at day n minus seven which is my decision factor, it itself is dependent on inflation distribution curve because that is fixed by the protocol, right? So this is very endogenous equation and this and this equation is what gives you that fundamental volatility. And this is what we wanted to show under simulation. And

these are like one snap of the result which I can go one by one. The The The first I'll just go through how to read the charts. The blue line and the red line represents the staking rate and APY. And the way to read this charts are the traffic light kind of a signal. The red in this chart means like people are moving towards using the staking rate. The The yellow is maintain and the green is increase.

These three charts represent one is the Polkadot like inflation we chatted. The last one is constant inflation we chatted about Ethereum like and the stability corridor design is what we are you know saying that it's a little bit better. The first chart as you can clearly see it's really bad. It's really bad in the terms of the inherent oscillations. The inherent volatility is induced around. The intuition is very same. There is a arbitrary kink around some stability rate and it makes the system unstable for a longer longer point of time.

Anyone who follows that kind of inflationary regime is bound to have oscillations that goes days and days out like it doesn't stop like it's very unstable system. If you see the staking rate it just oscillates and also in the background there is this you know the corridors which we are talking about the green and the red. There's a lot of fluctuation. You can't see but as you can see right you know there is some red and the yellow. So which is like a constant flip flop happening because at one point of time you like you really the your margin of errors are really very bad because you're operating around the kink sometimes sometimes.

>> [snorts] >> And on the last we think the constant inflation curve is you know would be way way way better, but it's not the case. It's not the case because if you look at the stability around first 45 days of simulation it's not as it's not it's not absolutely what you sought perfect. It does is it is better than the first benchmark case in the constant inflationary part, but it's not it's not so good. And this is like a clear artifact also inherent volatility which we see in this proof-of-stake chains

where there is a constant inflation and the decay staking rate is found under that. So you can see the red reds of it's it does it stabilizes after 90 days, but it's not perfect. The one the benchmark the our proposed idea of being in stability corridor is is better. It's better in the sense it does stabilizes and this has very less oscillations. One thing which I wanted to tell you about this chart is that this is a single shot simulation done. In an real economy we

will have these multiple uh snapshots coming at a play. The reason is that the reason is that because imagine you are having a fluctuation right now, but also the future fluctuation also impacts the uh you know, the fluctuations of the back end. Remember the B parameter and those are sensitivity parameter, those are time independent, but in in real uh sense, they are also time dependent. So, the more uh you know, the the the to give an example, the first chart the more oscillations you have, the worst sensitivity it belongs to the last chart. So, it's it's it's also uh I was trying just I was trying to say that this is like, you know, the base good

case. The worst case can be uh you know, uh way way way bad than this uh because of this sensitivity around the time dependent sensitivity can increase. Um >> [clears throat] >> So, uh one of the empirical uh exercise which is very standard in the literature around these things that are all trying to find the stability near the equilibrium. Uh when we say the equilibrium like that's a target yield right now. Um and how does those oscillation emerge around the local area? So, trying to find the local stability around that and what does this the uh directly correlates with the parameters?

Um So it's it's a standard procedure in the literature where you linearize and where you have uh some equilibrium conditions. We do have like, you know, the the arbitrary target yield 16.6. We can linearize it around that point and then uh you know, we can have uh an expansion first order degree and then we bunch of uh you know, uh the the cosines and other functions. You create the you try to back trace the stability regime around that local area using what parameters are uh you know, what are the ranges of that parameter which enforces that stability. Um So,

one of the parameter which you are interested which is a time invariant, that is the B remember the sensitivity parameter. We wanted to see that how broader the range of those parameters can be. So, to put that as into the more uh you know, stable equilibria. Um So, for the constant inflation model and uh the parameter ranges around 0 to 1.4, which is quite good. But, if you see uh the other benchmark, it's like literally 0 to .2. Uh it's it's the So, what does it show that even the stability corridor which we are proposing, the range of stable the range of B parameter increases. So, you have

larger degrees of freedom to play around that. It's it's it's the biggest what we find according to you know, some of the average simulations which we did. Uh but, it's way way way better than one of the Polkadot style benchmark, but it is even better than the constant inflationary regimes. Yeah. Uh the linearization, I think uh these are the uh methodology which we adopted which is uh uh how to how to show you this B ranges.

Um it's it's as I as I told you earlier, it works around the Taylor expansion and the linear difference equation. Uh the methodology works like the polynomial and exponential uh and again, uh it does have uh the characteristics which you can solve around local stability module. The it's a unit circle approach where you can have some kind of uh stability around the net parameters and then the you need to back trace the equilibrium equilibrium point in our previous equation, that is equation number two, I think which you saw which talks about the time series around that.

So, you get that uh the parameter dependence on the inflationary curve. So, it's a broader methodology which I wanted to show that so that where the numbers these numbers are coming to. Um Uh I'll I'll just try to uh conclude. Uh so, the conclusion here is uh that sensitivity uh of the of the yield together with this delayed reactions which we you can model it as validator reaction or any other arbitrary reaction, they are enough to create the oscillations in the in our system. This proof of stake kind of inflationary regime system. Um This we have done in this paper some

qualitative analysis which does show that it they are uh you know, the source is this and we can do little bit better in terms of uh not little bit actually way better in creating the stability corridor. It all depends on us like, you know, how dynamically we want to enforce stability corridors in the system. Um but uh is there like, you know, something needs to be done to uh uh maintain the staking rate as well as maintain the induced oscillation. That's what you know, the study talks about. There are certain future work which uh we plan to do and if happy to you know, take more uh suggestions and contributions if people are interested.

Uh it's a single agent model. By single agent, I mean uh on the staking the behavior of a stakers, they are one behavior only. They do according to the equation, but we know in the real world, there are multiple types of stakers like home stakers what we call it, institutional stakers. They all take care into different regimes of their sensitivity. So, the multi-agent model can uh make uh uh this uh our research more stronger in the sense and more validated across the multiple behaviors. So, that's what we are planning to do and also there is one synchronization uh phenomena which can play an important role. Um

we we deliberately excluded that uh because uh then um it just expands it to the different uh line of research, but that's also very important which uh we want to uh propose. And the next thing um you know, uh which uh which we have not written, but it's there in the paper. We are implementing this in the Paleora system uh which we are doing and uh so, we we are running a a testnet in which we are seeing better results and we are hoping that in the mainnet when more nodes join as a compute artifact doing confidential computation, it would be the our system would be much more stable. So, we will have like a real results as well in few

months of time. Uh thank you so much. Alejandro, if you hear you, welcome to come and set up your computer. Um Stefan. Yeah, so I have a question. Um Is this like the beer game or is this a different thing? Have you heard of the beer game? Uh the It's like the beer like beer as in drink beer. It's a very famous experiment where you every MBA class does it. So, you have like a chain of people who So, you have like the orders coming in through at the beginning and then every chain needs to every every block in the

chain needs to order for the for like one day ahead or whatever. Mhm. And this always blows up as well. It's kind of that that gets like infinite oscillations. If you play this, it's like over there always plays an MBA class and there's infinite oscillations. And I don't quite remember what it is, but the solution mathematically is that effectively you look at the matrix and the matrix has an eigenvalue bigger than one and so then exponentially uh disappears. And it looks like this delay plus delay plus correction is essentially exactly what makes the beer game explode. And I wonder whether this is something that you looked at and whether it's the same mechanism or it's a similar similar Uh

thank you for explaining the beer game. I didn't know about it, but uh I I have uh you know, some of the feedbacks from the market microstructure side in the order book uh phenomena. We know that uh you know, in the fast order book uh the market participants, especially the makers, actually adjust towards the prices and uh they adjust the volumes as well. So, there are certain exchanges which uh allow you uh very big block of volumes in intermittent, right? And when there is a little bit of a shock in the market, little bit panic in the market, the research shows that these kind of exchanges blow up

uh very early on than the C lob uh you know, the slicing dicing people. So, yes, it do correlates with that kind of that kind of an oscillation behavior which is unstable and it which is infinite regime. So, the solution of that problem which they found in the traditional finance is that you have a circuit breaker. I just stop it right there, right? And let everyone start from day zero. Um the solution that solution is not applicable uh not at all applicable in block proof of stake blockchain. You can't say like, you know, pause the chain, let's start from day zero. But, yeah, thanks thanks for the I think that.

I have one question. The for the Polkadot for the Polkadot staking regime, um there was a a sort of piecewise definition, right, for how that staking curve looked like for your stable corridor one as well, I think, right? Was this also piecewise but then sort of linear at the end or is that a continuous curve? Um >> [clears throat] >> Yeah, yeah, yeah. So, so to answer, it's a two-part answer actually. Let me So, we chose that a sample showing off that you know, trying to maintain as much closer to the Polkadot, but trying to enforce the stability corridor around some mean staking rate so that you know, our solution does not look

drastically different, right? The other part is that you can enforce microstability corridor in any piecewise linear or non-linear inflationary regimes, right? And like for example, in the constant inflation rate of Ethereum-like properties, you can have some kind of stability corridor around your targeted mean staking rate. And I think at one point of time the community was also discussing something around that like I think 6 to 8 months before that.

And they never discussed it about this having the less volatility over the ecosystem, but that would have been the first order effect apart from having the higher yield forced higher yield. Better answers, thanks. Right. Please thank me in thanking him, everyone. Okay, next to the stage is Alejandro Rocholl Pedroza who works at the Say Lab, if you like. All right, hello. Let me test out a little bit of the audience. Who's familiar here with So, who thinks here that transactions in Ethereum are private?

Raise your hand. Okay, who thinks that transactions are not private? Okay, good. Who's familiar with inclusion list or like fossil in Ethereum? Okay, braids, multi-proposer designs? Yeah, more or less? Okay. Okay. Well, I'll I'll take it slowly. Okay, so um first let me explain what multi-concurrent proposers are. Um and let me explain it with two different um consensus protocols. Who's not familiar with consensus protocols? Or what is consensus? Okay. So, yeah, for those of you who are not familiar, consensus protocols are at the core of uh blockchain designs.

They're what decide the ordering of transactions. And um I'm going to argue that single leader, which are the typical traditional consensus protocols uh for BFT chains, give too much power of ordering to the leader. So, what we have here at the bottom an example of a leader design leader-based design. So, we have the leader in this case process zero, proposer zero, proposing a value and then there's two rounds of voting and the value is decided, right? Um at the top we have an example of a multi-concurrent proposer design uh where we have four different proposers, each proposing a different value and then there's some consensus protocol that decides some of them to be included in some particular order and some of them not to be included. So, there's no single leader that controls ordering of the transactions. And this

is a very popular design at the moment. MCP chains, there's Sui, there's Aptos, there's Hedera. Now Solana's latest consensus proposal from last week. So, the upgrade to F and O is also based on MCP. With Ethereum, as I said, we have fossil, which is kind of a step in that direction. We have braids, which is explicit multi-concurrent proposer uh design for Ethereum. And the reason is because it provides uh censorship resistance. And for some definition of privacy, it could provide I would not not privacy, but it can provide uh MEV protection. I'm going to argue, however, Okay, who thinks that multi-concurrent proposers like is said typically by the Solana guys, by the Aptos guys, etc., is a solution for MEV protection or for censorship again like for to provide

censorship resistance. Who thinks that is enough? Okay, good. Um so, yeah, I agree with you guys. I don't think it's enough. Um and the reason is uh because of this three-way trade-off. So, if I'm a user and I want my transaction to be included and not get censored, um um what I can do is if I have a multi-concurrent proposer design, I send the transaction to one proposer at a time, right? Um and that gives me the guarantee that I'm not going to pay for the transaction more than once. And if the proposer doesn't include it in this lot, then in the next lot I try a different proposer, right? This is something that you can already do in Ethereum because we you have rotating leaders.

If um I want to exploit some low latency opportunity, I don't know, I see some arbitrage opportunity and it's either now or never, I can send the transaction and if it doesn't get included, then you know, I don't try anymore because that opportunity is gone, but then I don't get censorship resistance, right? I get low latency, but I don't get censorship resistance. And if I want both, then because it's a multi-concurrent proposer design, then I send the transaction to all the proposers and then I'm guaranteed that I unless all of them are trying to censor me, as long as one is not trying to censor me, I can include the transaction. But somebody has to pay for that because that transaction is going to If I want censorship resistance against F proposers, then I need to send the transaction to F plus one proposers, which means that somebody has to pay F

plus one times the price of including that transaction. And there's two different designs. On one side we we have um the Sui guys for example like in production, we have the Sui guys, the Aptos guys or Filecoin, which Filecoin is also a an MCP chain, where the cost of including that transaction is absorbed by the system, is subsidized by the system. So, effectively what means is that the user is only charged once, but he can include the transaction a hundred times, for example, which means that the good put, you know, if the throughput of the system is a thousand transactions per second, then it reduces to a good put, a useful throughput of ten transactions per second.

And then on the other side in production, we have Hedera that says, "Hey, you know, we provide this multi-concurrent proposer design. You can use it to to you know, leverage censorship resistance, but you're going to pay for it." And so, if a user wants to get censorship resistance against 99 proposers, he's going to have to pay for the transaction a hundred times. So, yeah, it's censorship resistance, but it's not really affordable, is it? Um also, I know that the way the reason why this is To answer the original question I did is Ethereum or are these chains censorship resistant? It actually depends, right? It depends on your assumptions of the adversary and whatnot. We are seeing in Ethereum big MEV being being extracted, you know, from users. So, it is an obvious answer that is not really that censorship

resistant or MEV protected. Um in these chains, the way this is actually alleviated is with a trusted RPC, right? So, it's the RPC the one that um selects which proposer to send the transaction to and for how many duplicates. And that's why, you know, we're not seeing an attack vector in which the good put is reduced by a hundred X in these chains. But that is trusted. And so, in a way I see the evolution of providing censorship resistance in blockchains in these steps. So, first we have the traditional step of leader-based consensus.

From there we some people in the space argued we can do better with MCP providing censorship resistance. And we could say the the Sui apps and Filecoin guys are there. Then the Hedera guys realized, "Oh, this is an attack vector. If we really do If we really want to do this in a trustless way, we need to charge users for this." And then finally, um realizing that this is too high a cost for users to pay and try to alleviate this cost. And this is the work that I'm going to be presenting that I I'm doing I'm doing at Say.

Um although actually it was uh Say with some collaborators researchers from Sui. And so, here's the solution. It's very simple. Um the traditional way, as I said, of getting censorship resistant benefits from a user would be to just replicate the transaction and send it to different proposers. And then as long as one of them proposes it to be included in the blockchain, we're good. Um which that means is to get a lead to get a censorship resistance that is that protects you against a linear number of proposers, you need to pay a linear number of fees.

Um and the good put of the system is reduced linearly as well. What we propose is sharding. So, the transaction is sharded into smaller chunks, smaller pieces, sent to different proposers such that as long as enough of these proposers include their chunks, you can reconstruct the transaction. And so, as a result you get the same or like um to you get the same tolerance in the linear number of proposers uh for censorship resistance, but you pay a constant cost. And you also get constant fraction of the throughput in good put. So, it's a strict improvement in these terms. So, um I have a presentation on Thursday about how this protocol works in particular and the Byzantine fault tolerance on the protocol, etc.

Um I'm going to just kind of like skip through that now to get into the economics. So, how What is the MEV cost? The the MEV protection cost using Sedona using the solution that of sharding. So, for that let's first define the problem and apply the protocol in a naive way. So, we have here a number of proposers, a user that is sharding his transactions and sending it to different proposers such that if enough of them include the chunks, we reconstruct the transaction. Um now, what the user what the attacker can do is, you know, we have a coalition, a cartel of a number of proposers that is going to try to reconstruct the transaction with the chunks privately

before it's on chain in order to exploit MEV. Cuz they if they just get some chunks, they cannot really know the content of the transaction. Um so, instead of sharing the and then they can decide also to censor or not to not share the chunks. So, for example, here one of the members of the cartel of the coalition decides not to include their chunk. But because uh there were more chunks than needed, the transaction is still reconstructed. This is what we call a slack of one. So, one chunk can be not included and still the transaction can be reconstructed.

What about two? So, now with two, the number of chunks that have been included on chain is not enough to reconstruct the transaction. So, at that point censorship has occurred. And also the cartel can privately share the chunks as I said and reconstruct the transaction on their end and they get one extra slot where they can you know basically extract MEV from this transaction. And here we analyze also two different risk that can occur with set now. Or like that not that are not fully solved by set now. By this charging solution. One is the multi slot one which is the one that I've shown. The transaction gets censored and so you need one more slot of consensus one more round of consensus in order to include the transaction. The other one is the within slot delay. So

even if the transaction is going to make it on chain in that same slot if the cartel if the coalition is very well connected they might still manage to get the chunks first reconstruct it on time and wait for that and then once they have reconstructed the transaction make their own proposal knowing the content of the transaction to try and still front run that transaction. So we analyze the two of them. The first thing that we notice is this very interesting kind of like inverse sawtooth where so the user has a lot of parameters that he can tweak to its benefit, you know? It's a user facing protocol. The user can decide how many chunks to split transaction into to how many lanes to share to how many proposers to send

chunks. How many chunks per proposer etc. What we see is the important parameter is what I was calling the slack, right? The slack is how many extra chunks the user can tolerate to to to not be included and still reconstruct the transaction. So the interesting bit is that as the slack so in this case we have 100 proposers the user is going to choose 20 of them at random per round of consensus. And we assume the cartel the coalition is also controlling 20 lanes some of the 100 20 of the 100.

And here the bottom the x-axis the decode threshold. So how many chunks are needed to reconstruct the transaction. So one thing that is interesting is here before I was explaining in the case of one round. But you can actually the user could actually and it's actually beneficial for the user to split the transaction across rounds. So basically to require more chunks that that that he sends in one round. But we see here is like kind of like a frequent pattern that repeats over the over the slack. So over basically the number of chunks needed for the construction modulus the the number of lanes that are contacted.

And what is interesting is here Q micro is the probability of the attackers managing to get enough chunks to reconstruct the transaction within one slot before it's included even if censorship doesn't happen. And for this one as the decode threshold gets closer so as the decode threshold gets closer to a slack of zero actually the probability decreases. Whereas for the multi slot delay happens the opposite. The higher the slack the harder it is for the attackers to to delay the transaction by one slot because for example if the slack is 19 and I send

that means that I send a transaction to 19 extra proposers in this slot. So I can afford 19 of them to censor. If one includes it. So it's really hard to delay one multiple slot. But that also means that that I only need one extra chunk to reconstruct the transaction. So it's a lot easier if that extra chunk one of the those 20 belongs to the coalition it's very easy for them to reconstruct the transaction quickly. So it's kind of like an inverse sawtooth. But this is the stronger approach. So what kind of what kind of stuff can we do from the user facing protocol in order to protect more the user. The first one is what we call the ratchet strategy. A ratchet for those of you who are not native in English like me is a tool that you can go like a screw in one direction

but then you cannot really go in the direction contrary.