The Precision and Accuracy of Carbon DeFi's Fixed-Point Arithmetic by @MBRichardson87

Transcript

so uh I think it's always a challenge with um  one of these eth volunteer conferences because you get a very mixed group of people some who are  uh much more technical much more smart contract focused and then others who are here maybe um  for their own curiosity maybe they're more from a scholarship sort of angle and so I try to cost  a relatively wide net with this presentation so if you find your glazing over during some of  it just wait a couple of slides and I'm sure that we'll find something that pequs your interest  um I'm also trying to keep this relatively brief obviously this is a huge topic and it's something  that I could spend many hours uh speaking on and so to condense it down into something that's  kind of manageable and a 15-minute time slot means we're going to skip over some of the details  I think necessarily um but if you are interested

in exploring some of those details with me more  thoroughly uh please feel free to um contact me either via the uh contact information that I'll  have at the end of the presentation um or uh Come and catch me at the booth um which is this  one just down the hallway here so um carbon defi belongs to what is now a growing family of what  we kind of call concentrated liquidity protocols and so this started with uh bankor V2 back in 2020  and this was essentially the construction that we had at that time now the formulas that described  this particular transformation are very different to the ones that we look at today um but it has  a very sort of strong geometric uh purpose that was kind of relevant to the way that that protocol  was implemented and used and so this is a really

interesting uh I think concept especially  because it's kind of On The Fringe you'll find that people even very strong defi enthusiasts  have this uh perspective that there is only one concentrated liquidity implementation and that's  the one that should be used but actually every concentrated liquidity implementation should be  specific for the system that it represents and so reparameterizing these equations is actually  a very sensible way to get more oomph um out of them um especially when it comes to things like  gas consumption but also smart contract security so this was actually where concentrated liquidity  began um but of course it's moved on since there this was popularized about a year later by Unis  swap V3 and they parameterized their curves very differently um and so their equations actually  look like this and I'm sure people that have

been around the the field for a little while  have seen these types of equations now what should be noted is that these equations actually  refer to the same underlying mathematical object they are one and the same thing and what you will  see is that as I move through some of these slide transitions that the colors change and the algebra  changes but the actual shape of the curve and its position doesn't change at all and that's not a  mistake so this again is some of the algebra um associated with the the uni swap B3 curves and and  then shifting now into um the present uh present tense um this is carbon defi parameterization  um and its formulas look like this right again something that looks completely alien and that's a  bit surprising considering that it actually refers

to exactly the same mathematical object now these  parameterizations are chosen with very deliberate and very specific knowledge of the system that  we're trying to implement right so to try and shoehorn something like carbon Defi and all of the  features that it has into what either the bankor V2 or the Unis swap V3 parameterization would have  been a mistake because it means that there's a an enormous computational overhead that can actually  be avoided if you just choose better variables to parameterize that curve and that is essentially  what we've done with carbon Defi and I call this kind of the the third prong or at least the  third major prong of the concentrated liquidity landscape but I should say that these aren't the  only three examples there are um many others that

um have reparameterized these curves as well um  I'm speaking obviously from a biased perspective you know I work for bankor and Unis swap V3 is the  market leader um but that's not to say that that is inclusive and I'm not trying to be exhaustive  so please don't feel like I'm you know leaving anyone out on purpose so the full system obviously  cannot really be described with just a handful of equations but these are the most important ones  the real invariant equation is obviously the one that people pay atten pention to the most the  marginal price equation is kind of the one that you would use for an onchain oracle or something  of that sort and then of course we've got the swap equations either how much can I get for giving  this amount or how much um do I have to give to receive a certain amount those are the the two  different swap equations now before we get further

into this I think it's worth at least looking at  what some of these parameters represent because you haven't seen them before unless you've kind of  read through the the white papers so these a and constants the lowercase ones are actually just  different parameterizations of the square roots of the uh high and low price bounds that you  would have seen on the Unis swap V3 equations anyway so this is not a significant re-education  um but what might be a little bit unusual is this Zed term and I actually fought with one of our uh  smart contract Engineers about how to name this he comes from like a a very Stout C++ programming  background where all variables have to have a single letter um and I want to name this as y int  because it actually represents the Y intercept and you can see that up here it's where the curve  actually strikes the Y AIS um but I lost that

battle and we ended up naming it Zed but so what  the other two um variables in these equations are obviously X and Y and you might think you know  what these are and you're probably right um because they do refer to the Y and X AIS um but  in carbon def's case only one of these uh axes refers to a token B balance so in general when  you see amm and concentrated liquidity curves both of these axes refer to token balances in and  of themselves but what you're looking at when you look at the familiar bonding curve here in carbon  def case is actually the integrated form of the underlying price equation so this is not a bonding  curve like you've seen before to my knowledge we're the first to actually take this uh approach  and it's nice because it means that we get to

separate uh bonding curves into like their atomist  so rather than having like a single bonding curve that describes any number of tokens instead  carbon Dei bonding curves describe only one token and that means you can compose them as many  ways as you want and and uh achieve a very wide uh variety of different features so the short version  here is that the A and B terms refer to rate parameters so prices and Y and Z refer to token  amounts and the question I wanted to ask is like what is a reasonable range to support CU one of  the things that we wanted to do with carbon defi was to remove the restrictions that in general  are imposed on users when they arrive in defi exchanges for the first time so for example things  like tick ranges we said that carbon defi should

