What is a declarative blockchain?

Transcript

GM and welcome to the rollup today's episode is with lisel and Simon from essential the first declarative blockchain declarative programming has been around for quite a long time and it's where developers will Express their intent and there's a process of solvers trying to fulfill that intent with background processes in blockchain it's very very similar except that users Express their intent and there's a network of solvers that will fulfill this intent on chain essential takes this declarative nature all the way down to the most fundamental level where validators will solve the next state of the blockchain in essential and declarative blockchains in general there

is no execution and that's something that makes essential very very special we talk about all of this and more on today's podcast before we get into it here's a word from our sponsors that help make all of this possible enjoy [Music] cartey is your home for app specific rollups at the Forefront of developing new tools and platforms that enhance the capabilities of blockchain Technology cartey enables applications that are flexible and built to scale build on a full Linux environment and use traditional software libraries but in blockchain development go to

cars.io that's cy. to learn more about building your own app chain today welcome to the rollup everyone we are back today talking about declarative blockchains and intents uh this is a new paradigm um we're making the transition from imperative to declarative we're going to talk all about what that means the declarative nature of uh blockchain transactions and intents um I am here with lisel and Simon from essential intents and very very excited to dive into uh into what you guys are building and uh everything going on in this world of declarative blockchains so thanks all for coming yeah thanks for having us

yeah thank you awesome well uh I think the the word here that uh is kind of profound that we haven't heard so much in the blockchain space is uh this declarative um this declarative word and so I'm curious like where does this come from um and then we'll get into kind of like how you guys use this in uh in blockchain transactions sure yeah the um the declarative imperative uh sort of comparison is uh is one that's existed in computer science as a concept for quite a while and basically on on a fundamental level you have imperative programming and declarative programming which are different ways of approaching um like how we build U computer programs

so imperative programs are focused on how to um achieve or how to execute something by um sort of executing Specific Instructions and declarative programming focuses instead on what the program should accomplish rather than how it should and so when you um when you sort of apply those Concepts to a blockchain context uh it becomes pretty clear that uh expressing an interaction with a blockchain in a declarative way saying what you want to accomplish rather than how is a lot more ergonomic and intuitive um on the on the user end and also on the sort of entire infrastructure layer so um yeah we building what we call the first declarative blockchain which really applies this uh this idea of you know how do you describe uh what and how do

you enshrine what you want an outcome to be on chain um and ensure that that gets preserved all the way throughout the transaction supply chain so that um you know no matter what the conditions are on the chain or um you know any actors that are standing in the middle that users are always guaranteed the outcomes that they asked for and are also um sort of statistically or probabilistically guaranteed the best possible outcome that can be achieved on chain at that time it's awesome I uh I recently heard that this could be a a potential application of ZK technology where um you have some sort of like intent and then the ZK verifier is actually proving that you got the best execution possible in that you know given some constraints

like timing um and so I I found that a very fascinating use case for for ZK uh like provable execution um found that really really cool because payment for order flow and all this like toxic uh order flow toxic me toxic execution has really plagued both the offchain and the onchain world of uh just going back for a long time so um I I I found that really really cool okay so um you you mentioned like declarative in general um is this ergonomic switch to saying like hey I don't really care how this thing gets done I just want I just want this thing done um and so when we're applying that to uh the the current blockchain landscape today I think when we initiate

a transaction really on any L1 or L2 this is all been done in this imperative nature like I instruct you do the transaction make a approval make a swap um but now we're we're kind of doing this paradigm shift so so what's the rationale for this declarative in a blockchain sense and and how does how do intense what's the rationale behind intense and how how do we incorporate intense in the declarative nature of blockchain transactions all right yeah I was going to say intents a sort of a um a concept that like enshrines this declarative nature um of you know what can be achieved with interacting with blockchains so um they're very much about expressing what you want to happen

and you know sort of Outsourcing the how and so in the case of the sort of first generation of intent projects um it's up to solvers to discover how to achieve that outcome uh by sort of you know exploring the onchain solution space but then providing a solution in the form of a transaction which then still goes on into the sort of like me Dark Forest um and has all of this additional execution risk between what the solver provides and what the user might actually get on chain um so you know the the the idea behind intents is obviously letting users uh and applications describe things in terms of outcomes um but the the next step in that is to actually enshrine those outcomes and Ensure that

