BTCFi：比特币DeFi的潜力与挑战？

什么是 BTCFI？全面解读 BTCFI 潜力与挑战

本文深入分析了比特币编程如何支持多种 BTCFI 应用。通过对多签名、时间锁、哈希锁等机制的解读，以及对 DLC、PSBT、MuSig 2 等工具的应用探讨，文章展示了比特币在无需信任前提下实现去中心化清算和复杂金融合约的可能性。这种原生于比特币网络的去中心化金融体系，不仅克服了 WBTC 时代跨链桥接模式的中心化风险，还为比特币持有者提供了更为稳固的信任基础。

今天本站小编就给大家详细介绍 BTCFI 是什么？BTCFI 未来潜力和 BTCFI 将要面对的哪些挑战，以及比特币上涨后的趋势！下面一起看看吧！

摘要

本文从比特币编程的可行性与演进路径入手，系统探讨了比特币在去中心化金融（BTCFI）领域的潜力与挑战。比特币在架构上采用了 UTXO 模型，并通过其独特的脚本语言和操作码形成了以验证为核心的合约体系。与以太坊的智能合约相比，比特币合约的特点是“无状态”和“不可计算”，使其在功能上受限，但同时也具备了更高的安全性和去中心化特质。

随着 Taproot 升级的实施，比特币合约能力得到了显著增强。Taproot 的引入，尤其是 MAST 和 Schnorr 签名的应用，使得比特币能够支持更复杂的合约逻辑，并大幅提升了隐私性和交易效率。这些技术创新为 BTCFI 的进一步发展铺平了道路，使得比特币能够在保持原有去中心化优势的同时，探索更多的金融应用场景。

在此基础上，本文深入分析了比特币编程如何支持多种 BTCFI 应用。通过对多签名、时间锁、哈希锁等机制的解读，以及对 DLC、PSBT、MuSig 2 等工具的应用探讨，文章展示了比特币在无需信任前提下实现去中心化清算和复杂金融合约的可能性。这种原生于比特币网络的去中心化金融体系，不仅克服了 WBTC 时代跨链桥接模式的中心化风险，还为比特币持有者提供了更为稳固的信任基础。

文章最后强调，比特币去中心化金融的发展，不仅仅是技术的进步，更是其生态结构的深刻变革。随着 Babylon 质押协议等新应用的涌现和 Fractal Bitcoin 等基于 UTXO 原生的 native scaling 方式的上线，BTCFI 的市场潜力正在逐步显现。未来，随着比特币价格的上升，BTCFI 将进一步吸引主流用户的参与，形成一个以比特币为核心的新金融生态。而这种生态的形成，将使比特币从“数字黄金”叙事中进一步演进，成为全球经济体系中不可或缺的去中心化金融基础设施。

前言

自 2022 年 12 月 Ordinals 协议推出以来，市场涌现了 BRC-20、Atomicals、Pipe、Runes 等数十种资产发行协议，以及数百条比特币 Layer 2 网络，同时社区也在积极探讨比特币去中心化金融（BTCFI）的可行性。

在上一个加密周期中，为吸引比特币持有者参与 Defi，WBTC 应运而生。WBTC 通过中心化托管机构将比特币锁定并铸造成 WBTC，以便在以太坊的 Defi 协议中使用。WBTC 的目标用户是那些愿意承担中心化跨链桥风险，以参与比特币 Defi 的比特币持有者。作为将比特币桥接至 EVM 生态的典型代表，WBTC 实现了 BTCFI 的一种路径。本周期出现的 EVM 系比特币 Layer 2 网络及其生态中的 Defi 项目也延续了这一模式。这一模式虽使 WBTC 在以太坊生态内获得了超 90 亿美元的市值，但与比特币总市值相比，这一比例不到 1% ，反映出该模式的局限性。

相比之下，如果比特币持有者可以直接拿着比特币参与 BTCFI，而无需跨链铸造，同时保证资金的去中心化托管，将能够吸引更多的比特币用户，创造一个更广阔的市场。这就需要在 UTXO 结构下实现比特币编程。正如掌握 Solidity 是进入以太坊 Defi 的关键，掌握比特币编程是进入 BTCFI 市场的必备技能。

与以太坊合约不同，比特币合约并不具备计算能力，更像通过一个个签名连接起来的验证程序。虽然最初应用场景有限，但随着比特币网络的持续升级和 OG 社区的创新，比特币编程的潜力日益显现，许多研究成果已经转化成即将上线的 BTCFI 产品。

