TL;DR
In the latest Consensus Layer Call #98, Mikhail Kalinin gave an update on the Engine API Improvement Proposal.
What is Engine API?
Every ethereum node is represented by the two parts, the Consensus Layer part and the Execution Layer part, which communicate via Engine API. Here is a video by the EW Team which can help readers to understand the concept of the Execution Layer and Consensus Layer.
Engine API is an interface that is used for communication between Consensus Layer and Execution Layer. Engine API uses JWT authentication enabled by default.
Here is a video by EW Team on The Merge Transition for the better understanding of the Engine API.
Background
Upcoming Ethereum HardForks will introduce changes to existing Engine API data structures and method semantics. This will also require new methods to be added. Also, there are a few of proposals like Add getPayloadBodiesByRangeV1 and Add engine_newPayloadHeaderV1 to add auxiliary methods for optimization and usability purposes.
Developers also need an easy way of deprecating unused or redundant methods like engine_exchangeTransitionConfigurationV1. This method contains configurable settings of the transition process, i.e., terminalTotalDifficulty, terminalBlockHash & terminalBlockNumber. This method was used during The Merge transition and isn't required anymore. Here is an article by the EW Team on Bellatrix, Paris & TTD for the better understanding of these terms.
This proposal doesn't affect the requirements described in the versioning section of the original specification. This approach makes specification clearer by shaping changes into separate self-contained definitions. CL and EL client implementations are free to maintain versioning of data structures according to their preferences and may utilize the optionality of JSON fields whenever suitable.
Proposed Changes
- A New
engine_getCapsmethod is proposed. The new method returns a list of Engine API methods that are currently supported by the corresponding EL client.engine_newPayloadV1andengine_newPayloadV2should be in the return list if the EL client supports both. This method will not return itself in the list. - Developers have also proposed to deprecate a method as soon as it becomes irrelevant to the protocol. A post-Shanghai HF will introduce V3 of some core methods so it is necessary to deprecate V1 versions of these methods introduced in Paris.
- The following method statuses are proposed:
| Status | Meaning |
|---|---|
| Experimental | Under Development |
| Final | Considered |
| Optional | As Name Suggests |
| Deprecated | No Longer Needed |
- Every method and a new version of a method starts its way with
Experimentalstatus whether it is a new EIP or a method for optimization. Then, it will slowly move towardsOptionalorFinal.
Related Videos
- The Merge Transition
- Ethereum: The Great Renaming
- Proof of Work
- Proof of Stake
- How to Join Kintsugi testnet?
- Kintsugi Fuzzer Issue
- What is Kiln Testnet?
- How to Join Kiln Testnet?
Related Articles
- An overview of expected changes with the Ethereum Merge upgrade
- MEV in DeFi
- Ethereum Mainnet Shadow Forking: An Overview
- What do Bellatrix, Paris & TTD mean in Ethereum Merge Upgrade?
- Ethereum's roadmap for 2022 and beyond!
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!