uh you know a a state update is only valid if the outcome is achieved and there's there's sort of two levels to that the first is just um like Baseline satisfaction that a the the minimum viable outcome that a user expressed is Achieve but there's also this additional layer of optimality so if you think of the solution space of what a user is willing to accept as an outcome you know there's like the worst case scenario that they will um that they will accept and in most existing um BL chain systems that is what the user will get because there's always someone who you know if you set High slippage is willing to stand with you and so this this system that preserves the declarative nature um all the way through the supply chain

actually enables um proof of of optimality as well so not only are you getting like the minimum thing that you actually expressed that you're um willing to accept but there's a competitive game that uh gives you the the best possible solution awesome okay um very very cool like how how does this work I mean you know we we've really traced through like the modular stack and like very very many episodes here on the rollup talked about you know execution consensus and da all the way through to settlement um is a declarative blockchain structured in a similar way or it is it not like H what are some of the mechanisms that you

changed to achieve this declarative nature all the way through to settlement I like tend to appeal to kind of like a first principal kind of thinking way to kind of get my head around this and so if you go all the way sort of back to you know why do we why do we have blockchains at all in the first place it's because we have a sort of a large network of of of actors who need to reach consensus over State and they need to reach consensus over what constitutes like a valid State transition um so today the way we've done that is we specify some virtual machine over which everybody agrees you know exactly how this machine is spe ified such that when I execute like a transaction or I execute you know uh I spin up an instance of this virtual machine for a

given set of inputs we all agree on what the output is um and that's certainly one way that that the works and it's got us quite a long way but fundamentally like thinking back to you know the fact that what we ultimately need to agree on is State and what valid State updates look like that sounds like a very like declarative problem statement um when you put it that way and so we kind of started thinking and you know we'd seen uh you you know projects that were working in the intent space applying these principles to the way the user expresses what they want at a given time and we realized that actually what if uh you know rather than the output to that being you know a solver finds an optimal transaction uh an optimal input to this uh virtual machines State transition

function and instead just discovers like what is an optimal State update that I could make so then you have to say okay well we can't have solvers just making arbitary state updates like they just give themselves and all their friends like arbitrarily large amounts of of money that doesn't work and so we started thinking about how can I design applications that themselves are declarative so any smart contract that I write it needs to be able to define the ways in which its state can be updated like it needs it needs that control over its own State um and that's where we got to thinking well maybe instead of having like a set of uh instructions written in some virtual machine that govern that what if it just Express those rules as constraints that say actually anybody

can set my state to anything they like but these are the declarative rules the constraints that have to be satisfied for any solution and sort of once you once you make that kind of shift in your thinking you realize that actually I don't need like an execution virtual machine at all because as long as I can as long as an application can reason about the ways in which its state can be updated using constraints which in you know we osit that in all cases it can be um then you actually don't need this execution at all you sort of you push that discovery of the next state offchain to uh a network of Agents they they could be they could be solvers um and then all you have to do on chain is is check that you know for this new

state are the constraints all satisfied um and that are some really nice properties around um and scaling and things like that that we can get into later expect yeah yeah be before we do and we we most certainly will kind of like uh talk about the the impact that it has on on scalability um and sort of the other the other optimizations that blockchains t tend to optimize for security and whatnot um be before we get into that I'm curious about the solver layer because this is an inherent like piece of infrastructure that is very important to uh fulfilling these these intents and and these declarations and so like how are you viewing the current landscape of solvers that are that are

operating on on the networks now um are these sufficient like if we totally op uh adopt this declarative blockchain and we have a a very significant throughput of of intents that are going through the system is the current landscape of of solvers um sufficient to to fill all of these intents and that's kind of a specific question but I am just generally curious about the perspective like where are we at what is the state of this solver landscape now navigating multiple blockchains can be complex and cumbersome let's say you want to deposit into a lending Market on polygon because they have the best rates but you only

