一种理解链抽象的新框架:把问题作为方法

如果你初次接触"链抽象"这个概念时感到困惑,你并不孤单。

这个概念看起来很重要,相关项目数量众多,融资规模巨大,各自声称是标准...但却难以明确其用途。"链抽象"是Web3新概念生产线上的又一个热门词汇吗?

本文将从概念出发,回归基本问题,试图在模糊中找寻清晰。

要点总结:

• 抽象的目的是隐藏复杂性,Web3中的抽象层级通常高于Web2(因此难度更大)
• 模块化降低了构建公链的门槛,链抽象则包括重新构建公链关系以及改善用户/开发者体验
• 跨链资产转移、跨链通信、互操作性和链抽象的辨析:一套以协调不同链上状态修改(交易)为核心的概念子集(但实际使用中往往存在大量交叉地带)
• 基于意图的链抽象解决方案成为一种流行架构,多个组件类产品可能会以拼图形式逐步接近链抽象的最终形态
• 行业目前对链抽象的讨论和建设尚未摆脱对基础设施本位的迷信,链抽象作为现实问题的成立离不开链上活跃度、模块化进展、新用户和开发者的加入
• 链抽象的前景并非一帆风顺,需要考虑对小型公链的影响,以及在非DeFi应用领域的探索

链抽象是什么问题?

链抽象是一个真实存在的问题吗?

不一定。问题的成立需要特定背景,就像询问500年前的人对能源危机的看法一样。

那么,我们为什么要讨论链抽象呢?

不同人可能会提到几个关键词:以太坊发展路线、模块化、意图、大规模应用...目前看来最有说服力的观点可能是:链抽象是模块化的下一阶段。

为了理解这一观点,有必要对链抽象的定义做出说明。

在计算机科学中,"抽象"指的是从后台过程中分离出高级操作和概念的过程,目的是通过隐藏复杂性来简化理解。例如大多数Web2用户只需要知道浏览器和ChatGPT,对其抽象的内容甚至抽象概念本身可以一无所知。

类似地:

• 账户抽象:通过隐藏区块链账户的地址、私钥、助记词等内部信息,实现账户的无感使用
• 链抽象:通过隐藏各条链的共识机制、Gas费、原生代币等内部信息,实现链的无感使用

在传统软件开发中,抽象和模块化是一对密切相关的重要概念。抽象定义了系统的层次和架构,模块化则是实现这种架构的方式。具体来说,每个模块都代表了一个抽象级别,模块之间的互动隐藏了其内部的复杂性,便于代码的扩展、复用和维护。如果没有抽象,模块之间的界限将变得复杂且难以管理。

值得注意的是,Web2通常在封闭或部分封闭的生态系统内进行抽象和模块化,抽象层次集中在单一平台或应用内部,环境相对受控,通常不需要解决跨平台或跨系统的兼容性问题。然而在Web3语境下,出于对去中心化和开放生态系统的追求,模块化和抽象的关系更加复杂。

目前看来,虽然模块化有助于解决单个公链内部的抽象问题,降低了公链构建的门槛,但多链格局下的用户/开发者体验抽象是模块化未能完全覆盖的领域。不同公链和生态之间存在明显的孤岛效应,具体体现在流动性、开发者和用户的分散。而链抽象的提出包含了对公链关系的重新架构,以实现多链之间的连接、整合和兼容。

我们可以认为,链抽象作为真实问题的迫切性与以下条件的发展密切相关:

