盘点市场中主流 BTC L2 的实现方式

  • blockpunk
  • 更新于 2024-01-22 17:49
  • 阅读 1708

BTC L2 大致分为侧链、rollup、DA 层、去中心化索引等方式,盘点一下各方式的实现方案。

原推: https://twitter.com/blockpunk2077/status/1748652961436492288

作者:https://twitter.com/blockpunk2077

盘点市场中主流 BTC L2 的实现方式,如何引入 BTC 资产与安全性。

长文不易,如果能帮到你,请转发 🔁 与点赞 ❤ 。

by @TrustlessLabs


上一条长推中提到,“铭文”的大发展促进了 BTC 生态的繁荣,但也加剧了 BTC 网络资源的竞争,过高的 fee 成本,与未来可预见的 BTC 的上涨,也在不断地增加 BTC 生态玩家的进入门槛。

这促使了人们跟更多的开始讨论 BTC 的扩容方案,这也吸引了社区与投资者的注意。

当然,人们非常默契地避开了直接升级 BTC L1 的扩容方案,最激进的讨论,也无非是解除一些 OP 脚本的封印,在 Taproot 下继续挖掘 BTC 的剩余潜力(如 CTV 与 CAT 的讨论)。

在 ETH 的 rollup 与模块化的发展和理论成果上,BTC Layer2 成为了扩容讨论的主流,也是见效最快的方案。首批项目也将在未来的两三个月上线,并成为炒作的绝对主流叙事。

由于 BTC 治理的高度去中心化,没有“教会”引导社区,因此其 L2 设计也是百花齐放。本文就将从市场上典型的 BTC L2 与相关协议入手,一窥 BTC 扩容的可能性。

这里大致将 BTC L2 分为侧链、rollup、DA 层、去中心化索引等方式,将我认为类似的项目放在一起说明。BTC 的扩容方案还无人有权做出定义,因此我的实际分类并不严谨。

本文重点从偏实现方案的角度来探讨,很多设计都还在纸面阶段。在二层资产的竞争上,技术与安全性绝定的是项目的下限。技术是车票,头等舱、经济舱甚至挂票都有可能,资产炒作的话,只要达倒及格水平就好。

Image

但从资产的角度来看,一个是 L2 本身创造资产的能力,不管是引入铭文,还是自己拉盘,仅从技术层面上来无法评估;第二个,能否吸引 L1 的 BTC 存入将是核心竞争力,这就非常非常看重桥接的安全性,毕竟“not my keys not my Bitcoins”是核心教义了,这就与方案设计中非常相关。

BTC 生态的采用是否会在未来超越 ETH?也许能给你一些参考。

首先需要介绍前置科技,Taproot 升级带来的2个改变:

🔹 Schnorr 签名为 BTC 引入了最多 1000 个参与者的多重签名方法,这是很多 L2 桥的实现基础;

🔹 MAST 允许一堆 UTXO 的脚本通过 Merkle 树的方式组合,实现更复杂的逻辑,这为 L2 上证明系统提供了可能性;

🔹 Tapscript 升级了比特币脚本,允许验证一系列脚本,来决定 UTXO 是否能被花费,这为 L2 的提款、罚没等操作提供了可能。

侧链

一切为了能用,能用就是一切。

侧链优势就是见效快,以快速发展业务逻辑为主。

其安全性基本只与它的网络本身有关,属于是 BTC 安全性这列火车上的“挂票”,最重要的部分就是 BTC 的跨链桥,这是唯一的连接点。

@BTClayer2 BEVM

实际上大部分 BTC L2 都如 BEVM 一样,延续了 ETH 扩容中侧链的思路。

BEVM 通过 Taproot 的能力在 BTC 的 L1 上部署一个多签地址,并运行者一个 EVM 侧链,在 EVM 中部署了接受 BTC 提取请求的智能合约。BEVM 的 GAS 使用的是跨链后的 BTC。

充值时,桥的运行者同步 BTC 数据并通知侧链,BEVM 节点还运行了轻客户端,同步 BTC 区块头验证充值;提款时,桥的托管人进行签名,收集到一定数量的签名后(门限),提取 BTC 的交易就会发出。这实现了侧链与 BTC 的资产互通。

