[ERC1167] コントラクトを簡単にガス効率良く複製する仕組みを理解しよう！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

今回の規格はOpcodesについての記述もあるため、Opcodesがわからない方は以下の記事などを参考にしてください。

この方法は、あるコントラクトが別のコントラクトの機能を使うことをシンプルにし、その過程で一貫性と予測可能性を保つことができる非常に効果的な手法です。 これにより、複雑なシステムやアプリケーションでも、様々な機能をスムーズに組み合わせて利用することができます。

メモリスロットの衝突

メモリスロットの衝突とは、複数のデータが同じメモリ位置（スロット）に保存されようとするときに起こる問題です。 スマートコントラクトやプログラミングにおいて、同じアドレス空間を共有する場合にバグやセキュリティリスクを引き起こす可能性があります。

例えば、イーサリアムのスマートコントラクトでは、ステート（コントラクトのストレージデータ）はメモリのスロットに保存されます。 コントラクトには、それぞれのステートがどのスロットに格納されるか決まっています。

具体例

オンラインバンキングシステムのスマートコントラクトを作っているとします。 このコントラクトには、ユーザーの残高を追跡するための変数とシステムの重要な設定を保存するための変数があります。

contract Bank {
    mapping(address => uint256) public balances;
    bool public systemMaintenance = false;
    // その他の変数や関数...
}

ここで、balancesはユーザーごとに異なる残高を追跡するためのもので、systemMaintenanceはシステムのメンテナンス状態を示すためのものです。

通常、これらの変数はそれぞれ異なるスロットに保存されます。 しかし、ある状況でこれらの変数が同じスロットに割り当てられてしまうと、balancesを更新するコードが誤ってsystemMaintenanceの値も変更してしまう可能性があります。 このような状況が発生するとセキュリティ問題につながります。 例えば、システムメンテナンスモードが意図せずに有効になり、全ての取引が停止してしまうかもしれません。

このような問題を避けるために、開発者はスマートコントラクトを設計する時に、データの保存場所に注意を払ってテストを徹底する必要があります。 また、既存のコントラクトをクローンする場合には、元のコントラクトのメモリ配置を正確に理解し、衝突が起きないようにすることが重要です。

この標準を使えば、あるコントラクトの機能をまったく同じように使える新しいコントラクトを作ることができます。 この方法は、余計な手間やコストをかけずに効率的に行えるため、開発者がブロックチェーン上でアプリケーションやサービスを簡単に、かつ経済的に構築するのに役立ちます。

この標準は、ブロックチェーン上で効率的かつ正確にコントラクトを複製するための「レシピ」のようなものと考えることができます。

クローンコントラクトは、既存のコントラクトの機能を複製して新しいコントラクトを作成するためのものです。 ここでは、そのバイトコードと、特定のアドレスをどのように置き換えるかについて説明しています。

バイトコード

「363d3d373d3d3d363d73bebebebebebebebebebebebebebebebebebebebe5af43d82803e903d91602b57fd5bf3」は、クローンコントラクトを作成するためのバイトコードです。 このコード内の10番目から29番目（両端を含む）のバイト（bebebebebebebebebebebebebebebebebebeの部分）は、複製したいマスター機能コントラクトのアドレスに置き換えられます。 これにより、クローンコントラクトは特定のマスターコントラクトの機能を複製することができます。

例

例えば、特定のトークンコントラクトの機能を持つ新しいコントラクトを作りたいとします。 そのトークンコントラクトのアドレスが「0x1234567890123456789012345678901234567890」だとすると、バイトコードの中のbebebebebebebebebebebebebebebebebebeの部分をこのアドレスで置き換えます。 置き換えた後のバイトコードは、新しいトークンコントラクトをデプロイする時にEthereumネットワークに送信され、その結果としてマスターコントラクトの機能を複製したクローンコントラクトが作成されます。

このように、標準クローンコントラクトのバイトコードは、特定の機能を持つコントラクトを効率的に複製し、新しいコントラクトを作成するための強力なツールです。 この技術を利用することで、開発の効率化、コスト削減、イーサリアムのスマートコントラクトの可能性をさらに広げることができます。

ガス効率向上

• コードの再利用
  • クローンコントラクトは既存のコントラクト（マスターコントラクト）のコードを再利用します。
  • 新しいコントラクトを作成する時に、既存のコードを再度ブロックチェーンにアップロードする代わりに、既存のコードを指し示すだけで済むため、デプロイメントに必要なガスが大幅に削減されます。
