Panel 5: State Your Intents

Panelists: 
Christopher Goes - Anoma (𝕏: @cwgoes)
Simon Roberts - Essential (𝕏: @simonr0204)
Vlad Zamfir - Smart Transactions (𝕏: @VladZamfir)
Philipp Zahn - 20Squares (20squares.xyz)
Markus Schmitt - PropellerHeads (𝕏: @haikane)

Moderator:
Ankit Chiplunkar - Frontier Research (𝕏: @ankitchiplunkar)

Welcome to the last panel of this session about intents.

Every week, there's a new Twitter thread about intents.

Still, we do not know what intents are and what they are used for.

I would like from the panel to basically go by order, introduce themselves, and just define or explain to the audience what do they mean by intense.

I work on Anoma, which is sort of an intent-centric architecture, as we understand it.

To us, or I mean, I think the sense in which like language, of course, is this decentralized coordination system, and no 1 gets to pick the 1 true definition of intent.

I think the sense in which we've seen intent as a like coordinating concept so far is as something like an intent is a credible commitment to a preference function over the state of a particular system.

And the system in question can be defined very differently.

So when you define the system as like the Ethereum main chain, then You could have intents referencing state on the Ethereum main chain.

When you define the system as the whole roll-up ecosystem, then your intent could reference any state on a roll-up.

When you define the system as, I don't know, what Google has indexed, then your intent is something you type in Google's search bar and searches over whatever is indexed.

To us, intents also include information about who knows what, so information flow control.

And this is what we spent a lot of time working on.

And we hope to be able to provide that to the ecosystem at large.

So when we think about intents, I guess, a user sits down to interact with a blockchain with an idea of what it is that they want to accomplish.

And they're then expected to approximate the execution trace that is going to lead to what they want.

And the reason that MEV exists and that you're all here is that there is a gap between those 2 things.

So it just makes good sense if there's a mechanism for the user to express what it is they want to achieve directly, and then repurpose the search network as a solver network to achieve that.

Yeah, at Essential, I guess we want to accelerate that transition from sort of value extraction to intent satisfaction.

I'm a troll, but everything I say you should take as a serious test.

However, I think like what intents are and what your intents are is forbidden knowledge that's forbidden for very good reasons.

And that's for your own safety because if you did, Other people would use it in disputes against you to wreck you.

They're forbidden to know for everyone's safety.

Then when you say about intents, what you're talking about is your conscious intents, and those are the things that you willingly let up for the purposes of disputes for other people to use against you in this dance that is the law.

And so intents are what we call conscious intents that we're willingly putting up in order to make a fair game for people to extract as much value from us as they can out of our insecurity.

And I wouldn't make my insecurity your insecurity.

And for that purpose, we have developed internal tooling that, together now with the Ethereum Foundation, We are basically developing a modeling framework that you can use intense fit in because that framework the main purpose of it is actually looking at the intersection and the kind of the connections between different mechanisms and different models and intense when they come as an as an input basically with a factor value chain and the question is how does it you know how does it spread through what are the economics of intents coming about what tendency of centralization will come about through them and what will be possible high order effects thanks

I'm Marcus founder propeller heads and we are solvers and we solve intents And intents are a simple way to think about it.

The way I think about it is that they are partial transactions where I might not know all the things I need to know to be able to form a transaction.

I don't know when price or gas will be low enough.

So I still want to execute that intent and publish it so someone else who might know this information can help me out.

And that is really what enables Intents to allow me to express a lot more than I can do today, because at the moment, I'm limited to the things that I can fully express.

But with Intents, I can express things partially.

And anybody can help me, now or in the future, to find that missing part.

And I agree with Vlad that there is a differentiation between conscious and unconscious intense And expressed and non expressed intense and I think we can explore that further

Yeah, I want to also explore like how our intends different from the current set of transaction types we already have.

We have these type of off-chain trusted transaction types, such as bundles.

How are intents different than what we already have?

And what new feature sets do they bring to the picture?

Yeah, I mean, I think intents, in a certain sense, are purposefully less specific than transactions.

They define what it would count for in order for a state transition to be correct without defining exactly how to get there.

So on purpose, they leave freedom to, if we think about the data flow of everything, users have intents.

And intents allow you to describe exactly how much choice you want to give up and to whom and what choices they can make as that information flows inward, potentially to optimize things and kind of the landscape of MEV.