与传统 $RSK $STX 方案不同的是,BEVM 使用 Taproot 的 BTC 多签实现了门限签名,桥的管理者理论上可以更多,这为 BTC 跨链增加了一定的容错性,更去中心化。

但 BEVM 并不会使用 BTC 的任何安全性保障,仅实现了 BTC 资产互通。其节点运行了自己的内部共识与 EVM,不在 BTC 网络中上传证明,因此没有 L1 DA。

网络的交易抗审查属性依靠网络本身,因此如果节点拒绝打包你的 BTC 提款交易,你将无法再从 L1 上获取 BTC,这是潜在的风险。

这种方式的好处在于能快速实现与验证,BEVM 自行实现的 Taproot 多签在桥的安全性上也更进一步,是目前少数上线主网的 BTC 侧链。

@MapProtocol Map Portocol

Map 也是一种 EVM 架构的铭文侧链,选择将 BTC L1 的 BRC20 跨链到 EVM 上,运行一些低成本的业务。

Map 运行了一个增强的 BRC20 索引器,用户从 BTC 上跨链 Brc20,需要发送新交易在 json 中插入目标链、目标地址等信息,从而被 Map 索引到,出现在侧链上;提款 BRC20 则由 Map Pos 机制下的签名委员会多签发起 BTC 交易。

BRC20 的账本其实在索引中运行,BTC L1 本质上是其可用数据源。

利用侧链较低的费用,Map 链上运行着 BRC20 的 Mint 工具 LessGas,与铭文市场 SATSAT,并通过 Roup 进行 BRC20 的跨链。以铭文为核心的思路颇具特色,吸引了一批用户。

Map 使用经典的PoS共识机制,向 BTC L1 上传检查点数据来增强其安全性。但除了防范长程攻击外,Map 依然没有使用 BTC 的安全性保障,在抗审查的提款、状态变化验证、数据可靠性上并无强化。

@BitmapTech Merlin Chain

由 Brc420 发布的 BTC 的侧链。Merlin Chain 选择使用 cobo 钱包的 MPC 方案来实现 BTC 的跨链,这看起来是个相对保守的选择:MPC 的签名者数量较少,相比 Taproot 升级后的 BTC 多签,在安全性上还有一些差距,但好在 MCP 已经久经验证。

Merlin 使用了 ParticleNtwrk 的账户抽象,可以继续使用比特币的钱包和地址与 侧链交互,不改变用户习惯,这一点值得点赞。相比起来,让比特币用户再回到 Metamask 做交互,这种设计就显得怠惰且简单粗暴了。

Brc420 与 Bitmap 热度够高,已经积累了很多的用户群体。Merlin 继续围绕铭文开展业务,支持多样的铭文资产从 L1 的跨链,并在侧链上提供新铭文的铭刻服务。

@dfinity ckBTC

ckBTC 是 ICP 中通过纯密码学方案,实现的 BTC 的跨链集成,不依赖任何第三方的桥或托管。

ICP 是一条独立运行的 L1 区块链,共识由其独特的 BLS 门限签名方案保证。与共识算法的门限签名绑定的 ChainKey 技术,允许了 ICP 整个网络共同管理一个BTC的门限签名地址,接受 BTC,并通过共识下的聚合签名,来控制这个地址下的 BTC,实现提款。

ICP 还在自己的网络中,使用账户模型复原了 BTC 的全部 UTXO,网络中的智能合约可以读取 BTC 的状态,这约等于在 ICP 网络中运行了 BTC 全节点。

由于此门限签名直接与 ICP 网络的共识算法强绑定,ckBTC 的安全性只与 ICP 网络与 BTC 网络有关,不引入额外的第三方信任假设。

因此,ckBTC 的中 ICP 使用的 ChainKey 门限签名方案,是目前最安全的 BTC 桥思路。但对于提款者来说,如果 IC 网络宕机或拒绝交易,就没法强制从 BTC L1 上提款。同时,ICP 作为独立 L1,安全性由自身保证,与 BTC 并无关系。

数据可用性

BTC 是世界上最稳固的可信数据源,没有之一,因此使用比特币作为可信数据的源头,就变得非常理所当然。