本文将从比特币可编程性的角度深入探索 BTCFI 的发展路径，厘清比特币编程的历史与逻辑脉络，帮助读者理解当前 BTCFI 的实际落地场景，以及这些场景将如何影响比特币持有者和整个比特币生态。

比特币合约的基础

中本聪的思考：UTXO、脚本语言和操作码

2010年，satoshi 即中本聪在 bitcoin talk 论坛写道：

比特币的核心设计将在版本 0.1 发布后固定下来，因此我希望它能支持尽可能多的交易类型，但这些交易类型都需要特殊的支持代码和数据字段，并且每次只能覆盖一种特殊情况，这样特殊情况就太多了。

解决这个问题的方法是脚本。交易输入输出方可以用脚本将交易编译为能让节点网络验证的断言（脚本语言），节点验证交易的断言（脚本语言）以评估发送者的条件是否满足。

“脚本” 只是一个 “断言（predicate）”。实际上它只是一个结果要么为真、要么为假的方程。但 predicate 是一个很长而且很罕见的词，所以我就叫它 “脚本” 了。

资金接收方会对脚本进行模板匹配。目前，接收方只接受两个模板：直接付款和比特币地址。未来版本可以添加更多的交易类型模板，运行该版本或更高版本的节点将能够接收它们。网络中的所有节点都可以验证并处理任何新的交易并将其放入区块中，即使它们可能不知道如何读取这些交易。

该设计支持我多年前设计的各种可能的交易类型。包括托管交易、担保合同、第三方仲裁、多方签名等。如果比特币大受欢迎，这些是我们将来可能想要探索的领域，但它们在一开始就必须被设计出来，以确保将来能够实现。

中本聪十四年前的设计奠定了比特币编程的基础。比特币网络没有 “账户” 的概念，只有 “输出”（output），其全称是 “交易输出（TXO）”，代表一笔笔比特币资金，是比特币系统状态的基本单元。

花费一个输出时就是让这个输出成为一笔交易的输入，也可以说是为这笔交易提供资金。这就是为什么我们说比特币系统是基于“UTXO（未花费的交易输出）”模型的，因为只有“UTXO（未花费的交易输出）”才是我们在交易过程中能够使用的金属块，金属块进入了一个熔炉，熔完之后会形成新的一些金属块（新的 UTXO），旧的金属块“交易输出（TXO）”即就不复存在了。

每一笔资金都有自己的锁定脚本（也叫脚本公钥）和面值，根据比特币的共识规则，脚本公钥可以形成一种验证程序，即公钥加上在脚本中执行特定操作的命令——操作码 OP-Codes，为了解锁它，必须提供一组特定的数据即解锁脚本，也叫脚本签名（scriptSig），如果完整的脚本（解锁脚本 + 锁定脚本+OP-Codes）是有效的，相应的输出就会 “被解锁”，可以花费了。

因此比特币的脚本编程是对资金进行编程、让具体的一笔钱能够对输入的特定数据作出响应，通过设计脚本公钥，操作码 OP-Codes，以及用户之间的交互流程，我们可以为比特币合约的关键状态转换提供密码学保证，确保合约正常履行。

这里是比特币的一个标准的 P2P KH（支付到公钥哈希值）脚本的简单图

假设我要向小明支付 1 BTC，就需要使用自己wallet内可动用的 UTXO 形成一个面额为 1 亿聪的 UTXO，并在该 UTXO 的锁定脚本中放入小明公钥（并加上检查签名的操作符），这样只有小明的私钥作为解锁脚本对应小明公钥的签名才能解锁这笔资金。

总结一下，Script 即脚本语言是一种非常基础的编程语言。它由两种类型的对象组成：数据（Data）如公钥与签名+操作码 —— 操作数据的简单函数（操作码的清单如下https://en.bitcoin.it/wiki/Script#Opcodes）。

比特币编程的武器库

在上文提到了中本聪一开始希望比特币网络能够支持的交易类型有托管交易、担保合同、第三方仲裁、多方签名等，那么实现这些武器有哪些呢，它们又是如何用于 BTCFI 的呢？多方签名（MULTISIG）

● 其锁定脚本形式为 M <PUB-1> <PUB-2> ... <PUB-N> N OP\_CHECKMULTISIG ，意思是它记录了 n 个公钥，需要提供其中 m 个公钥的签名来解锁，才能解锁此 UTXO。

