# [ERC5202] コントラクトを複製するブループリントコントラクトについて理解しよう！

> "ブループリント"コントラクトとは、初期化コード（initcode）がオンチェーンに保存されるコントラクトを表す標準のことです。

- URL: https://cardene.dev/articles/6db304301f6319fbe7bc
- 公開日: 2024-01-06
- 更新日: 2024-01-06
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

初めまして。
**CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

https://cryptogames.co.jp/

代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。

https://cryptospells.jp/

今回は、コントラクトを簡単に複製できるブループリントコントラクトを利用するための、バイトコードフォーマットを定義している規格である**ERC5202**についてまとめていきます！

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

https://eips.ethereum.org/EIPS/eip-5202

他にも様々なERCについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

この記事では一部分でOpcodesの知識が必要になります。
もし興味がある方は以下の記事を参考にしてください。

https://zenn.dev/heku/books/aef33b86ded3c0

## 概要

"ブループリント"コントラクトとは、初期化コード（`initcode`）がオンチェーンに保存されるコントラクトを表す標準のことです。
この初期化コードとは、コントラクトがブロックチェーン上でどのように機能するかを定義するコードのことで、基本的にコントラクトの「**設計図**」のようなものです。
ブループリントコントラクトを使うことで、開発者は一度コードをデプロイし、その後はそのブループリントを使って同様のコントラクトを簡単に生成できるようになります。
これは、新しいコントラクトの作成とデプロイをより効率的かつ迅速に行うことができるようにするための方法です。

この概念は、特に**ERC20**や**ERC721**などの標準化されたコントラクトで有用です。
開発者は、特定の機能やロールを持つコントラクトを一から作成する代わりに、既存のブループリントを使用して必要な機能を持つ新しいインスタンスを生成できます。
例えば、新しいトークンを作成する場合、開発者は**ERC20**や**ERC721**のブループリントを用いて、カスタムロジックやパラメータを加えた`mint`や`transfer`などの関数を持つ新しいコントラクトを迅速にデプロイできます。

また、ブループリントコントラクトは、異なるコントラクト間でのやり取りを簡素化し、より安全で効率的なやり取りを可能にします。
一度標準化された方法でブループリントが確立されると、それを使用する全てのコントラクトは互換性を持ち、予期しない動作を避けることができます。

## 動機

コントラクトのデプロイサイズを減らすために、初期化コード（`initcode`）をオンチェーンに「**ブループリント**」コントラクトとして保存し、その後`EXTCODECOPY`を使用して`initcode`をメモリにコピーし、`CREATE`または`CREATE2`を呼び出すというパターンが有用です。
しかしながら、この方法には以下の問題があります。

外部のツールやインデクサーが、あるコントラクトが「**通常の**」ランタイムコントラクトなのか、「**ブループリント**」コントラクトなのかを判定するのは困難です。
バイトコード内のパターンを経験的に探索して`initcode`であるかを判断するのは、維持管理と正確性に問題を抱えます。

`initcode`をバイト単位でオンチェーンに保存することは、正確性とセキュリティの問題を引き起こします。
EVMは実行可能コードと他のタイプのコードを区別するネイティブの方法を持っていないため、`initcode`が明示的にACL（アクセス制御リスト）ルールを実装していない限り、誰でもそのような「**ブループリント**」コントラクトを呼び出して、`initcode`を通常のランタイムコードとして直接実行できます。
これは特に、ブループリントコントラクトに保存された`initcode`がストレージへの書き込みや外部コントラクトの呼び出しなどの副作用を持っている場合に問題です。
もしブループリントコントラクトに保存された`initcode`が`SELFDESTRUCT`オペコードを実行すれば、ブループリントコントラクト自体が削除されてしまい、そのブループリントに依存している下流のデプロイヤーコントラクトの正確な動作を妨げる可能性があります。
このため、実行を防ぐためにブループリントコントラクトに特別な前文を付け加えることが望ましいです。

