比特币生态必读指南（1）：解锁万亿市场的力量

“我们期待下一个周期区块链指数型增长来源于比特币的大规模应用。”

随着 Web3 Labs 与 Waterdrip Capital 共同发起的 Satoshi Lab 实验室正式在香港成立，比特币生态系统的讨论热度在整个加密市场中逐渐攀升。在比特币脚本上利用客户端验证方案构建智能合约，同时兼容具备无限可扩展性的闪电网络进行通道交易，可能成为在同时保证 “安全性，去中心化，可扩展性” 三角上的区块链大规模应用方案。

本文将针对比特币生态一些基础层面概念进行科普讲解。从阻碍大规模应用的“区块链不可能三角”，到克服“不可能三角的比特币“闪电网络”，到目前对比特币脚本的解决方案及 UTXO 模型原理。

是什么阻碍了区块链的大规模应用？

以太坊创始人 Vitalik Buterin 和巴比特创始人长铗均提出过，“区块链网络无法同时实现安全性、去中心化和可扩展性”，即“区块链不可能三角”。“不可能三角”的难题，长久以来阻碍了区块链的大规模应用。

在保障安全性的基础上，以太坊过去十年将重心放在发展去中心化，并在底层公链的基础设施层不断创新，以拓展以太坊公链的可扩展性。为了实现这个目标，以太坊十年间也迭代出各种空气算法，分片，Rollup 等技术。

但对于可扩展性难题，从以太坊及其Layer2的尝试来看，似乎只要仍在解决方案局限在区块链上，性能就会存在上限的。即便是我们目前可见性能最强的区块链，仍难突破 TPS (每秒交易量) 上限，离百万级 TPS 的大规模商业应用的要求，和全球工业级实现数亿级 TPS 的目标仍有巨大差距。对于主流公链，不论是以太坊还是比特币，都面临一个瓶颈——“如何解决可扩展性？”

闪电网络是如何运作的？

闪电网络利用链下计算的方式，即 “支付通道 (Payment Channel)”，彻底解决了“不可能三角”的可扩展性问题——只要建足够多的通道，就可以跑任意多的并发交易。

闪电网络原理

1. 以银行体系作比喻，如果 A，B 两人开户转账。当两个人在相同银行时，在同一个银行内部清算。而当 A，B 两个人不在同一个银行时，需要通过央行执行跨行结算操作。
2. 闪电网络模仿了银行清算的方式：用户 A 和 B 通过闪电网络在两者之间开通闪电通道。通道开启时，A 和 B 利用通道直接在闪电网络进行清算，而不需要在比特币区块链上结算。只有当通道关闭时，A 和 B 才需要跨越闪电网络，在比特币区块链上结算。

闪电通道操作流程

1. 缴纳准备金：类比传统场景下银行开户需要提前缴纳准备金，开通闪电网络通道也需要缴纳比特币准备金。
2. 链下交易记账：通过闪电网络每笔交易逐笔记账，每一笔记账都要签订一个惩罚协议。
3. 链上结算记录：关闭闪电通道后，把历史交易数据一次性封装打包结算，最终发送到比特币区块链上。

闪电网络如何避免链上欺诈

如果在通道交易过程中，A 执行欺诈行为 —— 提前关闭通道结算比特币。那么通道关闭时，比特币链上会立刻产生一笔欺诈交易。基于比特币链的开放性，B 就可以及时观察到，并用提前签订的惩罚协议对 A 进行惩罚。惩罚内容就是没收 A 所有准备金。

闪电网络的大规模应用瓶颈

理论上闪电网络实现了无穷大的可扩展性，克服了区块链不可能三角。但阻碍闪电网络实现大规模应用最关键的问题是：闪电网络使用和比特币相同的脚本，而比特币链上没有智能合约，只有简单的脚本，无法承载复杂应用。即比特币链是图灵不完备的，图灵完备的意味着理论上可以解决任何计算性的问题。使用图灵完备的脚本语言，可以在逻辑上做到和其他编程语言兼容，并在理论上能够实现任何其他语言所能实现的逻辑，以及最大限度的复制现实的商业逻辑。比特币区块链上没有智能合约，更不用说基于智能合约搭建应用。所以闪电网络需要克服的最大问题就是“如何在比特币上实现智能合约”。

现有提升比特币区块链“功能”的方案

