# 与比特币的关联
在上一节中，我们将 Stacks 描述为在不修改比特币本身的情况下，为比特币带来智能合约功能，并简要解释了这条链的工作方式。这是一个很大的承诺，但 Stacks वास्तव如何兑现它？又是什么让 Stacks 在其他比特币层和像以太坊这样的其他区块链中独树一帜？ 在深入了解 Stacks 的技术细节之前，先从高层次了解它要解决的问题以及它实际上是如何做到的，这一点很重要。随着我们继续阅读文档，我们会更深入地探讨其中一些主题，但先形成一个整体印象，把所有内容串联起来会更好。这个主题有点像兔子洞，不过它会让你深入理解 Stacks 到底想解决什么问题，以及它是如何解决的。 让我们开始吧。 ### 比特币层的目的是什么？ 信任的去中心化是区块链最主要的创新和承诺。即使在加密货币世界中，2022 年最近的失败也都来自中心化实体，这进一步凸显了不依赖“可信”中心化中介的系统的重要性。比特币是最安全、最持久、最有价值的区块链；它已经被数百万人用作价值储存。它是一种稳健、“硬”的货币，拥有前所未有的非托管所有权和无通胀特性。比特币区块链也是交易的最佳结算层，因为它是最去中心化、最抗审查、也最持久的区块链。 然而，比特币在设计上相对缓慢且精简，并且在演进上保持保守，以保留这些强大的特性。它平均每 10 分钟产生一个区块，每秒仅能处理 5-7 笔交易。它原生不支持完全表达性的智能合约，因此也无法支持能够利用其特性的复杂应用。结果是，比特币一直更像一种被动资产，而不是一种生产性资产。尽管它拥有吸引人且独特的属性，它除了作为价值储存和偶尔的资金转移之外，并没有成为应用平台。 比特币层改变了这一点。比特币层在不要求对比特币区块链做任何修改的情况下，扩展了比特币区块链的功能和性能。 ### 我们该如何定义什么是比特币层？ 定义什么是比特币层很重要。虽然对于在 Layer 1 之上的系统何谓 Layer 2 有一些细微差别的观点，但以下是我们认为构成理想比特币 L2 的属性，以及我们所做的假设： 1. 开源且去中心化的开发流程 2. 完整的虚拟机支持，以及使用富表达力的高级语言进行编程的能力 3. 快速的交易和出块时间（不需要等待 10-30 分钟才能等到比特币区块） 4. 一种尽量减少信任的方式，在 L1 和 L2 之间转移 BTC 5. BTC 作为部署在 L2 应用中的主要资产 6. 能够用 BTC 支付 L2 交易费用 7. 能够在没有对手方风险的情况下，单方面将你的 BTC 从 L2 提回 Stacks V1 具备属性 1 和 2，但缺少其余属性。Nakamoto 升级带来了属性 3、4 和 5，目前也在讨论和推进实现 6。当前，Lightning 是唯一具备属性 7 的 L2，而真正利用这一点的唯一方式是运行自己的 Lightning 节点——这是一项复杂的工作，愿意这样做的用户并不多。此外，Lightning 缺少属性 2，这意味着我们无法在比特币 L1 已经具备的能力之外解锁任何额外功能。 需要承认的是，比特币上的 L2 与像以太坊这样的其他 L1 上的 L2 目标根本不同。以太坊上 L2 的主要动机是提升可扩展性，而比特币 L2 的作用是同时提升可扩展性和功能性。这意味着比特币层无法验证像 Stacks 这样 L2 上发生的交易有效性。相反，该层的虚拟机负责交易处理和验证，并将这些交易结算到比特币上，使它们共享相同的历史和最终性。 {% embed url="" %} ### Stacks 是比特币 L2 吗？ Stacks 是一个用于智能合约的比特币层。将其归类为 Layer 1（L1）、Layer 2（L2）或侧链，实际上取决于所采用的定义。话虽如此，一般来说，L1 链是主权的，这意味着：(a) 它们有自己的安全预算；(b) 它们在不需要任何其他 L1 链的情况下也能生存。L2 链通常没有自己的安全预算，而是共享底层 L1 链的安全性，并且离不开底层 L1 链。L2 可以采用许多不同的设计机制。 Stacks 在 2021 年初的首次发布时，拥有独立于比特币 L1 的安全预算。虽然 Stacks 层离不开比特币 L1，但当时该项目的开发者将其描述为一个不同的系统，不太能被现有分类准确归类，有时会使用 layer 1.5 这一术语（见 [这篇 Decrypt 文章](https://decrypt.co/82019/bitcoin-defi-thing-says-stacks-founder-muneeb-ali) 例如）。 2024 年的 Nakamoto 版本使 Stacks 能够与比特币共享同一安全预算。届时，100% 的比特币算力将决定 Stacks 层的最终性。要重组 Stacks 区块/交易，攻击者就必须重组比特币 L1 本身（这非常难做到，因此是比特币层非常重要的一项安全特性）。 以太坊和其他较新生态系统中使用的 L2 定义不同，它侧重于仅依靠 L1 安全性和 L1 矿工即可提取资产的能力。按这种定义，Stacks 层并不是一个明确的 L2，因为决定用户是否可以提取 sBTC 的是 peg-out 签名者集合。比特币无法在不修改比特币 L1 的情况下支持这种验证（未来可能会发生变化）。以太坊的 L2 定义对于比特币 L2 也并不那么适用，因为在比特币体系中，新资产是在 L2 上发行的，而不是在 L1 上发行的（L1 资产只有 BTC）。因此，使用“资产提取安全性”的定义并不直接适用，因为资产是被定义并在 L2 上使用的，而不是被提取回比特币 L1（BTC 本身除外）。相反，更重要的是“在比特币上结算”，也就是说，合约数据和状态是否由 100% 的比特币算力来保障。 记住，比特币上的 L2 还必须承担扩展功能和可扩展性这两个额外目的，这意味着 L2 所完成的目标会因 L1 的功能不同而根本不同。 用户和开发者通常会自然而然地把 Stacks 称为比特币 L2，因为这更容易理解。Stacks 层还有一些属性也有助于强化它作为比特币 L2 的概念： {% stepper %} {% step %} **比特币最终性** 100% 的比特币算力决定区块排序和交易最终性。 {% endstep %} {% step %} **共识运行在比特币上** Stacks 共识运行在比特币 L1 上，并且没有比特币 L1，Stacks L2 无法运行或生存。 {% endstep %} {% step %} **sBTC 和经济单位** 借助去中心化的比特币挂钩资产 sBTC，Stacks 层上大部分经济活动将使用 BTC 作为经济单位。预计大多数用户会直接在钱包和应用中使用比特币，然后将他们的 BTC 提回到比特币 L1。 {% endstep %} {% step %} **数据在比特币上哈希并存储** Stacks 上的所有数据和交易都会在每个比特币区块中自动哈希并永久存储到比特币 L1 上。任何人都可以通过检查比特币上的对应哈希，来验证 Stacks 上的某些数据是否有效。这种在 L1 上压缩存储哈希的方式，在某种程度上类似于 rollup（尽管还有其他差异）。你可以在 [出块](/learn/zh/block-production.md) 一节中了解更多关于这一过程的信息。 {% endstep %} {% step %} **合约可以读取比特币状态** Stacks 层上的合约可以读取比特币 L1 交易并对此作出响应。Stacks 层上的资产可以仅通过比特币 L1 交易进行转移。 {% endstep %} {% endstepper %}
回应怀疑者和批评者 考虑到以上所有细节，为什么有些人会认为 Stacks 不是比特币 L2？这个问题之所以经常被提起，主要有几个原因： * **旧的安全预算材料**：Stacks 的初始版本（于 2021 年初发布）拥有独立的安全预算，而在 Nakamoto 版本中，这一预算变为了继承 100% 的比特币算力。 * **以太坊 L2 提款定义无法直接对应**：按照以太坊对 L2 的定义，用户应该能够仅通过执行一笔 L1 交易，并且只依赖 L1 安全性，就能提取其底层资产（例如 Lightning 就符合这一点）。这一定义并不适用于比特币 L2，因为资产并不是在比特币 L1 上定义的，而是定义在 L2 中。唯一需要注意的资产是从比特币 L1 锚定来的 BTC 资产，因为其他所有资产本来就是 L2 原生资产。在即将发布的 Stacks 版本中，用户可以只发送一笔比特币 L1 交易来提取 BTC，但比特币 L1 无法验证这种复杂交易，且必须由多数 peg-out 签名者对该提取请求签名。理想情况下，比特币矿工可以验证这类交易，但这需要修改比特币 L1。因此，Stacks 的设计优化方向是实现一种去中心化、且无需对比特币 L1 做任何修改即可部署的方法。如果未来可以对比特币 L1 做出修改，那么 Stacks 层的安全性也可以从中受益。 * **健康的比特币怀疑主义**：比特币社区成员通常对各种说法持怀疑态度，并会留意任何虚假营销宣传的人。这对比特币生态系统通常是件好事，也能增强其免疫力。这样一些社区成员在完全阅读技术细节和推理之前，可能会对 Stacks 作为比特币层或 L2 持怀疑态度。关于这个主题也有一条不错的 Twitter 讨论串。
那为什么我们不用“侧链”这个术语来称呼 Stacks 呢？比特币中的侧链通常拥有不同于比特币 L1 的安全预算，通常是由参与侧链的一部分比特币矿工来提供（它们不遵循 100% 的比特币最终性）；它们的共识运行在侧链上（而不是运行在比特币 L1 上）；并且它们不会把数据/哈希发布到比特币 L1 上。Stacks 层并不完全符合这个定义，因为其共识运行在比特币 L1 上，它遵循比特币最终性，并且会将数据/哈希发布到 L1。 ### Stacks 与比特币之间的共生关系 Stacks 和比特币相互补充。Stacks 利用比特币极致的去中心化、其 PoW 共识机制，以及它作为加密货币的价值。 但 Stacks 也通过解锁更多用例来补充比特币，从而随着时间推移提升其价值。这也有助于解决这样一个额外问题：在区块奖励消失、比特币必须仅依靠交易手续费运行之后，如何维持比特币的未来可维护性。 {% embed url="" %} 如果把比特币只看作价值储存工具，那么每笔交易的经济密度，也就是交换的价值量，将会非常低。但如果比特币是整个去中心化经济的底层基础，那么这些交易就会变得更有价值，从而提高交易手续费。这对矿工在区块奖励下降后继续保障网络安全，是一个至关重要的激励。 ### 打造以比特币为先的开发者体验 Stacks 网络之所以能在与比特币连接时发挥“超能力”，不仅因为它在协议层面与比特币连接的方式，如上所述，还因为我们可以在程序层面利用比特币。 比特币 L2 的开发者体验应该抽象掉比特币的复杂性，同时也要保留 *那种* 在比特币上构建的感觉。听起来像是矛盾，但这就是 Stacks 的实现方式： {% stepper %} {% step %} **使用 sBTC 支持比特币流动**
sBTC 解锁了比特币的可编程性。你可以获得 L2 的表达能力，同时又不失去比特币熟悉的属性：计价单位、表示方式和信任模型。 {% endstep %} {% step %} **直接接入 BTCFi**
Zest、Bitflow、StackingDAO、Dual Stacking 以及其他 Stacks 上的主要 DeFi 协议，为构建智能、可组合、以比特币为先的应用提供开发工具。 {% endstep %} {% step %} **一个加密身份**
Stacks 使用 *相同的* 加密原语——相同的曲线（secp256k1），相同的 `hash160` 构造——来派生 Stacks 地址。它们的格式不同（版本字节/编码不同），但底层的身份锚点是相同的 20 字节公钥哈希。 不同层。相同的加密私钥。 {% endstep %} {% step %} **响应比特币状态**
Clarity 经常被宣传的一个特性，是它内置了对比特币链状态的访问，但它实际上是如何做到的？由于 Stacks 的 PoX 机制，每个 Stacks 区块都与一个比特币区块相连接，并且可以使用 `get-burn-block-info?` 函数查询比特币区块头哈希。 Clarity 可以直接读取比特币状态。解析 BTC 交易。根据比特币活动触发逻辑。 {% endstep %} {% step %} **以比特币速度在 L2 上捕捉时间**
Clarity 合约可以按比特币区块来衡量时间。这不仅仅是技术上的——它也具有象征意义：就像根据太阳追踪时间一样，我们信任比特币的节奏。 {% endstep %} {% endstepper %} *** ### 其他资源 * \[[Hiro 博客](https://www.hiro.so/blog/building-on-bitcoin-project-comparison)] 在比特币上构建：比特币项目比较 * \[[Hiro 书籍](https://www.hiro.so/books/a-beginners-guide-to-bitcoin-layers)] 比特币层入门指南 * \[[Stacks YT](https://www.youtube.com/watch?v=F31B-my510A)] Stacks 与比特币矿工的关系 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.stacks.co/learn/zh/stacks-101/bitcoin-connection.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.