以太坊合约地址查不到数据,以太坊合约地址与钱包地址

  

  CREATE2是以太坊于2019年2月在康斯坦丁包的硬分叉中推出的新操作码。CREATE2操作码可用于在部署智能合约之前提前计算智能合约的部署地址。在本教程中,我们将学习使用CRAETE2计算智能合约部署地址的基本方法,了解CREATE2操作码可以多次在同一地址部署合约,并使用CREATE2提出交易平台开发中一个常见问题的解决方案——为用户生成以太坊钱包地址。   

  

  正如EIP所解释的,CREATE2操作码主要用于状态通道,但我们可以用它来解决交易所或平台开发中经常遇到的另一个问题。   

  

  用熟悉的语言学习以太坊DApp开发:Java | PHP | Python |。NET/c# | Golang | node . js | Flutter/dart   

  

  1.问题:交易平台如何为用户创建钱包地址?交易所的每个用户都需要提供一个以太坊地址,以便接收用户填写的令牌。我们称这些地址为钱包。当用户为他们的钱包充值时,我们需要将重新输入的令牌发送到一个中央钱包(热钱包)。   

  

  我们来分析一下在没有CREATE2操作码的情况下,针对上述问题的解决方案,以及这些解决方案被放弃的原因。如果你只对最后的结果感兴趣,可以直接查看上一节的内容。   

  

  2.方案一:生成并使用以太坊外部地址作为用户平台钱包最简单的方案是为新用户生成以太坊(EOA)外部地址作为用户平台钱包。要将用户钱包中的令牌收集到中心热钱包中,我们需要在后台用钱包的私钥签署令牌契约的transfer()调用。   

  

  该方案的优点是:   

  

  将简单令牌从用户钱包转移到热钱包的价格与调用transfer()的价格相同。但是,我们决定放弃这个方案,因为它有一个重大缺点:你需要把私钥保存在某个地方,这不仅是私钥可能丢失的问题,而且你还需要仔细管理对这些私钥的访问。如果其中一个私钥被盗,该用户的令牌将不会被收集到中央热钱包中。   

  

  2.选项2:部署并使用合同地址作为用户的平台钱包地址。第二个选项是为每个用户创建单独的智能合约,并将智能合约的部署地址用作用户的平台钱包。这样避免了在服务器上保存用户钱包的私钥,交易所或平台可以调用这个智能合约将用户令牌收集到中央热钱包中。   

  

  但是我们也没有选择这个方案,因为用户在部署合约之前是没有办法显示自己的钱包地址的(其实是可以的,但是会很复杂,还会有一些其他的问题)。在交易所或平台上,一个用户应该能够创建任意数量的账户,这意味着我们需要在合约部署上浪费金钱,并且我们无法确认用户是否使用了这个成本高昂的账户。   

  

  3.方案2改进A:使用CREATE2操作码预先计算契约部署地址。我们决定继续研究智能合约地址作为用户钱包账号。为了解决上述问题,我们决定使用以太坊的CREATE2操作码。这样我们就不用部署合同了。   

  

  2 CREATE2允许预先计算要部署的智能合约的地址。计算公式如下:   

  

  Kecak 256 (0xff地址Salt Kecak 256(init _ code))12:其中:   

  

  Address:调用CREATE2的智能协定地址salt: random value init_code:要部署的协定的字节码。因此,可以保证提供给用户的地址包含预期的字节码。此外,这种智能合同可以仅在需要时部署。比如在决定使用用户钱包的时候。   

  

  此外,交易所或平台可以在任何时候计算智能合约的地址,而无需保存该地址:   

  

  地址:公式中的地址是一个常量,是我们的工厂钱包地址salt: Hash init_code using user_id:对于要部署的同一个契约是一个常量。4.方案二改进B:用自毁()退还合同部署费。之前的解决方案还有一个问题:平台需要支付部署智能合约的服务费,但我们可以找到避免这种情况的方法。要做到这一点,可以先调用transfer()方法,再调用selfdestruct()方法,那么部署契约的手续费就可以退还了。   

  

  与常见的误解相反,您实际上可以在同一个地址使用CREATE2操作码 多次部署智能合约,因为CREATE2将检查目标地址的nonce是否为0。在本例中,selfdestruct()方法将重置地址的nonce值。因此,如果您使用相同的参数再次调用CREATE2操作码,则nonce检查可以通过。   

  

  注意,这个方案和使用以太坊地址的方案类似,但是不需要保存用户钱包的私钥。将用户钱包的资金归集到中心热钱包的成本基本等于调用transfer()方法的成本,因为我们不再需要为智能合约的部署付费。   

  

  5.方案二优化版:用户平台钱包按需部署,无需额外部署成本。首先,准备以下实现代码:   

  

  通过user_id获取随机值salt的函数用合适的salt值调用CREATE2操作码的smart contract,例如wallet fabric的wallet contract的字节码用下面的构造函数:constructor(){ address hot wallet=0x…;地址tok   

en = 0x …; token.transfer (hotWallet, token.balanceOf (address (this))); selfdestruct (address (0));}对于每个新用户,我们通过计算展示其平台钱包地址:

  

keccak256 (0xff ++ fabric_addr ++ hash (user_id) ++ keccak256 (wallet_init_code)) <12:>当用户将代币转入其在平台上的钱包地址时,我们的后台系统会监控到 Transfer事件,其 _to参数表示转账目标地址。这时在实际部署钱包合约 前,已经可以增加用户在交易所的余额了。

  

当用户钱包中累积了足够的代币,我们就可以将其一次转入平台热钱包。 为此,后台调用工厂合约的方法:

  

function deployWallet (uint256 salt) { bytes memory walletBytecode = …; // invoke CREATE2 with wallet bytecode and salt}因此钱包智能合约的构造函数被调用,这会将所有代币转入平台热钱包然后 自动销毁。

  

可以在这里下载完整的代码. 注意,这不是我们的生产代码,因为我们还要优化钱包合约的字节码。

  

原文链接:http://blog.hubwiz.com/2020/06/29/contract-address-before-deploy/

相关文章