the system

Specular is an intent-driven L2, designed to enable the operation of next-generation intent-based dApps in a secure, trust-minimized fashion. To achieve this, the protocol enables intent-driven sequencing, EVM-native execution and secure settlement—backed by a trust-minimized proof system.

the thesis

The defining problem preventing Ethereum dApps from reaching a less-technical audience is the complexity and poor UX of the emerging modular ecosystem. Intent-based designs have surfaced as a solution, by enabling users to declaratively express onlywhat they want from execution, without specifying how.

While a few applications that leverage this paradigm already exist today, they are designed & deployed in ad hoc fashion, often by reintroducing trusted off-chain infrastructure back into the stack, fragmenting liquidity and relinquishing composability. This is because they require fine-grained control over mempool management and sequencing; however, general-purpose chains today —centralized and decentralized alike—do not expose such functionality. Centralized L2 chains typically delegate to an opinionated trusted sequencer, while decentralized L1s rely on a combination of incentives and trust.

The underlying system must provide sufficiently expressive primitives to developers, to enable them to deploy their dApps without having to deploy their own infrastructure. Moreover, to ensure the best execution for end-users, the system must provide secure, trustworthy settlement. Risks such as protocol bugs, governance attacks & reorgs must be mitigated to foster capital-efficient, decentralized intent-solving.

intent-centricity

An intent can be defined abstractly as a minimally-constrained expression of a user's desired end state. Fulfillment of an intent generally requires counterparty discovery and solving. Optimal fulfillment of an intent, through competitive forces, requires decentralized counterparty discovery and solving.

In practice, an off-chain intent is served by a solver, by producing a satisfying bundle of transactions for inclusion in a block. To ensure these bundles are successfully included, a solver must trust the block builder. Mitigating this trust requires a form of real-time censorship-resistance guaranteed by the protocol, i.e. at the block-level. Furthermore, to ensure the user’s intent is served by the best solution—without additional trust—the protocol must enable sequencing programmability. Specular does so by enshrining a censorship-resistant programmable intentpool, and ensuring that every block includes space for the transactions produced from it.

Account abstraction (AA), introduced through a series of proposals, complements intents. Eliding the differences in existing designs, AA provides users greater control, security and flexibility than EOAs today, through programmable fulfillment validation. Intents go hand-in-hand with account abstraction to enable a user-centric future for dApp development. Specular provides native AA in a form that augments intent functionality, enabling a new design space for user-centric dApps.

settlement layer security

Optimal intent-solving requires a secure, low-cost settlement layer to reduce the operating cost and risk for solvers. While L2s today provide low cost execution, they introduce several risks. This primarily includes bugs in the protocol implementation and/or proof system, as well as governance attacks. To mitigate such risks, the system must be trust-minimized and credibly neutral. Specular’s proof system is designed to achieve these properties.

Trust minimization means that a bug or exploit in one client software stack should have no impact on the system’s overall security. To minimize software trust and provide resiliency, the correctness of a rollup should only depend on conformance of a single implementation to the L2 protocol specification. Trust is minimized when operation of the protocol depends on the fewest components possible.

Credible neutrality means that the protocol should not be in the position of picking winners and losers. The protocol should not canonize one particular software stack over another at any level of the settlement protocol. To maximize credible neutrality, the protocol should only enforce minimal constraints over L2 execution semantics—only what is necessary to guarantee correctness. This means that a validator should be able to, just as in the case of Ethereum, operate permissionlessly using any client software stack—existing or new—of their choosing.

references & acknowledgements

A manuscript describing Specular’s settlement protocol in more detail is available here (to appear at Oakland’24).

This work began as academic research conducted at RDI (UC Berkeley), and is supported by contributions from Factor and a grant from the Ethereum Foundation.