https://mirror.xyz/0x5c6683e79e1Db842dBa9B527269ed39108D33773/-q3Cg3X8M2zUJJZToESFa8CA50mMhNio0HdAZQpjEcg

其实从 wBTC 被 Coinbase 和 Maker 提出质疑之后，关于 BTC wrap 这类资产的解决方案就在不断改进，从 wBTC 这类 permission 改进到 Permissionless 类的 tBTC，从 wBTC 和 tBTC 这类不生息的资产改进到生息的 LBTC 等。LBTC 是 Lombard 的 BTC LST 名称，接下来将从几个方面详细介绍一下。

Architecture

从架构上来说，对于 BTCFi 项目来说，其实最关注的点应该在托管 BTC 资产的部分，因为在前面分析 Babylon 的时候提到过因为 BTC 没有智能合约，所以很难去构建像 ETH LST 那样的 Trustless 。如果再细化这个问题的话，其实归结于两点

• BTC Reserve 的资产有多少

• 管理这些 BTC Reserve 的资产的 Key 是怎样的

据我了解到的目前多数 BTC 项目都是采用的 Cobo 的 MPC 多签方案，Cobo 的多签方案主要是由几个实体来掌控，Cobo 会作为一方持有 Key 的一部分，剩下的由项目方或是其它实体来持有 Key 的剩余部分，部分 Key 持有的安全性由各自掌管的实体负责，这还是多少有点中心化的意思。

https://www.cobo.com/developers/v1/api-references/mpc-wallet/babylon_prepare_staking

而通过 Lombard 架构来看，其并没有采用 Cobo 的方案，而是采用了 Cubist 的方案，Cubist 基于 AWS 的 TEE 方案构建了一种私钥的管理方案，任何一方都无法拥有。

Cubist’s non-custodial key manager protects your staking keys with secure hardware, and uses short-lived, revocable privileges to sign transactions and validation messages according to policies you set. No one can see, copy, or steal your secret keys (or get you slashed!)—even if your system gets hacked.

Key 的这部分也使得我对 Lombard 比较看好，接下来我们将对 Key 部分继续深入。

Key 的再深入

BTC Reserve 的资产数量是对于汇率和 Unstake 的一种资产保证，但是我认为质押 BTC 的托管钱包的 key 的安全是至关重要的，因为如果 Key 不安全了，那么所谓的这种资产保证也就从无从谈起了。

tBTC 采用了自己独创的门限签名生成 pub key 的方式来管理 Ethereum 和 Bitcoin 的交易，每次签名的 node operator 通过随机选举，选中的 node operator 通过再次随机分配的门限权重来完成签名。Stacks 的 sBTC 则是通过随机选取 stcaking 的 node operator 来多签处理 Stacks network 和 Bitcoin 的交易。

这其实就给出了一种 Key 去中心化的思路

• 首先生成 Key，而这个 Key 无法被任何一方知晓，但是可以被验证，这正是 Cubist 的 non-custodial key manager 实现的

• 其次 Key 处理的签名交易由去中心化的网络来验证和处理，比如可以使用基于 Babylon 构建的 Nubit POS 或是 Ethereum 的 restaking 相关的网络

• 最后保证上述两个方面可验证

BTC Trustless Staking

经过前面的探讨，这里我们似乎可以得到一种满足 BTC Trustless Staking 的解决方案

• 使用 Cubist 的 non-custodial key manager 来生成管理质押 BTC 的资产地址的 Key，这一点 Lombard 已经满足。

• BTC stake/unstake 相关的交易签名由去中心化的 POS 或是 Restaking 网络来验证，或是采取类似 tBTC 自己构建的验证网络，这一点 Lombard 还未做到 Permissionless，希望后续能够支持。

• BTC Reserve 的资产可以实时被验证，这一点 Lombard 已经采用 Nubit 的方案实现。

Lombard 的其它做的好的方面

Lombard 在 DeFi 方面也是目前 BTCFi 里面做的最好的，主要体现在以下几个方面

• LBTC 几乎没有 Peg，并且开了 unstake，TVL 依然是快速增长

• LBTC 有着最大的流动性，不管是在 Ethereum 还是 Base 上，LBTC 的流动性都在 10M+ 级别

• LBTC 在支持的 BTC 质押资产范围方面谨慎，目前只支持 cbBTC/bBTC 和 native BTC

以上这些都是持续看好 Lombard 的理由。最后附上 LBTC 质押地址

• 质押/解质押链接：https://lombard.finance/app/?referrer=lu0ivs…

• DeFi integration：https://lombard.finance/app/vault/

Background

BTC 由于在设计之初主要场景是记帐，并未有可编程构建应用的场景，因此在激活 BTC 时存在一些限制，主要是以下几点

• 去信任桥（Trustless Bridge）： 因为 BTC 链本身没有类似 EVM 的机制，如果想要构建 BTC 相关的应用，则需要将 BTC 资产映射到支持可编程的链上，而这个过程因为 BTC 本身的限制，很难去构建信任桥，目前的主要解决方案包括 MPC 多签、侧链等形式，都不是完全的 Trustless。

• **原生 BTC 收益（Native Yield）：**BTC 本身是基于 POW，并未有质押的原生 BTC 收益。

