Author: @knwang

Translation: Blockchain in Vernacular

1. Chain Abstraction (CA), Intent, and Intent Abstraction (IA)

Chain abstraction and intent-centric solutions are two architectural approaches that aim to solve the same fundamental problem: enabling automated, asynchronous interoperability between heterogeneous trust domains.

Both approaches introduce the concepts of “transaction parties” and “cross-chain proofs” to solve this problem, but there are significant differences in how they structure these elements:

1) Chain abstraction:

Chain-centric perspective: In this approach, a single blockchain acts as a “decentralized event transaction party” for users.

User Interaction: Users interact with the same counterparty — the chain abstraction blockchain.

Obligation: The blockchain and its “extra-chain components within the protocol” are responsible for producing desired outcomes for users.

Proof Flow: The direction of cross-chain proofs always flows from the chain abstract blockchain to the target chain. On the target chain, it is enforced by proof checks, which allows resources to be minted or spent on the target chain.

User abstraction: User-oriented abstractions are usually expressed as requests for computation or transactions on the target chain.

Scalability: Scaling this system generally requires a general-purpose proof system that can be verified on-chain on a variety of target chains — perhaps using an MPC solution.

Delay: The delay is determined by the confirmation rules enforced by the general proof system and does not vary from request to request.

2) Intent-centric solutions:

State-centric perspective: In this model, an open network of solvers acts as a “distributed state counterparty” for users.

User Interaction: The user interacts with a counterparty selected at runtime, typically based on which counterparty will produce the best outcome for the user.

Obligation: Whether through a reputation system or a commitment system, the selected counterparty is obligated to deliver the desired outcome to the user.

Proof Flow: The direction of cross-chain proofs is reversed, flowing from the target chain to the user's main chain. On the main chain, it is enforced by proof checks, which allows the user's resources to be used on the main chain.

User abstraction: User-oriented abstraction is presented as the obligation to prove the state of the account on the target chain.

Scalability: Scalability relies on a programmable proof checking system that supports heterogeneous proof methods for each target chain, most likely a “resource locking” system.

Latency: Latency is determined by the solver's self-perceived confirmation rules, allowing it to be optimized as part of counterparty selection.

2. Intention Abstraction

If the chain abstraction provides users with a heterogeneous domain execution abstraction, then the intention abstraction provides solvers with a heterogeneous proof obligation abstraction.

Just as developers need to compose, orchestrate, and guide computational processes for users in cross-domain computation execution to achieve chain abstraction, they also need to compose, orchestrate, and guide proof processes for solvers in the context of intent abstraction.

3. Summary

The concept of "chain abstraction" is still evolving, covering a variety of approaches from "chain-centric" to "state-centric". To simplify discussion and facilitate comparison, I will define "chain abstraction" here as "chain-centric", which is more consistent with the framework of some of the original chain abstraction advocates.

However, in practice, many newer architectures combine elements of both the “pure chain-centric” and “pure state-centric” models.

My opinion: I believe that the intent-centric approach provides a better architectural direction. It provides users with outcome-based guarantees, optimizes outcome status and latency through party selection, and is more scalable in terms of customizing the target chain.

However, to achieve this, the proof process needs to be reversed and the proof obligation is placed on the solver network. In other words, while the complexity and heterogeneity of the target chain does not disappear, the integration burden is transferred from the preset hub of on-chain computation combination to the distributed network of off-chain solvers that handle the proof combination.