同样,有着 @CelestiaOrg 的 DA 的理论基础,BTC 的数据存储虽然非常昂贵,但也有了作为 DA 层的共识基础。

本质上来说,Ordinals 与整个铭文生态,其实都是利用了 BTC 作为 DA,几乎所有的 “BTC L2” 都会向 BTC 传送数据,但这更像是一种形式主义,代表着美好的愿景。

下面是一些较有特色的设计。

@nubit_org Nubit

Nubit 是一个为 BTC 扩展数据可用性场景的 DA 协议,因为其融资有 Bounce Finance 与 domo 的参与而被关注。

简单来说,Nubit 通过运行 POS 共识组织了一条类似于 Celestia 的 DA 链,并定期将 Nubit 本身的 DA 数据如区块头、交易默克尔树根等上传到 BTC L1 中。

如此,Nubit 本身就由 BTC L1 保存其 DA,而 Nubit 又将自己链上的存储空间作为 DA 出售给用户与其他 rollup 链(DA 套娃)。Nubit 本身没有智能合约能力,需要有 rollup 基于其 DA 搭建。

用户向 Nubit 自身的 DA 层上传数据,这些数据经过 Nubit 的 POS 共识确认后,将进入“软确认”状态,而 Nubit 又会在一段时间后,将链的数据根上传到 BTC L1,BTC 交易完成后,最初用户上传至 Nubit 的数据才会进入最终确认状态。这之后,用户需要再去 BTC L1 中上传数据的标签,这是用于在 Nubit 全节点的默克尔树中查询原始数据。

Nubit 网络的 Pos 共识早期由 Babylon 的 BTC POS 质押支持(将在下文介绍)。

用户通过 BTC 来支付存储费用,为此 Nubit 使用了闪电网络来接受 BTC,状态通道不存在桥的问题,用户可以通过取消通道进行紧急提款,不需要与 Nubit 的 Pos 网络本身交易。

看起来,Nubit 似乎是一个比特币生态版本的 Celestia,没有添加复杂的智能合约功能,也是用来最去中心化的闪电网络进行 BTC 的支付,相对简洁。虽然闪电网络足够去信任,但是使用体验并不够好,难以支持大资金的进出 (状态通道耗尽问题)。

Nubit 与 BTC 一层的关系比较单薄,链本身的安全不被 BTC 担保,在 BTC 上的数据也仅被 Nubit 的节点客户端验证。

Rollup 与铭文数据为什么需要去 Nubit 包装一层,而不直接上传至 BTC?这可能是 Nubit 最需要回答的问题,低廉的费用可能并不能作为核心的驱动。

相对 BTC DA 最大的优势,可能是 Nubit 的 DA 支持了轻节点的抽样数据验证(DAS),这是 BTC 网络无法实现的,这意味着验证 DA 不再需要用户下载 BTC 的全节点。

不再是 fully-on-Bitcoin 的铭文还能获得社区共识吗?Nubit 尝试使用自己链的 DA 替代 BTC L1 链的 DA,面对的可能不是技术的质疑,而是社区共识的巨大挑战。当然,这也是巨大的机会。

@Veda_bitcoin Veda

Veda 协议读取 BTC L1 上特定的 Ordinals 刻录,将其作为交易请求,在 BTC 链下的 EVM 中执行。

用户在 BTC L1 上通过 BTC 私钥签名一个符合 EVM 的交易,然后再去 BTC 上铸造为铭文。Veda 的 EVM 节点会扫描 BTC 区块,一旦交易被 BTC 确认,EVM 就会执行请求,产生状态变化。

实际上,这就是将 BTC 当作了 Veda EVM 的待确认交易池。不过因为 BTC 的性能远低于 ETH 的 EVM,而且一定时间里写入 BTC 区块的数据有限,所以 Veda EVM 一定能执行掉上传到 BTC 上的所有 EVM 请求。

BTC 是 Veda 所有状态的数据源,任何人都可以通过扫描全部的 BTC 区块中的 Veda 请求,复原出 EVM 的完整状态。因此可以乐观地信任 Veda EVM,不存在任何复杂的安全性假设。

但是,Veda 无法扩展 BTC 的性能。可以把 Veda 看做一个区块间隔 10 分钟,TPS 为 5,但拥有数万个节点与巨大 Pow 算力的以太坊网络。