• コードの短縮
  • クローンコントラクトは、マスターコントラクトへの参照を持つ非常に短いバイトコードで構成されています。
  • 短いコードは、ブロックチェーンに保存するデータ量が少なくなるため、それに伴ってガス消費も減少します。
• バニティアドレス最適化
  • マスターコントラクトのアドレスを特定の形式（例えば先頭にゼロバイトが多い）にすることで、クローンコントラクト内のアドレス参照をさらに短くすることができます。
  • これにより、コントラクトのサイズがさらに削減され、デプロイメント時のガスコストが減少します。
• 一般的な処理の共有
  • クローンコントラクトはマスターコントラクトの機能をそのまま利用するため、新しいコントラクトごとに同じ処理を何度もデプロイする必要がありません。
  • この再利用により、ネットワーク全体の負荷とガス消費が減少します。

これらの要因により、クローンコントラクトは特にデプロイメント時にガス効率が良く、同様の機能を持つ独自コントラクトを一からデプロイするよりも、はるかに経済的です。 また、これらの最適化により、ブロックチェーンのリソースを節約し、全体のネットワーク効率も向上します。

ファクトリー・コントラクト・モデル

ファクトリー・コントラクト・モデルは、1つの「ファクトリー」と呼ばれるコントラクトを使って、他のコントラクトを生成、管理する方法です。 このモデルは特にイーサリアムのようなブロックチェーンでよく用いられます。

例

オンラインマーケットプレイスを運営しており、各販売者が自分の店を持てるようにしたいと考えています。 各店は独自の在庫、価格設定、販売記録を持つべきでファクトリー・コントラクト・モデルが役立ちます。

1. ファクトリー・コントラクトの作成
   • まずは「店舗ファクトリー」というコントラクトを作成します。
   • このコントラクトは、新しい店舗コントラクトを生成する機能を持っています。
2. 店舗コントラクトのテンプレート
   • 各店舗は、在庫、価格、販売記録などを管理する機能を持つ「店舗コントラクト」に基づいています。
   • この店舗コントラクトは、ファクトリー・コントラクトによって複製されるテンプレートのようなものです。
3. 新しい店舗の作成
   • 販売者がマーケットプレイスに参加したいとき、彼らはファクトリー・コントラクトに指示を出して、自分の店舗コントラクトを生成します。
   • ファクトリー・コントラクトは新しい店舗コントラクトをブロックチェーン上にデプロイし、その管理権を販売者に渡します。
4. 運用と管理
   • 販売者は自分の店舗コントラクトを通じて商品を追加したり、価格を設定したり、売り上げを管理したりできます。
   • また、ファクトリー・コントラクトはこれら全ての店舗コントラクトを追跡し、必要に応じて追加の機能やアップデートを提供できます。

このように、ファクトリー・コントラクト・モデルを使うと、簡単に多くの独立したコントラクトを生成し、管理することができ、大規模なアプリケーションやサービスを効率的に運営することが可能になります。

この取り組みはブロックチェーン上でコントラクトを複製する際のハードルを低くし、より多くの人が利用できるようにするとともに、操作がシンプルで予測可能、かつ安全に行えるようにすることを目指しています。

EIP211については以下の記事を参考にしてください。

処理フロー

上記のコードは、Ethereumのスマートコントラクトで使用されるバイトコードの一部です。 これは、プロキシコントラクトが他のコントラクトへの操作を委譲する時の処理を示しています。 各行はEVM（Ethereum Virtual Machine）の命令とその操作を表しています。 以下は、各ステップの説明です。

1. 0x00000000 36 calldatasize cds
   • 外部から送られてきたデータ（calldata）のサイズを取得します。
2. 0x00000001 3d returndatasize 0 cds
   • 現在のフレームで利用可能な戻り値のデータサイズを0としてスタックにプッシュします。
3. 0x00000002 3d returndatasize 0 0 cds
   • もう一度、戻り値のデータサイズ（ここでは0）をスタックにプッシュします。
4. 0x00000003 37 calldatacopy
   • 外部からのデータをEVMのメモリにコピーします。
5. 0x00000004 3d returndatasize 0
   • 新しい戻り値のデータサイズ（0）をスタックにプッシュします。
6. 0x00000005 3d returndatasize 0 0
   • 再び、戻り値のデータサイズ（0）をスタックにプッシュします。
7. 0x00000006 3d returndatasize 0 0 0
   • さらに、戻り値のデータサイズ（0）をスタックにプッシュします。