have funds on optimism so you bridge your funds to polygon only to realize that you need madic to pay for gas maybe use a centralized exchange or you ask a friend to pay for the gas but only then can you finish your transaction in a chain abstracted future powered by connects this is not the situation you can connect your wallet to any dap from any chain with all the complexities of swapping bridging and depositing all completely abstracted behind the scenes head over to connect. network that's connect. Network to learn more about connect chain abstraction toolkit I think we're used to thinking

um about solvers in the context of sort of enshrined searches and I think that's really where you know this this Paradigm came from was was around you know we had we had meev and we had all of these uh searches dedicating a large amount of of compute to working how to extract value from the system and so the initial intuition was well maybe we can turn this sort of Searcher uh Network into a kind of a solver Network where they can contribute utility to the system um that's definitely I think is definitely part of of any declarative system you know this this offchain agent that discovers Optimal Solutions I think an important kind of Distinction to make is that there are certainly use cases where having specialized um sort of uh offchain compute like that

can be you know Searchers that have awareness of great uh a Vari set of liquidity that they can tap into they know about a great number of onchain venues that they can use and that sort of I guess that kind of elite competitive uh view that we have of solvers today we think of things like cow swap solvers and that sort of thing that's certainly one aspect we anticipate that in a fully general purpose blockchain not all use cases will necessarily warrant like uh deferring uh to such a kind of a such a network but I think that so what's an interesting kind of Distinction to make is when we talk about solvers in the general case we're talking about any like offchain compute in service of finding Optimal Solutions so one thing

that like one example of this is like let's say I have some large relatively large complex application with which I've managed to distill down like into a a smallish set of like constraints and invariants that I can express declaratively on chain how I go about offchain like modeling what constitutes a valid State update it may be trivial it may not be but the important distinction is that part is happening off chain so you can almost imagine a situation where an application um you know it can uh leverage like a competitive solver Network to assist in finding these Solutions but if I'm an application developer and I write like a new application that has this large offchain component which I need to help me find some more solutions um that's

something I can run myself for example I could run like a a almost like a we see in like web 2 you have your typical like client side server side kind of application architecture you can almost mirror that in web 3 by having you know what we're calling solvers in the general case be this offchain compute like I could just run I could just run a server that knows my application very well and knows how knows good techniques for discovering optimal outcomes and then the kind of the because the constraints are being verified uh on chain I still have this I still benefit from the sort of decentralized aspect of my application so I think that's an important distinction to make when we're talking about solvers like in the general case is that we do Encompass this sort of highly competitive highly specialized um solver Network the way

that you would think about it in terms of things like cow Swap and Unis hex and that kind of thing but it sort of goes beyond that it's really this idea of General offchain compute being able to produce Solutions which are then very very fast and cheap to verify on chain awesome yeah it's this uh idea of like have your cake and eat it too or build it too because you you you want this like very robust network of solvers that are able to fulfill these intense um and who better to know your your application needs better than yourself and so it only makes sense that you would build out that solver yourself and then this is where kind of like the advantage of Open Source technology comes in where maybe you do choose to open source that that first solver that you build

yourself to to satisfy that application's needs and then you open source that and you say Hey you know if you can come build a better solver come in because it'll end up benefiting this the other side of the uh of the coin where it'll end up benefiting that application uh even more so than that that initial iteration So speaking of cake um there's like this standard that that's out there now uh it's this cake framework um Frontier research put this out um it seemed to get some adoption I think it's still like rather early or new in terms of uh the research that's that's been done with it but um I haven't looked into it too much I'm curious like being so deep in the

intense space uh what is your general perspective on this cake framework um maybe helpful for our audience just what is it um and then we can talk about like how some of these projects are starting to incorporated into their designs yeah so the the cake framework itself is um it's sort of like a a working group uh to achieve some sort of standardization around um how we as an ecosystem achieve chain abstraction with intents so I think it's helpful to conceptualize of intents um not as a use case in of themselves but as a primitive and that primitive is applied in a bunch of different areas so the sort of first uh generation of intent projects like cow swap um were applying it to swaps in a

single chain environment um um and then there's this other other direction which is applying intense to the um the problem of bridging and more specifically um abstracting away the the user interaction um with Bridges and enabling like actions across different chains without users having to directly Express um some kind of interaction with a particular Bridge so uh we've been working pretty pretty closely with the people working on the cake framework um and looking at you know how do we as a as a sort of sector of the ecosystem take uh this idea of intense and apply it to a cross chain environment and make sure that there is a degree of