● 例如，Alice、Bob 和 Chloe 三人（或者说三个公钥）中的两个的签名，即可花费这个脚本，它的 Script 代码是： 2 <Alice> <Bob> <Chloe> 3 OP\_CHECKMULTISIG，OP\_CHECKMULTISIG 是验证签名是否与提供的公钥匹配的操作码。

●用途包括：

1. 个人和企业资金管理：设置了一个 2-of-3 的多签名wallet后只要两个能用就能使用资金，还可以防止wallet制造商作恶，必须有 m 个制造商合谋才能提取资金。2. 交易仲裁：

\- 假定 Alice 和 Bob 要做一笔交易，比如购买 ordinals NFT，但无法做到一手交钱一手交货，于是他们约定，把钱锁入一个多签名输出中，当 Bob 收到 Alice 发出的 ordinals NFT 时，再把钱完整支付给 Alice，为了防止收到货不给钱的情况出现，可以引入一个第三方，形成一个 2-of-3 的多签名输出；当交易发生争议时，可以请求第三方来主持公道。如果第三方认为 Alice 已经发货，就可以跟 Alice 联手将资金转走。\- 只要第三方公开自己的公钥（比如 TA 是一个预言机），交易双方就可以在 2-of-3 多签名脚本中使用他们的公钥，从而加入仲裁者，因为链上输出上记录的是脚本的哈希值，因此可以在仲裁方不知情的情况下做到，但这里的问题是第三方预言机是可以决定具体的合约的结果，有一定的风险，后文提到的谨慎日志合约 DLC 在这点上做了优化，使其能够真正用于比特币借贷等 BTCFI。

时间锁

时间锁用来控制交易的有效性以及一个输出什么时候可以被花费，这是再质押，质押，抵押借贷等 BTCFI 场景都会用到的比特币脚本编程武器，开发者需要选择使用相对时间锁（nSequence）还是绝对时间锁（nLocktime）：

● 绝对时间锁（nLocktime）：仅在某个时间点后，这笔交易才会被视为有效交易，才能打包到区块中，脚本层面的绝对时间锁是 OP\_CLTV 操作码，验证在某个时间点之后，才能解锁这个 UTXO“，如这笔钱在区块高度 400000 后才可花费。

● 相对时间锁（nSequence）的意思是在输入创建这个 UTXO 的交易（即前序交易）得到区块确认的一段时间后，这笔交易才是有效的，才能解锁这个 UTXO，脚本层面的相对时间锁是 OP\_CSV，如“这笔钱在得到区块确认的 3 个区块之后才可花费。

哈希锁（哈希原像验证）

除此之外还有结合了哈希锁（哈希原像验证）的哈希时间锁，这也常常用在比特币质押和再质押之中：

● 哈希锁的锁定脚本形式为 OP\_HASH 160 <hash> OP\_EQUAL ，验证解锁脚本中的数据是不是锁定脚本中的哈希值的原像

● 哈希时间锁合约（HTLC）：收到资金的一方若不能在一定时间内提供一个哈希值的原像，这笔资金就可以被支付方收回

流程控制（并列的解锁条件）

OP\_IF 操作码可以在锁定脚本中安排多种解锁路径，只要任一路径的条件得到满足，就可以解锁这个 UTXO。上文提到的哈希时间锁合约，也是利用了这样的流程控制操作码。

在 taproot 升级 之后，MAST（默克尔化的抽象语法树）特性允许我们将不同的解锁路径放到不同的默克尔树叶子中，Babylon 的 BTC 质押交易中也使用了 MAST，提升了交易的效率和隐私性，我们将在后文描述。

SIGHASH 附带信息签名

比特币的交易在签名时允许使用 SIGHASH 标签，这些标签为签名的有效性作了额外的指定，允许我们改动交易的部分而不会使签名作废，表达签名人对这个签名的用途的期望或委托。比如：

● SIGHASH\_SINGLE | ANYONECANPAY 签名了输入以及与该输入使用同一个索引号的输出，其余的输入和输出都可以改变，签名不会因此而作废。Andy 可以签名价值 1 BTC 的输入和 100 某 Runes 代币的输出，那么任何愿意以 100 某 Runes 代币交换 1 BTC 的人都可以补完这个交易并使之上链。

