百链竞发下半场 BTC layer2市场该何去何从?

最近,整个一二级市场都承受着黑云压城般的压抑,有很多声音发问,BTC layer2的下一步到底该如何走? 答案显然不是东西方资本互不接盘那么简单,在深入调研多个代表性项目之后我有了深刻理解。

在我看来,破局点主要有三:1)资产发行“新”叙事;2)layer2 “标准”收窄;3)BTCFi生息大幕开启。接下来,系统说下我的看法:

资产发行“新”叙事

BTC生态随着Ordinals、BRC20、BitVM、Runes、Layer2的衍生发展至今,陷入了技术越来越趋于明朗,造富效应却越来越弱的困局当中。Why?根本原因在于,造富仅来源于存量资金信息博弈差,而技术迭代还无法吸引增量资金入场。

以漏洞百出的BRC20和含着金汤匙出生的Runes协议为例,BRC20尽管被百般诟病,但确实制造了财富效应把一大部分注意力吸引到了BTC 衍生市场,而后续在数据存储、索引逻辑甚至玩法都趋于成熟的Runes协议上,并没有预期的市场反响。

难道说,技术迭代发展方向错了吗?OP_Return剔除UTXO垃圾交易的导向错了吗?Premine预留机制的设计思路错了吗?显然不是,我更觉得 BRC20铭文掀起造富效应是特殊大环境背景下,纯信息差带来的偶然性现象,BTC 资产发行的叙事能不能跑的通,一定不是“first is first”,而是项目方的持续价值赋能。

因此,之前BTC主链绑定UTXO发行新资产的方式,只能让享有信息差的early birds获利,要让BTC 衍生资产的发行故事持续性感,需要从短期和长期分别解决两个困局:

1)短期资产流通性难题:发行BTC衍生资产,让一部分早鸟mint到一堆资产不是目的,要让这些资产流通起来通过换手产生价值才是。显然,仅凭BTC主网来承接铭文资产的流通行不通了,可以把资产跨链到二层在相应的应用生态市场内寻求激活流通的可能性。

@NervosNetworkCKB通过RGB++协议,实现了让BTC主网铭文资产Leap到CKB layer2链进行流通的思路,这种方案能解决资产的流通问题,尤其是一些有持续增长力的优秀资产。

2)长期项目赋能难题:虽然Runes协议在资产发行上足够有主流共识,项目方也可以通过Premine的方式控筹,但如果从主网发行资产制造热度,再去二层流通的思路,会导致项目方运维初期有庞大的运维成本。在市场Fomo情绪下Premine代币的成本,发放空投的高手续费成本,社区营销和运维成本等等,顶着这些成本压力,跟项目方谈“赋能”问题会很无力。

@RoochNetwork,一个基于MoveVM驱动的BTC Native layer2项目,通过Parallel的BTC全局状态同步,可以实现让一个BTC铭文资产先在layer2环境下低成本发行并做初期流通,然后在铭文资产具备一定市场规模和共识之后,再迁移到BTC主网,进行共识升级。这种围绕Assets资产流通目标为导向的叙事设计,目标就为解决BTC生态项目方赋能难的困局;

总之,BTC发展layer2生态,资产发行叙事只是个开始,变局点就在于这些纯社区驱动的资产,能否在1层或者2层找到一个强大项目的赋能,并在layer2市场生态内表现出不错的流通价值。

layer2“标准”收窄

过去一年内,BTC生态经历了野蛮生长的混序发展阶段,“无方向、无标准、无门槛”让BTC layer2赛道快速挤满了Builder:EVM- Compatible、UTXO Stack同构绑定、UTXO平行堆叠、BitVM链下图灵完备、RGB原生、AVM虚拟机等等,筹备中的BTC layer2据说已有上百条之多。但哪个方向能跑出来,目前尚无定论。

不过,BTC layer2市场的大乱斗并没有真正给BTC生态带来显著的增量,在市场陷入沉寂时,又时不时听到BTC layer2是否伪命题的争议。尽管“无标准”给了BTC layer2更多“拿来主义”的可能性,但把已经成熟的扩展方案直接缝合到本就局限很大的BTC主网上,未必能把二层的扩展增益回馈给主网,反倒会因安全和稳定性问题,给BTC主网用户群体带来伤害。

在我看来,BTC layer2无标准阶段的繁荣景象即将过去,BTC layer2接下来会趋向技术门槛更高的方向进阶:

1) UTXO Stack结构框架:Nervos CKB团队基于RGB++技术协议扩展出来的一套可标准化的BTC layer2构建方案,被视为融合BTC主链扩展起来最Native解决方案。因为UTXO Stack结构继承了原生BTC的简洁性和安全性,短期内可以视为一种相对主流的BTC layer2方向。最近RGB++ layer的协议升级和UTXO Swap的工程实现,都为BTC生态开发者基于UTXO结构扩展比特币生态提供了基础基建;

