er 正在向 Tether 提出新的 UBA（基于 UTXO 的资产）资产协议，该协议将利用 Taproot 升级。该协议将把资产信息嵌入到 Tapleaf 中，从而实现有条件支付等功能。与此同时，OmniBolt 正在致力于将 Stark 集成到 Omni Layer 的闪电网络基础设施中。 客户端验证的概念 如果我们想理解客户端验证（CSV）的概念，我们需要回到彩色币和Mastercoin出现后的那一年，即 2013 年。那一年，早期比特币和密码学研究者 Peter Todd，发表了一篇题为“解开加密货币挖矿：时间戳、发布证明和验证”的文章。虽然标题没有明确提及客户端验证，但仔细阅读就会发现这是最早介绍这个概念的一篇文章。 Peter Todd一直在寻找让比特币运行更高效的方法。他基于时间戳的思想开发了一种更复杂的客户端验证概念。此外，他还引入了“一次性密封”（single use seal）的概念，稍后会提到。 为了遵循Peter Todd的想法，我们首先需要了解比特币实际上解决了什么问题。根据 Peter Todd 的说法，比特币解决了三个问题： 1、发布证明：发布证明的本质是解决双花问题。例如，如果Alice想要将一些比特币转移给Bob，尽管她已经签署了要转移给Bob的交易，但Bob实际上可能不知道这样的交易存在。因此，我们需要一个公共场所来发布交易，每个人都可以从那里查询交易。 2、排序共识：在计算机系统中，我们通常经历的物理时间并不存在。在分布式系统中，时间通常是 Lamport 时间戳，它不提供物理时间的度量，而是对交易进行排序。 3、验证（可选）：比特币验证涉及验证签名和 BTC 交易中传输的金额。然而，Peter Todd 认为，这种验证对于在比特币之上构建代币系统来说并不是必需的；这只是一个优化选项。 此时，你可能还记得我们之前讨论过的 OmniLayer。OmniLayer 本身并不将状态计算和验证委托给比特币，但它确实复用了比特币的安全性。另一方面，彩色币将状态跟踪委托给比特币。这两个系统的存在已经证明验证不一定必须在区块链上进行。 那么客户端验证如何有效验证交易呢？ 首先我们看一下需要验证的内容： 状态（交易逻辑验证） 验证输入 (TxIn) 是否有效，以防止双重支出。 很容易注意到，对于在比特币上发行的资产，每笔交易都需要验证整个相关交易历史记录，以确保引用的输入没有被花费并且状态是正确的。这是非常不切实际的。那么，我们该如何改进呢？ Peter Todd 建议我们可以通过改变验证的重点来简化这个过程。该方法不是确认输出没有被双花，而是专注于确保交易的输入已发布并且不与其他输入冲突。通过对每个区块中的输入进行排序并使用 Merkle 树，这种类型的验证可以更有效地完成，因为它每次只需要一小部分数据，而不是输入的整个链历史记录。 Peter Todd提出的承诺树结构如下： CTxIn -> CTxOut -> -> CTransaction -> -> CTxIn 但是我们如何将这样的承诺树存储在区块链上呢？这是我们可以引入“一次性密封”（ingle Use Seal）概念的地方。 一次性密封（ingle Use Seal） 一次性密封是理解 CSV 的核心概念之一。它类似于用于保护货物集装箱的一次性物理密封。一次性密封是一种独特的物体，可以在一条消息上精确地关闭一次。简单来说，一次性密封是一种用于防止双重支出的抽象机制。 对于SealProtocol，有三个元素和两个操作。 基本要素： l： seal m：message，即信息或交易 W：见证，可以验证seal的人或物 基本操作：有两个基本操作： Close(l, m) → w：关闭消息m上的seal l，产生见证w。 Verify(l, w, m) → bool：验证Seal 1是否在消息m上关闭。 一次性密封实现的安全性意味着攻击者无法找到两个不同的消息m1和m2，并且对相同的密封，验证函数都返回true。 简而言之，一次性密封可确保特定资产或数据仅使用或锁定一次。在比特币的背景下，这通常意味着 UTXO 只能使用一次。因此，比特币交易输出可以被视为一次性密封，当输出被用作另一笔交易的输入时，该密封被“破坏”或“使用”。 对于比特币上的资产，比特币本身充当一次性密封的“见证”（w）。这是因为要验证比特币交易，节点必须检查交易的每个输入是否为有效且未使用的 UTXO。如果一笔交易试图双花已使用的 UTXO，比特币的共识规则和诚实节点网络将拒绝该交易。 更简单地说： 一次性密封将任何区块链视为数据库，我们在其中存储对特定消息的承诺并保持其状态为已用或未用。 综上所述，使用客户端验证的资产具有以下特征： 1、链下数据存储：使用客户端验证的资产的交易历史、所有权和其他相关数据大多存储在链下。这大大减少了对链上数据存储的需求，并有助于增强隐私性。 2、承诺机制：虽然资产数据存储在链下，但该数据的更改或转移通过承诺记录在链上。这些承诺允许链上交易引用链下状态，确保链下数据的完整性和不可篡改性。 3、链上见证（不一定是BTC）：尽管大多数数据和验证都发生在链下，但使用客户端验证的资产仍然可以通过嵌入在区块链上的承诺来利用底层区块链的安全性（发布证明、交易排序）。 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 则负责具体功能的实现，类似于编程语言中的接口。 这些合约的模式负责限制虚拟机执行期间超出预期的行为。例如，RGB20和RGB21分别负责在交易过程中对同质化和非同质化代币施加一定的限制。 RGB中使用的承诺机制Pedersen Hash 它的优势在于能够在不公开的情况下承诺某种价值。使用 Pedersen Hash 构建 Merkle 树意味着你可以创建一个可以隐藏其值的隐私保护 Merkle 树。这种结构在某些隐私保护协议中很有用，例如一些匿名加密货币项目。但是，它可能不适合 CSV 资产，稍后将在与 Taproot 资产比较时提到。 为RGB简单性设计的虚拟机 → AluVM RGB 的目标不仅是实现客户端验证的资产协议，而且还扩展到图灵完备的虚拟机执行和合约编程。最初，RGB 声称使用一种名为 Simplicity 的编程语言，它可以生成执行证明并允许对用它编写的合约进行形式验证（以避免错误）。然而，这种语言的开发并没有按计划进行，导致了复杂性，最终阻碍了整个 RGB 协议的发展。最终，RGB 开始使用由 Maxim 开发的名为 AluVM 的 VM，其目标是避免任何未定义的行为，类似于原始的 Simplicity。据说新的 AluVM 将来会被一种名为 Contractum 的编程语言所取代，从目前使用的 Rust语言迁移。 RGB Layer2 扩容方向：闪电网络还是侧链？ 客户端验证的资产无法持续安全地进行链下交易，因为它们仍然依赖 L1 进行交易发布和排序。这意味着，如果没有 2 层扩容解决方案，它们的交易速度仍然受到 L1 见证的区块生产速度的限制。这意味着，如果直接在比特币上进行RGB交易，在严格的安全要求下，两笔相关交易之间的时间至少需要相隔十分钟（BTC出块时间），这往往慢得令人难以接受。 RGB和闪电网络 简单来说，闪电网络的运作方式是让交易双方在链下签署一堆合约（承诺交易）。这些合约确保如果任何一方违反协议，受害方可以将合约（承诺交易）提交给BTC进行结算，收回其资金，并对违规者进行惩罚。换句话说，闪电网络通过协议和博弈论设计保证了链下交易的安全。 RGB可以通过设计适合RGB本身的支付通道合约细节来构建自己的闪电网络基础设施。然而，由于闪电网络的高度复杂性，建设这样的基础设施并不容易，特别是考虑到Lightning Labs在该领域的多年工作以及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）开发的人，展示了对 BTC 的深刻理解。 Taproot交易仅携带资产脚本的根哈希，使得外部观察者很难识别它们是否涉及 Taproot 资产，因为哈希本身是通用的，可以代表任何数据。通过 Taproot 升级，比特币获得了执行智能合约（TapScript）的能力。在此基础上，Taproot Assets 的资产编码本质上创建了类似于 ERC20 或 ERC721 定义的代币。这样，比特币不仅获得了定义资产的能力，还获得了编写智能合约的能力，为比特币的代币智能合约基础设施奠定了基础。 Taproot Assets的编码结构如下： 作者：Roasbeef，Lighting Labs首席技术官 同样作为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 升级后比特币附带的脚本执行引擎。而且，它使用了vPSBT，即比特币PSBT的变体，这表明一旦Taproot Assets闪电通道机制开发出来，它可以立即复用LND（Lightning Network Daemon）当前的所有基础设施，以及Lightning Labs之前的产品（LND目前在闪电网络中占有超过90%的市场份额）。此外，最近流行的 BitVM 提案是基于 TaprootScript 的，这从理论上讲意味着所有这些改进最终都可以使 Taproot Assets 受益。 然而，RGB 的运作方式略有不同。它的虚拟机和验证规则（SCHEMA）是一个独立系统的一部分，形成了一个有点封闭的生态系统。RGB 在自己的生态系统内运作，它与更广泛的比特币生态系统的关系并不像某些人想象的那么密切。例如，对于 Taproot 升级，RGB 唯一真正的交互是将承诺数据编码到区块中的 Witness TapLeaf 上。这说明 RGB 和 Taproot 升级仅存在最低程度的关联。 3、智能合约 在当前的 RGB 实现中，合约和 VM 被重点强调。然而，在 Taproot Assets 中，似乎并没有关注智能合约，至少目前还没有。当前的 RGB 实现尚未解释对全局状态的修改如何与各个合约分片 (UTXO) 同步。此外，虽然Pedersen承诺可以确保资产总量，但尚不清楚如何保护其他状态不被篡改，因为对此没有太多解释。 另一方面，Taproot Assets 的设计更简单，但目前仅存储资产余额，不处理更复杂的状态，使得智能合约讨论还为时过早。不过，据 Lightning Labs 称，明年计划将重点放在 Taproot Assets 的智能合约设计上。 4、同步中心 前面提到的关于资产在客户端验证的基本原则表明，持有 Proof 与持有私钥一样重要。然而，由于证明保存在客户端，因此存在丢失的风险。如何解决这个问题？在 Taproot Assets 中，可以通过使用“Universe”来避免这个问题。Universe 是一个可公开审计的稀疏 Merkle 树（sparse Merkle tree），涵盖一个或多个资产。不同于标准 Taproot 资产树，Universe 不用于托管 Taproot 资产。相反，它致力于一个或多个资产历史的子集。 在 RGB 系统中，这一角色由 Storm 来完成，它通过点对点（p2p）网络同步链下证明数据。然而，由于 RGB 开发团队的历史原因，这些团队目前使用不兼容的证明格式。RGB生态系统团队DIBA表示将开发“ carbonado ”来解决这个问题，但进展尚不清楚。 5、工程实施 Taproot Assets 使用的所有库都经过了充分测试，因为 Lightning Labs 拥有自己的比特币客户端 (BTCD)、闪电网络客户端 (LND) 和各种钱包库实现。相比之下，大多数用于 RGB 实现的库都是自定义的。从行业标准的角度来看，RGB的实施仍处于实验阶段。 简要展望BTC扩容的未来 很明显，客户端验证的资产协议已经超出了传统协议的范围，现在正朝着计算扩容的方向发展。 许多人声称，未来比特币将作为“数字黄金”而存在，而其他区块链将创建应用生态系统。不过，我却持有不同的看法。正如比特币论坛上的许多讨论所见，有很多关于各种山寨币及其短暂寿命的讨论。这些山寨币的迅速消亡使围绕它们的资本和努力变成了泡沫。我们已经将比特币作为共识的坚实基础；无需仅为应用协议构建新的L1解决方案。我们应该做的是利用比特币这个强大的基础设施来建立一个更长期的去中心化世界。 更少的链上计算，更多的链上验证 从应用设计的角度来看，比特币早期选择的理念不是以链上计算为中心，而是以验证为中心（智能合约的图灵完备性和状态）。区块链的本质是一个复制状态机。如果区块链的共识侧重于链上计算，那么很难说让网络中的每个节点重复这些计算是一种合理或可扩容的方法。如果重点是验证，那么验证链下交易可能是最适合比特币可扩容性的方法。 验证在哪里进行？这一点至关重要。 对于在比特币之上创建协议的开发者来说，如何使用比特币进行关键验证，甚至将验证置于链下，以及如何设计安全方案，都是协议设计者自己的事情。它们不应该也不需要与链本身相关联。如何实现验证将导致不同的BTC扩容方案。 从基于验证的实现角度来看，我们有三个扩容方向： 1、链上验证（OP-ZKP） 直接在 TaprootScriptVM 中实现 OP-ZKP 将赋予比特币本身执行 ZKP 验证的能力。这与一些 Covenant 设计结算协议相结合，可以创建继承比特币安全性的 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。 未来，我们也可以类似地将验证的计算推至链下，进一步释放当前区块链基础设施的性能。 来源：金色财经lg...
北美站