其他的例子还有 taproot 升级后的 Schnorr 签名，可以用于谨慎日志合约 DLC。

比特币可编程性的限制

比特币编程的基本模式是 UTXO 锁定脚本表明验证条件，解锁脚本提供数据，锁定脚本中的操作码指明了数据的验证程序（签名验证、哈希原像验证等等），通过验证程序，资金就可被花费，核心的限制点是：

1\.可用验证程序只有有限的几种：实施零知识证明或者其他验证程序就需要分叉，因此 unisat 推出的 BTCFI 拓展方案 Fractal 尽管 BTC 100% 保持一致，但为了能够实施 OP\_CAT，ZK 原生验证 OPCode 等具备「争议性」的操作码提案，在流动性和安全性方面也与比特币主网部分分离了。

2\.比特币脚本没有计算能力：只要能解锁资金，运用任何一条路径都可以使用全部资金，资金花费方式在解锁后无法限制，这也意味着在 BTCFI 借贷项目中很难使用浮动利率方案，只能用固定利率。为了解决这个问题，比特币的社区在讨论实施「限制条款」（covenants），这能够通过对交易进一步花费的限定解锁更多 BTCFI 应用场景。Taproot Wizard 说的 BIP-420 和 OP\_CAT、OP\_CTV、APO、OP\_VAULT 等都与这相关。

3\.UTXO 的解锁条件是完全独立的：一个 UTXO 不能根据另一个 UTXO 是否存在和其锁定条件决定自己能不能解锁，这个问题 BTCFI 的抵押借贷和质押中经常出现，后文说明的部分签名比特币交易 PSBT 就用于解决这个问题。

比特币合约的调整和进化

相对于基于计算的以太坊合约，比特币合约是基于验证的，这种无状态的合约为我们开发 BTCFI 产品带来了很多困难，在比特币合约发展的十多年中，密码学算法和签名的妙用大幅提升了隐私性，效率和去中心化程度，让产品化应用的 BTCFI 成为可能。

谨慎日志合约（DLC）：解决 BTCFI 场景中的去中心化清算问题

当借贷、期权、期货协议需要实现根据预言机价格对用户仓位进行清算时，无法避免地需要保留对于用户资产的操作权，而这无疑会造成用户需要信任协议不会作恶的信任成本。

谨慎日志合约（DLC）被引入用来解决这一问题，其使用了一种叫做适配器签名（adaptor signature）的密码学技巧，使得比特币脚本可以编程出依赖于外部事件的金融合约，并充分保证了隐私性。

它由麻省理工学院（MIT）的数字货币计划（Digital Currency Initiative）的Tadge Dryja （研究科学家）和 Gert-Jaap Glasbergen（软件开发者）在 2017 年提出，并在 2018 年 3 月 19 日公开演示。

适配器签名可以让一个签名仅在加入一个私钥之后，才会变成有效的签名。taproot 升级中引入的 Schnorr 签名就是适配器签名的例子。

通俗的说，Schnorr 签名的标准形式是 (R, s)，给出(R, s) ，只要知道 x 即秘密值（secret）， 就可以令 s = s + x，得到的 (R, s) 。

这里借助一个简单的例子来解释其应用方式：

● Alice 和 Bob 两人投注一场体育比赛（假设无平局）的相反结果，各自押注 1 $BTC，谁预测成功则从赢取全部 2 $BTC 的赌注，他们就会将赌注锁定在一个多重签名wallet中，该wallet需要多方签名才能释放资金。

● 选择预言机，它将公布比赛的结果（通常这种信息来源是在链外找到的，如交易所和比赛网站等）

● 预言机不需要知道有关赌注的任何细节，甚至不需要知道谁参与了 DLC。其工作严格限于提供结果，一旦事件发生，预言机就会发布一个称为承诺的加密证明，表明它已经确定了事件的结果。

● 为了领取锁定在多重签名wallet中的资金，获胜方 Alice 使用预言机提供的秘密值来创建有效的私钥，使他们能够签署花费wallet中资金的交易。

● 该交易被添加到比特币区块链中结算，这时由于其签名就是普通的签名，也看不出这是个 DLC。这与其他常见的多方签名模式 —— 合约的内容完全公开、预言机参与决策 —— 完全不同。

借贷协议的清算机制

