DeFi Needs Familiar Entry Points
Pragma Bangkok · 14 Nov 2024 · 22:21
Anton Bukov of 1inch doubts that gas limits will grow a thousandfold even though wallets could, so he advises protocols aiming at mass adoption to use constant-complexity algorithms whose gas cost stays the same however many wallets use them. He points to payment channels, Uniswap V2 fee distribution and lending interest flows as existing designs that already scale this way. His design advice is to map the whole protocol flow, learn primitives such as digital signatures, and leave micro-optimisation for last. He also asks for more precompiles that let layer 2s read from layer 1, and describes an atomic-swap-based cross-chain protocol that any team may implement under an MIT license.
Speakers
Topics
From Pragma Bangkok, hosted by ETHGlobal.
Transcript
[Music] next up is our last interview for the day and for this I'd like to bring on Anton from 1 inch to tell you more about how we can actually make blockchains ready for Defi and all the technical innovations that we can do so please give Anton a big round of applause [Music] hi everyone welcome um 1 inch has a special place in our hearts because the history
of 1 inch has been amazing and very big part of e Global's Journey as well and and that is that this is a project that was a hackathon project in New York a few years ago 2019 19 yeah 19 and uh you've made this from a haathon project to such an incredible business a pillar in the D5 space and just so many incredible improvements that have come out of it so I'm I'm glad to be sharing this stage with you here and talking about all the stuff that's been going on um my kind of first question is walk us through what the last few years have been for one inch uh from just aggregating on the amm side from years
ago to so many new products that you've done tell us about what one in STS at this moment and uh tell us kind of what has been some of the successes yeah uh thank you for that question uh actually in 2019 we participated I think in all e Global Hons around the globe and uh I remember you was wondering why you meet us at every hackaton everywhere like in Europe in Asia in India like in United States and yeah we started right on hackaton and uh the projects started from aggregating three dexes we saw this as a real issue for us uh at that time there were like Banker Unis Swap and kyber and
uh zerox2 but that was not really uh it was not really liquid since it's order book based uh compare comparing to amm which are like almost always liquid so yeah what what we saw that there are three websites and picking the right website at the right moment would save you few bucks even if you're swapping like 100 bucks but you also have to take into account gas costs which is not easy actually and we built uh front end with smart contract to aggregate it actually and right on hackaton we had aggregation among those three protocols so idea was simple whenever you swap on any
liquidity Source any de the more you swap the worse is exchange rate so if you would split your volume among multiple pools multiple protocols you would get better rate that was the the original idea we implemented it and started working on this project after after hackaton but still participated in other hackaton not reason not to participate and yeah we ended up that after like one and a half years or something like that algorithm became much more complex because we realized that we could use not only direct swaps from Source token to destination token we could utilize other liquidity if you
buy either for usdc we could for example buy some Bitcoin some usdt and then buy either out of these coins so it's actually like a road among the graph where nodes are different assets and edges are different liquid to sources different pools Dees or limit orders whatever and yeah originally users had to perform transactions on their own so one inch was helping them to construct transaction that way that it will execute this flow over different exchanges to achieve the best possible rate but after that two years ago we
introduced 1-in Fusion mode and uh it's uh intent based and uh price Discovery is made in a different way now it's a ddge auction which is started by user by signing order and then competiting resolvers are looking at the price which is improving for them and once it's profitable for at least one of them it makes sense to feel this order because if you would wait more time someone else will feel it so we we we designed it like that and pretty recently like less than one month ago we announced Fusion
plus that's actually implementation for cross chain swaps it's like uh we have obstructions like limit order fusion and fusion plus Fusion is adding DCH auctions Fusion plus is adding escrow on different Chains It's like Atomic SW based idea so yeah that's like what happened to 1 in since origination that's awesome um I guess one thing that you didn't talk about is is a credit card and uh that was uh the one I was surprised by the most because to me this was like an amazing way to get into Defi and then you kind of saw a credit card but you've done cool things with it so maybe tell us a bit more about uh how that happened and how the credit card
specifically Works uh I would say uh you shouldn't expect from uh web to products uh to work in non custody way so basically now it's a white label uh and yeah I I think we're going to expand with it to more different markets but uh yeah it's actually Web Two product which is connected to web three assets web three values actually if you look at any credit card there are only two ways to have credit card with crypto you either have to deposit your crypto beforehand or you could could approve crypto and it will be claimed
from your wallet right at the moment of the transaction so yeah amazing so we were kind of thinking about what we should cover here and uh and kind of how do we actually talk about the opportunity set and just even how do we make good decisions in this space uh especially when we look at defi where a lot of what defi originated from was actually taking advantage of how smart contracts were constructed across different protocols and making better optimizations uh so what I want to talk about for for this interview is actually some Frameworks that I know you've developed on how to think and how to design protocols and uh and we're going to cover some of these and then see uh
what are things that are either new to others or some crazy things that you believe that others uh May disagree with or will find fascinating and uh the first kind a question I have is um we recently talked about increasing the the gas limit uh for l2s and uh if you are following the super chain ecosystem you can hear the Giga gas word a lot uh but I don't think that's something that uh you're a fan of is is that correct uh I would say that I think that gas would never be enough so if you would look at the perspective of uh software engineering development you would see that every new software which is built nowadays it have
like a higher C uh calculations footprint so it's like 10 20 years ago we had much slower computers but now we have much faster computers and yeah when developers build abstractions on top of abstractions they rarely care about performance and yeah but in blockchain I'm not sure that we will have anytime 1,000 times more gas so yeah we're like I see we're adding uh the increasing this limit once per few years it's increasing by tens of percentages but yeah 1,000 times is not yet here but we
are aiming to have 1,000 times more wallets uh it's not like limited by the number of people on the planet because everyone will have not everyone but most of the people will have ai agents AI agents for their roles on their work AI personal AI agents and they will likely have addresses and they will use crypto for something probably micro payments or like whatever so I I think like the in like in 20 years we would probably have like tens of billions of wallets interacting with blockchains but it's like 1,000 times more than we have now
but I not sure we will have 1,000 times more gas so so what happens in that world obviously you have a chick in your neck problem which is you cannot have 10 billion wallets if you don't have the ability to actually process that much throughput is that a good way of thinking about it or how do you actually then design software and contracts when you have this condition yeah talking about protocols there are multiple ways to build the same functionality but when when you're building something like a protocol on architecture level you are deciding which data structures and algorithms you're going to use to achieve something and you can build protocols which are
oriented on like optimizing specific use case like optimizing subscriptions for example or optimizing yield flow from borrowers uh to lenders or optimizing anything else and you could achieve final final stage of this optimization by having uh constant complexity algorithms this algorithms uh it's called Big o1 this means that increasing num input numbers would not increase output numbers in the same way this mean that making thousands wallets involved
in this specific protocols or Millions wallets or even billions wallets would not increase uh gas amount uh gas fruit print for any operations is there an example you can give for this constant size algorithm like is the assumption that we get to make a lot of these changes off chain and we kind of just put proofs or just kind of the net change on on a single transaction and that's kind of how you get a constant sort of tries or or are there just much smarter ways of Designing contracts here I I think it's also possible when you design protocol part of the logic could be onchain part of the log could be offchain but you should always have something what you
can prove on chain at the end and uh yeah starting from beginning there are like a bunch of those algorithms for example even like uh uh payment channels it's actually a thing where you can have multiple payments by signature without transactions and and then end you can make one short transaction which kind of pro proves the final State you don't need to prove every payment in every direction in this channel that's like 01 complexity it doesn't me if you made like thousands or millions or billions payments inside settlement is the same gas cost in un swap V2 pools for example when you swap your swap fee 0.3 or something would be distributed
immediately among all the liquidity providers and you don't care if it's like thousands or millions of wallets gas cost are the same because there is a algorithm which makes them like a pulling of participants in manyy markets the thousands or millions of borrowers experiencing increasing of their depth every second while thousands of millions of lenders experiencing increasing of their collaterals every second and this yield flow from borrowers to Landers is actually happening without uh extra computations it's taking the same amount of computations for any um number of
participants so those protocols you inside of them under the hood they're using algorithms which have infinite scalability property and they are like all already ready I mean this protocol like money market lending protocol you have to do transactions to deposit to Wi draw or to borrow and repay and yeah you you this protocol do not spend any guas to process those yields from borrowers to lenders so those protocols like they are already ready for Mass adoption with existing gas limit it could work with billions of wallets
because those wallets only do transactions when they actually need to get any function completed I mean that's a really good way kind of actually framing that and uh seems like we already have examples of this and Unis V2 is a is a great example you just talked about and interestingly that's been around for four plus years um what is then a good way to think about designing protocols if you're a Founder trying to build something in Defi and you're now have the luxury of being able to deploy different l2s or l2s that are constantly increasing their gas limits and you may not have to pay too much attention in optimizing the code um do you have kind of Frameworks for how you
at one in make protocol decisions yeah I'll try to describe it first of all on very top level you have to understand everything what your protocol going to do like all the possible uh methods for it who are users what are their roles are they all the same roles or are different or different what are actions you need maybe you can decrease number of those actions the idea is that you should throw away everything what is not necessary and keep only what is necessary I saw a lot of different implementations of a lot of different protocols and sometimes implementation is moving numbers and variables from one
corner to another corner and this is happening from method to Method like multiple times uh like every method is kind of optimized but when you see the whole flow how methods are using each other you see that there are computations which are made twice cheaper or they are Computing something and do do computations in other way and they're not like really efficient so you have to wrap your mind around your like whole flow of this protocol and you have to decompose it to understand which data structures and algorithms you're going to have inside and which crypto Primitives could be used useful there
are a bunch of them the more you know and the more you understand the more use cases you can came up to you should understand like how digital signatures work you Miracle trees those algorithms inside protocols I already named Unis V2 pooling of participants money markets like farming uh different things and when you're like aware of all those small Primitives you could under understand the way you can build your new protocol in the most efficient way and then yeah you have to implement it and at the end you can even do some micro optimizations but it's like the
final stage because micro optimization is something which could probably save you some guas but the most important savings are coming from design architectural design of the protocol that makes a lot of sense and without kind of zooming out seeing the whole flow you don't get to understand where the the inefficiencies are um maybe kind of on that same topic uh what are some things that you think we can improve on the evm to make D5 more suitable uh I see that the current struggling in U evm EOS system is coming from scaling solution to have multiple layer tools and now we see that layer
tools they already have some benefits comparing to side chains um that's probably the most important is that the bridge is ultimately safe comparing to other Bridges because saity of the bridge is equivalent to the saity of the whole chain layer to but I think we could bring more advantages to layer TOS by introducing more pre compiles more functions which are kind of native and helps them to get be more to be more involved with L one I saw proposals to have L1 SL Lo L1 static call these things could help dramatically they
could help with a there are like multiple directions to solve cross chain ux issue I see them like from top to bottom it's intense like swaps and something like this and bottom to top when we try to build ownership or wallet uh which owns something on different chains so I mean having extra functionality on Layer Two which helps get get anything from layer one or like interact with the layer one to be like closer to layer one would help to build more interesting and more like better solutions for both top to bottom and bottom to top cross Chain Solutions so
yeah we we need more lot more pre compiles yeah more the only way you can extend uh yeah I mean you could add more instructions but you could alide promiles maybe promiles is more scalable way because we yeah y that's that's a good way to to think about it and maybe kind of last question which you kind of already brought up on how to think about cross chain you've obviously been working on uh the aggregation on on 1in Fusion so going to give us an overview of kind of what's something exciting that you're enabling with Fusion uh the most exciting thing for me now I'm working on specification for non- custody cross-chain protocol the reason why we introduced our own
protocol we have like tens of cross-chain protocols already we tried to build a non- custody cross chain protocol and the only way we know to build non- custody is to have Atomic swaps architecture which was introduced like 11 years ago even before e was started and this mean that this would allow to have functionality among any chains like Bitcoin like ton salana Tron EVMS like whatever and we built our own implementation for EVMS already we call it 1-in Fusion plus but one of the core principles of this protocol is that any team is welcome and free to develop own
solution for any chain and they're free to run their own front endend operator for any chains they can support and yeah that's like the way we think end game cross chain solution could be built to create opportunities for others and make everyone involved and yeah if someone is happy with our implementation they can use it if they're not happy they can develop their own or they can get our implementation and change because yeah we use MIT license everywhere awesome so being able to do cross chain swaps without actually taking any custody and making bridging a lot more safer that
seems like a pretty awesome use case and uh something about to happen soon yes hopefully and yeah we recently realized that the vision of 1 in to expand possibilities of self custody assets since origination the first digital self- custody asset was Bitcoin probably and there was only possibility to transfer value and then we got Atomic swaps we got account based uh blockchains like ethereum with smart contracts we got much more possibilities like Protocols are basically offering possibilities to self- custody assets
and yeah that's great I think we will see much more different ways how you could utilize values which you own self custody awesome well thank you so much for this amazing conversation and uh we can't wait to try out 1in Fusion Plus thank you please give me a big round of applause [Music]