:::message
前文（`preamble`）とは、コントラクトや文書の最初の部分に配置される特定のコードやテキストのことです。
プログラミングやブロックチェーンのコンテキストでは、前文は通常、コードの残りの部分に関する情報をエンコードしたシーケンスや識別子を含みます。
ブループリントコントラクトの場合、前文はコントラクトが実行可能な通常のランタイムコードではなく、`initcode`を含むブループリントであることを示すために使用されます。
この前文により、コントラクトが誤って実行されるのを防ぎ、セキュリティを向上させることができます。
特定のパターンやシーケンスが前文として使用され、コントラクトの意図とタイプを明確にするためのマーカーとして機能します。
:::

## 仕様

ブループリントコントラクトは、前文として`0xFE71<バージョンビット><エンコーディングビットの長さ>`を使用しなければなりません。
バージョンには`6`ビットが割り当てられ、エンコーディングビットの長さには`2`ビットが割り当てられます。
最初のバージョンは`0`（`0b000000`）で始まり、バージョンは1ずつ増加します。
<エンコーディングビットの長さ>の値`0b11`は予約されています。
長さビットが`0b11`の場合、3番目のバイトは継続バイトと見なされます（つまり、バージョンをエンコードするために複数のバイトが必要です）。
マルチバイトバージョンの正確なエンコーディングは、将来の**ERC**に委ねられています。

:::message
ブループリントコントラクトの前文で使用されるバージョンとエンコーディングの長さのビットについて具体的な例を用いて説明します。

- **バージョンビット**
    - 前文には6ビットがバージョン番号を表すために割り当てられています。
    - バージョンは`0`から始まり（`0b000000`）、1ずつ増加します。
    - これは、バージョン`0`からバージョン`63`（`0b111111`）までの`64`個の異なるバージョンを表現することができることを意味します。
    - たとえば、バージョン`5`はバイナリで`0b000101`として表されます。

- **エンコーディングの長さ**
    - エンコーディングの長さには`2`ビットが割り当てられており、これは3つの異なる値（`0b00`、`0b01`、`0b10`）を表すことができ、4つ目の値`0b11`は特別な意味を持ちます。
    - たとえば、エンコーディングの長さが`0b01`の場合、これは後続の特定のバイト数がデータの長さを表すことを意味します。

- **予約されたビット（`0b11`）**
    - 長さエンコーディングビットが`0b11`の場合、これは「**継続バイト**」があることを意味します。
    - つまり、バージョン番号をエンコードするためには複数のバイトが必要です。
    - これは、将来、より多くのバージョンが必要になった場合に拡張性を持たせるための仕組みです。
    - 将来の**ERC**でマルチバイトバージョンの正確なエンコーディング方法が定められる予定です。

**具体的な例**
- 仮にバージョン2（`0b000010`）のブループリントコントラクトを作成するとします。
- そして、エンコーディングの長さが1バイト（`0b01`）であるとします。
- この場合、前文は以下のようになります。

```
0xFE71 000010 01
```

- これは、バージョン2を示し、後続の1バイトがデータの長さを表すことを意味します。

このようにバージョンとエンコーディングの長さを用いることで、ブループリントコントラクトの前文は、コントラクトのバージョンとデータ構造を明確に表現し、将来の拡張性を確保するための情報を提供します。
:::

ブループリントコントラクトには、少なくとも1バイトの`initcode`が含まれていなければなりません。

ブループリントコントラクトは、バージョンバイトと`initcode`の間に任意のバイト（データまたはコード）を挿入することができます。
このような可変長データを使用する場合、前文は`0xFE71<バージョンビット><エンコーディングビットの長さ><バイトの長さ><データ>`でなければなりません。
<エンコーディングビットの長さ>は、<バイトの長さ>が何バイトを取るかを表す`0`から`2`（含む）までの数を表し、<バイトの長さ>は<データ>が何バイトを取るかをビッグエンディアンエンコーディングした数です。

:::message
ブループリントコントラクトの前文には、特定のフォーマットが要求されます。
このフォーマットはコントラクトが正しく認識され、使用されるようにするためのものです。

例えば、バージョン1（`0b000001`）のブループリントコントラクトを作成し、`10`バイトのデータ（任意のバイトまたはコード）を`initcode`の前に挿入したいとします。
そして、この`10`バイトの長さをエンコードするために`2`バイト（`16`ビット）を使用することにしました。