Often when you have entities with different preferences, they're using that to extract from you because they have more information at the time they make the decision.

So intents kind of allow you to program exactly how much you want to specify about what can build on top of your message, consume your intent.

And in that sense, I mean, you can see these things sort of converging towards 1 another, like smart transactions or partial transactions, or these are sort of modifications to the concept of transactions that I think converge towards intents.

On the other hand, I think it's helpful to think about just the term intent, to me, conveys this very intuitive thing to people, like about, oh, well, someone starts with an intent, and then they write down their intent.

It's explicit or sort of consciously articulated.

Then it's sent to the system in discrete.

And the system, along with the intents of other participants, determines what exactly happens.

But the intent sets the boundary constraints.

Yeah, I think the extent to which a user is sophisticated, the sort of intent they would express resembles more and more the sort of transaction they're capable of expressing.

So I think the kind of user, for example, that is perfectly capable of setting an appropriate slippage on Uniswap and not getting sandwiched is probably the kind of user who has the extent to which they're sophisticated in that respect, the intent will be close enough for an approximation to the transaction.

As I mentioned before, the less sophisticated the user, or the greater the gap between what they actually wanted and what they actually stated, whether that's just through ignorance of how the particular protocol they're working with functions.

That's really where the difference arises.

I think it's also super interesting in that it sort of enshrines what today we're calling MEV as a fundamental first class actor of a protocol.

So rather than it being this sort of like weird emergent property, which you sort of then forever are kind of trying to patch or trying to work out exactly what's the Appropriate or fair level of value that can be extracted by kind of enshrining it right from the get-go You kind of it becomes a just a part of the the market

Well, thankfully this is like sort of applied crypto economics.

So like the market will see who's the more sophisticated based on who makes the most map, am I right?

And in my opinion, the most sophisticated strategy is that you should have 0 knowledge about the intents of a transaction.

Its invariance and the invariance that it validates have nothing to do with its intent if it actually has a non-deterministic strategy that's secure.

If you have a secure strategy, it's not going to be deterministic.

It's going to be like a test that no 1 can tell what your intentions are.

And then if they can tell your intentions, then sort of you're going to be their breakfast.

And so it's not like your transaction gets closer to your intention.

It gets closer to the invariance you need to insist so that you can make the test that you can do to test the faith and the performance and the security of your adversaries.

It's not like you're going to know my intents when I'm pen testing you.

And you accept this as zero-knowledge proof that you will never know my intent.

Because this is sort of how, in my opinion, actually secure transacting game theory response works.

You're never going to have a deterministic invariance of the outcome.

You know, like, what is the intent of a test?

When I sit on the bridge all day and I throw bait on the bridge to see who eats my troll bait.

You know, you must imagine Sisyphus happy, and you must imagine me happy while I do that.

Like, your intent, I mean, your real world intent is out in the world.

Is your opinion, Vlad, that the best way to express an intent essentially is like provide a proof that your intent has been met?

So you're like, no 1 knows your intent, but they just have like a brief.

The best way to express an intent is repenting in front of the Lord at Judgment Day.

So do you think that intents are a wrong way forward?

No, they're there for us to extract mev out of you.

So I think there is a point where we actually agree even if the language might be different But there's the question of what is the what is the language when I mean average users normal users not knowing much will actually face Intense and at the moment we are talking when we see examples of that.

They are typically relatively low level I'm not sure users will care about this So there's the question of what will be basically the stack of translations in between not only the stacks They will also be the question of what services need to be provided to make it useful There's the question also, you know, does this lead to centralization and obviously awesome that I think ties back to what flood said Do you lose actually total control about what happens to what you state?

And how do you make sure that this is actually coming back at some level?

And I'm not sure how they will actually be.

There are some ideas out there, but a lot of modeling, a lot of details are super relevant here, basically.

Coming back to the original question, like what will Intents allow us to do that we can't do today.

Partial specifications, lazy evaluation is the best.

So I think there's a lot of spaces that you can go into.

I think starting with a simple example of what intents allow us to do already today, I think Kauser was a really good example where You submit an intent for transaction, but there's a lot of unseen information There might be others trading in the other direction and you can have a coincidence once There might be many others trading same direction can batch and benefit from that all of that would be impossible for you to know ahead of time and Also intense allow for much more complex coordination that is very difficult to express in current UIs So you have a massive bottleneck?

Blockchains are these wonderful programmable systems where you could actually settle on any Agreement and they're limited by the UI's that you can build and How fast you can build certain UI's with certain use cases?

