### **プリコンパイルされた契約とは何ですか? **プリコンパイルされたコントラクトは、より複雑なライブラリ関数 (通常、暗号化やハッシュなどの複雑な操作に使用される) を提供するために EVM で使用される妥協的な方法であり、オペコードの作成には適さない特別なコントラクトとして理解することもできます。これらは、単純だが頻繁に呼び出されるコントラクト、または論理的には固定されているが計算量が多いコントラクトに適しています。プリコンパイルされたコントラクトはノード クライアント コードを使用して実装され、EVM を必要としないため、高速に実行されます。開発者にとっても、EVM で直接実行される関数を使用するよりもコストが低くなります。次のコードからわかるように、evm.go コントラクトの run 関数には 2 つの分岐があります。最初の分岐は、プリコンパイルされたインデックスを介してインデックス パラメータをインスタンス化してプリコンパイルされたコントラクトを指定し、2 番目の分岐はプリコンパイルされたコントラクトを指定します。プリコンパイルされたコントラクトでない場合はコントラクト その evm が呼び出されます。// run は指定されたコントラクトを実行し、バイト コード インタープリターへのフォールバックでプリコンパイルの実行を処理します。func run(evm *EVM, Contract *Contract, input []byte, readOnly bool) ([]byte, error) {if Contract.CodeAddr != nil {プリコンパイル := PrecompiledContractsHomesteadif evm.ChainConfig().IsByzantium(evm.BlockNumber) {precompiles = PrecompiledContractsByzantium}if p := プリコンパイル[*contract.CodeAddr]; p != nil {return RunPrecompiledContract(p, 入力, コントラクト)}}for _、インタープリター := range evm.interpreters {ifinterpreter.CanRun(contract.Code) {if evm.interpreter != インタープリター {// インタプリタ ポインタが元に戻されていることを確認します// 戻ったときに現在の値に戻ります。defer func(i インタプリタ) {evm.インタープリター = i}(evm.インタープリター)evm.interpreter = インタープリタ}return interpreter.Run(contract, input, readOnly)}}nil を返す、ErrNoCompatibilityInterpreter}具体的なロジックを図で表すと次のようになります。### それでは、プリコンパイルされたコントラクトのボトルネックはどこにあるのでしょうか?イーサリアムには現在、8 つのプリコンパイルされたコントラクトがあります。1. ECRecover - 署名を通じて対応するアドレスを回復します2. SHA256 - SHA256 ハッシュを計算します3. RIPEMD160 - RIPEMD160 ハッシュを計算します。4. ID - 入力データの元の値を返します。5. ModExp - べき乗剰余演算を実行します。6. ECAdd - 楕円曲線点の追加7. ECMul - 楕円曲線点の乗算8. ECPairing - ペアリング操作、楕円曲線点の検証1 番目から 4 番目のプリコンパイル済みコントラクトは基本的な署名、ハッシュ、その他の暗号化関数を提供し、5 番目から 8 番目は zk-snark に関連する楕円曲線演算を提供していることがわかります。そこで疑問なのは、なぜイーサリアムのプリコンパイルは 8 つのプリコンパイル済みコントラクトのみをサポートするのかということです? プリコンパイルされたコントラクトはガス消費量を削減しないのでしょうか?そして、なぜ ECS (チェーン ゲーム全体のフレームワーク) をイーサリアムのプリコンパイル済みコントラクトに直接埋め込まないのでしょうか?実際には、次の 3 つの主な理由があります。1. プリコンパイルされたコントラクトに過度に依存すると、プラットフォーム全体の分散化の度合いが低下します。まず、プリコンパイルされたコントラクトのコードをクライアント ノードのコードに統合する必要がありますが、これによりクライアントの複雑さが増大します。第 2 に、検証ノードはセキュリティ上の理由からプリコンパイルされたコントラクトの計算を除外する可能性があるため、プリコンパイルされたコントラクトのリクエストのほとんどはフル ノードによって完了します。現在、世界中にはイーサリアム フル ノードが 4000 ～ 6000 個しかなく、検証ノードが 500,000 個あります。これは実際、プリコンパイルされていないコントラクトよりもはるかに集中化されています。2. プリコンパイルされたコントラクトの追加や変更にはハードフォークのアップグレードが必要ですが、柔軟に進化させるのは容易ではありません。プリコンパイルされたコントラクトのサポートには EIP プロセスが必要です。例: EIP-196 は、alt\_bn128 曲線に 2 つのプリコンパイルされたコントラクト ECADD() と ECMUL() を追加します。 EIP-197 は、alt\_bn128 曲線にペアリング機能を追加します。基本的に、これはサポートのためにイーサリアム上でプライバシーを利用できるようにすることであり、EIP プロセス全体は長くて洗練されており、EIP が通過するのを待つことは現実的な問題ではありません。3. プリコンパイルされたコントラクトのやり取りや結合が難しく、拡張性が低い。これはあまり説明する必要はなく、非常に直感的です。### プリコンパイルされたコントラクトはチェーン ゲーム全体でどのような役割を果たしますか?プリコンパイルされたコントラクトは EVM をスキップし、ノードを通じて直接実行されるため、コンピューティング効率が向上しますが、同時にチェーン全体の分散化の度合いが低下します。頻繁に使用されるゲームのコア ロジックをプリコンパイルすると、そのようなゲームのパフォーマンスを最適化できます。ゲームの種類が異なれば、キー ロジックも異なります。したがって、特定のタイプのゲームの専用チェーンの場合、そのプリコンパイルされた設計により、このタイプのゲームのニーズを高度に最適化できます。ゲームの反復プロセス中に、最も効率的なプリコンパイルされたコントラクトの組み合わせが徐々に最適化されます。
フルチェーン ゲーム 101: プリコンパイルされたコントラクト
**プリコンパイルされた契約とは何ですか? **
プリコンパイルされたコントラクトは、より複雑なライブラリ関数 (通常、暗号化やハッシュなどの複雑な操作に使用される) を提供するために EVM で使用される妥協的な方法であり、オペコードの作成には適さない特別なコントラクトとして理解することもできます。これらは、単純だが頻繁に呼び出されるコントラクト、または論理的には固定されているが計算量が多いコントラクトに適しています。プリコンパイルされたコントラクトはノード クライアント コードを使用して実装され、EVM を必要としないため、高速に実行されます。開発者にとっても、EVM で直接実行される関数を使用するよりもコストが低くなります。
次のコードからわかるように、evm.go コントラクトの run 関数には 2 つの分岐があります。最初の分岐は、プリコンパイルされたインデックスを介してインデックス パラメータをインスタンス化してプリコンパイルされたコントラクトを指定し、2 番目の分岐はプリコンパイルされたコントラクトを指定します。プリコンパイルされたコントラクトでない場合はコントラクト その evm が呼び出されます。
// run は指定されたコントラクトを実行し、バイト コード インタープリターへのフォールバックでプリコンパイルの実行を処理します。 func run(evm *EVM, Contract *Contract, input []byte, readOnly bool) ([]byte, error) { if Contract.CodeAddr != nil { プリコンパイル := PrecompiledContractsHomestead if evm.ChainConfig().IsByzantium(evm.BlockNumber) { precompiles = PrecompiledContractsByzantium } if p := プリコンパイル[*contract.CodeAddr]; p != nil { return RunPrecompiledContract(p, 入力, コントラクト) } } for _、インタープリター := range evm.interpreters { ifinterpreter.CanRun(contract.Code) { if evm.interpreter != インタープリター { // インタプリタ ポインタが元に戻されていることを確認します // 戻ったときに現在の値に戻ります。 defer func(i インタプリタ) { evm.インタープリター = i }(evm.インタープリター) evm.interpreter = インタープリタ } return interpreter.Run(contract, input, readOnly) } } nil を返す、ErrNoCompatibilityInterpreter }
具体的なロジックを図で表すと次のようになります。
それでは、プリコンパイルされたコントラクトのボトルネックはどこにあるのでしょうか?
イーサリアムには現在、8 つのプリコンパイルされたコントラクトがあります。
1 番目から 4 番目のプリコンパイル済みコントラクトは基本的な署名、ハッシュ、その他の暗号化関数を提供し、5 番目から 8 番目は zk-snark に関連する楕円曲線演算を提供していることがわかります。
そこで疑問なのは、なぜイーサリアムのプリコンパイルは 8 つのプリコンパイル済みコントラクトのみをサポートするのかということです? プリコンパイルされたコントラクトはガス消費量を削減しないのでしょうか?そして、なぜ ECS (チェーン ゲーム全体のフレームワーク) をイーサリアムのプリコンパイル済みコントラクトに直接埋め込まないのでしょうか?
実際には、次の 3 つの主な理由があります。
まず、プリコンパイルされたコントラクトのコードをクライアント ノードのコードに統合する必要がありますが、これによりクライアントの複雑さが増大します。第 2 に、検証ノードはセキュリティ上の理由からプリコンパイルされたコントラクトの計算を除外する可能性があるため、プリコンパイルされたコントラクトのリクエストのほとんどはフル ノードによって完了します。現在、世界中にはイーサリアム フル ノードが 4000 ～ 6000 個しかなく、検証ノードが 500,000 個あります。これは実際、プリコンパイルされていないコントラクトよりもはるかに集中化されています。
プリコンパイルされたコントラクトのサポートには EIP プロセスが必要です。例: EIP-196 は、alt_bn128 曲線に 2 つのプリコンパイルされたコントラクト ECADD() と ECMUL() を追加します。 EIP-197 は、alt_bn128 曲線にペアリング機能を追加します。基本的に、これはサポートのためにイーサリアム上でプライバシーを利用できるようにすることであり、EIP プロセス全体は長くて洗練されており、EIP が通過するのを待つことは現実的な問題ではありません。
これはあまり説明する必要はなく、非常に直感的です。
プリコンパイルされたコントラクトはチェーン ゲーム全体でどのような役割を果たしますか?
プリコンパイルされたコントラクトは EVM をスキップし、ノードを通じて直接実行されるため、コンピューティング効率が向上しますが、同時にチェーン全体の分散化の度合いが低下します。頻繁に使用されるゲームのコア ロジックをプリコンパイルすると、そのようなゲームのパフォーマンスを最適化できます。ゲームの種類が異なれば、キー ロジックも異なります。したがって、特定のタイプのゲームの専用チェーンの場合、そのプリコンパイルされた設計により、このタイプのゲームのニーズを高度に最適化できます。ゲームの反復プロセス中に、最も効率的なプリコンパイルされたコントラクトの組み合わせが徐々に最適化されます。