Unraveling the Meaning of Intents across Digital Domains
In computer science, Web3 and blockchains, terms can often take on multiple nuanced meanings depending on the context of their usage. One of these terms is Intent. An Intent encapsulates a goal or a target state that a system or process seeks to achieve, i.e., Intent conveys the idea of purpose and desired outcomes.
Although this concept might seem straightforward, its application varies significantly across domains. For example, within Android application development, intents are abstractions of operations such as switching between screens or initiating specific services. Another area where the term intent is widespread is computer networking, where intent-based networking (IBN) describes a shift where network administrators set high-level policies and the system automatically translates these into device configurations, streamlining network management.
Intents in Web3
Intents were created to outsource the complexity of interactions with the blockchain while allowing users to maintain the security of their assets and cryptographic identity. You may notice that many of these ideas match the systems that were already operational for several years, e.g., Limit orders, CowSwap auctions, Gas Sponsorship, Delegation, Transaction Batching:, and Aggregators (Source).
On the research side, previous related work applied intents within the context of blockchains to ease blockchain interoperability. Recent approaches (e.g., Anoma) leverage the term intent-centric to describe their abstraction layer across ecosystems. In a recent blogpost intents are informally captured as
an intent is signed a set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party. (Source)
In short, this notion of an Intent enables more flexible approaches where signed messages do not dictate the computational paths that have to be taken, but rather dictate what the desired outcome should be, instead.
If a transaction explicitly refers to “how” an action should be performed, an intent refers to “what” the desired outcome of that action should be. (Source)
As with every system, the game-theoretical model must be sound, and the system must align he incentives with the system’s design goals. Crucially, the critical questions in intent-based applications are who the party is that is (i) aware of the intent, (ii) incentivized to execute the intent, and also (iii) able to do so on time. Based on these answers, the efficacy, trust assumptions can be derived and assessed.
Intent Propagation
In the context of blockchains, intents need to be somehow gossipped or broadcasted before a valid transaction creation can occur. Therefore, after declaring and signing intents, these intents must find a way to propagate through the network. The most obvious component to aggregate intents would be a blockchain’s mempool. Unfortunately, current designs do not support the propagation of intents. Allowing fully generalized intents in mempools would also open the risk of DoS attacks.
Thus, collecting intents is crucial, and there are three distinct approaches: (i) permissionless mempools, (ii) permissioned mempools, and (iii) hybrid solutions.
Approaches toward Intentpools
Intent-based applications include not only a new message format, they also include mechanisms for intent propagation and counterparty discovery. Designing a system that is not centralized and incentive-compatible for promoting and identifying counterparties in the form of alternative mempools. It is not trivial to design a mechanism for discovery and matching that is incentive-compatible and not centralized at the same time.
Intentpool System Design
There are three distinct designs for intentpools: Permissionless Intentpools, permissioned intentpools, and hybrid solutions. As the names suggest, the primary design principles revolve around the access control of these pools.
Although permissionless approaches are favorable and aligned with blockchain design principles, but on the other hand have challenges with regards to Denial-of-Service (DoS) resistance, Miner Extractable Value (MEV) as well as the incentive for propagation.
Permissioned “mempools” are much more resistant to DoS by design, since they do not require intent propagation. While MEV issues are obliterated, trust in central entities is required and assured by their reputation.
Hybrid solutions merge these two approaches and try to eliminate trade-offs, e.g., permissioned propagation, but permissionless execution and vice versa. Usually, these designs assume a trusted entitiy receiving intents (or transactions) from the user and facilitating the auction on their behalf (e.g, order-flow auctions)
Risks of Intent-Centric Approaches
Every technological solution inhibits trade-offs. Well-beknown to the security-savvy mind; unfortunately, increasing usability can introduce novel threats or decrease security. Whether or not the security-usability trade-off is a myth goes well beyond this blogpost but is a critical discussion nonetheless.
Overall, the significant risk of intent-centric approaches is the centralization of trust, e.g., in permissioned intentpools or mempools. The increase in hacks and incidents over the past few years indicates that centralized or off-chain components (e.g., bridges) are prone to exploitation.
The status quo transaction flow of public blockchains is already complex for non-technical users. Although intent-centric architectures should increase usability, the underlying complexity of technical protocols will make it harder to explain and transparently show order execution.
Summary
In summary, the term “Intent” in computer science, Web3, and blockchain contexts refers to a goal or desired outcome that a system or process aims to achieve, and its meaning can vary across different domains.
Recent research has explored intent-centric approaches to improve blockchains and subprocesses (e.g., counterparty discovery). Intents dictate the desired outcome rather than the specific steps, distinguishing them from signed messages that define how actions should be performed.
Crucial considerations in intent-based systems include identifying parties aware of the intent, incentivized to execute it, and capable of doing so. Intent propagation in blockchains is essential, and various approaches, including permissionless and permissioned mempools, and hybrid solutions, have been proposed.
In summary, deploying intent-centric systems is complex because of its permissionless and adversarial environment, similar to public blockchains, which pose a similar threat model overall. Thus, these system designs require clearly defining design goals, requirements, and trust assumptions.
Intent-centric Architectures with Acurast
As outlined above, Intent-centric architectures at least require a partially permissionless intentpool to be in accordance with the trustless Web3 ethos. For example, the Acurast off-chain execution environment can be leveraged to incentivize and propagate intents, all while obliterating risks (e.g., MEV) and keep the permissionless nature.
Acurast enables many use cases because the zero trust confidential execution layer assures computational efficiency, confidentiality, and decentralization. If you require a zero trust execution layer or would like to contribute to the future of decentralized computation while earning rewards, head over to the documentation of Acurast.