1. **前文の開始**
    - すべてのブループリントコントラクトの前文は`0xFE71`で始まります。

2. **バージョンビット**
    - このコントラクトのバージョンは`1`なので、バージョンビットは`0b000001`です。

3. **エンコーディングビットの長さ**
    - 長さをエンコードするために`2`バイト（`16`ビット）を使用することにしました。
    - `2`バイトは`0b10`としてエンコードされます。

4. **バイトの長さ**
    - 挿入したいデータが`10`バイトであるため、この長さをビッグエンディアンでエンコードする必要があります。
    - `10`はバイナリで`0b0000000000001010`となります。
    - これを`2`バイトで表すと、`0x000A`となります。

5. **データ**
    - ここに`10`バイトのデータが続きます。
    - 例として、これを`0x1234567890ABCDEFFFED`とします。

したがって、このブループリントコントラクトの完全な前文は以下のようになります。

```
0xFE71 000001 10 000A 1234567890ABCDEFFFED
```

これにより、ブループリントコントラクトは自身のバージョンを識別し、`initcode`の前にどれだけのデータがあるかを知り、そしてそのデータが何であるかを正確に理解することができます。
これにより、ブループリントコントラクトはさまざまなサイズと内容の`initcode`を柔軟に扱うことが可能となります。
:::

:::message
**ビッグエンディアンエンコーディング**
ビッグエンディアンエンコーディングは、データをバイト列として表現する時に、最も重要なバイト（最上位バイト）を先頭に置く方法です。
これは数値やアドレスなどの複数バイトからなるデータを記憶装置に保存する時の一般的な方式の1つです。
ビッグエンディアンの対義語はリトルエンディアンで、こちらは最も重要でないバイト（最下位バイト）を先頭に置きます。

例として、数値`0x12345678`をビッグエンディアン形式でエンコードすることを考えましょう。

この数値を16進数で表すと、それぞれのバイトは次のようになります。
- `0x12`（最上位バイト）
- `0x34`
- `0x56`
- `0x78`（最下位バイト）

ビッグエンディアンエンコーディングでは、最上位バイトが最初に来るため、この数値は次のようにバイト列として表されます：

`0x12 0x34 0x56 0x78`

これに対して、もしリトルエンディアンエンコーディングを使用すると、最下位バイトが最初に来るため、バイト列は次のようになります：

`0x78 0x56 0x34 0x12`

ビッグエンディアンエンコーディングは、人間が読み書きする際に直感的であることが多く、ネットワーク上でデータを送受信する際の標準的な方法（ネットワークバイトオーダーとも呼ばれます）としても広く採用されています。
:::

## 補足

ブループリントコントラクトは、ブロックチェーン上でコントラクトの初期化コード（`initcode`）を保存し、再利用するための仕組みです。
この仕組みを使うと、新しいコントラクトを作成する時にガスやストレージスペースを節約できます。
ただし、この効率性を実現するためには、ブループリントコントラクト自体の構造にいくつかの工夫が必要です。

まず、ブループリントコントラクトの前文は`0xfe`で始まります。
この`0xfe`は`INVALID`オペコードであり、コントラクトが直接呼び出された場合には例外的な停止条件を引き起こし、実行を終了させます。
これは、ブループリントコントラクトが通常のコントラクトとして実行されるべきではないことを強制するための措置です。

しかし、`0xfe`で始まるコントラクトが他にも存在する可能性があるため、ブループリントコントラクトを明確に識別するためにマジックバイト`0x71`が続きます。
この`0x71`は、「`blueprint`」という文字列の**keccak256**ハッシュ値の最後のバイトから取得されたもので、ブループリントコントラクトの前文として特別な意味を持ちます。

:::message
**マジックバイト**

マジックバイトとは、ブループリントコントラクトの前文に含まれる特定のバイトで、そのコントラクトがブループリントであることを識別するために使用されます。
このバイトはコントラクトが特定の種類または形式であることを示すために任意に選ばれ、他のランダムなデータや通常のコントラクトと区別するのに役立ちます。

