shorten title and description

EIPS/eip-7851.md

@@ -1,7 +1,7 @@
 ---
 eip: 7851
-title: Private key deactivation and reactivation of EOAs with delegated code
-description: Introduce a new precompiled contract that enables Externally Owned Accounts (EOAs) with delegated code to deactivate and reactivate their private keys.
+title: EOA private key deactivation/reactivation
+description: Introduce a precompiled contract for EOAs with delegated code to deactivate/reactivate private keys.
 author: Liyi Guo (@colinlyguo)
 discussions-to: https://ethereum-magicians.org/t/eip-7851-private-key-deactivation-and-reactivation-of-eoas-with-delegated-code/22344
 status: Draft
@@ -13,7 +13,7 @@
 
 ## Abstract
 
-This EIP introduces a precompiled contract that enables EOAs with delegated control to smart contracts via [EIP-7702](./eip-7702) to deactivate/reactivate their private keys. This design does not require additional storage fields or account state changes. By leveraging delegated code, reactivation can be performed securely through mechanisms such as social recovery.
+This EIP introduces a precompiled contract that enables Externally Owned Accounts (EOAs) with delegated control to smart contracts via [EIP-7702](./eip-7702) to deactivate/reactivate their private keys. This design does not require additional storage fields or account state changes. By leveraging delegated code, reactivation can be performed securely through mechanisms such as social recovery.
 
 ## Motivation
 
@@ -42,39 +42,39 @@
 ### Precompiled contract
 
 A new precompiled contract is introduced at address `PRECOMPILE_ADDRESS`. For each call, it consumes `PRECOMPILE_GAS_COST` gas, and the precompiled contract executes the following steps:
 - The precompiled contract checks that the caller is an EOA with delegated code (i.e., its account code begins with the prefix `0xef0100`, as defined in [EIP-7702](./eip-7702)). If the code does not conform to the required prefix, the contract MUST terminate without making any state changes.
 - The precompile determines the current state of the delegated code based on its byte length:
     - If the delegated code is 24 bytes (`0xef0100 || address || 0x00`), it removes the last byte (`0x00`), transitioning to the active state (`0xef0100 || address`).
     - If the delegated code is 23 bytes (`0xef0100 || address`), it appends `0x00`, transitioning to the deactivated state (`0xef0100 || address || 0x00`).
 - The updated delegated code is saved as the new account code for the EOA.
 
 
 ### Transaction validation
 If the account is verified as an EOA with a delegated code (begins with the prefix `0xef0100`), transactions signed by the private key MUST be rejected if the delegated code is in the deactivated state (i.e., `24` bytes long).
 
 ### Gas cost
 No changes to the base transaction gas cost (`21000`) are required, as the additional valid check for the deactivation status is minimal compared with [EIP-7702](./eip-7702) transactions. Thus it is reasonable to include them in the base gas cost.
 
 ## Rationale
 
 ### Using a precompiled contract
 Alternative methods for implementing this feature include:
 - Adding a new transaction type: A new transaction type could deactivate/reactive EOA private keys. This would complicate reactivation, as the contract would need to serve as the authorizer for reactivation, increasing protocol complexity.
 - Deploying a regular smart contract: A regular deployed contract could track the `deactivated` status of each `address`. This approach would break the base transaction gas cost of `21000` in transaction validation, as accessing the `deactivated` status would require additional address and storage lookups, increasing gas usage.
 
 ### In-protocol reactivation
 This approach ensures maximum compatibility with future migrations. EOAs can reactivate their private keys, delegate their accounts to an [EIP-7701](./eip7701) contract, and then deactivate their private keys again. This avoids the limitations of upgradable contracts. e.g., to remove legacy proxy contracts when EOF contracts become available, thereby reducing gas overhead, one can reactivate the EOA and delegate to an EOF proxy contract.
 
 ### `5000` Gas `PRECOMPILE_GAS_COST`
 The `5000` gas cost is sufficient to cover validation, computation, and storage updates for the delegated code.
 
 ### Alternative EOA migration approach
 One alternative migration approach involves using a hard fork to edit all existing and new EOAs to upgradable smart contracts using EOA's ECDSA signatures. Users can then upgrade these smart contracts to achieve more granular permission control. However, this approach is incompatible with EOAs that have already delegated to smart contracts, as it overwrites the existing smart contract implementations. The EIP aims to fill this migration gap.
 
 ### Avoiding delegated code prefix modification
 This EIP appends a byte (`0x00`) to the delegated code instead of modifying the prefix (`0xef0100`) of [EIP-7702](./eip-7702) to ensure forward compatibility. If future prefixes such as `0xef0101` are introduced, changing the prefix (e.g., to `0xef01ff`) makes it unclear which prefix to restore upon reactivation.
 
 ### Avoiding account state changes
 Another alternative is to add a new field to the account state to store the `deactivated` status. However, this approach complicates the account state. It also brings changes in the account trie structure and RLP encoding used in networking, which complicates the implementation.
 
 ### Forwards compatibility for removing EOAs