standardization um so what we're what we're doing at essential is slightly different and that we're applying the intent primitive to um the the design of a blockchain state machine itself like how do you um you know design a blockchain that fundamentally incorporates this like constraint based um intent Centric model and so that is uh you know quite different from the ecosystem that cake or the cake um you know cohort are building in but there is a lot of overlap especially in terms of um you know how we build uis that enable users to interact with intense systems how we build some kind of universal uh intent expression format that any solver in any ecosystem whether it's um solvers

on essential or solvers in any of the projects working in the in the cake environment um that you know anyone can adjust an intent from anywhere and understand it because it's uh you know with the same standards in the same language um so that's actually something that we we're contributing to in the form of our sort of universal intent expression language uh called pint for programmable intents um and you know it's it's primarily developed to um to express intents and and express constraint in order to build applications um on our chain but at the same time it's also um you know pretty Universal and generalizable to any

intent system so if you imagine this future ecosystem where every user is interacting with a UI and a wallet and um you know solver networks that are a fully intense Centric um it can sort of be like the the underpinning that uh that ties all of those ecosystems together very cool it makes a lot of sense that when we start to change the way that we're interacting with blockchains it means that some of the infrastructure underneath is is going to change as well calls for new standards um pint of which is one of those um the cake framework I I also saw another standard I think put on by across and Unis swap uh that was this this new ERC um and it was this idea of combining

their solver networks so that um the this the solvers could kind of watch this like common intent men pool um and just kind of like look at a common place to fulfill those intents um I'm curious if that that is like what do we expect that uh this is kind of like the end game where we're trying to kind of like plug and and combine all of these intent uh uh initialization uh engines into one one single M Pool almost like a global men pool of intense and then have like a global liquidity layer that is also trying to fill those intents do we do you anticipate that we'll end up

integrating a lot of these uh these networks together or is there certain reasons why they may may or may not coexist I think um integration is a lot of people's end goal I think like having a single you know intent mle where every single uh blockchain you know uh interaction on every single chain goes through a has some you know scary implications for centralization so I don't think it would ever fully get to that point um but yeah definitely like a good example is um if you see like intent order flow on ethereum going pretty evenly split between um cow swap onein fusion and Unis swap X um where any of those intents you know the the

whole principle of intents is to be able to expose yourself to you know every single source of liquidity onchain and offchain um you know regardless of where you are but because um these projects are are all using different methods for solving and different standards that order flow has been fragmented again and so you know coincidences of once um across two different users using two of these different um you know still intent platforms and maybe even with the same solvers um operating in both of them um can't necessarily get that same you know explo exposure um because the water flow is still like segmented so I think that if if we don't um sort of come together as a a sector of the industry and create some sort of uh standardization to to

the point where order flow is um you know shared between different um different platforms and different protocols then you know we are we are kind of just uh taking the the current problem of fragmented order flow and liquidity up a layer and it'll still be a um you know a resource that can be guarded and can be um that value can be extracted from so yeah orderflow being um purely like uh sort of proprietary guess um is is something that yeah I think everybody in this space recognizes that we need to move away from um and is something that I think most most projects in the intent space are like

collaboratively working towards yeah that that makes a lot of sense and we we spent a lot of time uh really trying to think through like how we can create solutions that are not recreating the same problems that we have in trafi proprietary order flow payment for orderflow that that whole thing so um so that that makes a lot of sense we want to try to solve these at you know at a big base layer not just move them up the stack um and so I I think some of these standards are really really cool um it makes sense for some of these like very almost like similar you know if it's both a trading engine and they expect kind of a a similar style of intent where it's just swap here and here or even cross chain swaps right just swap here but on a different chain essential

has like some much more General use cases as as I'm coming to understand it um by providing for by providing uh solutions to intents of a much more General use case you can provide just the state of the the blockchain doesn't have to really have anything to do with value transfer any kind of swap or Bridge transaction and so my question is does does this more General use case or more General intent call for a different kind of solver or can you leverage kind of the existing solver networks that are out there now definitely got to be a combination of both um I think existing solvers like we have you know great relationships with and are doing like