1. 侧链（Side Chain）
2. 侧链是指做一条具有智能合约功能的链，复制它与比特币主链双向挂钩，从而使比特币资产在主链与侧链间无缝迁移，从而实现智能合约，但目前没有足够去中心化的双向挂钩技术。侧链对于主链的复制和资产迁移需要第三方中心化服务商，目前只有泛中心化方案。如“WBTC”，由 BitGo 发行在以太坊网络上的一种 ERC-20 代币，作为衍生资产与 BTC 1：1 锚定。侧链方案因为第三方发行的中心化问题始终未得到比特币核心开发者社区支持。
3. 彩色币（Colored Coins）
4. 2012年比特币协会主席 Meni Rosenfeld 发表了《彩色币概述》论文，文中介绍了一种利用比特币“可替代性”的机制，通过为某些硬币“着色”，将特定的代币与其他代币分开，从而创建适合这些硬币的应用程序。具体方式是利用比特币脚本里 OP_RETURN 指令，在后面增加 80 个字节的任意字符，在 80 个字节里按照指定格式设计字符串，通过人为指定字符串含义标记 “彩色币”，并且做更复杂的智能合约。但 80 个字节的空间太小，无法实现复杂功能。
5. 后续“彩色币”方案也推出了新技术。比如“Ordinals”铭刻技术，通过利用比特币区块内 3 M 的“隔离见证”空间，用在其中塞入小图片，发行NFT。比如 BRC-20，用一串代码表达比 80 个字节更丰富的内容。但这些彩色币会产生额外的严重问题——占用了“隔离见证”空间，原先用来存放比特币转账交易签名的空间，挤占了“隔离见证”空间会导致了比特币上可执行的交易数量减少，使比特币性能下降。彩色币方案同样遭到比特币核心开发者强烈抵制，原因是彩色币污染了原生比特币，另外人为指定的形式仍然需要中心化的第三方进行服务器解析。
6. 客户端验证（Client-Validation）

2016 年比特币核心开发者 Peter Todd 发表论文提出了客户端验证范式，通过模拟传统的合同签约方式保证只有双方知道合约内容的隐私性前提，无需任何第三方参与，实现完全去中心化。同时，在交易执行时，采用由交易发起方提供必要的完整交易历史数据，另一方自行验证的方式，来防止欺诈问题的产生。既不存在中心化困扰，又是链下验证不受性能限制的特征，使其目前被多数人认为是解决比特币区块链图灵完备性不足的“最优”方案。

传统合同签署vs区块链智能合约签署

1. 传统合同签署：A 和 B 之间有一笔交易，先签署一个合同，双方确认合同内容后签字，签字时合同不可篡改。未来合同执行过程的任何交易都是 A 和 B 两个人的交易，不需要第三方介入。
2. 区块链智能合约签署：交易过程公布给全网，所有矿工进行执行与验证。整个执行过程无隐私可言，且由于需要公布到全网达成共识，性能受到局限。

客户端验证是否无懈可击？

看到这里，似乎会有人产生疑问，去中心化的比特币区块链本身解决了传统商业中的安全问题，但随着客户端验证的引入，解决方案又回到链下，即便其解决了欺诈问题，那么又该如何有效地防止双花问题产生？

引入“一次性密封”

由于客户端验证本身并不包含双花防止机制，我们不得不需要引入第三方辅助来解决这个问题。为了实现这一目标，我们将客户端验证中需要验证的每个合约的每个状态，与特定比特币的未使用交易输出(UTXO)绑定。由于UTXO仅存在两种形态，”花费”与“未花费”。而一旦要变更验证合约的状态，就必须花费绑定的UTXO（任意金额均可），让花费它的交易得到区块链的确认。此外，花费它的比特币交易还必须提供状态转换的内容的证明（作用类似于哈希值）。简单来说，可以将被绑定的UTXO视为这个状态“信封”的封蜡一一想要打开信封，就必须开启封蜡。

UTXO模型的补充说明

区别于以太坊的账户模型，未花费的交易输出（UTXO）是从一个地址发送到另一个地址但尚未被接收方赎回的加密货币总和，以便在后续交易中将资金发送给其他人。

1. 例如，如果爱丽丝向鲍勃发送 1 个比特币，那么只要鲍勃没有花掉从爱丽丝那里收到的 BTC，他就拥有 UTXO。一旦 Bob 花费了 1 个 BTC，UTXO 的生命周期就结束了。
   

2. 假设Bob的钱包只参与过一笔交易，其中Bob从Alice那里收到了1 BTC，交易验证者就知道Bob的UTXO余额是1 BTC。如果 Bob 将 1 BTC 发送给 Carol，他的 UTXO 立即变为 0 BTC。如果 Bob 然后尝试在第二笔传出交易中双花-MN4DXX5)他的币，验证者将发现他的 UTXO 余额不足以用作第二笔交易的输入，并且诚实的验证者将不会传播或确认他的双花交易。

下一个指数增长：比特币生态全面爆发

在比特币的演进过程中，客户端验证的设计精妙地规避了侧链和彩色币方案的中心化问题，并引入了一次性密封机制，使其进一步提升了安全性。此刻，比特币生态正在迎来一系列全新协议的诞生，其中，RGB协议不仅沿用了上述理念，还提出与闪电网络兼容，为无限可扩展性打下基石。尽管RGB协议与闪电网络的兼容性尚未完美，但我们对未来充满信心，相信帮助协议不断优化的基础设施将突破长期以来的“区块链不可能三角”局限。

我们更加有理由期待下一个周期区块链指数型增长来源于比特币生态的爆发所带动的区块链大规模采用。相信比特币将突破原有的单一价值存储，彰显其货币属性的同时，不断通过多样化的解决方案为比特币生态嫁接更多应用，促进生态可扩展和可持续发展，继续为区块链世界带来无限可能。

声明：

1. 本文转载自[Waterdrip]，著作权归属原作者[Echo, Infinitas]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。