Wisps 合约：还在说 Create？一起看看 Create2 有何不一样？-价值区块链

在ETH Cape Town 黑客马拉松期间，我们使用功能强大的，新的以太坊操作码 —— CREATE2，制作了一个合约钱包的快速概念证明。较之 CREATE 操作码，CTEATE2 操作码可以在使用以太坊合约来生成新合约时更好地控制新合约的地址，当你想要反事实地（counter-factually）部署并使用一个自定义权限的合约时，这是非常有用的。

Wisp 合约的目标是演示一种生成稳定合约钱包地址的技术，该地址可与其他用户共享，也可以实现代币和以太币转账功能，同时还可以在不保留任何链上合约钱包代码的情况下控制链上资产（例如 ENS 域名）。

Wisp 地址的优点包括：首先，所有发给这种 Wisp 地址的交易都只需要确定的 21, 000 gas，但是更重要的是，这意味着可以访问代币、资金以及其他链上资产的合约钱包不能被攻击，因为它的代码实际上不在链上。

如果合约钱包中出现错误，可于再次使用前在客户端进行更新，此期间所有加密资产都是安全的。

使用静态引导程序_initcode 可以_获取 CREATE2 runtime 合约字节码从而生成可复用的合约地址。

initcode 是什么？

在深入了解这种技术之前，先得理解以太坊合约的部署过程。

合约的部署过程使用了一段被叫做initcode 的代码，它只是一个普通的以太坊程序，正常执行将返回部署合约实际所用的合约字节码。虽然有点抽象，但是它可以支撑功能非常强大的部署系统。

你可以想象一下，JavaScript 中「Hello Word」的 initcode 可能就是这样：

这个程序运行时将返回一个「Hello World」程序。这样做可以实现额外的部署时配置，例如：

需要注意的非常重要的一点是：被部署的不是initcode，而是 initcode 的运行结果。

CREATE vs CREATE2

尽管大多数以太坊开发者都使用了CREATE 操作码（来部署链上合约），但是他们可能并没有意识到这件事。Solidity 所生成的字节码实际上是 initcode，它使用 CREATE 来执行构造函数中的对应操作，随后返回合约除构造函数外的其他部分。实际部署上链的代码不包含构造函数代码。

为确定部署上链的合约地址，CREATE使用的标准参数包括：

1.发送账户（它本身可能也是一个合约）2. 发送账户的当前交易序号（也可以是一个合约当前的nonce）

因此，任意两个不同的发送者将生成不同的合约地址，而来自同一个账户的任意两笔不同交易也将生成不同的合约地址。

为确定部署上链的合约地址，新的CREATE2使用：

1.发送账户（同样，它本身可能也是一个合约）2.合约initcode（执行产生合约字节码）3. 由开发人员设定的自定义数（salt）

因此，CREATE2 与 CREATE 一样，不同的发送者将生成不同的合约地址。而 initcode 相同但是自定义数不同时将生成不同的合约地址；而 initcode 不同时（通常意味着不同合约），也将生成不同的合约地址。

CREATE2 的另一个值得注意的（有用的）是，由于其对计算合约地址的参数多了一点控制，如果一个合约自毁了，那么新合约未来可以再次部署到这个地址上。但是，如果已经有非自毁合约部署到这个地址上了，那么CREATE2 不能在这个地址上再次部署一个合约。

综合一下

由于控制发送者以及自定义数很容易，因此实现Wisp 合约目标唯一要做的事情就是绕过 CREATE2 的第二个参数；最终允许两个不同的合约在不同的时期被部署在同一个地址上。

但是，initcode 只是一个用于确定所部署合约的程序。这一特点可以用各种有趣的方法加以利用。

每个Wisp 合约的入口都是一个启用和管理所有 CREATE2 调用的跳板合约（SpringboardContract），因此跳板合约将一直是发送者。至于 salt，因为使用 msg.sender的哈希值作为自定义数，因此同一个账户的任意两个调用将始终指向同一个Wisp 合约。

剩下的是一个普通的（静态）引导程序initcode。initcode 要在新合约中运行，但是此时新合约还未创建；这意味着 msg.sender实际上是跳板合约。因此，跳板合约会将所需的合约字节码保存在自己的存储空间中，并提供一个名为getPendingBytecode()的公共方法，引导程序的（伪）代码可以简单地表示成如下形式：