2)zkVM通用协议框架:@ProjectZKM基于zkMIPS微处理指令架构构建了一整套ZK Bridgeless跨链、以及Entangled rollup Network可交互操作性层等,通过ZK技术在跨链可信验证的绝对权威性为BTC生态引入了一种Native的通用“跨链”方案。

其技术原理类似于RGB的Peg-in和Peg-Out的Commitment校验和解锁机制,同时采用了BitVM2的挑战机制。相较之下,zkVM的协议框架可以给Non-UTXO结构类型的公链Native接入BTC生态的可能性,会成为一种范围面更广的ZK技术加持的layer2扩展方案;

3)RGB客户端验证框架:Native的RGB协议方向,通过P2P的链下客户端infra的系统构建,基于one single seal一次性密封+状态通道等技术实现原生的BTC二层扩展方案,可支持智能合约等复杂应用,同时还能接轨闪电网络,扩大支付场景的应用扩展。比如:@BitlightLabs正致力于为RGB协议配套一系列钱包、DEX等基础设施;

4)AVM虚拟机框架:通过模拟比特币虚拟机,让原本无状态的比特币主网可通过嵌入一套特殊编码实现搭载智能合约的能力。这是一种既不依赖链外扩展,也遵循当前比特币核心OP Codes的“原生”拓展方法。比如:@atomicalsxyz一直在尝试做的事情。

总之,选择高技术门槛,收窄layer2标准势必能够清退市场上一些“追风作乱者”,让更多有实力的开发者能够在资本支持下,进一步拓展出适合比特币所需的扩展生态。尽管,这个探索周期会比较漫长,好比以太坊layer从Plasma、Validium再到Rollup主流也经历了长时间的探索。

BTCFi生息大幕开启

不知何时,BTCFi悄然成为BTC生态的叙事和话题焦点。起初我也很费解BTCFi和DeFi的区别,莫非是过去DeFI以“去中心化”为中心,现在BTCFi以“BTC公链”为中心?不过,要让拥有庞大社区共识的孤链资产成为盘活全链流动性的催化剂,那些更领先的高性能技术也势必都得向BTC老祖宗妥协让步。

鉴于BTC链特殊的脚本语言和无状态存储的Programmable受限性,这么说很make sense。因此在我看来,BTCFi概念范围内应该包含三个主要特性:

1)Inclusive资产包容性,除了BTC Native资产之外,BTCFi舞台的主角一定包含Runes、ARC20、BRC20等各类BTC公链上的衍生资产,如果BTCFi不以盘活BTC生态的更多衍生资产为目标,仅仅是BTC资产的流出和Wrapped BTC的已有DeFi生态很难区分开。

2)Native免跨链特性,也可以成为Bridgeless无跨链桥或免信任机制。基于原生跨链特性才能确保BTC和衍生资产的流进流出不会存在“中心化”信任环节,这会为BTC相关资产的生息提供绝对技术前提。唯有此再在layer2上做POS的Staking和Restaking等生息行为,才能保持一个绝对的链上可追溯和公平性,为一系列丰富的BTCFi生息玩法奠定基础。

3)Programmable复杂可编程特性,无论UTXO Stack架构还是zkVM协议底层架构,它们可接入的链下扩展环境一定具备复杂的可编程特性。短期内,UTXO有结构化同源优势,更容易产生落地应用,长期看,ZK技术可以成为BTC链入EVM或MoveVM等高性能公链环境的有力接口,届时BTCFi能发展出什么样的生态,长出什么样的花,想象空间就无限大了。

比如:@GOATRollup基于zkVM技术框架构建“Native安全跨链”和“统一流动性层”特性,并以GOAT Stack的堆栈方式来为BTC layer2市场提供一种技术基底扎实的扩展方案;

另外前边提到的Rooch Network,其Native技术方案目标为BTC提供应用场景(Utility)的同时再给BTC资产提供生息收益(Yield)可能性;UTXO结构的RGB++ layer更是如此。它们提供的解决方案都在最大限度靠近这三个技术特性。

不过,BTCFi在跑出来之前我更倾向于视其为一种生态开拓方向,现在沉闷的市场环境远无法支撑BTCFi从DeFi之中脱颖而出。因此,技术标准不是判断一个项目是不是BTCFi的硬性条件,只要有一定市场共识都可以加入BTCFi的范畴,毕竟除了技术方法论之外,最关键得向市场交答卷。好比,Blast到现在都不被主流人群视为layer2,但不妨碍它给layer2行业带来的影响。

以上。

Note:BTC layer2市场虽然资产发行、layer2标准、生息方案等目前还是杂而乱,但我其实看得到“Keep Optimism”的信号。至于铭文市场热潮会不会卷土再来,layer2能不能出现以太坊一样的盛景,BTC生息能否打破虚拟货币和现实世界的鸿沟,答案都在你我的乐观情绪当中。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注