amazing work in the existing um you know in production intent solutions that are out there but you know there is going to be a degree to which uh some more specialization um is going to need to happen um and also some more like generalization um so certain solvers will you know specialize in being General um and then sort of in the same way as such a market Dynamics um currently work there will be a long tale of opportunities where um you know it might not make sense for the largest solders to be paying attention to various different corners of the chain but that um you know there will be an edge for um certain like more specialized sols to fit in there um I

think Simon also has some interesting thoughts on how solers can fit into the network as market makers as well yeah I think the that's like the the real like power behind introducing the solver is like an abstraction is that um a solver can be many things right like it can be this kind of uh inine Searcher that I mentioned before uh it can be you know a market maker who is able to provide uh solutions that are optimal you know not because they they're crunching numbers on like a million different exchanges and finding optimal routing but just like they're present on a ton of exchanges and they have the know how to like model the execution risk of like showing a price here and then being able to like hedge it at a later time which is you know uh always

going to be sort of if somebody is is is prepared to take on that risk you're always going to end up with like a superior execution than someone who who must have atomist right now uh so there's that and then I think you know that it's there's a nice sort of if if you think of you mention like General State Transitions and not just necessarily defi like you can imagine some some kind of state that I want to change and maybe that's just like I want to make a transfer from me to somebody else like I know what the solution to that looks like it doesn't take a great deal of calculation to work out that I need to you know reduce my balance by 100 usdc and increment somebody else's balance by 100 usdc but at least what you get from the solver layer at that

point is like the gas abstraction side so like I just have to say this is what I want uh maybe I'm prepared to pay like some fraction of a sent of usdc for that to happen and that can be the extent of my sort of intent I can specify almost all of the I can almost fully constrain the final state that I want I just leave a little bit of uncertainty that says well how much going to pay for this and like the so the solver Network there kind of um covers this like gas abstraction side as well so I think in kind of like one Fell Swoop you kind of unite all of these different uh actors that are definitely they definitely add value in a network and you sort of put them under this kind of like umbrella of solver that introduces all these things at once

awesome and and yeah that that makes total sense I mean it seems to me that we could also drive down some gas cost in a way if if we're adopting that uh mechanism or solvers are the ones pricing in in the gas price um there's no reorg risk there's no finality risk of of just making a transfer on the same chain and so the solvers aren't taking on much risk in order to execute that transaction and so is it true that maybe executing transactions in this way would kind of commoditize uh the transaction fulfillment in such a way that it would drive down the cost to execute that that transaction yeah I think an important thing to note is uh that for framing it in terms of like executing a transaction

is sometimes helpful because that's the usual mental model that people come in with but what's actually happening is not execution nor is it a transaction in the sense that um you know transactions describe a particular sort of um you know they target a specific smart contract for example and they say you know this is the operation all the operations that I would like to undertake um and it sort of predefines in advance like this this imperative model um of like what are the the steps that going to be taken to get from A to B um and so the the sort of major difference in this declarative system is the um you know there is no like execution of transactions in the sense that we

usually think about it and so the concept of of gas which fundamentally is about um you know charging rent for taking up um you know compute power of of of a blockchain network um does have to be applied in the same way because uh because we can move execution off chain in this system um you know there isn't uh there isn't a need to have to pay for the repetition of computation that needs to happen in order for um validators to you know verify the chain fuel achieves Higher throughput by utilizing a novel utxo based approach that allows for parallelized execution this design

significantly accelerates transaction processing which enables fuel to handle vastly more transactions than nonp parallelized systems thanks to advancements introduced by Fuel ethereum rollups are set to be more powerful than ever before and fuel is not just enhancing etherium rollups it's redefining them making them faster more scalable and more adaptable to meet the needs of modern applications and developers go to fuel. network that's fuel. Network to learn how to build on the rollup OS and and so in a in a declarative blockchain we're not necessarily paying for Block space we're just paying for solvers to fulfill our

