您今天所知道的基于比特币构建的一切都是因为比特币脚本支持的原语。我所说的原语是什么意思？编程语言的基本组件，可用于构建实际的应用程序来执行任务。没有一种编程语言是专门为单个应用程序（即构建一个程序）而设计的。它们旨在支持基本原语，例如操纵数据的数学运算，或创建基本数据结构以以某种方式存储数据，或者在操纵数据时迭代数据的操作。
基本原语的设计方式使开发人员可以决定如何使用它们来创建实际的应用程序或程序。语言的核心设计不一定关注人们将用它做什么，只是语言的原语不能以以下方式组合：1）无法完成开发人员试图完成的任务他们了解原因，或者 2）以对最终用户不利的方式完成开发人员试图做的事情。
没有人在设计一种编程语言时从一开始就认为“哦，我们希望让开发人员能够执行 A、B 和 C，但完全阻止他们执行 X、Y 和 Z。” （对于这里更多技术读者来说，我在这里指的是开发人员正在构建的目标，而不是诸如基元如何组合之类的低级技术细节）。
比特币脚本与其他编程语言没有什么不同，只是在一个方面，即某种原语组合对最终用户有害。比特币具有一般计算机应用程序所没有的两个属性，区块链及其上执行的内容必须由运行完整节点的所有用户完全验证，并且系统的整个进程受到必须保持平衡的财务激励的保障。除了这些额外的考虑因素之外，脚本就像任何其他编程语言一样，它应该包含任何原语，允许开发人员为用户构建有用的东西，而不能以对用户不利的方式进行组合。
所有围绕软分叉添加契约（新原语）的讨论都已经转向（至少在公共领域）对它们的用途提出了荒谬的要求。这既不是一件可能做的事情，也不是需要关注的重要事情。使用脚本构建的内容与需要分析的风险无关，构建的内容如何与基础层交互是主要风险。它将带来哪些成本？如何限制这些成本？ （这是很大一部分 剧本大还原 Rusty 的提案）。基础层的这些成本如何影响激励措施？这是很大一部分 MEV 风险。
可以分析这些问题，而不必过分关注可以用原语构建的每种可能的事物。原语在验证成本和复杂性方面可能会受到基础层的限制。最重要的是，就激励而言，新原语所实现的功能可以与今天已经可以构建的东西进行比较。如果新原语只是改善了已经构建的系统最终用户的信任模型，而这些系统对系统激励有影响，而不会实质性地恶化它们对这些激励的影响，那么就不会引入真正的新风险。
这些对话需要开始关注真正重要的事情，即新功能与最终用户伤害。他们几乎完全脱轨了，再次是在公共领域，而不是技术圈，争论是否应该允许最终用户做某事。重要的不是谈话。重要的是向最终用户提供有价值的功能而不产生有害后果。
人们需要关注原始人，而不是他们在远处听到的大雁。
这篇文章是一篇 拿。所表达的观点完全是作者的观点，并不一定反映 BTC Inc 或比特币杂志的观点。