它只是对 BTC 的功能进行了扩展,添加了智能合约能力。这在本质上并不解决资源竞争的问题。

@babylon_chain Babylon

Babylon 是一套帮助其他区块链共享 BTC 安全性的协议,这包函了两个部分,比特币质押服务与比特币时间戳服务。

Babylon 允许通过质押 BTC 为 Pos 链提供经济型的安全保障(类似ETH的restake),质押过程完全以密码学的方式运行,不需要依靠任意的第三方桥与托管方。

BTC 质押者可以在 BTC 上发送一个具备两个 UTXO 输出的交易实现质押,第一个 UTXO 写入了一个时间锁脚本,到期后质押者可以使用自己的私钥解锁 BTC;另一个 UTXO 转给了一个临时比特币地址,这个地址的公私钥对满足“可提取的一次性签名 EOTS”的密码学标准。

当 BTC 质押者运行一个 POS 链的节点时,验证了唯一的有效区块后,使用 EOTS 私钥对它签名。

如果质押者(也是这个POS链的验证者)保持诚实,每次只签名一个有效区块,那么它将获得 POS 链的验证者奖励;如果它试图作恶,在同一区块高度同时签名了两个区块,那么它的 EOTS 私钥就会被反推出来,任何人都可以使用这个私钥去 BTC 链上转走质押的 BTC,实现罚没。以此督促质押者保持诚实。

Babylon 还提供了 BTC 时间戳的服务,也就是将任意区块链的检查点数据上传至 BTC 的 op_return 中,从而增加安全性。

上文的 Nubit 就计划使用 Babylon 的 BTC 质押服务来加强安全性。Babylon 在处理 BTC 的存取、罚没上,使用了纯密码学的方案,安全性很高。但对于使用质押服务的链来说,这在经济学层面上进行了制约,与 ETH 的 Rollup 方式等比较,在可验证上还有一些距离。

时间戳服务虽然将 L2 数据上传了 BTC,但直接检查 BTC 全部区块需要下载全节点,门槛较高。同时 BTC L1 没有智能合约,也无法验证这些数据的正确性。

Rollup

通过 Ordinals,比特币可以存储各种数据,成为一个高度安全的数据库。将 Rollup 的证明数据上传到 BTC 网络中,的确能保证其无法被篡改,但这不能确保 Rollup 内部交易的有效性和正确性。

BTC Rollup 核心问题在于验证。

大多数 BTC Rollup 可能会选择主权 rollup (客户端验证) 的方式,验证者在链下同步 Rollup 的全部数据,并自行检查。

但这也无法利用比特币最强的能力,即数十万个节点的的 POW 共识,来担保 rollup 的安全。最理想的状态,当然是让 BTC 网络能去主动验证 Rollup 的证明,像 ETH 一样,并拒绝掉无效的区块数据。

同时,也要确保 Rollup 中的资产可以在最极端的情况下,去信任的提取到 BTC 网络中,即使是 Rollup 的节点/排序器一直宕机或拒绝接受交易,仍然可以通过安全逃生通道取出。

这对于没有智能合约,只有脚本执行的 BTC 来说,也许能利用 MAST 的能力将脚本组合为逻辑电路,实现可验证,虽然难度较高,但属于 BTC 最原生的思路。

@ZeroSync_ BitVM

BitVM 是 BTC 上最受关注的扩展协议,是 BTC 的一种 optimistic rollup。

BitVM 创新地在提出了一种在 BTC 上进行欺诈挑战的方式,证明者与挑战者进行都在一个交易中存入同等数量的 BTC 进行对赌(作为输入),而这个交易输出将包含一个逻辑电路。

BTC 的脚本可以看做处理最简单逻辑的逻辑门,逻辑门就是计算机的最基本组成部分。逻辑门电路如果通过一种树状的方式互相组合,就能形成一个包函特定逻辑的电路(你可以想象一下三体中秦始皇的人列计算机)。

Image

BitVM 的在大量的 BTC 脚本组成的电路中写入了一个欺诈证明,这个证明的电路结构根据 Rollup 中排序器打包的一系列节点决定。

挑战者可以不断向这个欺诈证明电路上传 hash 值,验证者不断地运行对应的脚本,并揭示输出,来证实其结果正确。