intent so ultimately like ultimately like right right down at the core of it you know there are state state is being updated databases are being are being written to and constraints are being evaluated and those things those things are being done with some redundancy being not by validator said or or anybody who has an interest in tracking the network and so you do have to you know reimburse the network for those costs the distinction is firstly that's like on order of magnitude or orders of magnitude cheaper because um just evaluating you know booing constraints like is is this satisfied or not is much cheaper and can also be like almost infinitely partitioned out like if I need all the constraints to be true um I can I can sort of partition those anyway I like

and I can have them validated in parallel by by a large Network and I just have to take the intersection of all the results and check that it's still true um so that's like a a very a very nice property um I forget there was another part to your question there it was mostly about like not paying for Block space like it it is a fundamentally different mental model that we have when when thinking about a declarative blockchain and so I you know some of these like normal con like concepts of of something like you know block spaces scarce are are are now not necessarily accurate in in a declarative sense um and so gas abstraction is one of them uh because we're not necessarily

paying gas for execution um now solvers are pricing in uh the Fulfillment of updating the state um and what what it would take for them to provide that that next state um it it does take some resources on their part and so because they're expending some resources it makes sense uh that the person who's expressing this uh this declarative uh intent uh is going to pay some fee for for that uh solver to fulfill uh this this next state yeah that's right so like the only entity that directly kind of you know reimburses the network you know in the base asset of the network let's say is

the solver um because they're paying for the you know inclusion of their solution and then the the any user who's reasoning about state they're sort of paying and we sort of mentioned gas abstraction so they could be paying with a completely different asset um at the same time they're paying for any level of solution Discovery they need so any the extent to which their sort of intent is unconstrained and that there's still some you know some uh some uncertainty about where exactly in the state space to land is is something that they can pay the solver for if necessary and then also yet they they reimburse the solver for this kind of inclusion cost but crucially that can be done like in any in any asset so you get this gas substraction property got it okay okay so we we refer to it more as a

inclusion cost uh in order to include that that in the next uh State update um and then we did talk about and we're getting to like the impact on scalability I promise like we're we're gonna we're gonna get there but uh I am curious because you brought up like the Val the way that validations work and how there is still some redundancy of you know let's say solver provides the next state update they submit it to the network and then that's broadcasted to validators that agree and come to consensus on that on that state um and so how is that kind of like a normal consensus uh in terms of like how does you know data availability uh and and consensus work in terms of a declarative blockchain yeah so I would you know

picture the the fundamentally the consensus mechanism working the same as you would have seen on on any sort of Layer Two um the distinction being just that the the work that each validator is required to do is is significantly lower for any one interaction because all they're doing is checking you know the the the constraints are satisfied and they just evaluated bins rather than rather than each uh validator having to execute in order a large set of transactions um over some virtual machine I just have this is the new state that's been proposed and I have to check that it's acceptable uh from the point of view of all the state that that it touches um yeah in terms of like in terms of like data availability that's like another another place where like I

think the declarative approach like fits very nicely into kind of like a kind of like a modular design in that um really the the thing that's making changes to the network of solutions right but Solutions are formed from uh the observation of intents uh that the the users are making and so the only requirement for the like the intents themselves are Never Never Land on chain as such like they they they merely instruct what Solutions should look like and so the only thing that's required of intents is that they be available in a data availability sense and so it sort of fits nicely into that into that Paradigm too got it and uh something that that you said that you know since these there are no transactions that are getting executed in in sequence these

validators don't have to validate that these transactions are are are done uh in the right order is there no sequencer uh is there no need for a sequencer on a declar a declarative Network so you still need to determine um at any one time like for a given uh capacity of the network like which set which set of intents will be or like which Solutions will be included so it's more like instead of like okay these are the transactions and this is the order I'm going to execute them in it's how do I arbitrate between if I have a very large set of solutions and some of them will be some of them will be mutually exclusive because they may be competing over exactly the same state and probably will be um that's really where the

sequencing side comes in is okay how do I select which solution is optimal in this situation yeah yeah so so let's say I do try to double spend right that's like the the classical example of trying to operate on on the same state um like which one goes through right like how do solvers come to terms with two contradictory intents yeah so the sorry there's some cases where uh for example you can imagine um two intents where users are trying to swap like from the same asset a to asset B and Solas might provide solutions for both of those that both happen to let's say like it's an amm and try to pull from the same liquidity at