have no ticks right things like fee levels we said  that every single user should be able to choose their own fee level right it's not something  that's prescribed by the protocol but something that the user tells the protocol that it should  do and so what are we really sort of getting into like how big of a challenge is this and it  turns out it's a pretty big challenge um and it's because of tokens like this when you're building a  DEX um you have to be able to accommodate all the different kinds of erc20 combinations that users  might want to trade with so for example shibba enu which is a relatively worthless and I'm not saying  that because I think it's a bad token I just mean that its per token value is very very small um  versus something like wbtc which is in extremely

precious token has a very high dollar value and  so when you're comparing these tokens versus each other you have to ask like can we support that  rate because Sheba Eno versus wbtc has um has nine uh leading zeros before you end up with the first  significant number but that's on a per token basis so this again if you actually expand it out into  its decimal representation looks every bit as um as uh ludicrous and you'll actually note that if  we take this naively you actually can't even offer that rate even if you wanted to because Bitcoin  doesn't divide that far right Bitcoin only has eight decimal places of precision and so if you're  trying to offer an exchange rate beyond that then

exchanging one token for the other at that rate  is actually impossible not because the exchange is bad but because Bitcoin doesn't have enough  decimal places to support it now I said that this is the naive situation because it's actually a  lot worse than that because while Bitcoin is an 8 decimal token Sheba Eno is an 18 decimal token so  we need to actually compare these on a per token way basis what is their least divisible component  um and the reason we need to do that is because the smart contracts don't know the difference  between a whole token and one token way at the end of the day we're just dealing with bits right  in smart contracts and so we really should be thinking of one wrapped Bitcoin is actually 10 to  the 8 Bitcoin and one sheu is 10 to the 18 sheu one eth is 10 to the 18 e and so on and so forth  so this actually changes the exchange rate from

absurd to I I don't even know what you would call  that this is so vanishingly small that it starts to lose meaning so on a token per token basis we  have nine leading zeros and on a way per way basis we have 19 leading zeros so let's call this like  one of the extremes sure we can find some mem coin something that's less valuable than sha ener  and maybe some other meme on the other side of the Spectrum which has less decimal places or  something but I'd say that this is kind of at the margin of what we would expect reasonable us  of behavior to be now appreciate that when you're building an exchange you also need to support  the opposite exchange rate right if you've got nine leading zeros in one sense then the trade  in the opposite direction is by definition the

reciprocal so if we actually flip that chart  upside down now and by the way you can um go to our website and explore all of these charts  in any token paing that you like the um the the price of a single Bitcoin in terms of shba Eno is  somewhere in the like 2 billion tokens margin and again that's on a per token basis if we take the  decimal into account you end up with this number which I think is 27 quintilian Sheba token Sheba  way per Bitcoin way which is hugee right this is this is beyond human understanding and I'm  going to prove it for those who have let their eyes glaze over pay attention to this because I'm  going to help you understand just how stupid defi

is this is the Burge kifa and it stands at 828 M  tall and this is a carbon atom which is 10us 10 m tall one angstrom tall roundabout it's so small  that you can barely say it has a height at all and if you were to stack carbon atoms one on  top of the other all the way to the top of the B Khalifa you would have about 8 trillion  something I think right 8 8 is that 8 trillion 8 trillion 280 billion of uh of carbon atoms all  the way to the top now compare that to the size of Bitcoin and sheba Eno which which Tower  do you think would be taller and by how much because on that scale Sheba enu is still about I  think 1 million or 10 million times smaller than

the carbon atom compared to the Burge Khalifa  now the reason I'm bringing this up is that imagine someone told you to go and measure the  Burge Khalifa in carbon atoms and how difficult that would be well what's even more difficult  is to measure a carbon atom in BGE khalifas CU you have to do both on a decentralized exchange  and this is the difficulty when I'm talking about precision and accuracy it's that kind of accuracy  and sure you think well I can do this on my calculator at home or I can get python to do that  and that's fine but on a blockchain you have very limited memory and you have to respect that memory  limitation and you also have to respect that if there's a rounding error that that mean that your  protocol gets hacked and there have been and I'm not going to name any but many protocols that have  had rounding errors in their exchange mechanism

that have resulted in their liquidity pools being  drained so you need to be very very careful about this kind of stuff so the answer to this question  is what a reasonable range to support it's it's just arbitrary it has to be as wide you have  to go down to ridiculously small numbers and all the way up to stupidly High numbers so small  and so high that they lose all human meaning now I have written a very very in-depth blog entry on  this and you can again visit this via our website at carbon. XYZ and I'm going to run through just  through the Cliff's Notes right now about how we approached this problem and and um the results  that we achieved with it so the first thing that you should note is that when you are dealing with  very very small numbers in a fixo infrastructure