在一系列的交易下,挑战者可以不断挑战证明者,直到证明者证实了每个电路门都是正确的。由此,BTC 网络就完成了对 Rollup 的验证,证明者就可以领会自己的资金。否则,挑战者就会获得证明者质押的 BTC。

用一种好理解的方式来讲,BitVM 与 BTC 的关系好像 OP 之于 ETH 网络,其安全性在所有扩容方案中最高。BitVM 会产生的交易数量非常庞大,成本不菲,而且在参与双方进行链上验证前,需要进行大量的预签名,也就是需要大量的链下计算。

当然,与 ETH 的 optimistic/zk rollup 不同的是,BitVM 并没有紧急的BTC提款通道,L2网络中至少有一个诚实的节点才能完成正常退出。不过这已经是目前 BTC L2 能做到的最高安全保障了,上传了 DA,BTC L1 验证了 Rollup 数据的有效性,信任最小化的 BTC 桥,唯独缺少“紧急逃生通道”。

因此 BitVM 的实现看起来很远,但最近 BTC 社区对于解禁 op_cat 脚本的讨论可能会给 BitVM 的发展带来新的可能。op_cat 操作码可以江两个字符串链接起来,最多支持 520 个字节的长度。这种数据的串联可以在比特币上实现更复杂的计算。比如 BitVM 就可以通过它在同一个脚本下串联上百个逻辑门,这让 BitVM 能够在更少的交易中处理更多的二进制电路,几乎获得了上百倍的增速。

BitVM 对比特币脚本的复杂组合也启发了很多 L2 项目,纷纷基于此提出了新的在 BTC 上进行 “欺诈证明”挑战的思路。

@Bison_Labs Bison Network

Bison Network 是一种基于比特币的 ZK-STARK 主权 Rollup(客户端验证) 。

所谓主权 Rollup,即 L1 被当作 Rollup 的区块数据公示板(DA)使用,不验证 Rollup 交易是否正确, Rollup 交易被 Rollup 自己的节点验证。

Bison 将 Rollup 的 zk 证明提交到了 BTC Ordinals 中,用户可以可以从 BTC 下载证明,并运行自己的客户端来验证 Rollup 交易。如果需要验证 Rollup 的全部状态,就需要同步全节点。

Bison 的特色在于与 BTC L1 桥的实现。当一个用户向 Bison Rollup 存 BTC 时,这个 BTC 会被分给为多个包函了 BTC 的多签钱包中。这些多签钱包都支持了 DLC (Discreet Log Contracts),该技术以 Taproot 升级为基础,是一种利用了 BTC 多签与时间锁定脚本的简单逻辑合约。

当用户存入 BTC 时,需要同 Bison 网络一起,对未来的所有的情况签署相关的执行交易,比如: 1️⃣ 转账给他人的情况 2️⃣ 提取回 BTC 主网的情况 3️⃣ 长时间无人提取的情况。

签署后,这些交易并不会被发布到 BTC 区块中,交易若想执行,就需要预言机来驱动。多签钱包的控制者有三个,即用户、Bison Rollup、预言机,获得其中任意两个签名,就可以获得这些 BTC 的控制权。

DLC 就像是比特币上的 if-do 语句,预言机就来输入 if 的条件,do 的执行部分就是发送上述签署的三种情况下的交易。

这里的预言机链接着 Bison Rollup 的桥合约,如果桥收到用户的请求要将 BTC 转移给他人,预言机酒发送前情况 1️⃣ 下签署的交易,多签名的地址控制权给到 Bison 网络,进一步分配;如果收到用户的请求,发送 2️⃣ ,控制权移交给用户;如果长时间没有收到消息,则时间锁到期,控制权回归用户。

由此,Bison 实现了对从 Rollup 中提取 BTC,并设定了一个简单的逃生通道。不过这里的系统薄弱点在于预言机,如果传递错误信息,就会导致用户的资产丢失,因此可以考虑引入去中心化的部分,比如 chainlink。

DLC 实现的“去信任的桥”是对 BTC 脚本潜能的挖掘,http://DLC.link 使用它将 BTC 跨到 ETH 与 STX 等链中使用。

