Smart (enough to not fall for your intents) Transactions
This following is an adaption by Anuj Das Gupta of Vlad Zamfir’s arguments given in the “State Your Intents” panel hosted by Frontier Research, available here:
Smart transactions are a way to use the Ethereum Virtual Machine to validate outside of the scope of internal transactions or Ethereum transactions. This is what we mean when we say, it is our regular Ethereum transaction but with extended semantics to make temporal claims. It enables your transaction to validate into the future or the past. No different code, just running EVM. No special language, just EVM. And especially with limited legal exposure to fiduciary obligation requirements as it does not rely on Intents. Otherwise if I am solving your transaction with the aim to fulfill your intent, I end up being entrusted with your will, your desire, what you wanted, therefore I’m your fiduciary.
Rather than catering to your every intent, our approach is to ensure program behavior using invariance by hypothesis/penetration testing.
The Utter Absence of Intents in Smart Transactions
Intents are supposed to allow users to specify their goals while giving freedom to the network in terms of optimizing execution. They are less specific than traditional transactions, setting conditions without defining the exact steps of achieving them.
Transactions encode imperative execution logic, which means that every single step of the “execution chain” needs to be clearly defined. In contrast, intents are signed messages that only define an acceptable end state and potential constraints. They don’t define “how” this end state is achieved. Finding the best “how” is outsourced to a specialized actor, called a solver.
However, our true intents are secret and often subconscious. It should not be explicitly known to others due to security risks. They can expose users to exploitation, particularly by MEV extractors who can use the information to their advantage. Intents should not be made public or explicit, as this invites adversaries to exploit these vulnerabilities. Instead, we should focus on using invariants — conditions that are guaranteed to be true about a program at all states. By relying on invariants, we can ensure program behavior, and thus have computational/verifiable guarantees for secure and reliable transaction execution without exposing ourselves to unnecessary risks.
On Intents as Forbidden Knowledge
What your intents are is forbidden knowledge. That’s forbidden for very good reason. It’s kept hidden in your subconscious. You can’t even know about it. And that’s for your own safety because if you did other people would use it in disputes against you to wreck you. So your intents are secret to you and as to everyone else. They are forbidden to know for everyone’s safety.
When you state your intents what you’re revealing 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 we call the law. So what we call intents are only the conscious intents that we’re willingly putting up in order to make it a fair game for people to extract as much value from us as they can out of our insecurities. When we demand our intents be fulfilled we do so under the mistaken view that we all our intents are known by us, that all our intents belong to us (as if we do not suffer from the anxiety of influence), that they can even be articulated in a language let alone one which can be computationally inscribed for the EVM and the surrounding ecosystem to respect.
So will I tell you my intent? No, that would be insecure, even for me to myself, as then I am acting out of a deeply mistaken view of life and mind. Stating my intent would make my insecurity your insecurity. One should avoid that as much as we can. That is our basic duty toward each other, especially in this adversarial setup that is crypto.
You can’t trust people who aren’t secure. You (hypothesis/penetration) test them to see if they are: if you see their intent then obviously they have failed, they are not secure. And you kept testing them until they get wrecked enough or when you run out of gas.
On the Semantics of Intents versus Invariants
Instead of the using the term Intents, why don’t we laser focus on a tinier aspect of what Intents are supposed to cater to. This is the constraints that must be satisfied within every Intents. These are Invariants.
Invariants do not map one to one with Intents as they are on the different level of semantic abstraction, the former being at a lower level. The invariants that it validates have nothing to do with its intent since it is at a lower level of semantic abstraction.
If you frame the user’s requests as intents and agreements, from a legal perspective, you are going to get yourself in lawsuits and torts; you’ll be liable. Instead just call them invariants and validation. Use computer science terms. Don’t get yourself liable.
Maybe the solution is to simplify the expression language rather than make it more complicated in order to simplify the solving.
So instead of Intents, if we inscribe invariants and other program behavior that you can prove in a proof assistant, which you can do offchain. Instead of revealing what is inside of your mind with intents, you leverage computer science to enforce guarantees on the results of the computation: you can prove claims about the program at all states, thereby allowing you to know if it’s an invariant across the entire execution trace. Invariants are the computer science way of talking about behaviors we can prove about computer programs. This is hypothesis testing in and as an extremely adversarial setup.
On the Diminishing Dichotomy of On-Chain-versus-Off-Chain
Smart transactions does the following for all transactions: the execution is the search. The search is the choice of block that you make to add to the chain. The onchain is the search result which is a trace of the search, while the invariants can be verified offchain in a proof assistance with respect to their penetration testing. So is the search lifecycle onchain or offchain? This goes to show that the strict dichotomy of onchain-v-offchain will not survive, the line separating them keeps getting blurry, if not to eventually collapse.
On Legal Liability and Cryptoeconomics
If you’re parsing intents of users, if you’re in any way aware or are notified of what their intents are, that makes you in trust of their will, making you their fiduciaries. Rather, the strategy should always be to never want to know user’s intents. So if you tell me I won’t believe you to maintain my claim of ignorance of your intents, as also you’ll never know mine. This is an adversarial setup through and through out. This has been the climate in and as crypto since its genesis with Nakamoto’s adversarial stance towards The State and TradFi with the genesis block inscription.
To that effect, MEV is applied crypto-economics. The market will see who is the most sophisticated based on who makes the most MEV. The most sophisticated strategy is to have zero knowledge about the intents of a transaction — its invariants. The invariants that it validates have nothing to do with its intent. If it has a non-deterministic strategy, that’s secure. If you have a secure strategy, it’s not going to be deterministic; it will be like a test where no one can tell what your intentions are. If they can tell your intentions, then you’re going to be their breakfast. So, it’s not that your transaction gets closer to your intention; rather it gets closer to the invariants.
If it actually has a non-deterministic strategy, then it is secure. If you have a secure strategy it’s not going to be deterministic. It’s going to be like a test that no one can tell what your intentions are. And then if they can tell your intentions then you’re going to be their breakfast.
You need to insist on making the test that you can do to test the faith, performance, and security of your adversaries. We’re going to pen test each other. It’s not like you’re going to know my intent when I’m penetration testing you. You don’t know my intent. I promise you that I don’t know my intent, and you accept this as zero-knowledge proof that you will never know my intent, because this is, in my opinion, actually secure. Transacting game theory works like this: you’re never going to have a deterministic invariant of the outcome. You have non-deterministic invariants. They’re not your intent; they’re just how the test works. And then, you know, it’s a test.