假定 Alice 以 $ORDI 作为抵押资产，借出价值为 0.15 $BTC ，当且仅当预言机对于 $ORDI 报价低于 225, 000 sats/ordi 时，该借贷仓位将变更为待清算状态。DLC 能让清算人在待清算状态下，可以无需许可地清算该仓位，同时又能够保证其在价格未达到清算价格时无法操作用户的抵押资产。在上述场景中，Alice 相当于与借贷协议对于 $ORDI 的价格立下了一个赌约：

● 如果价格低于 225, 000 sats/ordi，则协议则可以获得 Alice 的全部抵押品，并承担起相应的 BTC 债务

● 如果价格大于等于 225, 000 sats/ordi，则无事发生，资产归属关系保持不变

那么，我们需要预言机承诺在价格低于 225, 000 sats/ordi 时，用一个 nonce R\_c 发布对结果的签名 s\_c\_ 1 ：

● Alice 和协议仅需为该结果创建一笔承诺交易，创建适配器签名 (R, s)，而不是签名 (R, s)，这也就意味着双方交给对方的签名都是不能直接用来解锁这个合约的，而必须揭晓一个秘密值才可以。这个秘密值正是 s\_c\_ 1.G 的原像，即预言机的签名。因为预言机的签名 nonce 值已经确定了，所以，s\_c\_ 1.G 是可以构造出来的。

● 当价格低于 225, 000 sats/ordi 时，预言机就会发布签名 (R\_c, s\_c\_ 1)，那么协议可以补完对手的适配器签名，再加上自己的签名，使上述交易成为一笔有效交易，并广播到网络中、触发结算效果。

● 相反，但如果价格不低于 225, 000 sats/ordi 时，预言机就不会发布 s\_c\_ 1 ，这笔承诺交易也就不可能成为一笔有效交易。

从本质上讲，DLC 允许用户与协议作为参与者使用比特币区块链进行约定，双方通过将资金锁定在多重签名地址中以构建 DLC 脚本。这些资金只有在预言机在指定时间发布指定信息时才能使用并按照某一规则进行重新分配。

这样，借贷协议就能借助于 DLC 实现了一套无需用户信任任何实体前提下的，外部价格预言机参与的清算机制。

我们后文将要提到的借贷协议 liquidium 和 shell finance 都是利用这种技术实现的无需许可的去中心化清算。

预言机的作用

DLC 中的预言机用于提供提供固定频率的喂价服务，同时会作为第三方参与 DLC 机制中的秘密值（secret）生成与公开的流程。

目前 DLC 预言机还没有标准化的产品，主要是借贷协议研发 DLC 模块，chainlink 等标准化预言机承担链外数据喂价的职能，但随着基于 DLC 的借贷协议上线和不断发展，也有不少现有的预言机项目在持续探索如何开发 DLC 预言机。

部分签名比特币交易（PSBT）：实现 BTCFI 协议中多方交易下资金的无需托管

PSBT 来自于比特币标准 BIP-174 ，该标准可以让多方可以并行地签名同一笔交易，然后将相应的 PSBT 合并起来、形成一笔完整签名的交易，这里的多方可以是协议和用户，买方和卖方，质押者和质押协议等，因此只要涉及多方资金互换场景的 BTCFI 应用都可以利用 PSBT，绝大多数现有的 BTCFI 项目都用了这个技术。

Alice、Bob 和 Charlie 有一笔 资金 存在一个 2/3 的多签中，他们想把这笔钱取出并均分为 3 份，他们三人必须签署同一个交易去花费这个 UTXO。 假设他们互不信任，他们需要怎么做才能保证资金安全呢？

●首先，Alice 作为创建者发起一个 PSBT 交易，多签的 UTXO 作为输入，输出是三人各自的wallet地址。由于 PSBT 保证了除该交易外的任何交易都不能调用任何一人的签名，所以 Alice 可以签完名后发给 Bob。

● 同样，Bob 检查 PSBT 后，如果觉得没问题也进行签名；签名后给到 Charlie 进行签名和交易发布。Charlie 也进行同样的操作。

因此部分签名 Partially signed 的意思就是让每个人只需要检查跟自己相关的那部分交易，只要和自己相关的交易没问题就能保证交易上链后不会有问题。

2023 年 3 月 7 日，Yuga Labs 的 Ordinals NFT 拍卖采用了极度中心化托管的竞拍模式。在竞拍过程中，所有竞拍的资金被要求统一打入 Yuga 的地址托管，这让资金的安全性受到严重威胁。

