Arbitrum网络上Uniswap日交易
深入探讨比特币Layer 2概念
来源:Biteye
谈起 Layer 2 大多数人会想到以太坊的一众二层项目,比如 Arbitrum、Zksync、Optimism、StarkWare 等,也有人会说 Layer2 概念本起源于比特币闪电网络,后来才被 Vtalik 应用到了以太坊之上发扬光大。这些都是事实,只不过视角不同。
Layer 2 的概念并非比特币或以太坊独有,而是区块链技术中的一个扩容技术的大方向。
Layer 2 是指建立在主网之上的一套链外解决方案,目的是在不牺牲去中心化或安全性(敲黑板!!)的情况下提高交易吞吐量。
而随着 BTC 扩容叙事不断发酵,涌现出了五花八门的 BTC Layer 2 项目。Layer 2 逐渐从以技术为导向的区块链扩容路线变成一个模糊的营销标签。
本文将针对此贴着 BTC Layer 2 标签的项目做一个简单的技术梳理。要注意,在这个由热度主导的市场上,技术对行情的影响往往是次要的。同时由于笔者自身局限,有些技术观点可能会和外界有所出入。欢迎大家加群讨论。
全文不构成任何投资建议。
01 绕不开的老话题 Layer 2 与 侧链的区别?
上文提到了 Layer 2 技术的目的是在不牺牲去中心化或安全性的前提下为主网扩容,因此在狭义上也并不是一个单一的技术概念,而是包含了多种不同的方案和实现。
目前,最常见的 Layer 2 技术有两类:状态通道(State Channel)和 Rollups。
状态通道是指在主网上建立一个双方或多方之间的通道,然后在通道内进行多次交易,只有在通道开启或关闭时才需要在主网上广播交易。
BTC 的闪电网络正式采用的这种方案,通俗的讲,闪电网络的通道可以理解成一个多签地址,Bob 和 Alice 在主网上分别向这个通道(地址)存入 BTC 后,双方通过闪电网络开展日常交易。
这些日常交易并不上主网,因此节省了昂贵的 Gas,待有一天,双方认为不再会进行交易时,双方可以向主网发起提款命令,这个命令的签名可以向 BTC 主网证明双方在主网之外一系列交易账本的真实性。
在此刻主网的安全共识会介入为 Bob 和 Alice 结算并放款,因此发生在闪电网络之上的交易也就具备了 BTC 主网的安全水平。目前,这种方案没有实现智能合约的先例。
Rollup 大家可能更为熟悉,以太坊上的 Optimistic Rollups 和 Zero-Knowledge Rollups 都是以太坊的 Layer 2 扩展解决方案,旨在将复杂的执行和状态存储过程移至 Layer 2 来提高吞吐量。
通俗的讲,主网会验证 Layer 2 定期提交到主网上的 Proof 以保证 Layer 2 账本的真实性(这个验证过程尤其重要)。
如此,主网就可以「实时」掌控 L2 账本,待 L2 资金跨回主网时,ETH 主网的安全共识将会介入,主网的 Layer 2 放款合约可以在不依靠第三方信息来源的情况下,仅凭经过主网共识产生的数据来核实是否可以放款。
读到这里,相信不少读者可以意识到传统的 Layer 2 的本质是一个安全性与主网相同的跨链桥。有了这个意识,我们就能很好的鉴别侧链了。
侧链是指在主网之外建立一个独立的区块链网络(比如 BSC),主网的共识无法鉴别侧脸跨链行为的合法性。
通向侧链的跨链桥把主网上资产锁定并映射到侧链上,随后在侧链映射出的资产可以实现交易转账等功能,而在侧链回到主网时,主网的跨链桥合约只会核实侧链跨链发出的放款的消息本身的真实性,而不会验证侧链的账本。
换句话说如果跨链桥项目方作恶,恶意签名,或者侧链直接制造假账本,主网端的资金都会受到损失。
不难看出,如果按照传统的 L2 定义,观察主网是否可以验证主网之外的账本就能判断一条链是否是 Layer 2 的关键。
有了这个观念,就不难解释为什么 ETH 上线晚于 BTC,却可以实现反超,抢先异步做出了 Layer 2 了。
02 BTC Layer 2 的技术难点——验证
想要弄清 BTC Layer 2 的技术难点,要先了解为 BTC Layer 2 创造可能性的 BTC Taproot 升级。
Taproot 由 Bitcoin Core 贡献者 Gregory Maxwell 于 2018 年首次提出。Taproot 是一项比特币协议的改进,初衷是提高比特币交易的隐私性和效率。
Taproot 的核心思想是让多种条件下的交易看起来像普通的单签交易,从而减少链上数据的占用和泄露,让复杂交易(多签、时间锁)像单个比特币交易那样执行。
Taproot 可以 Taproot 升级引入了 2 个重要的技术,用来为未来的 BTC Layer 2 创造可能。
1)MAST(Merklized Abstract Syntax Tree 默克尔抽象语法树);
2)Schnorr 签名;
MAST 是一种将复杂的脚本分解为多个子脚本,并将它们组织成一个默克尔树的结构,只有在满足某个子脚本的条件时,才需要公开该子脚本的哈希值和内容。这样可以节省空间,提高灵活性,增加隐私。