具体例として、「**blueprint**」という文字列に対する**keccak256**ハッシュ関数の最後のバイトを取ることで、マジックバイト`0x71`が選ばれました。
**keccak256**は一般的なハッシュ関数で、任意のデータに対して一意のハッシュ値を生成します。
この場合、「`blueprint`」という文字列をハッシュ化すると、ハッシュ値の最後のバイトが`0x71`になります。

たとえば、Pythonでこの操作を行うコードは以下のようになります。

```python
import hashlib

# 'blueprint'文字列のkeccak256ハッシュ値を計算します。
hash_value = hashlib.sha3_256(b'blueprint').digest()

# ハッシュ値の最後のバイトを取得します。
magic_byte = hash_value[-1]

print(f"魔法のバイト: {magic_byte:02x}")
```

このコードを実行すると、`0x71`という値が「マジックバイト」として表示されます。
このようにして選ばれた`0x71`は、ブループリントコントラクトの前文で使われ、ブループリントコントラクトであることを明確に示します。
他の通常のコントラクトやランダムなデータが偶然にも`0xFE71`で始まる可能性は非常に低いため、この魔法のバイトはブループリントコントラクトの信頼性を高める重要な役割を果たします。
:::

ブループリントコントラクトには少なくとも`1`バイトの`initcode`が必要であり、空の`initcode`は許可されていません。
これは、空の`initcode`が誤って設定されるという一般的な間違いを防ぐためです。

ユーザーが前文に任意のデータやコードを含めたい場合、可変長エンコーディングが使用されます。
これにより、データの長さが`256`バイト未満である場合、その長さを`0`バイトまたは`1`バイトで表すことができます。
長さを表すためのビットは、前文の3番目のバイトの`2`ビットに予約されています。

バージョンビットが含まれているため、将来的にブループリントコントラクトがアップグレードされる必要がある場合に対応できます。
もしバージョンビットを使い果たした場合に備えて、継続シーケンスも予約されています。
しかし、通常は`2`バイトで十分であり、特別な継続シーケンスマーカー（`0b11`）が用意されています。

最後に、Ethereum Object Format（EOF）が将来的にEVMに導入されることにより、ブループリントコントラクトをさらに明確に指定する新しい方法が提供されるかもしれません。
しかし、それまではこのERCを使用してブループリントコントラクトを標準化し、より効率的なブロックチェーンアプリケーションを実現することが可能です。

:::message
**Ethereum Object Format（EOF）**
Ethereum Object Format（EOF）は、Ethereumのスマートコントラクトとその実行環境をより安全で効率的かつ透明にするために提案されている新しいフォーマットです。
現在のEthereum Virtual Machine (EVM) コードは単一のバイト列として格納されており、コントラクトの構造やコンテンツに関する明確な情報を提供しません。
これは、コントラクトの解析や検証を複雑にし、セキュリティリスクや効率の問題を引き起こす可能性があります。

EOFは、コントラクトのコードとデータを区別し、それぞれを異なるセクションに格納することで、これらの問題に対処しようとしています。
具体的には、EOFは以下のような特徴を持っています。

**セクション化されたフォーマット**
コントラクトのコード、データ、および他の要素は、異なるセクションに分割されます。
これにより、コントラクトの構造がより明確になり、解析や検証が容易になります。

**明確なバージョニング**
EOFにはバージョン番号が含まれており、異なるバージョンのフォーマットや実行環境の違いを明確に区別できます。
これにより、将来的なアップグレードや変更が容易になります。

**セキュリティの向上**
セクション化されたフォーマットにより、コードとデータを分離することができ、意図しないコード実行やデータ漏洩のリスクを低減できます。

**効率的な実行**
コントラクトの構造が明確になることで、EVMはより効率的にコードを解析し実行することができるようになります。
これは、ガス消費の削減にもつながります。

EOFは、Ethereumの将来的なアップグレードの一環として提案されており、Ethereum Improvement Proposals（EIP）を通じて議論されています。
EOFが実装されれば、Ethereumのスマートコントラクトのセキュリティと効率が大幅に向上することが期待されています。
:::

## 互換性

互換性の問題は特にありません。

## テスト

ブループリントコントラクトは、Ethereum上で再利用可能な初期化コード（`initcode`）を保存するための仕組みです。

