導入前にスマート コントラクトのアドレスを決定する方法: 暗号交換に CREATE2 を使用する

ブロックチェーンの話題は、あらゆる種類の誇大宣伝の源であるだけでなく、技術的な観点から非常に貴重なアイデアの源でもあります。 したがって、彼女は晴れた都市の住民を迂回しませんでした。 人々は注意深く観察し、研究し、従来の情報ベースの専門知識をブロックチェーン システムに移行しようとしています。 これまでのところ、ポイント的には、Rostelecom-Solar の開発の 2 つは、ブロックチェーンに基づいてソフトウェアのセキュリティをチェックできることです。 そしてその過程で、ブロックチェーンコミュニティの応用問題の解決についていくつかの考えが生まれます。 これらのライフハックの XNUMX つである、CREATEXNUMX を使用して展開前にスマート コントラクトのアドレスを決定する方法を、今日は一部抜粋して共有したいと思います。

CREATE2 オペコードは、今年 28 月 XNUMX 日にコンスタンティノープルのハード フォークに追加されました。 EIP に記載されているように、このオペコードは主に状態チャネルのために導入されました。 ただし、私たちはそれを別の問題を解決するために使用しました。

取引所に残高があるユーザーがいます。 各ユーザーにイーサリアム アドレスを提供する必要があります。イーサリアム アドレスには誰でもトークンを送信でき、それによってアカウントが補充されます。 これらのアドレスを「ウォレット」と呼びます。 トークンがウォレットに到着したら、単一のウォレット (ホットウォレット) にトークンを送信する必要があります。

次のセクションでは、CREATE2 を使用せずにこの問題を解決するためのオプションを分析し、それらを放棄した理由を説明します。 最終結果のみに興味がある場合は、「最終ソリューション」セクションで見つけることができます。

イーサリアムアドレス

最も簡単な解決策は、新しいユーザー用に新しいイーサリアム アドレスを生成することです。 これらのアドレスがウォレットになります。 トークンをウォレットからホットウォレットに転送するには、関数を呼び出してトランザクションに署名する必要があります。 転送（） バックエンドからウォレットの秘密キーを使用して。

このアプローチには次の利点があります。

• それだけです
• ウォレットからホットウォレットにトークンを転送するコストは、関数を呼び出すコストと同じです。 転送（）

ただし、このアプローチには重大な欠点が XNUMX つあるため、私たちはこのアプローチを放棄しました。秘密キーをどこかに保存する必要があるということです。 また、紛失する可能性があるだけでなく、これらのキーへのアクセスを慎重に管理する必要もあります。 少なくとも XNUMX つが侵害された場合、特定のユーザーのトークンはホット ウォレットに到達できなくなります。

ユーザーごとに個別のスマート コントラクトを作成する

ユーザーごとに個別のスマート コントラクトをデプロイすると、ウォレットの秘密キーをサーバーに保存しなくても済みます。 取引所はこのスマート コントラクトを呼び出して、トークンをホットウォレットに転送します。

また、スマート コントラクトを展開しないとユーザーに自分のウォレット アドレスを表示できないため、このソリューションも放棄しました (これは実際には可能ですが、かなり複雑な方法であり、ここでは説明しない他の欠点もあります)。 取引所では、ユーザーは必要なだけアカウントを作成でき、誰もが自分のウォレットを必要とします。 これは、ユーザーがこのアカウントを使用するかどうかさえ分からないまま、コントラクトの展開に費用を費やす必要があることを意味します。

オペコード CREATE2

前の方法の問題を解決するために、CREATE2 オペコードを使用することにしました。 CREATE2 を使用すると、スマート コントラクトを展開するアドレスを事前に決定できます。 アドレスは次の式を使用して計算されます。

keccak256 (0xff ++ address ++ salt ++ keccak256 (init_code)) [12:]

ここで、

• 住所 — CREATE2を呼び出すスマートコントラクトのアドレス
• 塩 - ランダムな値
• 初期化コード - デプロイメント用のスマート コントラクト バイトコード

これにより、ユーザーに提供するアドレスに実際に必要なバイトコードが含まれることが保証されます。 また、このスマート コントラクトは、必要なときにいつでも展開できます。 たとえば、ユーザーが初めてウォレットを使用することを決めたとき。

さらに、次の理由により、スマート コントラクト アドレスを保存する代わりに、毎回計算することができます。

• 住所 式内のはウォレットファクトリーのアドレスであるため定数です
• 塩 - user_id ハッシュ
• 初期化コード 同じウォレットを使用しているため永続的です

さらなる改善

以前のソリューションには依然として XNUMX つの欠点があります。それは、スマート コントラクトの導入に料金を支払う必要があることです。 ただし、それを取り除くことはできます。 このために、関数を呼び出すことができます 転送（）そして 自己破壊（） ウォレットコンストラクター内で。 そして、スマートコントラクトを展開するためのガスが返されます。

一般的な考えに反して、CREATE2 オペコードを使用すると、スマート コントラクトを同じアドレスに複数回デプロイできます。 これは、CREATE2 がターゲット アドレスのノンスがゼロであることをチェックするためです (コンストラクターの先頭で値 "1" が割り当てられます)。 同時に機能は、 自己破壊（） 毎回 nonce アドレスをリセットします。 したがって、同じ引数を使用して CREATE2 を再度呼び出すと、nonce チェックに合格します。

このソリューションはイーサリアム アドレス ソリューションに似ていますが、秘密キーを保存する必要がないことに注意してください。 ウォレットからホットウォレットに送金するコストは、関数を呼び出すコストとほぼ同じです 転送（）、スマートコントラクトの展開に料金を支払わないためです。

最終決定

最初に準備したもの:

• 塩を取得する関数 USER_ID
• 適切なソルト（つまり、ウォレットファクトリー）を使用してCREATE2オペコードを呼び出すスマートコントラクト
• 次のコンストラクターとのコントラクトに対応するウォレットのバイトコード:

constructor () {
    address hotWallet = 0x…;
    address token = 0x…;
    token.transfer (hotWallet, token.balanceOf (address (this)));
    selfdestruct (address (0));
}

新しいユーザーごとに、計算によってそのユーザーのウォレット アドレスが表示されます。

keccak256 (0xff ++ address ++ salt ++ keccak256 (init_code)) [12:]

ユーザーが対応するウォレット アドレスにトークンを転送すると、バックエンドはパラメータを持つ Transfer イベントを確認します。 _にウォレットアドレスと同じです。 この時点で、ウォレットを展開する前に取引所でユーザーの残高を増やすことがすでに可能です。

十分なトークンがウォレット アドレスに蓄積されたら、それらをすべて一度にホットウォレットに転送できます。 これを行うために、バックエンドはスマート コントラクト ファクトリ関数を呼び出し、次のアクションを実行します。

function deployWallet (соль uint256) {
    bytes memory walletBytecode =…;
    // invoke CREATE2 with wallet bytecode and salt
}

したがって、ウォレット スマート コントラクト コンストラクターが呼び出され、すべてのトークンがホットウォレット アドレスに転送されてから自己破壊されます。

完全なコードが見つかります ここで。 ウォレットのバイトコードを最適化し、オペコードに記述することにしたため、これは製品コードではないことに注意してください。

著者Pavel Kondratenkov、イーサリアムスペシャリスト

出所： habr.com