すべては
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つの異なるスマートコントラクトによってダウンロードされました。
新たに満たされたスマート契約である
claim方法を呼び出した後、資金が正常に受領されました。
また、スマート契約は、資金が到着してから2日後にネットワークにアップロードされたことに注意してください。
手短に。 Ethereum
コアネットワークに、Ethereum
テストネットワークにアップロードされたスマートコントラクトのアドレスに送金しました。 同じウォレットを使用して、トランザクション
ノンスフィールドが値13に達するまでまったく異なるスマートコントラクトをイーサリアム
メインネットワークに数回アップロードしました。これは、スマートコントラクトを
テストネットワークにアップロードするために使用されました。 次に、新しいスマート契約の特別な方法を呼び出しました。これにより、ウォレットに資金を引き出すことができました。 資金が既に待っている住所にスマート契約をダウンロードしたことが判明しました
PSHabréの記事に絵文字を追加する可能性
について賛成票を投じてください