Web3.0安全开发实践：9个sCrypt智能合约开发的最佳实践

sCrypt是一种基于TypeScript的嵌入式领域特定语言（eDSL），专为在比特币链上编写智能合约而设计。sCrypt智能合约使用比特币支持的操作码，可以编译成Bitcoin Script。由此生成的类似汇编的脚本可用作交易中的锁定脚本。

本文将探讨sCrypt智能合约背后的概念，以及使用sCrypt编程的一些最佳实践和安全检查清单。

使用sCrypt编写编写智能合约：一个简单示例

比特币上的智能合约使用UTXO模型，每笔比特币交易由输入和输出组成，每笔比特币交易由输入和输出组成：

输出包含：

比特币的数量
字节码（称为locking script，“锁定脚本”）

输入包含：

对上一笔笔交易输出的引用
字节码（unlocking script，“解锁脚本”）

未花费交易输出（UTXO）是指在任何交易中尚未被消耗消耗的输出。低级字节码/操作码，称为Bitcoin Script，由比特币虚拟机（BVM）解释执行。

比特币支持的操作码可以编译为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标志决定了加密签名涵盖比特币交易中哪些部分。默认情况下，使用SIGHASH_ALL标志，确保签名涵盖所有输入和输出。然而，选择不同的SigHash类型时需要谨慎。例如，SIGHASH_NONE标志不会签署任何输出，这就可能引入安全漏洞。应用签名后可更改的输出可能会导致欺诈或操纵。

7. 验证合约完整性

在比特币的UTXO模型中，智能合约通常是一次性且无状态的。这是因为包含合约的UTXO一旦用完就会被销毁，且不会在区块链上留下痕迹。尽管这种设计简单高效，但也存在安全风险，因为合约可能会被篡改。为此，需要验证合约脚本代码的哈希值，这包括将脚本的哈希值嵌入到脚本数据中。在交易过程中，将嵌入的哈希值与脚本的实际哈希值进行比较，即可确认脚本的完整性。

为了应对挑战，一种方法是验证合约脚本代码的哈希值。这种方法需要将脚本的哈希值作为数据的一部分保存在脚本内部。在执行涉及智能合约的交易时，可以将脚本代码的哈希值与存储的值进行比对。如果哈希值匹配，则确认合约脚本未发生变化，未被篡改。