以太坊生态用户指出，Yuga 的拍卖事件恰好说明了 ETH 智能合约的重要性，但 Ordinals 的开发者也回应：基于 PSBT 的无信任报价交易非常好用，可以实现 NFT 购买者和 Yuga Labs 之间的资金无需托管交易。

假设现在有一对比特币 NFT 交易者，且 NFT 卖方的公钥是双方可知的信息。在发起一笔 NFT 交易时，买方先在交易中写好自己的 UTXO 输入以及一个承接 NFT 的输出。买方在构建好交易并签名后，将其转为 PSBT 发给卖方，卖方通过协议接收到消息后签名，这笔比特币 NFT 交易就成交了。

上述整个过程对买卖双方而言都是完全去信任的。对于买方来说，出价、接受地址等信息已经提前构建在交易中，一旦发生改动，签名便会失效。对于卖方来说，只有自己完成签名，NFT 才会卖出，价格则是经过自己衡量的。

Taproot 升级：打开比特币生态和 BTCFI 爆发的潘多拉魔盒

Taproot 升级在 2021 年 11 月激活，旨在提升比特币隐私性，提高交易效率，并扩展比特币可编程性。通过 Taproot 的实现，比特币可以托管拥有数万个签名者的大规模智能合约，同时掩盖所有参与者并保留单个签名交易的规模，这让更复杂的 BTCFI 链上操作成为可能。几乎所有的 BTCFI 项目都采用了 Taproot 升级的脚本语言。

1\.BIP 340 （BIP-Schnorr）：支持多方签署单笔交易，以及前文提到的在谨慎日志合约 DLC 应用中用到的，必须满足预定条件才能执行某交易。它们其向 Bitcoin 所 commit 的数据量，与标准的单签交易数据量一样。

2.BIP341（BIP-Taproot）：Taproot引入了 Merkle 抽象语法树（MAST），将更少的合约交易数据 commit 到链上，这使得比特币能够创建更复杂的合约，而且不同于现有的支付到脚本哈希(P 2 SH)交易，MAST 允许用户按需选择性的公开部分脚本，提高了隐私性和效率。MAST 在 Babylon 的 BTC 质押交易中也有很好的运用，将其多个锁定脚本构建成一笔包含多脚本的交易，三个锁定脚本：

● TimeLockScript 时间锁，实现质押的锁仓功能；

● UnboundingPathScript 解质押：实现提前结束质押功能；

● SlashingPathScript 罚没：实现作恶时系统的惩罚功能

全为叶子节点，从叶子节点开始，逐渐构建二叉树如下

3.BIP342（BIP-Tapscript）：为比特币提供了一种升级的交易编程语言，该语言利用了 Schnorr 和 Taproot 技术。Tapscript 还允许开发者更高效地实现未来的比特币升级。

4. 奠定 Ordinals 协议的基础：

● Taproot 升级还引入了 Taproot (P 2 TR)地址，以 bc 1 p 开头，让元数据能够写入存储在 Taproot 脚本路径的花费脚本（spent script）中，但却从未出现在 UTXO 集中。

● 由于维护/修改 UTXO 集需要更多的资源，因此这种做法可以节省大量资源，增加了一个区块存储数据量 —— 这意味着现在有空间可以存储图像、视频，甚至游戏 —— 无意中让 Ordinals 的部署成为了可能。我们常用的铭文地址就是 Taproot (P 2 TR)地址。

● 由于 Taproot 脚本的消费只能从已经存在的 Taproot 输出中进行，因此，铭文采用了两阶段的提交/揭示流程进行铸造。首先，在提交交易中，创建了一个承诺包含铭文内容的脚本的 Taproot 输出。然后，在揭示交易中，通过将那笔铭文对应的 UTXO 作为输入，发起交易。此时，其对应的铭文内容被公开至全网。

● Ordinals BRC-20、 ARC-20、 Runes 等新资产涌现，也让 Taproot 的转账采用率基本一直保持 70% 左右。

Ordinals 和 Brc 20 ：为 BTCFI 创造一批蓝筹资产，开启基于索引器编程的大门

Ordinals 实现了比特币 OG 在比特币主网上买买买的愿望，其热度市值已然超过以太坊 NFT。