• 链上活跃度:是否有更多的dAPP带来更多的用户链上活跃行为
• 模块化区块链的进展:更活跃的链上行为是否驱动了更多的rollup和app chain的构建
• 新用户和开发者进入障碍:目前的区块链环境在多大程度上阻碍了新用户和开发者涌入(指上升趋势中的磨损,而非停滞状态的迁怒）

链抽象属于哪一类问题?

链抽象本身就是一个抽象的概念,在Web3内部的叙事层次也较为高维,这或许在一定程度上解释了为什么链抽象呈现出包罗万象乃至扑朔迷离的样貌。具体来说,它不是一种解决方案,而是一种指导思想。

另一个例子是如今的比特币,在经历了数次减半、急涨暴跌、ETF落地等事件后,比特币已不只是一种技术解决方案或者资产类别,还成为了一种跨越时间的思想体系和行业图腾,代表了一系列加密核心价值观,并且在可见的未来依旧会对行业的创新和发展做出指引。

跨链、互操作性、链抽象这些问题有什么区别和联系?

我们同样可以按从具体到抽象的光谱去理解跨链、互操作性和链抽象。从形态上看它们是一套以协调不同链上的状态修改(交易)为核心的概念子集,但在实际使用中往往充满了中间地带。

我们可以将跨链相关的应用和协议大致分为两类:

• 跨链资产转移:跨链桥、跨链AMM、跨链聚合器等
• 跨链通信:某些知名跨链通信协议等

资产的转移也离不开消息传递。跨链资产转移应用的消息传递层一般由一组链上智能合约和状态更新逻辑构成,将这种消息传递的功能抽象成通用的、协议层的解决方案便是跨链通信协议。

跨链通信协议能够处理更复杂的跨链操作,如治理、流动性挖矿、NFT交易、代币发布、游戏操作等。互操作性协议在此基础上更进一步,涉及到更深层次的数据处理、共识和验证,从区块链系统层面确保不同区块链之间的一致性和兼容性。但在实际使用中,这两个概念往往互为表里、根据语境可以相互替代。

链抽象的内涵包括了区块链的互操作性,但使用语境增加了一层用户和开发者侧的体验改善,这与本周期兴起的意图叙事不无关系。关于意图与链抽象的结合将在下文阐述。

链抽象包含哪些具体问题?

如何实现链抽象?

不同项目对链抽象的理解和切入点不尽相同,在这里我们将其分为从互操作性协议进化而来、更贴近开发者端抽象的古典派,以及结合新兴意图架构、更注重用户端抽象的意图派。

古典派的历史可以追溯到某些知名的跨链生态,它们的诞生要远早于链抽象概念。某些Layer2解决方案作为后起之秀,现阶段专注于以太坊L2生态内的流动性聚合和互操作性。跨链通信协议出身的几个项目也在向更多链扩展,争取更多的客户采用,以期增强自身的网络效应。

意图派内部包括致力于提供链抽象综合解决方案的某些公链,以及从解决具体问题出发的组件类,目前以DeFi协议为主,代表是某些知名DEX和跨链协议。

无论是古典派还是意图派,安全快速的跨链以及友好的交互都处于设计的核心,包括但不限于统一的用户界面、dAPP无缝跨链、gas赞助和管理等。

我们为什么要关注链抽象和意图的结合?

"基于意图的xx协议"层出不穷,本部分将探究其作为一种流行产品架构的原因和潜力。

与抽象和模块化类似,意图也非Web3原生的概念。意图识别在自然语言处理领域已经存在了几十年,并且在人机对话中得到了大量研究。

谈到Web3领域的意图研究,离不开某知名投资机构的著名论文。虽然类似的设计理念在某些产品中已经有所体现,但意图架构的核心正是在这篇文章中被正式提出--用户只需要指定期望的结果,而无需在乎过程,实现任务的复杂过程最好外包给第三方。这与链抽象关注的用户体验改善是契合的,并且提供了一个较为具体的解决思路。

市场上关于链抽象的架构分类众多,比较知名的有某研究机构开发的CAKE框架。这个框架结合了意图架构,将构成链抽象的各种技术和解决方案划分为权限层、求解层和结算层。也有其他框架在此基础上做出微调,如在求解层和结算层之间加入了一层清算功能。

具体而言:

• 权限层:核心是账户抽象,作为dAPP的用户入口请求意图报价--用户表达意图
• 求解层:一般是一个链下的第三方求解器层,用于满足用户意图--solvers竞争订单
• 结算层:用户批准交易后,调用预言机、跨链桥等方案确保交易的执行--用户获得预期结果,solvers获得报酬

求解层的solvers是一群第三方链下实体,它们在不同的协议中被称为solvers, resolvers, searchers, fillers, takers, relayers等。solvers通常需要质押资产作为保证金来获取竞争订单的资格。

用户使用意图产品的过程近似于填写一个限价订单。在跨链情境下,为了使用户的意图尽快得到满足,solvers们通常会先垫付资金,并在结算时收取一定的风险费用(这种模式类似于一项短期贷款,贷款期限=区块链状态同步时间,利息=服务费)。

某些公链为代表的综合类意图解决方案希望将权限层、求解层和结算层组合成一个统一的基础设施产品,目前处于概念验证的早期,难以直接观测和评价其效用。

而以跨链DeFi协议为代表的组件类意图解决方案相较于传统的跨链模式(如Lock & Mint, Burn & Mint)已经显现出较为明显的优势。作为某跨链协议的旗舰产品,其基于意图的架构使其在EVM生态的跨链桥中拥有第一梯队的速度、低廉价格和收费能力,在小额跨链情境中的优势尤为明显。

从路线图来看,某些跨链协议将在未来推出跨链意图结算层。某些知名DEX团队和跨链协议一同提出的新ERC标准试图通过标准化的意图表达降低solver的进入门槛,并构建solver的通用网络。众多组件类产品可能会以拼图的形式渐进链抽象的最终形态。

我们对链抽象的理解和实践有什么问题?

基础设施本位带来了什么问题?

作为互操作性协议