Babylon 基于以上几个问题，提出了自己的解决方案。

Specification

Overview

为了确保 BTC 资产的安全，Babylon 直接在 BTC 链上完成质押，这种方式避免了使用复杂的跨链方案可能带来的安全问题。

质押奖励通过 Babylon 链还以 BBN 代币或与它绑实的项目代币按照奖励系列发放。Babylon 链是基于 Cosmos SDK 构建的。奖励的分发方式类似 Eigenlayer。

更多细节，可参考官方文档：[https://docs.babylonchain.io/docs/introduction/architecture](https://为了确保 BTC 存活的安全，Babylon 直接在 BTC 链上完成存活，这种方式避免了使用复杂的跨链方案。存活奖励通过 Babylon 链还以 BBN 代币或与它绑实的项目代币按照奖励系列发放。Babylon 链是基于 Cosmos SDK 构建的。 更多细节，可参考官方文档：https://docs.babylonchain.io/docs/introduction/architecture)

Remote Staking

为了解决BTC跨链的问题，Babylon并没有依赖传统的POS链多签验证机制。相反，它是用户直接在BTC链上操作进行质押。质押、解押和惩罚（slashing）都通过UTXO机制完成，而奖励则由BBN链进行管理。

Stacks sBTC 提出的解决方案是由 Stacks 的 Validator 去验证和完成 BTC 质押和转移的多签操作，其它的基于 POS 的侧链也是类似操作机制。

虽然这种方法提高了安全性，但也增加了用户的操作复杂性。他们需要同时处理BBN链和BTC链上的交易，这可能会影响用户体验，也就是用户需要在多个链之间进行切换操作和签名。

Timestamp & Timelock

To prevent potential attacks, it's important to note that BTC staking happens on the BTC chain, while block voting occurs on the PoS chain. An attacker would need significant resources to launch an attack, but they could slow down the PoS chain's block production, allowing expired stakers to validate PoS blocks. This loophole could let the attacker cancel BTC staking while keeping voting rights on the forked PoS chain. To prevent this and ensure quick staking, the PoS chain must sync closely with the BTC chain, achieved through "Bitcoin timestamping," recording PoS block data on the BTC chain.

为了防止潜在的攻击，需要注意的是，BTC质押发生在BTC链上，而区块投票则发生在PoS链上。攻击者需要大量资源才能发起攻击，但他们可以通过减缓PoS链的区块生产速度，使过期的质押者有机会验证PoS区块。这个漏洞可能使攻击者能够取消BTC质押，同时保持在分叉后的PoS链上的投票权。为了防止这种情况并确保质押操作的快速性，PoS链必须与BTC链紧密同步，通过“比特币时间戳”实现，即将PoS区块数据记录在BTC链上。

鉴于与每个BTC区块同步的高成本，Babylon 通过 IBC 跨链聚合时间戳并与BTC链同步进行优化，在确保安全性的同时降低了成本，反映到用户操作上，就是在链上进行操作时 gas 降低了。

对于BTC链的质押，Babylon使用现有的UTXO机制完成质押和解押操作。质押BTC意味着通过UTXO创建一个设定解锁时间的交易。当达到该时间时，交易将自动解押BTC。

Slash

由于比特币缺乏智能合约，向比特币网络提交区块链损害的证据不可行。为了解决这个问题，Babylon 引入了一种惩罚机制，通过公开质押者的私钥来实现。为了保护该私钥，在共识后通过一次性签名验证区块，然后进行 EOTS 签名投票。如果一个区块获得超过三分之二质押权利的 EOTS 签名，则该区块被确认；如果发生区块链损害，则当三分之一的质押者签署两个区块时触发私钥提取，从而完成惩罚。

Liquid Staking Challenges

Babylon的BTC流动质押面临着复杂性和挑战，尤其是与以太坊相比。这些挑战包括：

• 去信任化的质押池（Trustless Staking Pool）：Babylon 时直接在 BTC 链上进行质押，绕过了智能合约的需求。然而，对于 LST 来说，则绕不过，由于比特币缺乏智能合约功能，在 BTC 链上建立去信任化的质押池非常困难。目前的解决方案类似于BTC跨链，采用多签名机制。

• 奖励分配（Rewards Distrbution）：将 BTC 质押奖励转化为 BTC 对于确定 BTC LST与 BTC之间的兑换率至关重要。然而，由于奖励存储在 BBN 链上，想要将其转换为 BTC，需要在 BBN 链上使用包装的 BTC，这种做法似乎与Babylon 的设计理念相矛盾。另一种方式是类似目前 Eigenlayer 的奖励分发方式，就是按周期用户去 Claim BBN 奖励，但是 BTC LST 和 BTC 的汇率始终保持在 1，这有点类似于 BTC LST 更多是充当 BTC 在其它 EVM 链的稳定币。

• 用户体验差：Babylon以安全为核心的设计需要在不同链之间进行多重签名和操作，这对用户体验有较大的挑战。

关于目前市场上已经出现的项目，后面系列我们将详细分析，之前有简单的提到过，可以查看

https://x.com/signal0x/status/1849461674530492722

https://x.com/signal0x/status/1849837754554671196