声明
本文所表达的观点和意见仅代表作者本人，并不代表crypto.news编辑部的观点和意见。
智能合约平台的费用资产
每个智能合约平台都有其内置的费用资产。例如，以太坊（ETH）使用ETH，Solana（SOL）使用SOL，但比特币（BTC）的情况则较为复杂。如果你想要构建富有表现力的应用，通常需要采用第二层网络的经济模型。例如，在Stacks上，你需要使用STX支付费用。在EVM风格的比特币层上，虽然可能会告诉你BTC是燃气代币，但它通常是一个L2本地的表示，采用EVM类似的约定（包括18位小数），而你仍然是在该L2环境中操作。
与此同时，比特币本身已经拥有一个清晰的费用市场，用户以sat/vB的形式竞标区块空间，矿工优先选择费用率较高的交易。
OpNet的解决方案
考虑到这一点，如果智能合约的交互可以像普通比特币交易一样发起并支付（以BTC计费，无需额外的燃气代币或分叉），而智能合约的执行在其他地方进行，并且可以可靠地与比特币关联，这将会怎样呢？OpNet正致力于提供这样的解决方案。
比特币的费用市场
比特币的费用市场在一件事上表现出色：定价区块空间。用户在sat/vB中竞争，矿工选择费用率最高的交易，网络保持简单且具有对抗性。比特币并不提供一个通用的执行环境，链上无法测量和收费任意计算。比特币脚本故意是无状态的，并且不具备图灵完备性，特别缺乏循环或跳转，因此每个节点都可以预测性地验证脚本，而不会打开无限计算的可能性。
独立的执行层
这就是为什么大多数比特币智能合约方案最终将执行放在一个可以计量计算并运行自己费用市场的独立系统上。一旦你有了那个独立的执行层，通常会伴随一个独立的费用资产（例如，Stacks以STX收取费用）。
这种情况并不理想，一个可以在比特币的本地费用市场内保持支付，同时将执行转移到其他地方的系统将更为可取。一旦你接受比特币脚本是故意有限的（无状态且不设计用于无限计算），你就会开始思考如何让比特币结算结果和支付。
执行与结算
实际上，执行可以在一个专门的虚拟机中进行，该虚拟机旨在以确定性方式运行智能合约逻辑，而比特币仍然是基础层，负责通过其现有的费用市场对交互进行时间戳、排序和定价。在OpNet的设计中，合约逻辑由一个面向Wasm的虚拟机（OP-VM）评估，而更广泛的节点堆栈则明确构建用于管理和执行智能合约，利用比特币现有的交易和UTXO机制。
关键是，这并不需要一个新的费用资产。比特币不需要计量计算来作为燃气货币。它需要成为最终的结算层，所有交易最终都支付到这里并与之锚定。
交互模型
我们的交互模型遵循“模拟-再支出”的流程，而不是传统的智能合约执行模式，最终的执行步骤作为实际的比特币交易进行。首先，你的应用以模拟模式调用合约方法。该请求通过提供者发送到一个OPNet节点，该节点在其虚拟机中执行合约，并返回一个CallResult（包括燃气/费用估算），而不向比特币广播任何信息。如果调用是状态改变的，你将该CallResult作为执行发送。在这一点上，库构建一个比特币交易，进行签名，并将其广播到比特币网络。
费用计量与用户体验
有两个要点值得记住：与此同时，OpNet自己的计算计量仍然存在。但它以聪（satoshis）计价（估算的SATS Gas，退款以SATS等），因此单位从未漂移到一个独立的代币经济中。用户不再需要采用第二个费用经济体系来与应用交互。在比特币上，费用已经是区块空间的拍卖，按字节定价并支付给矿工。当合约调用仅仅是比特币交易时，你又回到了熟悉的领域（以sat/vB计费，内存池波动和矿工激励），无需学习一个独立的燃气代币市场。
此外，工具也倾向于标准的比特币工作流程，例如UTXO处理、提供者连接，甚至离线/冷签名。合约在Wasm运行时中运行，并使用AssemblyScript编写，旨在实现类似Solidity的表现力，而不假装比特币脚本突然变成了一个虚拟机。
结论
声称BTC无法作为燃气的观点通常基于一个假设，即基础层必须计量计算以定价。比特币并不计量计算；它计量区块空间并结算价值。解决方案是让虚拟机以确定性方式处理执行，然后通过标准比特币交易路由每个状态改变的交互，费用以熟悉的术语（如sat/vB）表示，并以聪为上限。在我们的案例中，这在客户端级别通过参数如feeRate和maximumAllowedSatToSpend实现。
因此，也许BTC作为燃气的想法确实是可行的。费用在端到端过程中保持BTC本地，而合约运行时则保持基于WebAssembly（AssemblyScript → Wasm），这使得逻辑具有表现力而不改变费用货币。
弗雷德里克·福斯科（Frederic Fosco）
