前言
基于比特币发行资产一直是一个热门话题。从 2011 年最早的 Colored Coins 到最近流行的 Ordinal 协议，BTC 社区一直能够提出新的参与者和共识，但很少有人坚持下来。然而，闪电实验室公布了雄心勃勃的计划，即开发基于 Taproot Assets 的稳定币。Tether 还宣布将利用 RGB 协议在比特币的第一层上铸造 USDT。
这意味着曾经著名的 OmniLayer(以前的 Mastercoin) 不再是 BTC 生态系统中最大的玩家。客户端验证 (CSV) 资产协议开始进入每个人的视野。这些协议既保持了传统比特币资产协议的完整性，又增强了可扩展性。然而，比特币生态系统中的一系列资产协议提出了相关问题：它们彼此之间有何不同，人们应该如何在这一领域中导航和抓住机会？
本文旨在引导读者全面回顾比特币历史上出现的各种资产协议。此外，它还试图深入研究在可预见的未来基于比特币的资产协议发展的潜在轨迹。
彩色的硬币
彩色硬币的概念最早是由 eToro 现任首席执行官 Yoni Assia 在 2012 年 3 月 27 日发表的开创性文章「bitcoin 2.X (aka Colored bitcoin)」中提出的。这篇文章认为，比特币的底层技术就像互联网的 HTTP 一样基础和完美。因此，彩色币代币协议是在 BTC 的基础上设计的。
Yoni Assia 设想通过这一创新创造 BTC 2.0 经济，使任何社区都能以这种方式产生多种货币。在当时，利用比特币的底层技术进行交易结算和防止双重支出是一个开创性的想法。
彩色币是一种用于在比特币区块链上发行资产的协议。它通过「着色」比特币的特定部分来表示其他资产。这些标记的比特币仍然保留其原始功能，但它们也代表另一种资产或价值。然而，紧迫的问题是，这个想法如何在比特币网络上实现。
2014 年 7 月 3 日，ChromaWay 迈出了重要的一步，开发了增强型彩色币基于订单的协议 (EPOBC)，大大简化了开发者创建彩色币的过程。这是首个使用比特币脚本OP_RETURN函数的协议。
结果是这样的：
这样的实现非常简洁，但也带来了很多问题：
1. 可替代性和最小绑定值问题通过在创世交易中为一枚彩色硬币绑定 1000 个 sat，该彩色硬币的最小单位变成 1 sat。这意味着该资产或代币理论上可以分为最多 1000 个单位 (但在实践中，为了防止灰尘攻击，它会更低)。例如，最小 satoshi 值曾经被设置为 546 sat，而对于 Ordinals，它甚至更高)。
2. 为了确定彩色硬币的真实性和所有权，需要追溯其交易历史，并从创世交易到当前 UTXO 进行验证。因此，需要开发专用钱包，全节点甚至扫描仪。
3. 潜在的矿工审查风险 ColoredTransaction 具有鲜明的特征，例如在输出中写入元数据，这带来了矿工审查的可能性。
彩色币本质上是一种资产跟踪系统，它使用比特币的验证规则来跟踪资产转移。然而，为了证明任何特定的输出 (txout) 代表特定的资产，你需要提供从资产来源开始的整个传输链。这意味着验证交易的有效性可能需要一个很长的证明链。为了解决这个问题，OP_CHECKCOLORVERIFY等提案被提出，以帮助直接在 BTC 上验证彩色币交易，但该提案未被采用。
加密领域的第一个 ICO： Mastercoin
Mastercoin 的概念最初是由 J.R. Willett 提出的。2012 年，他发表了一份名为「The Second Bitcoin Whitepaper」的白皮书，概述了在现有比特币区块链基础上创建新资产或代币的想法。这个概念最终被称为「MasterCoin」，后来更名为 Omni Layer。
2013 年，Mastercoin 项目进行了我们今天所说的 ICO(首次代币发行) 的早期版本，成功筹集了数百万美元。这被认为是历史上第一次 ICO。Mastercoin 最引人注目的应用之一是 Tether (USDT)，这是一种著名的法定抵押稳定币，最初是在 Omni 层上发行的。
事实上，Mastercoin 的想法早于彩色币。我们第二个讨论它的原因是，与彩色币相比，MasterCoin 是一个相对更全面的解决方案。MasterCoin 建立了一个完整的节点层，提供更复杂的功能，如智能合约。相比之下，彩色币更简单，更直接，主要侧重于「着色」或标记比特币 UTXO 来代表其他资产。
两者的关键区别在于，在区块链上，Mastercoin 只记录各类交易行为，不存储相关资产信息。在 Mastercoin 的节点中，通过扫描比特币区块来维护状态模型数据库，该数据库驻留在区块链之外的节点中。
与彩色币相比，Mastercoin 可以执行更复杂的逻辑。此外，由于它不记录或验证区块链上的状态，因此它的交易不需要连续 (连续着色)。
然而，为了实现 Mastercoin 的复杂逻辑，用户需要信任节点内链下数据库中维护的状态，或者运行自己的 Omni Layer 节点来执行验证。
总而言之：
Mastercoin 和彩色币之间的主要区别在于 Mastercoin 不维护区块链上协议所需的所有数据。相反，它依靠比特币的共识系统来管理自己的交易发布和排序，然后在链下数据库中维护状态。
根据 OmniBolt 提供的信息：Omni Layer 正在向 Tether 提出一种新的 UBA(基于 UTXO 的资产) 资产协议，该协议将利用 Taproot 升级。该协议将资产信息嵌入到 Tapleaf 中，实现有条件支付 Stark 整合到 Omni Layer 的闪电网络基础设施中。
客户端验证的概念
如果我们想了解客户端验证 (CSV) 的概念，我们需要回到彩色币和 Mastercoin 出现后的那一年，也就是 2013 年。那一年，早期的比特币和密码学研究人员彼得·托德 (Peter Todd) 发表了一篇题为「Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation.」的文章。虽然标题没有明确提到客户端验证，但仔细阅读就会发现这是最早介绍这个概念的文章之一。
Peter Todd 一直在寻找提高比特币运营效率的方法。他基于时间戳的思想开发了一个更复杂的客户端验证概念。此外，他还引入了「一次性密封件」的概念，这将在后面提到。
为了遵循 Peter Todd 的想法，我们首先需要了解比特币实际上解决了什么问题。Peter Todd 认为，比特币解决了三个问题：
1. 发布证明：发布证明的本质是解决双重支出问题。例如，如果 Alice 想将一些比特币转移给 Bob，尽管她已经签署了一笔交易来转移给 Bob，但 Bob 可能在物理上不知道这样一笔交易的存在。因此，我们需要一个公共场所来发布交易，每个人都可以从那里查询交易。
2. 秩序共识：在计算机系统中，我们通常经历的物理时间不存在。在分布式系统中，时间通常是 Lamport 时间戳，它不为我们的物理时间提供度量，但为我们的交易排序。
3. 验证 (可选)：比特币的验证包括验证比特币交易中的签名和转账金额。然而，Peter Todd 认为，这种验证对于在比特币之上构建代币系统是没有必要的，这只是一个优化选项。
此时，你可能会想起我们前面讨论过的 OmniLayer。OmniLayer 本身并没有将状态计算和验证委托给比特币，但它确实重用了比特币的安全性。另一方面，彩色币将状态跟踪委托给比特币。这两个系统的存在已经证明，验证不一定必须在区块链上进行。
那么，客户端验证如何有效地验证交易呢？
首先，让我们看看需要验证的内容：
•状态 (交易逻辑验证)
•验证输入 (TxIn) 是否有效，以防止双重支出。
很容易注意到，对于在比特币上发行的资产，每笔交易都需要验证整个相关交易历史，以确保引用的输入没有被花费，状态是正确的。这是非常不切实际的。那么，我们如何改善这一点呢？
Peter Todd 建议我们可以通过改变验证的焦点来简化这个过程。这种方法不是确认输出没有被双重花费，而是侧重于确保交易的输入已经发布，并且不与其他输入冲突。通过对每个区块中的输入进行排序并使用 Merkle 树，这种类型的验证可以更有效地完成，因为它每次只需要一小部分数据，而不是输入的整个链历史记录。
Peter Todd 提出的承诺树（commitment tree）结构如下：
CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn
但是我们如何在区块链上存储这样一个承诺树呢？这就是我们可以引入「一次性密封件」概念的地方。
一次性封件
「一次性密封件 (Single Use Seal)」是理解 CSV 的核心概念之一。它类似于用于保护货物集装箱的一次性密封。一次性封条是一种独特的对象，可以在消息上精确地关闭一次。简单来说，一次性封条是一种用于防止双重支出的抽象机制。
对于 SealProtocol，有三个元素和两个操作。
基本元素：
•L：密封
•M：消息，即信息或交易
•W，可以验证印章的人或物
基本操作：有两个基本动作：
•Close(l, m)→w：关闭消息 M 上的密封 L，产生见证人 W。
•Verify(l, w, m)→bool：验证消息 M 上的密封 L 是否已关闭。
单次使用密封实现的安全性意味着攻击者无法找到两个不同的消息 m1 和 m2，使得 Verify 函数对同一个密封返回 true。
简而言之，一次性密封件确保某个资产或数据块仅被使用或锁定一次。在比特币的背景下，这通常意味着 UTXO 只能花一次。因此，比特币交易输出可以被视为一次性使用的印章，当一个输出被用作另一个交易的输入时，该密封件被「破坏」或「使用」。
对于比特币上的资产，比特币本身充当了一次性密封件的「见证人」(w)。这是因为为了验证比特币交易，节点必须检查交易的每个输入是否引用了一个有效且未使用的 UTXO。如果一笔交易试图对已经使用的 UTXO 进行双重支付，比特币的共识规则和诚实节点网络将拒绝该交易。
更简单地说：
一次性密封件将任何区块链视为数据库，我们在其中存储对某个消息的承诺，并将其状态保持为已使用或未使用。
综上所述，使用客户端验证的资产具有以下特征：
1. 链下数据存储：使用客户端验证的资产的交易历史、所有权和其他相关数据主要存储在链下。这大大减少了对链上数据存储的需求，并有助于增强隐私。
2. 承诺机制：虽然资产数据存储在链下，但这些数据的更改或传输通过承诺记录在链上。这些承诺允许链上交易引用链下状态，确保链下数据的完整性和不可变性。
3. 链上见证 (不一定是比特币)：尽管大多数数据和验证发生在链下，但使用客户端验证的资产仍然可以通过嵌入链上的承诺来利用底层区块链的安全性 (发布证明、交易排序)。
4. 在客户端完成验证工作：大多数验证工作是在用户的设备上完成的。这意味着并非网络中的每个节点都需要参与验证每个交易，只有相关各方需要验证交易的有效性。
对于那些使用客户端验证资产的人来说，还有一点需要注意：
在使用客户端链下验证进行资产交易和验证时，不仅需要提供持有资产的私钥，还需要提供相应资产的完整 Merkle 路径证明。
RGB, CSV 的先驱
RGB 的概念是由社区知名人士 Giacomo Zucco 在 2015 年之后提出的。这是一个以太坊崛起的时期，ICO(首次代币发行) 激增，许多人试图创建比特币以外的项目，如 Mastercoin 和彩色币（Colored Coins）。
贾科莫·祖科（Giacomo Zucco）对这些进展感到失望。他认为，这些项目都无法与比特币的潜力相匹配，之前在比特币上实施代币的尝试是不够的。在此期间，他遇到了 Peter Todd，并对 Todd 关于客户端验证 (CSV) 的想法着迷。这使他提出了 RGB 的概念。
除了前面提到的使用客户端验证的资产的特征之外，RGB 和早期资产协议的主要区别在于增加了用于图灵完备合约执行的执行 VM(虚拟机)。为保证合约数据的安全性，设计了 Schema 和 Interface。Schema 类似于以太坊，声明合约的内容和功能，而 Interface 负责实现特定功能，类似于编程语言中的接口。
这些合约的 Schema 负责限制在 VM 执行期间超出预期的行为。例如，RGB20 和 RGB21 分别负责在交易过程中对可替代和不可替代的代币施加一定的限制。
RGB 中使用的承诺机制，Pedersen Hash
它的优势在于能够在不公开的情况下承诺价值。使用 Pedersen Hash 来构建 Merkle 树意味着你可以创建一个可以隐藏其值的隐私保护的 Merkle 树。这种结构在某些隐私保护协议中很有用，例如一些匿名加密货币项目。然而，它可能不适合 CSV 资产，这将在稍后与 Taproot Assets 的比较中提到。
RGB 简化的虚拟机设计→AluVM
RGB 的目标不仅是实现客户端验证的资产协议，而且还扩展到图灵完备的虚拟机执行和合约编程。最初，RGB 声称使用一种名为 Simplicity 的编程语言，该语言生成执行证明，并允许对其中编写的合约进行正式验证 (以避免错误)。然而，这种语言的开发并没有按计划进行，导致了复杂性，最终阻碍了整个 RGB 协议的发展。最终，RGB 开始使用由 Maxim 开发的名为 AluVM 的虚拟机，其目标是避免任何未定义的行为，类似于最初的 Simplicity。据称，新的 AluVM 未来将被一种名为 Contractum 的编程语言取代，而不是目前使用的 Rust。
RGB Layer2 扩容方向：闪电网络还是侧链？
客户端验证资产不能持续安全地进行链下交易，因为它们仍然依赖 L1 进行交易发布和排序。这意味着，如果没有第 2 层扩展解决方案，它们的交易速度仍然受到 L1 见证的区块生产速度的限制。这意味着，如果直接在比特币上进行 RGB 交易，在严格的安全要求下，两个相关交易之间的时间间隔至少需要十分钟 (BTC 的区块时间)，这通常是不可接受的慢。
RGB 和闪电网络
简而言之，闪电网络的运作方式是让交易各方在链下签署一系列合约 (承诺交易)。这些合约确保了如果任何一方违反协议，受害方可以将合约 (承诺交易) 提交给 BTC 进行结算，收回其资金，并对违规者进行处罚。换句话说，闪电网络通过协议和博弈论设计来确保链下交易的安全性。
RGB 可以通过设计适合 RGB 自身的支付通道合约细节来构建自己的闪电网络基础设施。然而，由于闪电网络的高度复杂性，构建这样的基础设施并不容易，特别是考虑到闪电实验室在该领域的多年工作和 LND 超过 90% 的市场份额。
RGB 的侧链 Prime
目前 RGB 协议的维护者 LNP-BP 在 2023 年 6 月发布了 Maxim 提出的一项名为 Prime 的客户端验证资产扩展解决方案的提案。Maxim 在文中批评了现有的侧链和闪电网络扩展解决方案在开发过程中过于复杂。他认为，除了 Prime 之外，其他的扩展方式，包括 NUCLEUS 多节点闪电通道和 Ark/Enigma 通道工厂，都需要两年以上的开发时间。然而，Prime 可以在一年内完成。
Prime 并不是作为传统的区块链设计的。相反，它是专门为客户端验证创建的模块化证明发布层。它由四个主要部分组成：
1. 时间戳服务：此服务可以在短短 10 秒内完成一系列交易。
2. 证明：它们以部分默克尔树 (PMT) 的形式存储，并与区块头一起生成和发布。
3. 一次性密封件：这是一个抽象的一次性密封件协议，旨在防止重复支出。当在比特币上实现时，它可以绑定到 UTXO，类似于当前的 RGB 设计。
4. 智能合约协议：RGB 分片合约 (可替换)
由此可以看出，为了解决 RGB 中的交易确认时间问题，Prime 利用时间戳服务快速确认链下交易，并将其与 id 打包到区块中。同时，Prime 上的交易证明可以通过 PMT 进一步整合，然后以类似检查点的方式锚定在 BTC 上。
基于 Taproot 的 CSV 资产协议：Taproot Assets
Taproot Assets 是一种基于 Taproot 的 CSV 资产协议，用于在比特币区块链上发行资产。这些资产可以通过闪电网络进行即时、大量、低成本的交易。Taproot Assets 的核心是利用比特币的安全性和稳定性，以及闪电网络的速度、可扩展性和低成本。该协议由闪电实验室的首席技术官 Roasbeef 设计和开发。Roasbeef 可能是这个星球上唯一一个亲自领导比特币客户端 (BTCD) 和闪电网络客户端 (LND) 开发的人，他对比特币有着深刻的理解。
Taproot 交易只携带资产脚本的根哈希，这使得外部观察者很难识别它们是否涉及 Taproot Assets，因为哈希本身是通用的，可以表示任何数据。随着 Taproot 的升级，比特币获得了执行智能合约 (TapScript) 的能力。在此基础上，Taproot Assets 的资产编码实际上创建了一个类似于 ERC20 或 ERC721 的代币定义。因此，比特币不仅获得了定义资产的能力，还获得了编写智能合约的能力，为比特币的代币智能合约基础设施奠定了基础。
Taproot Assets 的编码结构如下：
同样作为一种 CSV 资产协议，Taproot Assets 的设计比 RGB 更简洁。Taproot Assets 和 RGB 在应用程序可扩展性方面的最大区别在于执行 VM, Taproot Assets 使用与 BTC 的原生默认相同的 TaprootScript VM。近年来，很多针对 BTC 的基础设施研究都是基于 TapScript，但由于 BTC 的升级缓慢，短时间内无法应用，因此可以预见，Taproot Assets 将是未来这些新鲜想法的试验场。
Taproot Assets 和 RGB 的区别
1. 交易验证和轻节点友好性
Taproot Assets 由于实现了和树（sum tree）结构，具有很高的验证效率和安全性。它允许通过拥有证明来进行状态验证和交易，而无需遍历整个交易历史。相比之下，RGB 使用 Pedersen 承诺使得很难有效地验证输入的有效性。因此，RGB 需要追溯输入的交易历史，随着时间的推移和交易的积累，这可能成为一个很大的负担。默克尔和树（Merkel sum tree）的设计还使 Taproot Assets 能够轻松地促进轻节点验证，这是以前在比特币之上构建的资产协议中不可用的功能。
2. 执行虚拟机
Taproot Assets 是针对比特币网络的 Taproot 升级而开发的。它利用 TaprootScriptVM，这是在 Taproot 升级后随比特币附带的脚本执行引擎。此外，它使用了比特币 PSBT 的变体 vPSBT，这表明一旦 Taproot Assets 闪电通道机制被开发出来，它可以立即重用 LND(闪电网络守护进程，Lightning Network Daemon) 现有的所有基础设施，以及闪电实验室以前的产品 (LND 目前在闪电网络中占有超过 90% 的市场份额)。此外，最近流行的 BitVM 提案是基于 TaprootScript 的，理论上这意味着所有这些改进最终都将使 Taproot Assets 受益。
然而，RGB 的运行方式有些不同。它的虚拟机和验证规则 (SCHEMA) 是独立系统的一部分，形成了一个有点封闭的生态系统。RGB 在自己的生态系统中运作，它与更广泛的比特币生态系统的关系并不像一些人想象的那么密切。例如，对于 Taproot 升级，RGB 唯一真正的交互是将提交数据编码到 Witness TapLeaf 中的区块链上。这说明 RGB 和 Taproot 升级仅存在最低程度的关联。
3. 智能合约
在当前的 RGB 实施中，合约和虚拟机被重点强调。然而，在 Taproot Assets 中，似乎并没有关注智能合约，至少目前还没有。当前的 RGB 实现尚未解释对全局状态的修改如何与单个合约分片 (UTXO) 同步。此外，尽管 Pedersen 承诺可以确保资产总额，但其他状态将如何免受篡改尚不清楚，因为对此没有太多解释。
另一方面，Taproot Assets 的设计更简单，但目前只存储资产余额，不处理更复杂的状态，这使得智能合约的讨论为时过早。然而，根据闪电实验室的说法，他们计划明年专注于 Taproot Assets 的智能合约设计。
4. 同步中心
前面提到的关于在客户端验证的资产的基本原则表明，持有证明与持有私钥同样重要。然而，由于证明保存在客户端，因此存在丢失的风险。如何解决这个问题？在 Taproot Assets 中，可以通过使用「universe」来避免这个问题。universe 是一个公开可审计的稀疏 Merkle 树，它覆盖了一个或多个资产。与标准的 Taproot Assets 树不同，universe 不用于保管 Taproot Assets。相反，它提交给一个或多个资产历史记录的子集。
在 RGB 系统中，这个角色由 Storm 完成，它通过点对点 (p2p) 网络同步链下证明数据。然而，由于与 RGB 开发团队相关的历史原因，这些团队目前使用不兼容的证明格式。RGB 生态系统团队 DIBA 表示，它将开发「carbonado」来解决这个问题，但其进展尚不清楚。
5. 工程实现
Taproot Assets 使用的所有库都经过了良好的测试，因为闪电实验室有自己的比特币客户端 (BTCD)、闪电网络客户端 (LND) 和各种钱包库实现。相反，用于 RGB 实现的大多数库都是自定义的。从行业标准的角度来看，RGB 的实施还处于实验阶段。
简要介绍一下比特币扩容的未来
继续讨论，很明显，客户端验证的资产协议已经超越了传统协议的范围，现在正朝着计算扩展的方向发展。
许多人声称，在未来，比特币将作为「数字黄金」存在，而其他区块链将创建应用生态系统。然而，我有不同的看法。正如在比特币论坛上的许多讨论中所看到的，有很多关于各种山寨币及其短暂寿命的讨论。这些山寨币的迅速消亡已经把围绕它们的资本和努力变成了泡沫。我们已经有了比特币作为共识的坚实基础, 没有必要为应用程序协议构建新的第 1 层 (L1) 解决方案。我们应该做的是利用比特币这个强大的基础设施，建立一个更长期的去中心化世界。
更少链上计算，更多链上验证
从应用程序设计的角度来看，比特币早期选择的理念不是以链上计算为中心，而是以验证为中心 (智能合约的图灵完备性和状态)。区块链的本质是一个复制状态机。如果区块链的共识集中在链上计算上，那么很难说让网络中的每个节点重复这些计算是一种合理或可扩展的方法。如果重点是验证，那么验证链下交易可能是最适合比特币可扩展性的方法。
验证在哪里进行？这一点至关重要。
对于在比特币之上创建协议的开发人员来说，如何使用比特币进行关键验证，甚至将验证置于链下，以及如何设计安全方案，都是协议设计者自己的问题。它们不应该也不需要与链本身相关联。如何实现验证将导致 BTC 的不同扩展解决方案。
从基于验证的实现的角度来看，我们有三个扩展方向：
1. 链上验证 (OP-ZKP)
在 TaprootScriptVM 中直接实现 OP-ZKP 将赋予比特币本身执行 ZKP 验证的能力。这一点，加上一些合约设计结算协议，可以创建一个继承比特币安全性的 Zk-Rollup 扩展解决方案。然而，与在以太坊上部署验证合约不同，比特币的升级本身就很慢，添加这样一个专门的、可能需要升级的操作码必然是具有挑战性的。
2. 半链上验证 (BitVM)
BitVM 的设计确保了它不是为普通的交易逻辑设计的。Robin Linus 还表示，BitVM 的未来在于为各种侧链创建一个免费的跨链市场。BitVM 的方法被认为是半链上的，因为大多数验证计算不会在链上进行，而是在链下进行。围绕比特币的 Taproot 进行设计的重要原因是在必要时利用 TapScriptVM 进行计算验证，理论上继承了比特币的安全性。此过程还生成一个验证信任链，例如在「n」个验证者中只需要一个诚实的验证者，称为乐观汇总（Optimistic Rollups）。
BitVM 会产生大量链上开销，但它能使用 ZK 欺诈证明来提高效率吗？答案是否定的，因为 ZK 欺诈证明的实现依赖于在链上执行 ZKP 验证的能力，这使我们回到了 OP-ZKP 方法的困难。
3. 链下验证 (客户端验证，闪电网络)
完全链下验证指的是前面讨论的 CSV 资产协议和闪电网络。正如在前面的讨论中所看到的，我们不能完全防止 CSV 设计中的共谋。我们能做的是使用密码学和协议设计，将恶意串通造成的损害控制在可控范围内，使此类行为无利可图。
链下验证的优点和缺点同样明显。它的优点是使用最少的链上资源，并且具有巨大的可扩展性潜力。缺点是几乎不可能完全继承比特币的安全性，这极大地限制了可以进行的链下交易的类型和方法。此外，链下验证也意味着数据的保存是在链外的，由用户自己管理，这就对软件执行环境的安全性和软件的稳定性提出了更高的要求。
规模演进趋势
目前以太坊上流行的 Layer 2 解决方案，从范式上来说，都是通过 Layer 1 来验证 Layer 2 的计算，这意味着状态计算被推到 Layer 2，但验证仍然保留在 Layer 1。在未来，我们可以类似地将验证计算放到链下计算，进一步释放当前区块链基础设施的性能。