But intense I think it can move much faster than the UIs will be able to move.

And that will allow you to express much more complex transaction types.

For example, multi-party coordination, where you have different level actors that agree together to make a particular transaction happen that only is valid when 5 different parties actually agree on that.

And it's very difficult to design UIs for this kind of thing.

But on an intent layer, it's much more realistic.

Like, if you just said invariant, you would have no problem with me and you wouldn't be, you know, you wouldn't have put yourself in this position where I'm gonna like extract mev from your intents, bro.

If you call them intents and agreements, like legally, you're gonna get yourself in lawsuits and torts and you'll be liable.

Just call them invariant, invalidation, use computer science terms, don't get yourself liable.

Pay attention when the law professor claps, you know what I mean?

Are there any audience questions till now?

I mean, is language bound by law or is law bound by language?

I mean, language is the medium of legal argument.

if we change the definitions of the concepts, the laws say different things.

I mean, I'm going to dispute your definitions, bro, like, good luck.

Let's revert back to, yeah, let's revert back to, maybe Fabrizio has a question.

Okay, so it's clear to me that up to now, given what we heard, basically no 1 has any fucking clue what the intents are.

I just want to, okay, I just wanted to know, at least do

you have any idea about what mathematical Instruments, would you like to use to study them or to even attempt to give a decent definition or it's just like Magic,

Yeah, so I mean, I'm old enough, maybe it sounds stupid, but these problems of intents, you can call it differently.

So the question is, for instance, if you think about combinatorial auctions, same problem.

So you need interfaces to actually specify what exactly you want to do Main question or the main approach there basically is to definition define what is needed from the allocation perspective here It would be basically what happens as a transaction on the higher level is the question of what?

Attributes to the user actually care about And honestly, I think in the end this is a thing that has to be experimented about there are some ideas that you know We saw But the the idea that the same domain that is relevant for what is the value created down downstream is the same that users care About is obviously not I mean, there is no I don't think there may be much overlap I guess So we need that language first from a user perspective and see what demand actually is there for that.

I'm not sure what people are willing to share, for instance, with current proposals.

don't mind, I have a quick thing to add about that.

You know, in mechanism design, there's this idea of a truthful mechanism where you have the incentive to reveal your type to the mechanism, or something like that, roughly.

And then, in like the sort of version that I'm thinking about is you would never tell anyone your type.

That's the most private information that you're going to get marked for right away.

What instead you do is you provide an encrypted blob, and then the mechanism does it without knowing anything about your type.

The point is, in classical mechanism design, you have typical results.

That means you can just, there is a central mechanism which acquires your private information and you can provide your optimal allocation under certain conditions Obviously in many cases like if you're bidding in an auction, you will be very unwilling to pit your full vector of information, right?

I mean because you don't know whether the auctioneer says basically fuck you I'm you know, I'm turning the mechanism around and similar problems are here There's also the algorithmic perspective.

If you are, again, complex auction, if you try to bid on everything, that space is far too complex.

You need user interfaces that are simple enough, people can understand, and can be then translated into the actual allocation layer that matters

yeah, so Reflecting back on some of the learnings we have from the account extraction space Basically a big like 1 of the biggest challenges of account extraction standard in Ethereum was that fees of user operations are conditional upon user operations settling on chain.

And so you always have to deal with the situation where there are some intents, these like third-party solvers process them, like they they spend resources, computational resources to solve them, but they only get paid if they can like actually eventually settle them on chain.

And so that kind of brings a lot of the OS vectors, which is how this

standard becomes very complex because of this.

So I kind of wonder your opinions on that.

Yeah, just your general opinions on that.

Do you see it as a threat to perhaps like the goal of like simplifying user experience Our users are now required to like have some sort of reputation for their intense to be processed Do you see that as a as a significant challenge?

Mean I mentioned initially that what 1 thing that is very interesting is basically the whole value chain.

And what you're mentioning is that if there's a change of behavior at the bottom, how does this affect basically how, you know, which builders do you approach?

For instance, do we approach all builders?

Do you basically create redundancy because you might be in danger of not matching demand that you already created downstream?

I think this is all of these things will you know, there are these interlinkages and I'm pretty sure that will happen The main problem again is we can talk about it But ultimately you need to some form of modeling to think about reason, you know isolate factors and think about what it will happen I mean I can talk and talk but it's you need models in the end.

