本文将探讨 sCrypt 智能合约背后的概念，以及使用 sCrypt 编程的一些最佳实践和安全检查清单。
作者：Certik
封面：Photo by Conny Schneider on Unsplash
sCrypt 是一种基于 TypeScript 的嵌入式领域特定语言（eDSL），专为在比特币链上编写智能合约而设计。sCrypt 智能合约使用比特币支持的操作码，可以编译成 Bitcoin Script。由此生成的类似汇编的脚本可用作交易中的锁定脚本。
本文将探讨 sCrypt 智能合约背后的概念，以及使用 sCrypt 编程的一些最佳实践和安全检查清单。
使用 sCrypt 编写编写智能合约：一个简单示例
比特币上的智能合约使用 UTXO 模型，每笔比特币交易由输入和输出组成，每笔比特币交易由输入和输出组成：输出包含：
- 比特币的数量
- 字节码（称为 locking script，“锁定脚本”）
输入包含：
- 对上一笔笔交易输出的引用
- 字节码（unlocking script，“解锁脚本”）
未花费交易输出（UTXO）是指在任何交易中尚未被消耗消耗的输出。低级字节码/操作码，称为 Bitcoin Script[1]，由比特币虚拟机（BVM）[2]解释执行。
比特币支持的操作码可以编译为 Bitcoin Script。生成的类似汇编的脚本用作交易中的锁定脚本。
如上图展示的两个交易，每个交易都有一个输入（绿色）和一个输出（红色）。右侧的交易使用了左侧交易的输出。锁定脚本可以视为一个布尔函数 f(x)，它定义了花费 UTXO 中比特币的条件，起到 “锁” 的作用（因此称为 “锁定”）。解锁脚本则提供了使 f(x) 结果为 true 的函数参数，充当 “钥匙”（也称为见证）来解锁它。只有当输入中的 “钥匙” 与先前输出的 “锁” 匹配时，才能花费该输出中包含的比特币。
在标准的比特币支付中，锁定脚本是 “Pay To Pubkey Hash”（P2PKH）。它用于验证付款人是否拥有与地址对应的正确私钥，从而使他们能够在解锁脚本中生成有效的签名。sCrypt 语言使得锁定脚本可以指定比简单的 P2PKH 更加复杂的花费条件，即 P2TR/P2SH 交易中的比特币智能合约。
sCrypt 的智能合约在概念上类似于面向对象编程中的类。每个包都为特定类型的合约（例如 P2PKH 或多签名）提供了模板，可以实例化为具体的可执行合约对象。
部署和调用 sCrypt 智能合约
sCrypt 使用支付到见证脚本哈希（Pay-to-Witness-Script-Hash，P2WSH）来部署合约。部署过程包括将智能合约代码编译成脚本，对该脚本进行哈希处理，然后将哈希值放入一个 P2WSH 交易 (Tx0)，并将其广播到网络。
当有人要调用已部署的合约时，他们会将完整的合约脚本和被调用方法的输入作为见证数据嵌入到花费 Tx0 的后续事务 (Tx1) 中。
已知的 sCrypt 局限性
sCrypt 可以在任何支持 Bitcoin Script 的区块链上运行，包括比特币分叉链和基于比特币的链，如 Litecoin 和 Dogecoin。
比特币禁用了许多脚本操作码，如 OP_CAT 和 OP_MUL，这极大地限制了 sCrypt 能表述的智能合约类型。比特币社区正在积极讨论重新启用这些操作码并引入新的操作码。如果变更的提议得到采纳，sCrypt 在比特币上的功能将比现在更强大。
与此同时，有些区块链具备完整的脚本操作码，例如比特币 SV 和 MVC。如今，sCrypt 在这些链上已达到满负荷运行。
回溯至创世问题（Back-to-Genesis）
使用 sCrypt 的智能合约实现同质化代币（FT）和非同质化代币（NFT）时，会引发回溯至创世（Back-to-Genesis，B2G）问题，这是一个极大的安全挑战。该问题涉及在基于 UTXO 的区块链中追踪代币的创建交易。在比特币等区块链上，通过 sCrypt 创建的代币以 UTXO 形式存在，并可能被频繁转移。B2G 问题的关键在于，当试图追踪或验证代币的完整历史记录时，需要找到其创世交易，以确认代币的来源和真实性。
从各种角度上来说，这一点很重要。包括：
- 来源和真实性：了解代币的完整历史可以让用户验证其真实性和来源。用户可能希望确保代币有一个合法且可追溯的来源。
- 智能合约逻辑：智能合约或去中心化应用可能会依赖于代币的历史。了解代币的来源对于某些智能合约功能至关重要。
下图展示了伪造基于 sCrypt 的 FT 和 NFT 的两种方法。每个框代表一个交易，左侧是输入，右侧是输出。箭头指向表示从一个交易到另一个交易的流转过程。具有相同输出颜色的交易使用相同的合约代码。
Back-to-Genesis 问题可能会引发代币协议中的两个问题：
- 重放攻击（Replay Attack）：攻击者可能会重新发行相同的代币。
- 中间人攻击（Man-in-the-Middle Attack）：攻击者可以从一个不相关的 UTXO 开始，并复制一个代币交易链。他们可以复制交易的输出（如第 1 行所示），并将其逐字粘贴到另一个交易中（如第 3 行所示）。这种情况之所以可能发生，是因为锁定脚本仅在解锁时进行评估，而不是在部署时进行评估。从那时起，交易就可以用来创建一个并行的虚假代币链。
解决方案
在这些场景中，交易因为满足 Layer-1 的验证而被矿工接受。被红色圆圈标记的最后几笔交易看起来完全相同。验证代币交易合法性的唯一方法是追溯到其发行交易（即创世交易）。
为了解决重放攻击，我们建议实施一个全局唯一的 ID，“GenesisID”，它代表发行交易的交易 ID（txid）。当发行 UTXO 被消费时，该 ID 会被复制，并作为代币 ID 保留在所有后续代币传输 UTXO 中。
为了减少中间人攻击，我们建议开发者在当前交易之前回溯两步，验证父交易及其前一交易。
以下是一个简单的示例，用于说明回溯验证以及提前两步验证的重要性：
当伪造的 UTXO（UTXO1）被花费到另一个代币 UTXO（UTXO2）时，由于代币合约并未被激活（UTXO 的锁定脚本仅在解锁时执行），所以它会通过矿工验证。然而，在我们建议的实现中，尝试将 UTXO2 存入 UTXO3 需要同时验证 UTXO1 和 UTXO2。这样，中间人攻击就失败了，因 UTXO1 不包含与 UTXO2 和 UTXO3 相同的解锁合约，交易将因此被拒绝。
sCrypt 安全提示与检查清单
以下是 CertiK 在完成对一个基于 sCrypt 的 FT/NFT 项目审计后总结的安全提示和检查清单：
1. 验证代币的回溯是否准确，当前 UTXO 的锁定脚本代码段是否与前一个 UTXO 的匹配
sCrypt 团队提供了一个示例，可以帮助开发者设计回溯验证流程：
2. 确保协议不会受到伪造创世 ID 的攻击
这可以通过在回溯过程中验证创世 ID 来实现，如下例所示：
检查应确认当前的 genesisTxid 是否与创世交易的 ID 或前一个交易的 ID 匹配。
3. 确认 UTXO 输入证明真实合法，而非伪造
必须验证以下参数：
- tokenTxHeader
- prevTokenInputIndex
- tokenTxInputProof
- prevTokenTxProof
我们建议开发者在验证 UTXO 输入证明时遵循此流程图。
4. 确保代币解锁过程已得到适当授权
代币可以由代币所有者直接解锁，也可以通过代币锁定合约进行解锁。代币所有者必须通过有效的签名验证其所有权，以解锁代币。如果通过智能合约解锁代币，必须遵守合约中规定的任何条款或限制。请注意，禁止解锁被烧毁的代币。
5. 确保代币转移 UTXO 中的代币数量保持一致，以防止双花攻击
已解锁的代币可以转移到一个或多个接收钱包。重要的是确保作为输入的代币总量等于作为输出的代币总量。换句话说，正在转移的代币必须与可用的代币相匹配，以保持平衡。通过强制执行这一要求，合约能够防止双花攻击的可能性。
6. 验证是否选择了适当的 SigHash 类型，明确指定交易的哪些部分被签名
SigHash[3]标志决定了加密签名涵盖比特币交易中哪些部分。默认情况下，使用 SIGHASH_ALL 标志，确保签名涵盖所有输入和输出。然而，选择不同的 SigHash 类型时需要谨慎。例如，SIGHASH_NONE 标志不会签署任何输出，这就可能引入安全漏洞。应用签名后可更改的输出可能会导致欺诈或操纵。
7. 验证合约完整性
在比特币的 UTXO 模型中，智能合约通常是一次性且无状态的。这是因为包含合约的 UTXO 一旦用完就会被销毁，且不会在区块链上留下痕迹。尽管这种设计简单高效，但也存在安全风险，因为合约可能会被篡改。为此，需要验证合约脚本代码的哈希值，这包括将脚本的哈希值嵌入到脚本数据中。在交易过程中，将嵌入的哈希值与脚本的实际哈希值进行比较，即可确认脚本的完整性。
为了应对挑战，一种方法是验证合约脚本代码的哈希值。这种方法需要将脚本的哈希值作为数据的一部分保存在脚本内部。在执行涉及智能合约的交易时，可以将脚本代码的哈希值与存储的值进行比对。如果哈希值匹配，则确认合约脚本未发生变化，未被篡改。
8. 验证交易完整性
sCrypt 提供了一个强大的库叫做 Tx，除了锁定脚本和解锁脚本外，还能检查包含合约本身的整个交易。sCrypt 通过这一全面的交易检查功能，使合约能够验证输入数据。
主要验证步骤之一是将解锁脚本的输入与从交易预映像中提取的数据进行匹配。此外，还需要验证 txPreimage 是否为当前交易的预映像。
9. 验证数据完整性
在输出的锁定脚本中，智能合约被分为两个部分：代码和状态。合约的状态存储在锁定脚本的数据部分。在协议本身管理数据部分的场景中，必须特别注意数据字段的处理。至关重要的是，必须要验证存储在锁定脚本数据部分的数据字段是否在正确的位置索引上进行访问和存储。
总结
综上所述，sCrypt 作为一种比特币智能合约开发语言，为开发者提供了丰富的可能性。从回溯验证到防伪造代币和完整性检查，本文总结的安全提示与最佳实践建议，来源于业内领先的审计机构与开发者的实际经验。希望这些内容能够为开发者提供有价值的参考，助力构建更加安全、高效的 Web3.0 应用。
[1] Bitcoin Script: https://wiki.bitcoinsv.io/index.php/Script [2] 比特币虚拟机（BVM）: https://xiaohuiliu.medium.com/introduction-to-bitcoin-smart-contracts-9c0ea37dc757 [3] SigHash: https://wiki.bitcoinsv.io/index.php/SIGHASH_flags免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
