すべてはBitClaveで発生した問題から始まりました：ICOの準備中に、一定量のETH暗号通貨（エーテル）がスマートコントラクトのアドレスに送信されました。スマートコントラクトは以前にイーサリアム テストネットワークに沈められていました。 メインネットワーク上で、プライベートキーやこのネットワークの単一のスマートコントラクトに属さないアドレスに送金されました。 最初は、資金を返還する機会がなくても、単に2000ドルを捨てたように思えました。
私の同僚がアドレス0x9c86825280b1d6c7dB043D4CC86E1549990149f9への秘密鍵を私に尋ねたとき、物語は始まりました。 私は彼にアドレス0x231A3925A014EF0a11a0DC5c33bF7cdB3bd9919fに秘密鍵を送信し、そこから最初のアドレスでスマートコントラクトがダウンロードされました。 私たちは問題を議論し、送金を返す方法はないという結論に達しました
Ethereumネットワークにアップロードされた各スマートコントラクトには一意のアドレスがあり、一見ランダムに見えますが、ネットワークにアップロードされたときにアドレスがどのように生成されるかを正確に見つけました： ethereum.stackexchange.com/a/761/3032 。 簡単に言えば、ダウンロードアドレスは、トランザクションの送信者のハッシュとナンス値（このアドレスからの発信トランザクションの数に等しい）です。
deployed_address = sha3(rlp.encode([sender, nonce]))
これにより、同じウォレット（ テストネットワークで使用したもの）を使用して、新しいスマートコントラクトをメインネットワークにアップロードするようになりました。 単純なウォレットのスマートコントラクトを開発しました。これにより、残高の表示と失われた資金の転送のみが可能になります。
contract SimpleWallet is Ownable { function () public payable { } function weiBalance() public constant returns(uint256) { return this.balance; } function claim(address destination) public onlyOwner { destination.transfer(this.balance); } }
次に、元の契約がダウンロードされたテストネットワークでトランザクションを見つけました。0xc4c32a3d97dbd691eb3646e4c0c404e899a632010bc48d7182d75bef6803b7bcで、 nonceフィールドが13であることがわかりました。 ノンスが0から13に成長するまで。それだけで、目的のアドレスにスマートコントラクトが読み込まれました。 ここでは、同じナンスが13である2つのトランザクションを観察できます。これらは、5日間の差で同じアドレスにある2つの異なるネットワークの2つの異なるスマートコントラクトによってダウンロードされました。
- 0xc4c32a3d97dbd691eb3646e4c0c404e899a632010bc48d7182d75bef6803b7bc
- 0xeaeb29871ceaabb3dc200b424f38ae1b493262eb8c7f5be7d000f2399e4edba0
新たに満たされたスマート契約である
claim
方法を呼び出した後、資金が正常に受領されました。
また、スマート契約は、資金が到着してから2日後にネットワークにアップロードされたことに注意してください。
手短に。 Ethereum コアネットワークに、Ethereum テストネットワークにアップロードされたスマートコントラクトのアドレスに送金しました。 同じウォレットを使用して、トランザクションノンスフィールドが値13に達するまでまったく異なるスマートコントラクトをイーサリアムメインネットワークに数回アップロードしました。これは、スマートコントラクトをテストネットワークにアップロードするために使用されました。 次に、新しいスマート契約の特別な方法を呼び出しました。これにより、ウォレットに資金を引き出すことができました。 資金が既に待っている住所にスマート契約をダウンロードしたことが判明しました
PSHabréの記事に絵文字を追加する可能性について賛成票を投じてください