比特币最初被设计为拥有一个完备的脚本语言，旨在涵盖并支持用户未来可能想到的任何安全用例。正如中本聪在他消失前所说：
“比特币的本质是一旦版本0.1发布，核心设计将在其生命周期内固定不变。因此，我希望设计一个支持我能想到的每一种可能交易类型的系统。问题在于，每种类型都需要特殊的支持代码和数据字段，无论是否使用，并且每次只覆盖一种特定情况。这将导致特殊情况的爆炸式增长。解决方案是脚本，它泛化了这个问题，以便交易方可以将他们的交易描述为节点网络评估的谓词。” ——中本聪，2010年6月17日。
整个目的是为用户提供足够通用的语言，使他们能够根据需要设计自己的交易类型。换句话说，给用户空间去设计和实验如何编程他们自己的钱。
在他消失之前，中本聪删除了15个操作码，完全禁用了它们，并为脚本引擎堆栈上可以操作的数据片段设置了一个硬性限制（520字节）。这是因为他坦率地说搞砸了，留下了大量复杂脚本可以用来对整个网络进行拒绝服务攻击的方式，创建庞大且验证成本高昂的交易，这些交易会导致节点崩溃。
这些操作码并不是因为中本聪认为其功能危险或者人们不应该用它们来构建东西而被移除的，而是仅仅（至少表面上）因为它们在没有资源限制的情况下使用时，对网络验证成本的最坏情况带来的风险。
自那以来，比特币的每次升级最终都是简化剩余功能，纠正中本聪留下的其他不太严重的缺陷，并扩展我们剩下的那部分脚本的功能。
伟大的脚本恢复计划
在五月初的Austin Bitcoin++会议上，Core Lightning开发者Rusty Russell在会议的首次演讲中提出了一个相当激进的建议。他本质上建议重新启用Satoshi在2010年消失前禁用的大多数操作码（opcodes）。
自2021年Taproot激活以来的这几年里，开发领域实际上有些迷茫。我们都知道，比特币没有足够的可扩展性，无法真正以自我主权的方式服务于全球大量人口，甚至在信任最小化或托管方式下也难以超越非常大型的托管人和服务提供商，无法真正逃脱政府的长臂。
任何对比特币有技术了解的人都明白这一点，这无可争辩。但争论的焦点，也是非常有争议的一点，是如何解决这一不足。自Taproot以来，每个人都在提出非常狭隘的建议，旨在解决特定的用例。
ANYPREVOUT (APO)是一个提案，允许签名在不同交易上可重复使用，只要输入的脚本和金额相同，专门优化了闪电网络及其多方版本。CHECKTEMPLATEVERIFY (CTV)是另一个提案，旨在强制硬币只能通过与预定义交易完全匹配的交易来花费，这使得预签名交易链完全无信任。OP_VAULT旨在为冷存储方案启用“超时期”，这样用户可以在密钥被泄露的情况下，通过将资金发送到更冷的多签设置来“取消”从冷存储的提取。
还有许多其他提案，但我想你明白我的意思。与其尝试全面解决扩展比特币所需的表达性和可编程性，这些年来的每一个提案都旨在提供小幅度的可扩展性提升或改善某个狭隘的功能。这正是这些对话没有进展的原因。没有人对其他提案感到满意，因为它不符合他们希望构建的用例。
没有哪个提案足够全面，让提案以外的人认为这是下一步的合理举措。
这就是伟大脚本恢复计划的逻辑。通过推动和分析Satoshi最初设计的脚本的全面恢复，我们可以实际探索所需功能的整个空间，而不是在各种小功能扩展上争吵不休。
操作码（Opcodes）
- OP_CAT：从栈中取出两个数据并将它们合并为一个。
- OP_SUBSTR：接收一个长度参数（以字节为单位），从栈中取出一段数据，移除指定长度的字节并将剩余数据放回栈中。
- OP_LEFT 和 OP_RIGHT：接收一个长度参数，分别从栈中数据的左侧或右侧移除指定长度的字节。
- OP_INVERT、OP_AND、OP_OR、OP_XOR、OP_UPSHIFT 和 OP_DOWNSHIFT：从栈中取出一个数据元素并对其进行相应的位运算操作。
- OP_2MUL 和 OP_2DIV、OP_MUL、OP_DIV、OP_MOD：用于乘法、除法和取模（返回除法余数）的数学操作。
- 以上是拟恢复的操作码。此外，Rusty 提议了三个更多的操作码，以简化不同操作码的组合。
- OP_CTV (或 TXHASH/等效操作码)：用于细化强制要求交易的某些部分必须完全符合预先定义的内容。
- CSFS：允许对任意数据验证签名，而不仅仅是整个交易。这使得可以要求脚本或其使用的数据的某些部分被签名后才能执行。
- OP_TWEAKVERIFY：验证涉及公钥的 Schnorr 操作，例如从聚合公钥中添加或减去单个公钥。这可以确保在某方单方面离开共享 UTXO 的情况下，其他人的资金被发送到一个不需要离开方签名即可共同支配的聚合公钥。
我们为什么要这样做
Layer 2 解决方案本质上是比特币基础层的延伸，由于基础层功能的限制，Layer 2 的功能也受到限制。例如，闪电网络在实现之前需要三个独立的软分叉：CHECKLOCKTIMEVERIFY (CLTV)、CHECKSEQUENCEVERIFY (CSV) 和 Segregated Witness (隔离见证)。
在没有更灵活的基础层的情况下，无法构建更灵活的 Layer 2 解决方案。唯一的捷径就是依赖可信的第三方，但我们希望在大规模使用比特币时尽可能消除第三方的参与。
目前，我们需要在基础层上实现一些功能，才能在一个单一的UTXO中安全地容纳两人以上，并且能以信任最小化的方式执行。这需要比特币脚本有更高的灵活性。基本上，我们需要covenants（契约），需要脚本能够执行更细粒度的交易控制，确保用户在单独退出 UTXO 时不会影响其他用户的资金安全。
高层次上，我们需要以下功能：
1. 内省（Introspection）：我们需要能够在栈上检查花费交易的具体细节，比如“这笔钱进入某个输出的某个公钥”。这允许我使用自己的特定 Taproot 分支单独取回我的资金，同时确保我不能拿走其他人的钱。脚本执行将通过共识机制强制执行，确保如果我退出，其他人的资金将被发送到由其他用户公钥组成的地址。
2. 正向数据传递（Forward Data Carrying）：假设我们进一步扩展一个包含多人的闪电通道，构建一个包含大量人的单一 UTXO，任何人都可以自由进出。我们需要某种方式来跟踪每个人拥有多少钱，通常这通过 merkle 树及其根来实现。这意味着当有人离开时，我们必须确保谁有权得到什么的“记录”是其他人资金变更 UTXO 的一部分。这本质上是 introspection 的一种特定应用。
3. 公钥修改（Public Key Modification）：我们需要能够确保对聚合公钥的修改可以在栈上验证。UTXO 共享方案的目标是有一个聚合密钥，允许每个参与者共同且更高效地移动资金。每当有人单方面退出共享 UTXO 时，我们需要从聚合密钥中移除他们的个人密钥。在不预先计算所有可能组合的情况下，唯一的选择是能够验证从聚合密钥中减去一个密钥后，剩余的密钥仍然构成一个有效的聚合密钥。
如何确保VAROPS的安全性
正如上文所述，这些操作码（opcodes）被禁用的原因是为了消除导致网络节点崩溃的拒绝服务攻击风险。解决这个问题的方法是限制这些操作码可以使用的资源量。
我们在签名验证方面已经有了这样的解决方案，这是验证比特币脚本最耗费资源的部分。这个解决方案称为签名操作预算（sigops budget）。每次使用签名检查操作码都会消耗每个区块允许的签名操作数量的‘预算’。这为用户在验证单个区块时可以施加的成本设置了一个硬性限制。
Taproot改变了这种工作方式，不再使用单一的全局区块限制，而是根据每个交易的大小设置各自的签名操作限制。这实际上相当于相同的全局限制，但在推理单个交易可以使用的签名操作数量时更为简便。
Taproot在处理签名操作限制方面的这种转变提供了一种推广该方法的途径，这正是Rusty提出的varops限制的概念。这个想法是为每个重新激活的操作码分配一个成本，以考虑到每个操作码可能产生的最坏情况下，即验证时最昂贵的计算成本。通过这种方式，每个操作码都会有自己的“sigops”限制，以限制其在验证中可以消耗的资源量。同时，这种限制也会基于使用这些操作码的交易大小，从而保持对其推理的简便性，同时仍然累计到每个区块的隐含全局限制。
这将解决导致中本聪最初禁用所有这些操作码的拒绝服务风险。
向前迈进
我相信很多人会认为“这是一个太大的改变。”我能理解这种想法，但我认为理解这个项目作为一个提案的一个重要方面是，我们不必全盘接受这个提案。这个提案的价值并不一定在于真的要将所有这些内容全部重新开启，而在于我们将全面审视一系列原始功能，并询问自己我们真正需要从这些功能中得到什么。
这将是与过去三年里为了某些功能而进行的细小改动争论完全相反的举动。它是一个可以让大家聚集在一个屋檐下，全面评估下一步该怎么走的契机。也许我们最终会重新启动所有这些功能，也许我们最终只激活其中的一些功能，因为共识是那就是我们需要的功能，以确保每个人都同意的功能。
不论最终结果如何，这都可以成为关于未来方向的整个讨论中的一个积极变化。我们可以真正地绘制出全面的蓝图，而不是在下一步该走哪条模糊不清的道路上争论不休。
这绝对不一定是我们要走的前进道路，但我认为这是我们决定要走哪条道路的最佳机会。是时候重新以一种积极的方式一起努力了。
声明：
- 本文转载自[bitcoinmagazine]，所有版权归原作者所有[SHINOBI]。若对本次转载有异议，请联系Gate Learn 团队，他们会及时处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。
相关文章
什么是比特币?
比特币最初被设计为拥有一个完备的脚本语言，旨在涵盖并支持用户未来可能想到的任何安全用例。正如中本聪在他消失前所说：
“比特币的本质是一旦版本0.1发布，核心设计将在其生命周期内固定不变。因此，我希望设计一个支持我能想到的每一种可能交易类型的系统。问题在于，每种类型都需要特殊的支持代码和数据字段，无论是否使用，并且每次只覆盖一种特定情况。这将导致特殊情况的爆炸式增长。解决方案是脚本，它泛化了这个问题，以便交易方可以将他们的交易描述为节点网络评估的谓词。” ——中本聪，2010年6月17日。
整个目的是为用户提供足够通用的语言，使他们能够根据需要设计自己的交易类型。换句话说，给用户空间去设计和实验如何编程他们自己的钱。
在他消失之前，中本聪删除了15个操作码，完全禁用了它们，并为脚本引擎堆栈上可以操作的数据片段设置了一个硬性限制（520字节）。这是因为他坦率地说搞砸了，留下了大量复杂脚本可以用来对整个网络进行拒绝服务攻击的方式，创建庞大且验证成本高昂的交易，这些交易会导致节点崩溃。
这些操作码并不是因为中本聪认为其功能危险或者人们不应该用它们来构建东西而被移除的，而是仅仅（至少表面上）因为它们在没有资源限制的情况下使用时，对网络验证成本的最坏情况带来的风险。
自那以来，比特币的每次升级最终都是简化剩余功能，纠正中本聪留下的其他不太严重的缺陷，并扩展我们剩下的那部分脚本的功能。
伟大的脚本恢复计划
在五月初的Austin Bitcoin++会议上，Core Lightning开发者Rusty Russell在会议的首次演讲中提出了一个相当激进的建议。他本质上建议重新启用Satoshi在2010年消失前禁用的大多数操作码（opcodes）。
自2021年Taproot激活以来的这几年里，开发领域实际上有些迷茫。我们都知道，比特币没有足够的可扩展性，无法真正以自我主权的方式服务于全球大量人口，甚至在信任最小化或托管方式下也难以超越非常大型的托管人和服务提供商，无法真正逃脱政府的长臂。
任何对比特币有技术了解的人都明白这一点，这无可争辩。但争论的焦点，也是非常有争议的一点，是如何解决这一不足。自Taproot以来，每个人都在提出非常狭隘的建议，旨在解决特定的用例。
ANYPREVOUT (APO)是一个提案，允许签名在不同交易上可重复使用，只要输入的脚本和金额相同，专门优化了闪电网络及其多方版本。CHECKTEMPLATEVERIFY (CTV)是另一个提案，旨在强制硬币只能通过与预定义交易完全匹配的交易来花费，这使得预签名交易链完全无信任。OP_VAULT旨在为冷存储方案启用“超时期”，这样用户可以在密钥被泄露的情况下，通过将资金发送到更冷的多签设置来“取消”从冷存储的提取。
还有许多其他提案，但我想你明白我的意思。与其尝试全面解决扩展比特币所需的表达性和可编程性，这些年来的每一个提案都旨在提供小幅度的可扩展性提升或改善某个狭隘的功能。这正是这些对话没有进展的原因。没有人对其他提案感到满意，因为它不符合他们希望构建的用例。
没有哪个提案足够全面，让提案以外的人认为这是下一步的合理举措。
这就是伟大脚本恢复计划的逻辑。通过推动和分析Satoshi最初设计的脚本的全面恢复，我们可以实际探索所需功能的整个空间，而不是在各种小功能扩展上争吵不休。
操作码（Opcodes）
- OP_CAT：从栈中取出两个数据并将它们合并为一个。
- OP_SUBSTR：接收一个长度参数（以字节为单位），从栈中取出一段数据，移除指定长度的字节并将剩余数据放回栈中。
- OP_LEFT 和 OP_RIGHT：接收一个长度参数，分别从栈中数据的左侧或右侧移除指定长度的字节。
- OP_INVERT、OP_AND、OP_OR、OP_XOR、OP_UPSHIFT 和 OP_DOWNSHIFT：从栈中取出一个数据元素并对其进行相应的位运算操作。
- OP_2MUL 和 OP_2DIV、OP_MUL、OP_DIV、OP_MOD：用于乘法、除法和取模（返回除法余数）的数学操作。
- 以上是拟恢复的操作码。此外，Rusty 提议了三个更多的操作码，以简化不同操作码的组合。
- OP_CTV (或 TXHASH/等效操作码)：用于细化强制要求交易的某些部分必须完全符合预先定义的内容。
- CSFS：允许对任意数据验证签名，而不仅仅是整个交易。这使得可以要求脚本或其使用的数据的某些部分被签名后才能执行。
- OP_TWEAKVERIFY：验证涉及公钥的 Schnorr 操作，例如从聚合公钥中添加或减去单个公钥。这可以确保在某方单方面离开共享 UTXO 的情况下，其他人的资金被发送到一个不需要离开方签名即可共同支配的聚合公钥。
我们为什么要这样做
Layer 2 解决方案本质上是比特币基础层的延伸，由于基础层功能的限制，Layer 2 的功能也受到限制。例如，闪电网络在实现之前需要三个独立的软分叉：CHECKLOCKTIMEVERIFY (CLTV)、CHECKSEQUENCEVERIFY (CSV) 和 Segregated Witness (隔离见证)。
在没有更灵活的基础层的情况下，无法构建更灵活的 Layer 2 解决方案。唯一的捷径就是依赖可信的第三方，但我们希望在大规模使用比特币时尽可能消除第三方的参与。
目前，我们需要在基础层上实现一些功能，才能在一个单一的UTXO中安全地容纳两人以上，并且能以信任最小化的方式执行。这需要比特币脚本有更高的灵活性。基本上，我们需要covenants（契约），需要脚本能够执行更细粒度的交易控制，确保用户在单独退出 UTXO 时不会影响其他用户的资金安全。
高层次上，我们需要以下功能：
1. 内省（Introspection）：我们需要能够在栈上检查花费交易的具体细节，比如“这笔钱进入某个输出的某个公钥”。这允许我使用自己的特定 Taproot 分支单独取回我的资金，同时确保我不能拿走其他人的钱。脚本执行将通过共识机制强制执行，确保如果我退出，其他人的资金将被发送到由其他用户公钥组成的地址。
2. 正向数据传递（Forward Data Carrying）：假设我们进一步扩展一个包含多人的闪电通道，构建一个包含大量人的单一 UTXO，任何人都可以自由进出。我们需要某种方式来跟踪每个人拥有多少钱，通常这通过 merkle 树及其根来实现。这意味着当有人离开时，我们必须确保谁有权得到什么的“记录”是其他人资金变更 UTXO 的一部分。这本质上是 introspection 的一种特定应用。
3. 公钥修改（Public Key Modification）：我们需要能够确保对聚合公钥的修改可以在栈上验证。UTXO 共享方案的目标是有一个聚合密钥，允许每个参与者共同且更高效地移动资金。每当有人单方面退出共享 UTXO 时，我们需要从聚合密钥中移除他们的个人密钥。在不预先计算所有可能组合的情况下，唯一的选择是能够验证从聚合密钥中减去一个密钥后，剩余的密钥仍然构成一个有效的聚合密钥。
如何确保VAROPS的安全性
正如上文所述，这些操作码（opcodes）被禁用的原因是为了消除导致网络节点崩溃的拒绝服务攻击风险。解决这个问题的方法是限制这些操作码可以使用的资源量。
我们在签名验证方面已经有了这样的解决方案，这是验证比特币脚本最耗费资源的部分。这个解决方案称为签名操作预算（sigops budget）。每次使用签名检查操作码都会消耗每个区块允许的签名操作数量的‘预算’。这为用户在验证单个区块时可以施加的成本设置了一个硬性限制。
Taproot改变了这种工作方式，不再使用单一的全局区块限制，而是根据每个交易的大小设置各自的签名操作限制。这实际上相当于相同的全局限制，但在推理单个交易可以使用的签名操作数量时更为简便。
Taproot在处理签名操作限制方面的这种转变提供了一种推广该方法的途径，这正是Rusty提出的varops限制的概念。这个想法是为每个重新激活的操作码分配一个成本，以考虑到每个操作码可能产生的最坏情况下，即验证时最昂贵的计算成本。通过这种方式，每个操作码都会有自己的“sigops”限制，以限制其在验证中可以消耗的资源量。同时，这种限制也会基于使用这些操作码的交易大小，从而保持对其推理的简便性，同时仍然累计到每个区块的隐含全局限制。
这将解决导致中本聪最初禁用所有这些操作码的拒绝服务风险。
向前迈进
我相信很多人会认为“这是一个太大的改变。”我能理解这种想法，但我认为理解这个项目作为一个提案的一个重要方面是，我们不必全盘接受这个提案。这个提案的价值并不一定在于真的要将所有这些内容全部重新开启，而在于我们将全面审视一系列原始功能，并询问自己我们真正需要从这些功能中得到什么。
这将是与过去三年里为了某些功能而进行的细小改动争论完全相反的举动。它是一个可以让大家聚集在一个屋檐下，全面评估下一步该怎么走的契机。也许我们最终会重新启动所有这些功能，也许我们最终只激活其中的一些功能，因为共识是那就是我们需要的功能，以确保每个人都同意的功能。
不论最终结果如何，这都可以成为关于未来方向的整个讨论中的一个积极变化。我们可以真正地绘制出全面的蓝图，而不是在下一步该走哪条模糊不清的道路上争论不休。
这绝对不一定是我们要走的前进道路，但我认为这是我们决定要走哪条道路的最佳机会。是时候重新以一种积极的方式一起努力了。
声明：
- 本文转载自[bitcoinmagazine]，所有版权归原作者所有[SHINOBI]。若对本次转载有异议，请联系Gate Learn 团队，他们会及时处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。
相关文章
什么是比特币?