```
0xFE710000
```

- `0xFE71`は、このコードがブループリントコントラクトであることを示すマジックヘッダです。
- `0x00`はバージョンが`0`であり、データセクションの長さが`0`バイトであることを示しています。
- つまり、このコントラクトにはデータセクションがないということです。
- 最後の`0x00`は、コントラクトの実行が終了するための`STOP`命令です。

```
0xFE710107FFFFFFFFFFFFFF00
```

- `0xFE71`は同じくマジックヘッダです。
- `0x01`はバージョンが`0`であり、データセクションの長さを示すビットが`1`バイトであることを意味します。
- `0x07`はデータセクションが`7`バイトであることを示しています。
    - この場合、それは`FFFFFFFFFFFFFF`、つまり`0xFF`が7回繰り返されたものです。
- 最後に、`0x00`が続き、これは`STOP`命令です。
- `0xFE71|01|07|FFFFFFFFFFFFFF|00`

```
0xFE71020100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
```

- ここでも`0xFE71`はマジックヘッダを示します。
- `0x02`はバージョン`0`で、データ長を示すビットが`2`バイトあることを意味します。
- `0100`はデータセクションが`256`バイトであることを示しています。
    - ここではビッグエンディアン形式で長さがエンコードされているため、`0100`は`256`を意味します。
- その後に`256`バイトの`FF`が続きます。
    - これは、`0xFF`が256回繰り返されたデータセクションです。
- 最後に、`0x00`の`STOP`命令があります。
- `0xFE71|02|0100|FF...FF|00`

これらの例は、ブループリントコントラクトの基本的な構造を示しています。マジックヘッダ(`0xFE71`)で始まり、バージョンとデータ長の情報、任意の長さのデータセクション、そして`STOP`命令で終わります。
データセクションはコントラクトの実行時に特定の目的のために使われる任意のデータを含めることができ、この柔軟性によりブループリントコントラクトは多様な用途に使用することが可能です。

## 実装

```python
from typing import Optional, Tuple

def parse_blueprint_preamble(bytecode: bytes) -> Tuple[int, Optional[bytes], bytes]:
    """
    Given bytecode as a sequence of bytes, parse the blueprint preamble and
    deconstruct the bytecode into:
        the ERC version, preamble data and initcode.
    Raises an exception if the bytecode is not a valid blueprint contract
    according to this ERC.
    arguments:
        bytecode: a `bytes` object representing the bytecode
    returns:
        (version,
         None if <length encoding bits> is 0, otherwise the bytes of the data section,
         the bytes of the initcode,
        )
    """
    if bytecode[:2] != b"\xFE\x71":
        raise Exception("Not a blueprint!")

    erc_version = (bytecode[2] & 0b11111100) >> 2

    n_length_bytes = bytecode[2] & 0b11
    if n_length_bytes == 0b11:
        raise Exception("Reserved bits are set")

    data_length = int.from_bytes(bytecode[3:3 + n_length_bytes], byteorder="big")

    if n_length_bytes == 0:
        preamble_data = None
    else:
        data_start = 3 + n_length_bytes
        preamble_data = bytecode[data_start:data_start + data_length]

    initcode = bytecode[3 + n_length_bytes + data_length:]

    if len(initcode) == 0:
        raise Exception("Empty initcode!")

    return erc_version, preamble_data, initcode
```

:::message
このPython関数`parse_blueprint_preamble`は、ブループリントコントラクトのバイトコードを解析し、その構成要素を分解して返します。
具体的には、ERCバージョン、前文データ、そして`initcode`（初期化コード）を抽出します。
ここで、バイトコードはブループリントコントラクトのバイナリ表現です。

1. **バイトコードの検証**
    - 最初に、バイトコードが`\xFE\x71`で始まっているかどうかを確認します。
    - これはブループリントコントラクトのマジックヘッダです。
    - もしこのヘッダがなければ、「**Not a blueprint!**」というエラーメッセージとともに例外を投げます。

2. **ERCバージョンの解析**
    - バイトコードの`3`バイト目から、ERCバージョンを抽出します。
    - これは`6`ビットの値で、バイトの上位`6`ビットに格納されています。
    - バージョンは、そのバイトを右に`2`ビットシフトして、下位`2`ビットを切り捨てることで取得できます。