everything rounds to zero right if you ask  ethereum today what's 1 divided 3 it tells you oh it's zero right oh what's you know what's 10  divided 6 zero okay there is no number between 0 one one in a fixo infrastructure so when you have  to uh account for that what you end up doing is kind of recreating fractional components inside of  calculations and so what we've done is to actually introduce a scaling constant which is 2 to 48  which covers a very very large um range of of uh prices for us and then we um we basically rework  the formulas so as to account for that change in the scale and this means that rather than storing  a um a quotient as like two different numbers in memory instead we can just store a single integer  and always remember that we need to divide through

by that scaling conent at the end so here's just  a very very quick example again wbtc versus shib here's some infinite Precision you can see that  the numbers are running off to the right so we're simulating a blockchain that has unlimited memory  unlimited Precision unlimited computation power and then comparing ethereum to that Benchmark now  because of the way these formulas work when a user submits their price data at the beginning this  is a calculation that can be done off chain which is great so we can do that with an SDK we can do  that inside of the user browser and we can perform a square root which is in general something you  should never try to do on ethereum um and we can get a very good number that we have a lot of trust  in and then that is the data that gets saved to

the blockchain now that number is still ludicrous  ludicrously large because we've scaled it up by a factor of 2 48 so how do we get that down into  something manageable well we basically have an inhouse floating Point approximation method where  we uh we cut off the um significant digits after the 48th and then we just scale up that number and  store it as a um as an exponent um at the front of the memory slot so basically when you're reading  the the the smart contracts it will tell you what the number is and then how many zeros you have to  add to it now of course that means that you lose a little bit of precision but we're losing it at the  48th decimal place right not up near the front um

and we do this obviously for both price parameters  I can skip through that um and then we can uh we can start to analyze what this looks like both  from the maker who again had arbitrary Precision in mind when they set up their strategy we can  compare it to the contract which didn't know what the M what the maker wanted in the first place  only the information that it provided and then we can compare the calculations with to both of  those reference points and measure two different types of accuracy so because of the way that we've  organized the data we can actually fit all of carbon's contracts um at least per user into three  slots in memory and because of the way that these things arranged um in general it's uh it's only  ever a single read and a single right oh sorry it's it's generally only a single right that's the  one that matters reading data from the blockchain

is generally free writing data is expensive  and so when we're looking at Precision loss and accuracy it's really these two cases that we're  examining we're looking at how much data is lost or how much Precision is lost at the time that  the maker writes their data to the contract and then how much Precision is lost at the time that  someone interacts with that data and I'm pleased to report that our Precision is phenomenally good  so even with all of that bit wrapping and evil bit hacks and things um we're getting something like  60 parts per million um accuracy on coins like rat Bitcoin and and sheba enu and of things that  are both like you know similar value and similar token ways things like I don't know uni and BNT um  those have like near perfect precision and then in the opposite direction which again should be very  difficult um so we're getting something like 2.5

parts per quadrillion um accuracy which is again  um very very impressive and that's compared to the maker arbitrary Precision value um when we  compare it to the contract which again doesn't know what the maker Wanted only what the contract  received the Precision goes up and we get about 26 parts per octillion under those circumstances so  we're very confident that we've we've created an an extremely robust system um and like I said if  you want to explore how I did this I've actually made some of the code available for you to test  this on your own um it's available via the the blog entry that I've written for the the company  website if you would like to reach out to me um discuss anything that I've discussed here maybe  you've got some technical issues or you want some advice I hand out free advice all the time um feel  free to contact me at any of these uh channels and

also if anything that I've said today has um you  know tickled your fancy uh I am doing a five-part lecture series with token engineering Academy  which is going to be basically a a sort of M somewhere between undergraduate and postgraduate  level mathematics so it's going to have some calculus some uh differential geometry some linear  algebra all of Math's Greatest Hits you'll love it it's a lot of fun um so please if uh these are  still going so there's um I think there's still slots ready we are choosing candidates later  tonight so time is running out um but it's free this is a public good and I just do this because I  want people to have a better understanding of the protocols that they're interacting with and have  the tools to interrogate the mechanisms uh that

are being sold to them on their own uh thank you  so much for your attention I hope that this was informative um and I'm happy to take any questions  although I fear I may have spoken for too long I think we could take at least one question does  anyone have a burning question that you you like to ask Mark okay uh so my question is that since  you are actually losing some accuracy uh would it like did you pay attention to uh that not being  exploitable in a security sense yes absolutely so um read the um I I direct you to the blog entry  but yeah so the the point that this gentleman has raised is really important so you're always  going to have a rounding area because there there

is no infinite Precision um anywhere and so the  question is can you control which way the rounding error goes and in our case yes you can it's it's  it's proven um so we use um a series of um of of very clever uh implementations in solidity that  allow to do a multiplication and division at the same time um which means that you can get like a  temporary overflow um but as long as the division at the end brings it back within the Overflow  constraints then you're um you're good and in those circumstances you're going also choose is  it a ceiling division or floor division so the short version is we always make sure that the  person trading against a strategy gets slightly less than the perfect amount so that always  rounds in the favor of the person who created

the strategy if you get that backwards that's  when the protocol exploits happen yeah and you can check that out at Carbon def. XYZ blog all  right give it up for Mark Richardson [Applause]