8. 0x00000007 36 calldatasize cds 0 0 0
   • もう一度、calldataのサイズをスタックにプッシュします。
9. 0x00000008 3d returndatasize 0 cds 0 0 0
   • 新しい戻り値のデータサイズ（0）をスタックにプッシュします。
10. 0x00000009 73bebebebebe push20 0xbebebebe 0xbebe 0 cds 0 0 0
    • delegatecallを送る先のアドレス（ここでは0xbebebebebebe...）をスタックにプッシュします。
11. 0x0000001e 5a gas gas 0xbebe 0 cds 0 0 0
    • 利用可能なガスの量をスタックにプッシュします。
12. 0x0000001f f4 delegatecall suc 0
    • スタックの内容を使って、別のコントラクトに操作を委譲するdelegatecallを実行します。
13. 0x00000020 3d returndatasize rds suc 0
    • delegatecallからの戻り値のサイズをスタックにプッシュします。
14. 0x00000021 82 dup3 0 rds suc 0
    • スタックの3番目の要素をコピーしてプッシュします。
15. 0x00000022 80 dup1 0 0 rds suc 0
    • スタックの先頭の要素をコピーしてプッシュします。
16. 0x00000023 3e returndatacopy suc 0
    • delegatecallからの戻り値をメモリにコピーします。
17. 0x00000024 90 swap1 0 suc
    • スタックの上位2つの要素の位置を入れ替えます。
18. 0x00000025 3d returndatasize rds 0 suc
    • 新しい戻り値のデータサイズをスタックにプッシュします。
19. 0x00000026 91 swap2 suc 0 rds
    • スタックの上から2番目と3番目の要素を入れ替えます。
20. 0x00000027 602b push1 0x2b 0x2b suc 0 rds
    • ジャンプ先のアドレス（0x2b）をスタックにプッシュします。
21. 0x00000029 57 jumpi 0 rds
    • 条件付きでジャンプします。
    • もしスタックの2番目の要素が0なら、指定されたアドレス（0x2b）にジャンプします。
22. 0x0000002a fd revert
    • もしジャンプが実行されなければ、操作を中止してすべての変更を元に戻します。
23. 0x0000002b 5b jumpdest 0 rds
    • ジャンプの目的地です。
    • ここから次の命令が実行されます。
24. 0x0000002c f3 return
    • 最終的な結果を呼び出し元に返します。

この一連の命令は、プロキシコントラクトがデリゲートコールを使用して別のコントラクトのコードを実行し、その結果を呼び出し元に返すプロセスを示しています。

この最適化はプロキシコントラクトをより小さく、よりコスト効率良くデプロイするための方法です。 これにより、特に多くのコントラクトをデプロイする必要がある大規模なアプリケーションやサービスで、コストと効率の面で大きなメリットが得られます。

処理フロー

上記のコードは、Ethereumのスマートコントラクトで使用されるバイトコードの一部であり、EVM（Ethereum Virtual Machine）の命令セットを表しています。 この特定のコードは、プロキシコントラクトの一例であり、別のコントラクトへの呼び出しを委譲する機能を持っています。 以下は、各ステップの説明です。

1. 0x00000000 36 calldatasize cds
   • 外部から送られてきたデータ（calldata）のサイズをスタックにプッシュします。
2. 0x00000001 3d returndatasize 0 cds
   • 現在のコンテキストで利用可能な戻り値データのサイズ（この時点では0）をスタックにプッシュします。
3. 0x00000002 3d returndatasize 0 0 cds
   • 再び、戻り値データのサイズ（0）をスタックにプッシュします。
4. 0x00000003 37 calldatacopy
   • 外部からのデータ（calldata）をEVMのメモリにコピーします。
5. 0x00000004 3d returndatasize 0
   • 新しい戻り値データのサイズ（0）をスタックにプッシュします。
6. 0x00000005 3d returndatasize 0 0
   • さらに、戻り値データのサイズ（0）をスタックにプッシュします。
7. 0x00000006 3d returndatasize 0 0 0
   • もう一度、戻り値データのサイズ（0）をスタックにプッシュします。
8. 0x00000007 36 calldatasize cds 0 0 0
   • calldataのサイズを再度スタックにプッシュします。
9. 0x00000008 3d returndatasize 0 cds 0 0 0
   • 新しい戻り値データのサイズ（0）をスタックにプッシュします。
10. 0x00000009 6fbebebebebe push16 0xbebebebe 0xbebe 0 cds 0 0 0：
    • 委譲先コントラクトのアドレス（0xbebebebe...）の一部をスタックにプッシュします。
