# イーサリアム Pectra アップグレードと EIP-7702: EOA とコントラクトアカウントの境界を曖昧にする重要なステップ## イントロダクションイーサリアムはまもなくPectraアップグレードを迎えます。これは重要な更新であり、いくつかの重要なイーサリアム改善提案が導入されます。その中で、EIP-7702はイーサリアム外部アカウント(EOA)に対して画期的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、EIP-4337に続く原生アカウント抽象化に向けた重要なステップであり、イーサリアムエコシステムに全く新しいインタラクションモデルをもたらします。Pectraはテストネットでの展開を完了し、近日中にメインネットにローンチされる予定です。この記事ではEIP-7702の実装メカニズムを深く分析し、それがもたらす可能性のある機会と課題を探り、さまざまな参加者に実用的な操作ガイドを提供します。## プロトコル分析###概要EIP-7702は新しいトランザクションタイプを導入し、EOAがスマートコントラクトアドレスを指定してコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行できると同時に、トランザクションを開始する能力を保持します。この機能はEOAにプログラム可能性とコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、マルチサイン管理、zk検証、サブスクリプション型支払い、トランザクションスポンサーシップ、トランザクションバッチ処理などの機能を実現できます。EIP-7702はEIP-4337が実現するスマートコントラクトウォレットと完全に互換性があり、両者のシームレスな統合は新機能の開発と適用プロセスを大幅に簡素化します。EIP-7702は、取引タイプSET_CODE_TX_TYPE (0x04)の取引を導入し、そのデータ構造は以下のように定義されています:rlp([chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s])その authorization_list フィールドは次のように定義されています:authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]新しい取引構造では、authorization_list フィールドを除いて、他は EIP-4844 と同じ意味に従います。このフィールドはリスト型であり、複数の承認エントリを含むことができ、各承認エントリには次のものが含まれます。- chain_id:この委任が有効になるチェーン- 住所:代理店の目的地住所- nonce:現在の承認されたアカウントの nonce と一致する必要があります- y_parity, r, s: アカウントが権限を持つ署名データに署名します一つのトランザクション内の authorization_list フィールドには、複数の異なるアカウント ( EOA ) によって署名された権限項目を含めることができます。トランザクションの発起者は、権限者とは異なる場合があり、権限者に対するガス代の支払いを実現できます。###実装承認者が承認データに署名する際は、まず chain_id、address、nonce を RLP エンコードする必要があります。次に、エンコードされたデータを MAGIC 数と一緒に keccak256 ハッシュ演算を行い、署名待ちのデータを得ます。最後に、承認者の秘密鍵を使用してハッシュされたデータに署名し、y_parity、r、s データを取得します。MAGIC (0x05) はドメインセパレーターとして使用され、異なるタイプの署名の結果が衝突しないようにします。当授权者授权の chain_id が 0 の場合、これは授权者がすべての EIP-7702 をサポートする EVM 互換チェーン上での授权(のリプレイを許可することを示し、前提として nonce もちょうど一致する)であることが求められます。権限者が権限データに署名した後、取引の発起者はそれを authorization_list フィールドに集約して署名し、RPC を介して取引をブロードキャストします。取引がブロックに含まれて実行される前に、Proposer はまず取引を事前チェックし、to アドレスを強制的にチェックしてこの取引が契約作成取引ではないことを確認します。つまり、EIP-7702 型取引を送信する際、取引の to アドレスは空であってはなりません。同時に、このような取引では authorization_list フィールドに少なくとも1つの承認項目が含まれている必要があります。もし複数の承認項目が同じ承認者によって署名されている場合、最終的には最後の承認項目のみが有効になります。トランザクション実行プロセス中、ノードは最初にトランザクション・イニシエータのnonce値を増やし、次にauthorization_listの各認証エントリに対してapplyAuthorization操作を実行します。 applyAuthorization操作では、ノードはオーソライザーのnonceをチェックし、オーソライザーのnonceをインクリメントします。 つまり、トランザクションのオリジネーターとオーソライザーが同じユーザーである場合(EOA)認証トランザクションに署名するときにnonceの値を1ずつ加算する必要があります。ノードが特定の承認項目を適用する際に、何らかのエラーが発生した場合、その承認項目はスキップされ、トランザクションは失敗しません。他の承認項目は引き続き適用され、バッチ承認のシナリオでDoSリスクが発生しないようにします。アプリケーションの承認が完了すると、承認者のアドレスの code フィールドは 0xef0100 || address に設定されます。このとき、0xef0100 は固定識別子で、address は委託先のアドレスです。EIP-3541 の制限により、ユーザーは通常の方法で 0xef バイトで始まるコントラクトコードをデプロイすることができません。これにより、このような識別子は SET_CODE_TX_TYPE ( 0x04) タイプのトランザクションによってのみデプロイされることが保証されます。承認が完了した後、承認者が承認を解除したい場合は、委託先のアドレスを0アドレスに設定するだけです。EIP-7702によって導入された新しいトランザクションタイプにより、許可者(EOA)は、スマートコントラクトのようにコードを実行できると同時に、トランザクションを開始する能力も保持しています。EIP-4337と比較して、これはユーザーによりネイティブアカウント抽象(Native AA)に近い体験を提供し、ユーザーの使用ハードルを大幅に下げました。## ベストプラクティスEIP-7702がイーサリアムエコシステムに新たな活力を注入したにもかかわらず、新しいアプリケーションのシナリオは新たなリスクをもたらすこともあります。以下は、エコシステムの参加者が実践の過程で注意すべき点です:### 秘密鍵の保管EOAが委任された後、スマートコントラクトに組み込まれたソーシャルリカバリーなどの手段を使って、秘密鍵の喪失による資金損失問題を解決できるとしても、EOAの秘密鍵が漏洩するリスクを回避することはできません。委任を実行した後も、EOAの秘密鍵はアカウントに対して最高の制御権を保持していることを明確にする必要があります。秘密鍵を持っていれば、アカウント内の資産を自由に処分することができます。ユーザーやウォレットサービスプロバイダーがEOAの委任を完了した後、ローカルに保存されている秘密鍵を完全に削除しても、秘密鍵の漏洩リスクを完全に排除することはできません。特にサプライチェーン攻撃のリスクが存在するシナリオではなおさらです。ユーザーにとって、委託後のアカウントを使用する際には、引き続き秘密鍵の保護を最優先にし、常に注意すること: Not your keys, not your coins。### マルチチェーンリプレイユーザーは委任の権限を署名する際に、chainIdを通じて委任が有効となるチェーンを選択することができ、またchainIdを0に設定して委任を行うことも可能です。これにより、ユーザーは一度の署名で複数のチェーンで委任を行うことができるようになります。ただし、複数のチェーンで委任する同一のコントラクトアドレスには、異なる実装コードが存在する可能性があることに注意が必要です。ウォレットサービスプロバイダーは、ユーザーが委託を行う際に、委託の有効チェーンと現在接続しているネットワークが一致しているか確認し、chainIdが0の委託を署名することによるリスクをユーザーに警告すべきです。ユーザーはまた、異なるチェーン上の同じコントラクトアドレスでは、そのコントラクトコードが常に同じであるとは限らないことに注意する必要があります。委託の目的を事前に理解するべきです。### 初期化できません現在主流のスマートコントラクトウォレットの多くは、プロキシモデルを採用しています。ウォレットプロキシはデプロイ時に、DELEGateCALLを通じてコントラクトの初期化関数を呼び出し、ウォレットの初期化とプロキシウォレットのデプロイメントの原子操作を実現し、先に初期化される問題を避けます。しかし、ユーザーがEIP-7702を使用して委任する際には、アドレスのcodeフィールドのみが更新され、委任アドレスを呼び出して初期化することができません。これにより、EIP-7702は一般的なERC-1967プロキシコントラクトのように、コントラクトデプロイメントのトランザクション内で初期化関数を呼び出してウォレットを初期化することができません。開発者にとって、EIP-7702を既存のEIP-4337ウォレットと組み合わせて適応させる際には、ウォレットの初期化操作において権限チェックを行うことに注意すべきです(。例えば、ecrecoverを通じて署名アドレスを復元し、権限チェックを行うことが重要です)。このようにすることで、ウォレットの初期化操作が奪われるリスクを回避できます。### ストレージ管理ユーザーがEIP-7702委任機能を使用する際、機能要求の変更やウォレットのアップグレードなどの理由で、異なるコントラクトアドレスに再委任する必要が生じる可能性があります。しかし、異なるコントラクトのストレージ構造には違いがある場合があります(例えば、異なるコントラクトのslot0スロットは異なる種類のデータを表す可能性があります)再委任の場合、旧コントラクトのデータが新コントラクトで意図せず再利用される可能性があり、その結果、アカウントのロックや資金の損失などの悪影響を引き起こす可能性があります。ユーザーにとって、再委託の状況には慎重に対処すべきです。開発者にとって、開発プロセスではERC-7201が提案するNamespace Formulaに従い、変数を指定された独立したストレージ位置に割り当てることで、ストレージの衝突リスクを軽減する必要があります。さらに、ERC-7779 (draft)はEIP-7702のために再委託の標準プロセスを提供しています：ストレージの衝突を防ぐためにERC-7201を使用し、再委託の前にストレージの互換性を検証し、古い委託のインターフェースを呼び出してストレージの古いデータをクリーンアップします。### 偽チャージユーザーが委託を行った後、EOAもスマートコントラクトとして使用できるようになります。したがって、取引所(CEX)は、スマートコントラクトの充電が一般化する状況に直面する可能性があります。CEX は trace を通じて各リチャージトランザクションの状態を確認し、スマートコントラクトの偽リチャージリスクを防ぐべきです。### アカウント変換EIP-7702の委任を実施した後、ユーザーのアカウントタイプはEOAとSCの間で自由に変換できるようになり、アカウントは取引を開始することも、呼び出されることも可能になります。つまり、アカウントが自分自身を呼び出し、外部呼び出しを行うと、そのmsg.senderもtx.originになるため、EOAのみがプロジェクトに参加するというセキュリティ仮定が破られることになります。コントラクト開発者にとって、tx.origin が常に EOA であると仮定することはもはや実行可能ではありません。同様に、msg.sender == tx.origin をチェックして再入攻撃を防ぐことも無効になります。開発者は開発過程で将来の参加者がすべてスマートコントラクトであると仮定すべきである。### コントラクトの互換性現在のERC-721、ERC-777トークンは、コントラクトに対する転送時にHook機能を持っています。これは、受信者がトークンを正常に受信するために対応するコールバック関数を実装する必要があることを意味します。開発者にとって、ユーザーが委託したターゲットコントラクトは、主流トークンと互換性を持つことを確保するために、適切なコールバック関数を実装するべきです。### フィッシングチェックEIP-7702の委任を実施した後、ユーザーアカウント内の資産はすべてスマートコントラクトによって制御される可能性があります。一旦ユーザーがアカウントを悪意のあるコントラクトに委任すると、攻撃者が資金を盗むことが容易になります。ウォレットサービスプロバイダーにとって、できるだけ早くEIP-7702タイプの取引をサポートすることが非常に重要であり、ユーザーが委任署名を行う際には、ユーザーに委任先のコントラクトを強調して表示し、ユーザーがフィッシング攻撃に遭うリスクを軽減する必要があります。さらに、アカウント委託の対象契約に対するより深い自動分析(オープンソースチェック、権限チェックなど)は、ユーザーがそのようなリスクを回避するのに役立ちます。## まとめ本稿は、イーサリアムの間もなく行われるPectraアップグレードにおけるEIP-7702提案について探討します。EIP-7702は新しい取引タイプを導入することで、EOAにプログラム可能性とコンポーザビリティを持たせ、EOAと契約アカウントの境界を曖昧にしました。現在、実戦で検証されたEIP-7702タイプのスマートコントラクト標準は存在しないため、実際の応用においては、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなどのさまざまなエコシステム参加者が多くの課題と機会に直面しています。本稿で説明されるベストプラクティスの内容は、すべての潜在的なリスクをカバーすることはできませんが、実際の操作において各方面が参考にして応用する価値があります。
EIP-7702: イーサリアムアカウントの抽象化新章 モラルEOAと契約の境界
イーサリアム Pectra アップグレードと EIP-7702: EOA とコントラクトアカウントの境界を曖昧にする重要なステップ
イントロダクション
イーサリアムはまもなくPectraアップグレードを迎えます。これは重要な更新であり、いくつかの重要なイーサリアム改善提案が導入されます。その中で、EIP-7702はイーサリアム外部アカウント(EOA)に対して画期的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、EIP-4337に続く原生アカウント抽象化に向けた重要なステップであり、イーサリアムエコシステムに全く新しいインタラクションモデルをもたらします。
Pectraはテストネットでの展開を完了し、近日中にメインネットにローンチされる予定です。この記事ではEIP-7702の実装メカニズムを深く分析し、それがもたらす可能性のある機会と課題を探り、さまざまな参加者に実用的な操作ガイドを提供します。
プロトコル分析
###概要
EIP-7702は新しいトランザクションタイプを導入し、EOAがスマートコントラクトアドレスを指定してコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行できると同時に、トランザクションを開始する能力を保持します。この機能はEOAにプログラム可能性とコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、マルチサイン管理、zk検証、サブスクリプション型支払い、トランザクションスポンサーシップ、トランザクションバッチ処理などの機能を実現できます。EIP-7702はEIP-4337が実現するスマートコントラクトウォレットと完全に互換性があり、両者のシームレスな統合は新機能の開発と適用プロセスを大幅に簡素化します。
EIP-7702は、取引タイプSET_CODE_TX_TYPE (0x04)の取引を導入し、そのデータ構造は以下のように定義されています:
rlp([chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s])
その authorization_list フィールドは次のように定義されています:
authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]
新しい取引構造では、authorization_list フィールドを除いて、他は EIP-4844 と同じ意味に従います。このフィールドはリスト型であり、複数の承認エントリを含むことができ、各承認エントリには次のものが含まれます。
一つのトランザクション内の authorization_list フィールドには、複数の異なるアカウント ( EOA ) によって署名された権限項目を含めることができます。トランザクションの発起者は、権限者とは異なる場合があり、権限者に対するガス代の支払いを実現できます。
###実装
承認者が承認データに署名する際は、まず chain_id、address、nonce を RLP エンコードする必要があります。次に、エンコードされたデータを MAGIC 数と一緒に keccak256 ハッシュ演算を行い、署名待ちのデータを得ます。最後に、承認者の秘密鍵を使用してハッシュされたデータに署名し、y_parity、r、s データを取得します。MAGIC (0x05) はドメインセパレーターとして使用され、異なるタイプの署名の結果が衝突しないようにします。
当授权者授权の chain_id が 0 の場合、これは授权者がすべての EIP-7702 をサポートする EVM 互換チェーン上での授权(のリプレイを許可することを示し、前提として nonce もちょうど一致する)であることが求められます。
権限者が権限データに署名した後、取引の発起者はそれを authorization_list フィールドに集約して署名し、RPC を介して取引をブロードキャストします。取引がブロックに含まれて実行される前に、Proposer はまず取引を事前チェックし、to アドレスを強制的にチェックしてこの取引が契約作成取引ではないことを確認します。つまり、EIP-7702 型取引を送信する際、取引の to アドレスは空であってはなりません。
同時に、このような取引では authorization_list フィールドに少なくとも1つの承認項目が含まれている必要があります。もし複数の承認項目が同じ承認者によって署名されている場合、最終的には最後の承認項目のみが有効になります。
トランザクション実行プロセス中、ノードは最初にトランザクション・イニシエータのnonce値を増やし、次にauthorization_listの各認証エントリに対してapplyAuthorization操作を実行します。 applyAuthorization操作では、ノードはオーソライザーのnonceをチェックし、オーソライザーのnonceをインクリメントします。 つまり、トランザクションのオリジネーターとオーソライザーが同じユーザーである場合(EOA)認証トランザクションに署名するときにnonceの値を1ずつ加算する必要があります。
ノードが特定の承認項目を適用する際に、何らかのエラーが発生した場合、その承認項目はスキップされ、トランザクションは失敗しません。他の承認項目は引き続き適用され、バッチ承認のシナリオでDoSリスクが発生しないようにします。
アプリケーションの承認が完了すると、承認者のアドレスの code フィールドは 0xef0100 || address に設定されます。このとき、0xef0100 は固定識別子で、address は委託先のアドレスです。EIP-3541 の制限により、ユーザーは通常の方法で 0xef バイトで始まるコントラクトコードをデプロイすることができません。これにより、このような識別子は SET_CODE_TX_TYPE ( 0x04) タイプのトランザクションによってのみデプロイされることが保証されます。
承認が完了した後、承認者が承認を解除したい場合は、委託先のアドレスを0アドレスに設定するだけです。
EIP-7702によって導入された新しいトランザクションタイプにより、許可者(EOA)は、スマートコントラクトのようにコードを実行できると同時に、トランザクションを開始する能力も保持しています。EIP-4337と比較して、これはユーザーによりネイティブアカウント抽象(Native AA)に近い体験を提供し、ユーザーの使用ハードルを大幅に下げました。
ベストプラクティス
EIP-7702がイーサリアムエコシステムに新たな活力を注入したにもかかわらず、新しいアプリケーションのシナリオは新たなリスクをもたらすこともあります。以下は、エコシステムの参加者が実践の過程で注意すべき点です:
秘密鍵の保管
EOAが委任された後、スマートコントラクトに組み込まれたソーシャルリカバリーなどの手段を使って、秘密鍵の喪失による資金損失問題を解決できるとしても、EOAの秘密鍵が漏洩するリスクを回避することはできません。委任を実行した後も、EOAの秘密鍵はアカウントに対して最高の制御権を保持していることを明確にする必要があります。秘密鍵を持っていれば、アカウント内の資産を自由に処分することができます。ユーザーやウォレットサービスプロバイダーがEOAの委任を完了した後、ローカルに保存されている秘密鍵を完全に削除しても、秘密鍵の漏洩リスクを完全に排除することはできません。特にサプライチェーン攻撃のリスクが存在するシナリオではなおさらです。
ユーザーにとって、委託後のアカウントを使用する際には、引き続き秘密鍵の保護を最優先にし、常に注意すること: Not your keys, not your coins。
マルチチェーンリプレイ
ユーザーは委任の権限を署名する際に、chainIdを通じて委任が有効となるチェーンを選択することができ、またchainIdを0に設定して委任を行うことも可能です。これにより、ユーザーは一度の署名で複数のチェーンで委任を行うことができるようになります。ただし、複数のチェーンで委任する同一のコントラクトアドレスには、異なる実装コードが存在する可能性があることに注意が必要です。
ウォレットサービスプロバイダーは、ユーザーが委託を行う際に、委託の有効チェーンと現在接続しているネットワークが一致しているか確認し、chainIdが0の委託を署名することによるリスクをユーザーに警告すべきです。
ユーザーはまた、異なるチェーン上の同じコントラクトアドレスでは、そのコントラクトコードが常に同じであるとは限らないことに注意する必要があります。委託の目的を事前に理解するべきです。
初期化できません
現在主流のスマートコントラクトウォレットの多くは、プロキシモデルを採用しています。ウォレットプロキシはデプロイ時に、DELEGateCALLを通じてコントラクトの初期化関数を呼び出し、ウォレットの初期化とプロキシウォレットのデプロイメントの原子操作を実現し、先に初期化される問題を避けます。しかし、ユーザーがEIP-7702を使用して委任する際には、アドレスのcodeフィールドのみが更新され、委任アドレスを呼び出して初期化することができません。これにより、EIP-7702は一般的なERC-1967プロキシコントラクトのように、コントラクトデプロイメントのトランザクション内で初期化関数を呼び出してウォレットを初期化することができません。
開発者にとって、EIP-7702を既存のEIP-4337ウォレットと組み合わせて適応させる際には、ウォレットの初期化操作において権限チェックを行うことに注意すべきです(。例えば、ecrecoverを通じて署名アドレスを復元し、権限チェックを行うことが重要です)。このようにすることで、ウォレットの初期化操作が奪われるリスクを回避できます。
ストレージ管理
ユーザーがEIP-7702委任機能を使用する際、機能要求の変更やウォレットのアップグレードなどの理由で、異なるコントラクトアドレスに再委任する必要が生じる可能性があります。しかし、異なるコントラクトのストレージ構造には違いがある場合があります(例えば、異なるコントラクトのslot0スロットは異なる種類のデータを表す可能性があります)再委任の場合、旧コントラクトのデータが新コントラクトで意図せず再利用される可能性があり、その結果、アカウントのロックや資金の損失などの悪影響を引き起こす可能性があります。
ユーザーにとって、再委託の状況には慎重に対処すべきです。
開発者にとって、開発プロセスではERC-7201が提案するNamespace Formulaに従い、変数を指定された独立したストレージ位置に割り当てることで、ストレージの衝突リスクを軽減する必要があります。さらに、ERC-7779 (draft)はEIP-7702のために再委託の標準プロセスを提供しています：ストレージの衝突を防ぐためにERC-7201を使用し、再委託の前にストレージの互換性を検証し、古い委託のインターフェースを呼び出してストレージの古いデータをクリーンアップします。
偽チャージ
ユーザーが委託を行った後、EOAもスマートコントラクトとして使用できるようになります。したがって、取引所(CEX)は、スマートコントラクトの充電が一般化する状況に直面する可能性があります。
CEX は trace を通じて各リチャージトランザクションの状態を確認し、スマートコントラクトの偽リチャージリスクを防ぐべきです。
アカウント変換
EIP-7702の委任を実施した後、ユーザーのアカウントタイプはEOAとSCの間で自由に変換できるようになり、アカウントは取引を開始することも、呼び出されることも可能になります。つまり、アカウントが自分自身を呼び出し、外部呼び出しを行うと、そのmsg.senderもtx.originになるため、EOAのみがプロジェクトに参加するというセキュリティ仮定が破られることになります。
コントラクト開発者にとって、tx.origin が常に EOA であると仮定することはもはや実行可能ではありません。同様に、msg.sender == tx.origin をチェックして再入攻撃を防ぐことも無効になります。
開発者は開発過程で将来の参加者がすべてスマートコントラクトであると仮定すべきである。
コントラクトの互換性
現在のERC-721、ERC-777トークンは、コントラクトに対する転送時にHook機能を持っています。これは、受信者がトークンを正常に受信するために対応するコールバック関数を実装する必要があることを意味します。
開発者にとって、ユーザーが委託したターゲットコントラクトは、主流トークンと互換性を持つことを確保するために、適切なコールバック関数を実装するべきです。
フィッシングチェック
EIP-7702の委任を実施した後、ユーザーアカウント内の資産はすべてスマートコントラクトによって制御される可能性があります。一旦ユーザーがアカウントを悪意のあるコントラクトに委任すると、攻撃者が資金を盗むことが容易になります。
ウォレットサービスプロバイダーにとって、できるだけ早くEIP-7702タイプの取引をサポートすることが非常に重要であり、ユーザーが委任署名を行う際には、ユーザーに委任先のコントラクトを強調して表示し、ユーザーがフィッシング攻撃に遭うリスクを軽減する必要があります。
さらに、アカウント委託の対象契約に対するより深い自動分析(オープンソースチェック、権限チェックなど)は、ユーザーがそのようなリスクを回避するのに役立ちます。
まとめ
本稿は、イーサリアムの間もなく行われるPectraアップグレードにおけるEIP-7702提案について探討します。EIP-7702は新しい取引タイプを導入することで、EOAにプログラム可能性とコンポーザビリティを持たせ、EOAと契約アカウントの境界を曖昧にしました。現在、実戦で検証されたEIP-7702タイプのスマートコントラクト標準は存在しないため、実際の応用においては、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなどのさまざまなエコシステム参加者が多くの課題と機会に直面しています。本稿で説明されるベストプラクティスの内容は、すべての潜在的なリスクをカバーすることはできませんが、実際の操作において各方面が参考にして応用する価値があります。