the same price obviously only one of those is going to be able to go through before the price moves um but so you can imagine that like in this sort of Rich solar ecosystem um for each of those intents there is not only one solution that's setting there waiting to be um you know to to compete to be included um and so the sort of the the stage um you know after solvers have initially like provided and committed their Solutions where then um there's a collaborative block building process where uh solvers come together and basically try and like append new solutions to um you know in in an ordered list and uh try and find the most optimal um and optimality here as Miss in terms of like how close to um

you know maximum satisfaction um in terms of uh what the user has Express in their intent uh does this solution or series of solutions get and ultimately the the consensus rules dictate that the the winning block the one that's selected is the one that provides the maximum like aggregate utility um across like all of the intents so uh you know that there may be cases where is 100% Zero Sum um you know there's only one p it's an nft for example um you know there's not going to be like an alternative option and ultimately on you one of those users um intent is going to be able to or Solutions is going to be

able to get included uh but for the majority of cases one of the big benefits of having a solver ecosystem is that uh users aren't necessarily having to compete for like just the same liquidity in a single pool because U solid are able to you know dynamically find okay if this if this solution is uh you know if this state space is no longer available um rather than still pulling from that same pool what's the next best solution that we can find across the entire network got it I love that that idea of Maximum satisfaction uh based on on the constraints that a that a user uh expresses um so that that makes a lot of sense um okay so like what what is the impact here like you know traditionally

blockchains have have been faced with this trilemma trying to um provide you know very fast uh TR I'm gonna use the word transactions but I realized it's not a very EP term in in when we're talking about declarative but traditionally chains have been trying to trying to provide fast transactions cheap transactions and secure transactions um and collectively this makes a a robust efficient blockchain um and so that's traditionally this trilemma um how how does that like how do we just kind of like solve that with this with this declarative blockchain what is the impact on scalability um on

on speed cost and security as a result of using a declarative programming in our in our blockchain so one example like uh well I guess the fundamentally the answer is that it's much much cheaper to verify a set of constraints are satisfied for a given solution than it is to calculate that solution um that's sort of where the that's where the gain in in in um in sort of scaling you know faster faster cheaper transactions is coming from um I I think a useful example to think about is like uh let's say um let's say like a transaction that's executing a swap on some amm like in a in a uh like in on the evm for example like you you just

have to to sort of see the complexity of this operation you just have to read like the smart contract and you'll see or even you can look at the the assembly and you'll see basically all of these operations that are happening many of which are really just sort of setting up what turns out to be a constraint based problem in the end uh which is you know in the name namely in if you're dealing with a constant product Market maker you just have to check that the product of the liquidity before and after um is the same modul some fee uh whereas you know if you just do that directly declaratively all for a given swap what a swap looks like from the point of view of a validator is this amm has a new state now like the reserves have changed all I have to

check as a validator is if I take the product before and after this solution is it the same and that's literally all valid dat has to do to check that okay the the state of this amm has evolved in a way that is uh that satisfies the constraints so kind of this whole overhead of like uh of setting up the constraint problem is is kind of factored out and you know the offchain solver can model the curve of the amm imperatively if they choose to like they can they can use some functional methods to to work out you know what what should the reserves be before and after for a swap of a given size but like once it lands on chain and the validator has to check is this a f swap or not all I have to do is just look at State before and

after and so so hopefully that like illustrates that like there's it's it's a lot less load on the like validat network and on anybody who wants to be able to verify the chain that it isn't an imperative design yeah and that load can be shared amongst um you know a bunch of different validators so you know for people who sort of understand in the modular ecosystem how data availability sampling Works um you can do the same thing with sampling valid VI of constraints so uh you know a bunch of different validators can collectively um sample uh or or you know validate um pieces of this of these constraints and come together to sort of probabilistically prove that um you know everything is valid awesome this has

been a lot of fun I uh I feel like I learned a lot and and some of my most fundamental understandings of blockchains have been blown to bits so um thank you so much for coming on and uh yeah AB absolute pleasure learning about the clear of blockchains thank you so much for having us yeah this was fun yeah cheers R it was a good time