I think mathematically, there's a strain on between the complexity of expression and the difficulty of solving.

So I wanted to ask you guys how you deal with that issue, and whether maybe the solution is to simplify the expression language, rather than make it more complicated, to simplify the solving.

So I guess perhaps the correct answer is to do both to some degree.

1 of the things we quickly came across was that in this whole idea of intent expression, there needs to be some specified language for intent expression.

So that is 1 of the first things that we're thinking about building.

To tie into, I think, the first question that was asked about what's the mathematical formalization of this, this all sounds very vague, very fair question.

So you are dealing with a very complex state machine, which basically is your constraints.

So everything that you can do is bound by an awfully complex, by now, take the EVM machine.

The user is going to express some objective function of some final state they would like to achieve.

And so that is sort of the formalization of how you're saying, now, this is the state I would like to achieve.

This is the gradient in n dimensions over which I would like it to be evaluated.

So to tie that back into this question, so you really, if we're going to be speaking in such terms, you need the appropriate tool for the job.

So essentially, our answer to that question is that it's a DSL for intent expression, which is essentially a constraint-based programming language.

I have a sort of radical alternative, which is basically don't ever encode your intent ever anywhere, sorry.

Just invariants and things you can prove, which are nothing to do with intents.

And then those you prove in a proof assistant, and you do that sort of off-chain.

You don't tell anyone, or you keep that as if it's like

Oh, it's like the traditional computer science word for what we are trying to call intense.

It's something that just is guaranteed to be true about the program at this point, no matter who got to that point.

It's sort of like something you can prove about the program at all states, or if it's an invariant across the whole trace.

Invariants are sort of the traditional way to talk about things we can prove about programs.

Yeah, but if I specify, if I have a geometric variety of some sort, and I give you a start point and an end point, or a start region and an end region, And I say, give me 1 curve that connects the 2 regions.

But if you're doing a good strategy, your opponents, you will basically have this sort of invariance curve and you will not know what outcome you get and you will not invariant your outcome.

With a secure strategy, a secure test, you know, it's like a hypothesis test.

How could you do a hypothesis test validating for your outcome ahead of time.

And if it's not a test, then you're basically having actually an order or an intent.

And then you're just making it fair game for me to extract as much MEV from you as I can.

Since we, I guess, touched on the acceptability or not of the terminology of intense and without ought to be invariance I mean I guess my point is that the average what I'm gonna call a first-order user so not not somebody looking to extract MEV it's not reasonable that they should be conceptualizing these systems in terms of strategy and adversaries.

You don't want to think about strategy or adversary.

And then you're going to make everyone else die with you and you're making your security, your insecurity and everyone else, you go to the desert with no water and then you expect me to give you my water and make me die with you too?

You know, this is like the desert of the real, man.

You have to think about security, you have to think about your own security.

You have to, You don't go out to the desert without thinking about your security or your strategy or your adversaries or you're gonna get sniped in the dark for it.

Like they will pick up your loot and they will be right to.

No, I agree with you that that is the state of things, but I think that's why we're proposing.

This is like most lawfully what you deserve if you go out there not thinking about your strategy and your

I mean I think the only way to escape the desert of the real is trust, right?

To come back to your original question, you know, currently we live in this like economically abstract model And in an economically abstract model, solvers or whoever's processing intents needs to be always concerned about DOS.

And that relationship, it's going to converge to something that looks like transactions if the only way you can prevent DOS is by charging proportional to the amount of computation, right?

Because transactions charge gas proportional to the amount of computation.

And intents don't like magically escape this restriction because this restriction is economic.

It's not like about the expression language, although constrained expression languages can help you bound the computational costs.

But ultimately, I think we'll just see the pipeline converge towards more of a trust graph or a web of trust, where solvers who are interacting with your intents or your friends in the desert of the real.

How do you trust someone who has a billion dollars if they're insecure?

It doesn't matter how much money they have, they're insecure.

That's why you don't send all of your intents to the

You need at least 1 secure person in the web of trust, or the whole thing is obviously not secure.

I mean, you can't have trust without security first.

Like, you're gonna go out into the desert of the real, everyone's insecure, and make a web of trust with a bunch of insecure people who are gonna turn you in and wreck you.

No, no, you can trust people who are secure.

Like, I'm not going to trust people who aren't secure.

See all Frontier Research transcripts on Youtube

MEVday Paris: State Your Intents