11. 0x0000001a 5a gas gas 0xbebe 0 cds 0 0 0
    • 現在の利用可能なガス量をスタックにプッシュします。
12. 0x0000001b f4 delegatecall suc 0
    • 委譲先コントラクトに操作を委譲し、成功したかどうかの結果（成功なら1、失敗なら0）をスタックにプッシュします。
13. 0x0000001c 3d returndatasize rds suc 0
    • delegatecallからの戻り値データのサイズをスタックにプッシュします。
14. 0x0000001d 82 dup3 0 rds suc 0
    • スタックの3番目の要素（この場合0）をコピーしてスタックのトップにプッシュします。
15. 0x0000001e 80 dup1 0 0 rds suc 0
    • スタックのトップの要素（この場合0）をコピーしてスタックのトップにプッシュします。
16. 0x0000001f 3e returndatacopy suc 0
    • delegatecallからの戻り値をメモリにコピーします。
17. 0x00000020 90 swap1 0 suc
    • スタックのトップ2つの要素の位置を入れ替えます。
18. 0x00000021 3d returndatasize rds 0 suc
    • 新しい戻り値データのサイズをスタックにプッシュします。
19. 0x00000022 91 swap2 suc 0 rds
    • スタックの2番目と3番目の要素の位置を入れ替えます。
20. 0x00000023 6027 push1 0x27 0x27 suc 0 rds
    • ジャンプ先のアドレス（0x27）をスタックにプッシュします。
21. 0x00000025 57 jumpi 0 rds
    • 条件付きジャンプを行います。
    • もしスタックの2番目の要素（0）が0でなければ、指定されたアドレス（0x27）にジャンプします。
22. 0x00000026 fd revert
    • ジャンプが実行されなかった場合（つまりdelegatecallが失敗した場合）、操作を中止してすべての変更を元に戻します。
23. 0x00000027 5b jumpdest 0 rds
    • ジャンプの目的地です。
    • ここから次の命令が実行されます。
24. 0x00000028 f3 return
    • 最終的な結果を呼び出し元に返します。

このコードは、プロキシコントラクトが別のコントラクトへの呼び出しを委譲するプロセスを実装しており、その過程でメモリの操作、条件付きジャンプ、エラーハンドリングなど複数のステップが含まれています。

Standard Proxyとの比較

両方のコードはEthereumのスマートコントラクト内でデリゲートコールを行うプロキシコントラクトの動作を示しています。 基本的な処理の流れは同じですが、以下の点で異なります。

Standard Proxy

• 0x00000009 73bebebebebe. push20 0xbebebebe
  • この命令は20バイトのアドレス（0xbebebebebebe...）をスタックにプッシュしています。
  • これはデリゲートコールの目的地アドレスです。
• 0x00000027 602b push1 0x2b
  • この命令は1バイトの値（0x2b）をスタックにプッシュしています。
  • これは後に条件付きジャンプ（jumpi）の目的地として使用されます。
• 0x0000002b 5b jumpdest 0 rds
  • このjumpdestはアドレス0x2bに設定されています。

Vanity Address Optimization

• 0x00000009 6fbebebebebe. push16 0xbebebebe
  • この命令は16バイトのアドレス（0xbebebebe）をスタックにプッシュしています。
  • このアドレスは最初のコードと同じアドレスの末尾16バイトですが、長さが異なります。
  • これは、バニティアドレス最適化が適用され、先頭の0バイトが省略されているためです。
• 0x00000023 6027 push1 0x27
  • この命令は1バイトの値（0x27）をスタックにプッシュしています。
  • この値は最初のコードの0x2bよりも小さく、これもバニティアドレス最適化の結果、アドレスが短くなったために必要なジャンプアドレスが変わったことを示しています。
• 0x00000027 5b jumpdest 0 rds
  • このjumpdestはアドレス0x27に設定されています。

異なる点

• アドレスの長さ
  • 最初のコードは20バイトのアドレスを使用していますが、2番目のコードはバニティアドレス最適化により16バイトのアドレスを使用しています。
• jumpdest
  • バニティアドレス最適化の結果、2番目のコードのジャンプデスティネーションアドレスは最初のコードよりも小さくなっています。

これらの違いは、プロキシコントラクトのサイズを削減し、デプロイメント時のガスコストを節約するための最適化を反映しています。 バニティアドレス最適化は、アドレスの長さを短縮し、それに伴い必要なコードを調整することで実現されています。