TL;DR

What is Engine API?
Background
Proposed Changes

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_getCaps method is proposed. The new method returns a list of Engine API methods that are currently supported by the corresponding EL client. engine_newPayloadV1 and engine_newPayloadV2 should 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 Experimental status whether it is a new EIP or a method for optimization. Then, it will slowly move towards Optional or Final.