Bison Rollup 虽然通过引入新的第三方,实现了简单的“逃生通道”,但依然没有实现 BTC L1 验证 Rollup 证明。

@BsquaredNetwork B² Network

B² Network 是 BTC 上混合了“承诺挑战”的 zk Rollup。网络分为两层,Rollup 层与 DA 层。

Rollup 层采用 zkEVM,运行智能合约逻辑,这一层包含了多个模块,这包括了交易的接受、排序和打包,ZK 证明的产出,支持 BTC 地址的账目抽象,同步读取 BTC L1 数据 (BTC与 BRC20 余额)。

DA 层为 Rollup 提供了数据存储,存储节点对 Rollup 交易进行链下的 zk 验证。完成验证后,DA 层节点将 Rollup 数据写入 BTC 的 Ordinals 铭文中,这包括了 Rollup 数据在 DA 层中的位置、交易的默克尔树根、ZK 证明数据,以及上一个 BTC 证明铭文的 hash。

对证明的验证是核心。在 ETH 中桥接合约在 L1 上直接验证 ZK 证明,而在 BTC 上并没有智能合约功能,由于 ZK 验证的逻辑复杂,也无法通过组合 BTC 脚本实现验证的逻辑电路(成本巨大且可能超过BTC区块上限)。

因此 B² 在验证中引入了更多链下的计算,将 L1 对 ZK 对直接验证,转化为一种类似于Optimistic 的 “欺诈证明”挑战。B² 将 ZK 的证明分解为不同脚本,将这些脚本叠加组成了 Mast 二叉树。B² 节点通过这个交易发送了 BTC,做为欺诈挑战的奖励。

Image

包含“欺诈证明挑战”的交易一旦在 BTC L1 上确认,挑战者就可以从 DA 层下载原数据,在链下执行上述的脚本。

如果执行最终输出与 B² 节点提交的不一致,说明节点作恶,挑战者可以获得节点锁定在脚本根中 BTC 的控制权,同时 rollup 交易都会回滚。

如果在锁定时间内没有挑战,那么节点就可以取回锁定的 BTC,Rollup 获得了最终的确认。

B² Network 中,第一个发完 BTC 的交易确认了 zk 证明的不可篡改。虽然 BTC 还是没法验证 zk 交易,但是通过在第二个交易中实现 “欺诈证明挑战” ,间接的完成了 L1 的验证,保证了 Rollup 下交易的有效,增加了安全性,这的确是亮眼的创新。

B² Network 于引入了账户抽象,在不改变用户习惯的情况下,让大家直接使用 BTC 的钱包与 Rollup 交互,这是非常值得称赞的地方。但在 BTC 资产从 L2 的提取上,依然使用了多签地址桥的方式,没有引入“逃生通道”。

@SatoshiVM SatoshiVM

SatoshiVM 也是基于 BTC 的 ZK Rollup,其逻辑与 B² Network 类似,都在 Rollup 中生成 zk 证明后,证明者将证明数据上传到 BTC 网络后,再发送一个包含了 BTC 的“欺诈证明”挑战,挑战成功者将获得 BTC 奖励。

不同的是,SatoshiVM 在“欺诈证明”挑战中加入了两个时间锁,对应挑战开始时间,与挑战结束世界,这样通过比较 BTC 发生转移等待了多少个区块,就可以亲送分辨出 ZK 证明是否正确有效。

其跨链桥的部分,实际上只是使用了多签的方案,并无亮点。

@chainway_xyz Chainway

Chainway 是一个 BTC 的 ZK 主权 rollup,不仅仅使用比特币作为数据的发布层,还将 BTC 的数据作为生产 ZK 证明的源。

Chainway 的证明者需要一个不漏地扫描每一个 BTC 区块。从 BTC 区块中读取区块头,上一个的 zk proof,以及区块中刻入的“强制交易”,才能生成一个完整的 ZK proof。每一个 BTC 区块中,Chainway 都会提交一个刻录 ZK proof 的交易,从而形成递归的证明。

Image

在 BTC 区块中,以 Ordinals 铭文形式刻入的“强制交易”,是 Chainway 设定的“抗审查交易发送方法”。如果 Chainway rollup 节点宕机,或一直拒绝接受来自用户的提取交易,用户可以将提取请求的直接刻入比特币区块。节点必须将这些“强制交易”包含到rollup的区块中,否则将无法满足 zk 电路的约束,proof 生成将失败。