● Ordinals 于 2023 年 1 月由比特币核心贡献者 Casey Rodarmor 提出，其核心是序数理论，旨在赋予比特币最小单位——聪（sats）以唯一标识和属性，将其转化为独一无二的非可替代代币（NFT），通过在聪中铭刻多样的数据（图片、文字、视频等），Ordinals 协议实现了比特币 NFT 的创建和交易。

● 这一过程不仅增加了比特币的用途，还允许用户在比特币区块链上直接创建和交易数字资产。永久价值在于由于 Ordinals 基于比特币的聪进行创建，其基础价值与比特币本身相连，理论上不会归零。

BRC-20 是一种链上记录，链下处理的代币系统，利用 JSON 数据的序数铭文来部署代币合约、铸币和转移代币。

● 它把铭文当作一个链上账本，用于记录 BRC-20 代币的部署、铸造和转移。

● 在结算上，需要通过链下查询，依赖第三方索引工具检索比特币区块，记录所有 BRC-20 代币的部署、铸造和转移操作从而查询出各用户的 BRC-20 代币最终的余额。这可能会导致不同平台对于某一账户余额的查询会有不同的结果。

Ordinals 和 Brc 20 不仅为 BTCFI 提供了交易的需求和蓝筹资产，还为很多 BTCFI 项目提供了基于索引器编程，提升比特币合约能力的新思路，Json 的 「op」 字段组合下能够进一步进化出基于铭文的 defi 乃至 socialfi 和 gamefi，包括 AVM、tap protocol、brc 100、unisat 的 swap 功能乃至很多提出在比特币一层做智能合约平台的项目都是使用基于索引器编程的方案。

MuSig 2 ：去中心化模式玩转比特币 Restaking 和 LST

多重签名方案使一组签名者能够在消息上产生联合签名，MuSig 允许多个签名者从他们各自的私钥中创建一个聚合公钥，然后共同为该公钥创建一个有效签名，它是 Schnorr 签名的一种应用，我们在前文说过，Schnorr 签名的标准形式是 (R, s)，给出(R, s) ，只要知道 x 即秘密值（secret）， 就可以令 s = s + x，得到的 (R, s) ，这里的用于生成聚合公钥和有效签名的也是私钥加上一个随机数 nonce 值。

MuSig 2 方案只需要两轮即可完成多重签名，通过这个方式创建的聚合公钥与其他公钥无法区分，提高了隐私性，并显著降低了交易手续费，Taproot 升级兼容 Musig 2 多签方案，其 BIP 提案在 2022 年比特币 BIP-327: MuSig 2 for BIP 340-compatible Multi-Signatures 中发布。

● 以太坊上的流动性质押可以通过智能合约实现，比特币缺乏实现流动性质押所需的合约能力，而像前文所说的一样，比特币巨鲸普遍厌恶中心化托管商，需要 MuSig 2 来实现去中心化的比特币流动性质押，我们这里以 Shell Finance 的方案为例：

1\. 用户和 Shell Finance 根据双方私钥数据和wallet生成的两个 nonce 随机数，计算出一个聚合公钥和对应的 MulSig 2 多签的地址 P。

2\. 由 Shell Finance 构造 PSBT 交易，用户和 Shell Finance 资产从 MuSig 2 支持的多签地址 P，质押入 Babylon，wallet方再次提供 nonce 随机数支持，传入多签地址对应的聚合公钥。

3\. 当 Babylon 质押时间结束，由 Shell Finance 构造 PSBT 解锁交易，用户和 Shell Finance 共同签名将质押资产解锁。

由生成 nonce 的随机数的第三方wallet，质押用户和 LST 项目方三方共同创建聚合公钥和签名，这个过程中，用户和项目方都只能保管一份私钥，没有 nonce 值都无法生成聚合公钥和签名，取回资金；而wallet没有私钥也无法动用资金。如果 nonce 值是由项目方自己生成的，项目方是存在作恶风险的，用户需要注意。

当前 BTCFI 的落地应用场景

比特币编程并不复杂，它甚至比 Rust 这些语言简单得多，其重点是创造可供验证的，可信的承诺，并能够提供比以太坊更优越的技术安全性，这为 BTCFI 的开发划定了边界，最难的是在边界内能够开发什么样的符合 PMF（project market fit）的 BTCFI 产品，就像以太坊 solidity 合约刚刚面世的时候，开发者也不知道能用它开发 x\*y=k 的 amm 算法一样，而是先选择从 ICO、订单薄、点对点的借贷等方向开始探索。