<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>PepeTimes</title>
        <link>https://paragraph.com/@hellonakamoto</link>
        <description>all in ordinals </description>
        <lastBuildDate>Fri, 14 Aug 2026 23:13:11 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>en</language>
        <image>
            <title>PepeTimes</title>
            <url>https://storage.googleapis.com/papyrus_images/2db8ed8af334e718b70eb7ed64c42e10672b184b7b80c3123113b411d2e8bd9b.png</url>
            <link>https://paragraph.com/@hellonakamoto</link>
        </image>
        <copyright>All rights reserved</copyright>
        <item>
            <title><![CDATA[如何在比特币中构建ZK-Rollup]]></title>
            <link>https://paragraph.com/@hellonakamoto/zk-rollup</link>
            <guid>4GAogE1QKKNnPfjAOOG3</guid>
            <pubDate>Sat, 13 May 2023 12:51:56 GMT</pubDate>
            <description><![CDATA[节选翻译自john-light 的Validity Rollups on Bitcoin报告 译者：kaishek.bnb https://twitter.com/han_web3译者注事实证明，比特币生态尤其是Dapp方面生态的发展不如人意，被以太坊远远落下。事实上比特币生态并非没有在智能合约领域发力，无论stacks还是rsk都是市值曾过10亿美元的项目，这个项目也都在做defi nft did赛道，但都没什么影响力。但比特币作为最安全、市值最好和共识最强的加密货币，难道只能作为数字黄金，只能用于支付和储值吗？Ordinal协议的横空出世给我们提供了一种新的思路，或许盲目模仿以太坊的智能合约的路径是错的，比特币可以走出自己的新路。 Del Bonis提出的ZK Rollup方案实际与Ordinal协议有异曲同工之妙，就是在比特币上“屎上雕花”。比特币不需要搞出一条新的侧链（如RSK等），不需要重新搞一套智能合约语言，事实证明这样搞是搞不过以太坊的，比特币可以通过改进自己的Script脚本语言实现类似智能合约的效果，即BTC ZK-Rollup，这样做的好处是完美利用比特币网络...]]></description>
            <content:encoded><![CDATA[<p>节选翻译自<a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://github.com/john-light">john-light</a> 的Validity Rollups on Bitcoin报告</p><p>译者：kaishek.bnb</p><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://twitter.com/han_web3">https://twitter.com/han_web3</a></p><h3 id="h-" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">译者注</h3><p>事实证明，比特币生态尤其是Dapp方面生态的发展不如人意，被以太坊远远落下。事实上比特币生态并非没有在智能合约领域发力，无论stacks还是rsk都是市值曾过10亿美元的项目，这个项目也都在做defi nft did赛道，但都没什么影响力。但比特币作为最安全、市值最好和共识最强的加密货币，难道只能作为数字黄金，只能用于支付和储值吗？Ordinal协议的横空出世给我们提供了一种新的思路，或许盲目模仿以太坊的智能合约的路径是错的，比特币可以走出自己的新路。</p><p>Del Bonis提出的ZK Rollup方案实际与Ordinal协议有异曲同工之妙，就是在比特币上“屎上雕花”。比特币不需要搞出一条新的侧链（如RSK等），不需要重新搞一套智能合约语言，事实证明这样搞是搞不过以太坊的，比特币可以通过改进自己的Script脚本语言实现类似智能合约的效果，即BTC ZK-Rollup，这样做的好处是完美利用比特币网络的安全性与共识。Ordinal的火热证明了这种区别于以太坊的功能实现方式是有市场的也是吸引人的。密切关注比特币生态的发展，Make Bitcoin Great Again！</p><h3 id="h-" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">前言</h3><p>自从Satoshi Nakamoto首次发布比特币以来，它的支持者，批评者和怀疑者一直在质疑比特币协议如何随着使用量的增长进行扩展。在比特币区块链日益拥堵的今天，这个问题变得比以往任何时候都更为重要。所谓的“第二层”（L2）协议，例如闪电网络，已经部署以将一些交易量“离线”，但即使是闪电网络也需要使用一些比特币块空间。很明显，随着越来越多的世界人口（无论是人还是机器！）采用比特币，将需要更多的区块空间。另一方面，有一些研究关注于比特币有限的脚本功能是否有助于或妨碍其作为电子现金的价值。研究人员和发明者已经表明，比特币首先实现的电子现金交易可以通过提高交易隐私、支持新类型的智能合约甚至创建完全新的基于区块链的资产而得到新的形式。</p><p>对像比特币这样的区块链进行扩展和扩展功能十年以上的研究的结果之一是有Validity Rollup的发明。鉴于Validity Rollup对已经实现它们的区块链的观察到的优点，现在的关注点转向了它们是否对比特币和现有的比特币L2协议如闪电网络等也有益。我们通过从多个角度（包括它们的历史，它们在技术层面上的工作方式，它们如何在比特币上构建以及构建它们的成本和风险）来探讨这个问题。**我们得出结论，Validity Rollup有潜力提高比特币的可扩展性、隐私性和可编程性，而不会牺牲比特币作为点对点电子现金系统的核心价值或功能。**鉴于Validity Rollup的“无信任”本质是其父链的密码学安全性的扩展，并考虑到比特币是最安全的结算层，可以说这些协议之间是完美匹配的。</p><h3 id="h-" class="text-2xl font-header !mt-6 !mb-4 first:!mt-0 first:!mb-0">如何实现</h3><p>截至撰写本文时，几乎所有部署到生产环境的Validity Rollup都是基于支持图灵完备编程语言的智能合约的区块链构建的。图灵完备编程语言的灵活性为 Rollup 开发者提供了广阔的设计空间，他们利用这种灵活性为 Rollup 智能合约编写特色功能和限制，如脚本编程能力、存款限额和升级能力。这种灵活性还意味着，随着有效性证明技术的改进和发现实现或优化某些功能的新方法，Rollup 开发者可以升级他们的智能合约或部署新合约，以跟上技术前沿的发展。</p><p>尽管使用图灵完备编程语言构建 Rollup 智能合约非常流行，但通过比特币的本地非图灵完备编程语言 Script，在比特币上构建Validity Rollup 仍是可行的，只需相对较小的改动（就代码规模而言）。2022 年 3 月，Trey Del Bonis 发表了一篇详细介绍如何在比特币上运作Validity Rollup 的文章。根据 Del Bonis 的说法，为了支持在比特币上运作Validity Rollups，需要一些额外的操作码，以启用其 Rollup 设计的两个主要原语 —— 有效性证明验证和递归契约。尽管不是严格必需的，但 Del Bonis 表示，还有一些其他改动可以显著降低成本并提高 Rollup 效率，例如 OP_EVAL 和 PUSHSCRIPT 操作码以及增加甚至完全取消堆栈元素大小限制。 </p><p>**赋予比特币全节点验证有效性证明的能力，是支持Validity Rollup的必备条件。**为实现这一部分，任何为比特币启用有效性证明验证功能的开发人员都需要根据他们想要实现的 Rollup 类型来做一些决策。比如，实现验证更复杂程序的证明将使具有更多功能的 Rollup 得以实现（例如如 Rootstock 或 Stacks），而较简单的证明将使具有较少功能的 Rollup 得以实现（例如简单的支付和有限的操作码，如 Liquid 或比特币）。</p><p>**此外，至少在Del Bonis比特币Rollup设计中，需要采用递归契约。**递归契约是一种智能合约类型，用于限制在 BTC 被花费后，可发送至的脚本类型。Del Bonis 使用递归契约将Rollup结构随每次状态更新向前传播，确保锁定在Rollup脚本中且尚未由所有者提取的BTC在Rollup状态更新过程中保持在脚本中。一旦Rollup上的BTC所有者在Rollup中确认了一个有效的提现交易，他们就可以将BTC从递归契约脚本中解除，并发送至他们指定的L1提现地址。</p><p>**递归契约是比特币社区长期以来一直在考虑的一种对Script的改进。**然而，目前尚无具体提案在比特币开发者社区中获得广泛共识以实现递归契约。虽然有像BIP-118和BIP-119这样的提案可以实现更有限的契约，但它们没有递归属性，而这是确保比特币所有者准备将比特币提款回L1时，发送至 Rollup 的 UTXOs 仍然在 Rollup 中的必要条件。</p><p>**Del Bonis的Rollup设计的另一个重要变化是增加或取消栈元素大小限制。**这会让Validity Rollup数据更容易被Rollup脚本处理。同时，通过增加每次Rollup状态更新中可容纳的交易数量，让更多交易共享Rollup更新成本，从而降低Rollup的使用成本。在“好用”的改进方面，Del Bonis建议使用 OP_EVAL 和 PUSHSCRIPT 操作码来减小某些区域的Rollup脚本大小，从而减少区块空间的占用，使Rollup使用成本更低，前提是其他所有条件相等。</p><p>Del Bonis的Rollup设计并不是在比特币上构建Validity Rollup的唯一方式。其他方式例如，可以在比特币上添加一个具有自定义逻辑的扩展区块，以支持创建特定或任意Rollup设计。在他的文章中，Del Bonis讨论了在比特币上构建Rollup的几种替代方案，无论是对他的详细设计做一些小调整，还是使用完全不同的机制来确保Rollup中资金的安全。例如，不是直接为需要的操作码提供支持，而是在 Simplicity 中使用 Jets来实现Validity Rollup 原语。Anthony Towns还建议将 Chialisp 作为 Simplicity 的替代方案来满足类似用例。</p><p>虽然Elements侧链项目（以及基于Elements的Liquid区块链）尚未支持有效性证明，但已经支持递归契约。因此可以通过在Elements中实现有效性证明以及Del Bonis提出的其他一些改进，测试最终将在比特币上部署的Validity Rollup协议。</p><p>到目前为止的研究表明，在进行一些改进后，有可能在比特币上构建Validity Rollups。尽管有些设计在技术上难以实现，但即便使用较简单的提案实现，比特币用户同样可以获得显著的扩容优势，以及更高的隐私性和其他期望的功能。</p><p>资料来源：</p><p>[1]Validity Rollups on Bitcoin</p><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://github.com/john-light/validity-rollups/blob/main/validity_rollups_on_bitcoin.md">https://github.com/john-light/validity-rollups/blob/main/validity_rollups_on_bitcoin.md</a></p><p>[2]Bitcoin zk-rollups</p><p><a target="_blank" rel="noopener noreferrer nofollow ugc" class="dont-break-out" href="https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html">https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html</a></p>]]></content:encoded>
            <author>hellonakamoto@newsletter.paragraph.com (PepeTimes)</author>
        </item>
    </channel>
</rss>