在最新的推特上,Chainway 号称来自于 BitVM 的灵感,他们已经找到了在比特币上验证 zk 证明的方法,来实现 BTC L1 的结算。

显然,目前 Chainway 的设计基于主权 Rollup 的客户端本地验证。虽然“强制交易”在一定程度上解决了 Rollup 交易的抗节点审查问题,但是还是无法实现真正的 BTC L1 资产结算。

@QEDProtocol QED Protocol

QED Protocol 是 BTC 上的 ZK rollup,基于 zkevm 运行。与其他 zk rollup 不同,QED 没有选择为整个 Rollup 的交易生成 zk proof,而只为从 rollup 到 BTC L1 的提款交易创建 ZK proof。

与 BitVM 的思路类似,QED Protocol 将脚本组成逻辑电路,从而在 BTC L1 上对提款交易的 ZK proof 进行了验证,这类逻辑电路将包含 1000 个 UTXO,虽然实现了直接验证,但成本耗费巨大。

面向索引编程

如果追根溯源,Brc20 本质是就是一种 BTC L2,Brc20 的所以交易数据都被记录在 BTC 上,而账本实际上在链下的索引器中运行。

虽然目前的 Brc20 账本本身都是完全中心化的,但是我们很少担心其安全性,因为 BTC 网络的 Ordinals 中不可篡改的记录着所有的交易记录,任何人都能通过扫描 BTC 网络,从而复原出 Brc20 的状态。

但是这种扩容只为 BTC 添加了新功能,对扩展其性能上并无帮助。如果对索引器中的账本进行去中心化,那是否能创新一条铭文链呢?

实际上, @unisat_wallet 推出的基于 $sats 的后续业务就是这个思路,swap 与 pool 就是在其索引器中实现的,如果想获得资金安全的共识,去中心化是必然的过程。

也有 @RoochNetwork 这类完全不从 L1 获取资产,而只是运行索引和 BTC 全节点,通过只读取数据供其链上智能合约使用的只读型 L2。

最后

当然,也有很多我没有介绍到的项目,部分因为其描述不详,部分因为我精力有限。

行业瞬息万变,每一秒都有新的 BTC L2 诞生,但不变的是 BTC 生态向二层发展的必然趋势。

BTC 就是一趟人人都想扒上去的火车,仅从方案上来说,侧链们就是买了挂票的乘客,仅用跨链桥与 BTC 产生联系,但它们能最早的被使用。

DA 类型的项目是试图建立 celestia 与 eigenlayer 的 BTC 版本,噱头上做足,在模块化的广泛共识下也存在机会。

而 rollup 们通过上传 DA,并使用 BTC 脚本实现一些简单的 BTC 链上机制(大部分都是借鉴 BitVM 的 bit commitment 思路),勉强地算是半只脚踏入了 BTC 安全性的车厢。谁说依靠自行验证的主权 Rollup 不是 Rollup 呢?(都需要去感谢 Celestia 对主权 Rollup 的长期 CX)

BTC L2 皇冠上的宝石,就是使用 BTC 脚本逻辑去验证 Rollup 上传的证明,目前只有 BitVM 与 #Atomicals 的 AVM 在尝试,这已经无限接近于 ETH 于其 Rollup 的安全性关系。目前在实现层面上看起来遥不可及,不过 op_cat 这类新操作符的解封,看起来能进一步加速它的进程,BitVM 可能比大家预估的更快地被实现。


更新:

忘记带上经典的 #Atomicals 环节了,补上。

众 L2 比较看好两类:

🔹 一种是本身自己在 BTC L1 就上发了资产就有热度了,用户进入快,会带来很多 BTC。

🔹 一种是从技术层面上来看,用到比特币脚本做实现的(验证 or 桥),这种更安全,存 BTC 放心。

Atomicals 两个都占上了。

点赞 2
收藏 1
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
blockpunk
blockpunk
|尝试成为一个 BTC Wizard ?‍♂️| |胡言乱语假扮先知 ?| |自以为是的 degen ? | @TrustlessLabs