3. **長さビットの解析**
    - 同じく`3`バイト目の下位`2`ビットを使用して、データセクションの長さをエンコードするために使われるバイト数（`n_length_bytes`）を取得します。
    - もしこの値が予約された`0b11`であれば、例外を投げます。

4. **データセクションの長さの計算**
    - 次の`n_length_bytes`バイトを読み取り、それをビッグエンディアン形式として解釈し、データセクションの長さ（`data_length`）を計算します。

5. **前文データの抽出**
    - `n_length_bytes`が`0`の場合、前文データはありません（`None`）。
    - そうでない場合、`data_length`の長さだけバイトコードからデータセクションを切り出して、`preamble_data`として保存します。

6. **initcodeの抽出**
    - データセクションの後に続くすべてのバイトが`initcode`です。
    - これを`initcode`変数に保存します。
    - もし`initcode`が空（長さが`0`）の場合は、例外を投げます。
    - ブループリントコントラクトには少なくとも`1`バイトの`initcode`が必要だからです。

最後に、関数は`(erc_version, preamble_data, initcode)`という形式のタプルでこれらの情報を返します。
これにより、呼び出し元はブループリントコントラクトの重要な要素にアクセスし、必要に応じてそれらをさらに処理できるようになります。
この関数は、ブループリントコントラクトのバイトコードがこのERCの仕様に従っているかどうかを検証し、解析するための強力なツールです。
:::

以下の参考関数は、ブループリントに必要な`initcode`をパラメータとして受け取り、対応するブループリント契約（データセクションなし）をデプロイするEVMコードを返します。

```python
def blueprint_deployer_bytecode(initcode: bytes) -> bytes:
    blueprint_preamble = b"\xFE\x71\x00"  # ERC5202 preamble
    blueprint_bytecode = blueprint_preamble + initcode

    # the length of the deployed code in bytes
    len_bytes = len(blueprint_bytecode).to_bytes(2, "big")

    # copy <blueprint_bytecode> to memory and `RETURN` it per EVM creation semantics
    # PUSH2 <len> RETURNDATASIZE DUP2 PUSH1 10 RETURNDATASIZE CODECOPY RETURN
    deploy_bytecode = b"\x61" + len_bytes + b"\x3d\x81\x60\x0a\x3d\x39\xf3"

    return deploy_bytecode + blueprint_bytecode
```

## セキュリティ

このERCでは、ブループリントコントラクトとして特定されるための一意の前文`0xFE71`が提案されています。
しかし、理論上は、既にオンチェーン上に存在するコントラクトが偶然にも同じプレフィックスを持っている可能性があります。
つまり、これらのコントラクトはブループリントコントラクトではないにもかかわらず、前文が`0xFE71`で始まるかもしれません。
しかし、このような偶然の一致は深刻なリスクとは見なされていません。

理由は、このERCに基づいてブループリントコントラクトを識別するインデクサー（ブロックチェーン上のデータを整理・索引するシステム）は、単にコードのプレフィックスを見るだけではなく、ソースコードをコンパイルして前文を確認し、それが意図した通りのブループリントコントラクトであるかを検証します。
この検証プロセスにより、偶然の一致は無視され、実際にブループリントコントラクトとして設計されたものだけが認識されます。

さらに、2022年7月8日の時点でEthereumメインネットを調査した結果、`0xFE71`で始まるバイトコードを持つコントラクトは一つも見つかっていません。
これは、提案された前文が現在のところユニークであることを示しており、既存のコントラクトとの衝突の可能性が非常に低いことを意味します。
結果として、この新しい前文を採用することによるリスクは限定的であり、ブループリントコントラクトの識別と使用に関して安全性が保たれると考えられています。

## 引用

Charles Cooper (@charles-cooper), Edward Amor (@skellet0r), "ERC-5202: Blueprint contract format," Ethereum Improvement Proposals, no. 5202, June 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5202.

## 最後に

今回は「コントラクトを簡単に複製できるブループリントコントラクトを利用するための、バイトコードフォーマットを定義している規格である**ERC5202**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58


https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4