Align other message names with HookStore rename

Signed-off-by: Michael Tinker <michael.tinker@swirldslabs.com>

Author: tinker-michaelj

HIP/hip-1195.md

@@ -19,11 +19,9 @@ updated: 2025-10-03
 
 We propose **hooks**, programmable Hiero extension points that let users customize the behavior of their entities.
 In principle, hooks could be programmed in any language, but we begin with **EVM hooks**. Users program EVM hooks by
-writing contracts in a language like Solidity that compiles to EVM bytecode. EVM hooks may have optimized variants in
-the future, but we propose first a full-featured **lambda** EVM hook. The name is chosen to evoke event-driven code
-running in the cloud or call other external services. For any given entity, its user can create many hooks for that
-entity with different 64-bit **hook ids**. There is no limit on the number of hook ids than an entity can use; but
-its storage footprint, and hence rent, will increase proportionally.
+writing contracts in a language like Solidity that compiles to EVM bytecode. For any given entity, its user can create
+many hooks for that entity with different 64-bit **hook ids**. There is no limit on the number of hook ids than an
+entity can use; but its storage footprint, and hence rent, will increase proportionally.
 
 As a first Hiero extension point, we propose **account allowance hooks**. Users can create these hooks on their
 accounts, and a Hiero API (HAPI) `CryptoTransfer` transaction can then reference an allowance hook just as it does an
@@ -33,10 +31,10 @@ If the hook function returns `true`, the network continues executing the transfe
 transfer. Creating an account hook is analogous to adding a function to a smart contract: That is, the hook executes
 with the account's privileges when calling Hedera system contracts, just as a smart contract's functions do.
 
-Unlike smart contracts, which must encapsulate trust guarantees for multiple parties, lambda hooks belong to a single
+Unlike smart contracts, which must encapsulate trust guarantees for multiple parties, EVM hooks belong to a single
 owner who can directly update their storage via a new `HookStore` transaction that acts on EVM storage slots. This
-permits fast, heap adjustments to a lambda's behavior with less overhead than a typical `ConsensusSubmitMessage`; and
-far less overhead than a `ContractCall`.
+permits fast, direct adjustments to an EVM hook's behavior with less overhead than a typical `ConsensusSubmitMessage`;
+and far less overhead than a `ContractCall`.
 
 ## Motivation
 
@@ -80,7 +78,7 @@ which are charged purely in gas, hook executions are already "gated" by the fee
 So it makes sense to reduce the intrinsic gas cost of their execution. We propose adding another network property to give
 this effect while keeping it customizable for Hiero network operators.
 ```
-hooks.evm.lambdaIntrinsicGasCost=1000
+hooks.evm.intrinsicGasCost=1000
 ```
 
 ### Rent collection
@@ -93,7 +91,7 @@ At the time of this HIP, rent was not yet enabled on Hedera mainnet, but it is i
 support seamless extension of rent to hooks, we propose to keep in network state two pieces of summary data for each
 entity using hooks:
 1. The number of hooks the entity has; and,
-2. The total number of storage slots used by the entity's lambdas.
+2. The total number of storage slots used by the entity's EVM hooks.
 
 The rent of an entity with `N` hooks using `S` storage slots will then scale linearly with `N` and `S`.
 
@@ -133,18 +131,18 @@ address `0x16d` to the hook's implementing contract. That is, even though the ho
 with a Hiero contract id `0.0.H`, that bytecode _executes_ with a contract address of `0x16d`. If it calls another
 contract and that contract, in turn, calls back to address `0x16d`, then control flow returns to the hook's bytecode.
 
-As a concrete example, suppose a user creates a `ACCOUNT_ALLOWANCE_HOOK` lambda with hook id `1` for account `0.0.A`.
+As a concrete example, suppose a user creates a `ACCOUNT_ALLOWANCE_HOOK` EVM hook with id `1` for account `0.0.A`.
 The hook's implementing contract is `0.0.H` with EVM address `0xab...cd`. Now `0.0.B` with EVM address `0x01...23`
 sends a `CryptoTransfer` transaction that references the hook `0.0.A/1` with gas limit `100_000`.
 
 The network will construct an initial EVM message frame with,
 1. `sender` address `0x01...23`; and,
 2. `receiver` address `0x16d`; and,
 3. `contract` address `0xab...cd` (hence the source of the executing bytecode); and,
-4. Storage of the `0.0.A/1` lambda; and,
+4. Storage of the `0.0.A/1` hook; and,
 5. Gas remaining of `99_000` (lower intrinsic gas cost).
 
-The lambda can then proceed with arbitrary actions, including calls to other contracts, `SLOAD` and `SSTORE` operations
+The hook can then proceed with arbitrary actions, including calls to other contracts, `SLOAD` and `SSTORE` operations
 with its storage, and so on. We expect the most common type of EVM hook contract to implement a single external method
 that reverts when not executed by the network _as a hook_. That is,
 
@@ -197,13 +195,14 @@ EVM programmability without incurring any special risk.
 
 #### Unsupported contexts and EVM operations
 
-Hook executions are not supported in Batch and Scheduled transactions, but hook creations are supported in 
-Batch and Scheduled transactions.
+Hook _executions_ are not supported in batch and scheduled transactions; though hook creations are supported in both.
 
-Hook executions have additional restrictions on EVM opcodes:
+Hook executions have additional restrictions on EVM opcodes, as follows:
 - `CALLCODE` will always fail with halt reason of `INVALID_OPERATION`
 - `DELEGATECALL` will always fail with halt reason of `INVALID_OPERATION` unless its is done in the facade contract of native entity.
-- `SELFDESTRUCT` will always fail with halt reason of `INVALID_OPERATION` if it is done in the frame with address`0x16d`
+- `SELFDESTRUCT` will always fail with halt reason of `INVALID_OPERATION` if it is done in the frame with address `0x16d`
+
+These restrictions are consistent with the existing Hedera EVM security model.
 
 ### Mirror node and block explorer support
 
@@ -233,7 +232,7 @@ Response format:
       "extension_point": "ACCOUNT_ALLOWANCE_HOOK",
       "hook_id": 5,
       "owner_id": "0.0.123",
-      "type": "LAMBDA"
+      "type": "EVM_HOOK"
     }
   ],
   "links": {
@@ -348,35 +347,35 @@ message HookCreationDetails {
      * A hook programmed in EVM bytecode that may access state or interact with
      * external contracts.
      */
-    LambdaEvmHook lambda_evm_hook = 4;
+    EvmHook evm_hook = 4;
   }
 
   /**
    * If set, a key that that can be used to remove or replace the hook; or (if
-   * applicable, as with a lambda EVM hook) perform transactions that customize
-   * the hook.
+   * applicable, as with a EVM hook) perform transactions that customize the hook.
    */
   proto.Key admin_key = 5;
 }
 ```
 
-The `LambdaEvmHook` uses a resuable a `EvmHookSpec` message that specifies the source of the hook's EVM
-bytecode. The `LambdaEvmHook` message also includes the initial storage slots for the lambda, if desired.
+The `EvmHook` uses a resuable a `EvmHookSpec` message that specifies the source of the hook's EVM
+bytecode (in case we ever introduce more specialized EVM hook variants). The `EvmHook` message also
+includes the initial storage slots for the EVM hook, if desired.
 
 ```protobuf
 /**
- * Definition of a lambda EVM hook.
+ * Definition of a EVM hook.
  */
-message LambdaEvmHook {
+message EvmHook {
   /**
    * The specification for the hook.
    */
   EvmHookSpec spec = 1;
 
   /**
-   * Initial storage updates for the lambda, if any.
+   * Initial storage updates for the hook, if any.
    */
-  repeated LambdaStorageUpdate storage_updates = 2;
+  repeated EvmHookStorageUpdate storage_updates = 2;
 }
 
 /**
@@ -395,20 +394,20 @@ message EvmHookSpec {
 }
 
 /**
- * Specifies a key/value pair in the storage of a lambda, either by the explicit storage
+ * Specifies a key/value pair in the storage of an EVM hook, either by the explicit storage
  * slot contents; or by a combination of a Solidity mapping's slot key and the key into
  * that mapping.
  */
-message LambdaStorageUpdate {
+message EvmHookStorageUpdate {
   oneof update {
     /**
      * An explicit storage slot update.
      */
-    LambdaStorageSlot storage_slot = 1;
+    EvmHookStorageSlot storage_slot = 1;
     /**
      * An implicit storage slot update specified as a Solidity mapping entry.
      */
-    LambdaMappingEntry mapping_entry = 2;
+    EvmHookMappingEntry mapping_entry = 2;
   }
 }
 
@@ -424,7 +423,7 @@ message LambdaStorageUpdate {
  * stream consumer following the metaprotocol would have to invert the Keccak256
  * hash to determine which mapping entry was being updated, which is not possible.
  */
-message LambdaMappingEntry {
+message EvmHookMappingEntry {
   /**
    * The slot that corresponds to the Solidity mapping itself.
    */
@@ -444,9 +443,9 @@ message LambdaMappingEntry {
 }
 
 /**
- * A slot in the storage of a lambda EVM hook.
+ * A slot in the storage of an EVM hook.
  */
-message LambdaStorageSlot {
+message EvmHookStorageSlot {
   /**
    * The 32-byte key of the slot; leading zeros may be omitted.
    */
@@ -461,24 +460,24 @@ message LambdaStorageSlot {
 }
 ```
 
-After an entity has a lambda, a new `HookStore` transaction supports efficiently updating the lambda's storage. It
-must be signed by either the entity's controlling key or the admin key set in the lambda's `HookCreationDetails`.
+After an entity has an EVM hook, a new `HookStore` transaction supports directly updating the hook's storage. It
+must be signed by either the entity's controlling key or the admin key set in the hook's `HookCreationDetails`.
 ```protobuf
 /**
- * Adds or removes key/value pairs in the storage of a lambda.
+ * Adds or removes key/value pairs in the storage of an EVM hook.
  * <p>
- * Either the lambda owner's key or the lambda's admin key must sign this transaction.
+ * Either the EVM hook owner's key or the EVM hook's admin key must sign this transaction.
  */
 message HookStoreTransactionBody {
   /**
-   * The id of the lambda whose storage is being updated.
+   * The id of the EVM hook whose storage is being updated.
    */
   CreatedHookId hook_id = 1;
 
   /**
-   * The updates to the storage of the lambda.
+   * The updates to the storage of the EVM hook.
    */
-  repeated LambdaStorageUpdate storage_updates = 2;
+  repeated EvmHookStorageUpdate storage_updates = 2;
 }
 ```
 
@@ -632,9 +631,9 @@ message EvmHookState {
   proto.CreatedHookId hook_id = 1;
 
   /**
-   * The type of the EVM hook.
+   * The type of the hook.
    */
-  EvmHookType type = 2;
+  HookType type = 2;
 
   /**
    * The type of the extension point the hook implements.
@@ -647,7 +646,7 @@ message EvmHookState {
   proto.ContractID hook_contract_id = 4;
 
   /**
-   * For a lambda, its first storage key.
+   * If the hook has num_storage_slots > 0, its first storage key.
    */
   bytes first_contract_storage_key = 5;
 
@@ -664,33 +663,34 @@ message EvmHookState {
   google.protobuf.Int64Value next_hook_id = 7;
 
   /**
-   * The number of storage slots a lambda is using.
+   * The number of storage slots the hook is using.
    */
   uint32 num_storage_slots = 8;
 }
 
 /**
- * The type of an EVM hook.
+ * The type of a hook; currently just general-purpose EVM hooks are supported, but
+ * more types will likely be proposed and added over time.
  */
-enum EvmHookType {
+enum HookType {
   /**
-   * A lambda EVM hook.
+   * A general-purpose EVM hook.
    */
-  LAMBDA = 0;
+  EVM_HOOK = 0;
 }
 ```
 
 And its storage is keyed by the following type,
 ```protobuf
 /**
- * The key of a lambda's storage slot.
+ * The key of an EVM hook's storage slot.
  *
- * For each lambda, its EVM storage is a mapping of 256-bit keys (or "words")
+ * For each EVM hook, its storage is a mapping of 256-bit keys (or "words")
  * to 256-bit values.
  */
-message LambdaSlotKey {
+message EvmHookSlotKey {
   /**
-   * The id of the lambda EVM hook that owns this slot.
+   * The id of the EVM hook that owns this slot.
    */
   proto.CreatedHookId hook_id = 1;
 
@@ -774,7 +774,7 @@ id in a single update transaction. (That is, the `hook_ids_to_delete` list is pr
 `hook_creation_details` list.)
 
 We extend the `Account` message in `TokenService` state to include the number of hooks in use by an account or contract,
-and the total number of storage slots their lambdas use; as well as the id of the last hook in the doubly-linked list of
+and the total number of storage slots their EVM hooks use; as well as the id of the last hook in the doubly-linked list of
 the account or contract's hooks.
 
 ```protobuf
@@ -793,9 +793,9 @@ message Account {
   int64 first_hook_id = 37;
 
   /**
-   * The number of storage slots in use by this account's lambdas.
+   * The number of storage slots in use by this account's EVM hooks.
    */
-  uint64 number_lambda_storage_slots = 38;
+  uint64 number_evm_hook_storage_slots = 38;
 }
 ```
 
@@ -1034,7 +1034,7 @@ sending a NFT from the treasury to account `0.0.X`, and publishing a puzzle. The
 use passcode that allows the solver to collect the NFT held by `0.0.X`.
 
 In particular, the project team creates a custom hook on account `0.0.X` with hook id `1`. It is an account allowance
-lambda EVM hook that references the following contract.
+EVM hook that references the following contract.
 
 ```solidity
 import "./IHieroAccountAllowanceHook.sol";
@@ -1046,9 +1046,9 @@ contract OneTimeCodeTransferAllowance is IHieroAccountAllowanceHook {
     /// Allow the proposed transfers if and only if the args are the
     /// ABI encoding of the current one-time use passcode in storage.
     ///
-    /// NOTE: this lambda's behavior does not depend on what owning
+    /// NOTE: this hook's behavior does not depend on what owning
     /// address is set in `context.owner`; it depends only the contents
-    /// of the active lambda's 0x00 storage slot.
+    /// of the active hook's 0x00 storage slot.
     function allow(
         IHieroHook.HookContext calldata context,
         ProposedTransfers memory proposedTransfers
@@ -1193,10 +1193,10 @@ In progress, please see [here](https://github.com/hiero-ledger/hiero-consensus-n
    Ultimately it seemed better to keep the charging scheme simple and let hooks manage any refunds themselves.
 5. We considered not including the `IHieroAccountAllowancePrePostHook` option, but this left a gap in support for the
    full range of HTS/ERC-20 integrations that Hedera users will likely be interested in.
-6. We considered **pure** EVM hooks with the same conceptual model as lambdas, but with some severe restrictions. The
-   initial EVM frame would be marked `static`, which prohibits all state-changing operations; and we would also disable
-   the `PREVRANDAO`, `SLOAD`, and `CALL` opcodes. Such a hook could not do anything but apply a pure function to its
-   input data; hence pure hook calls could be computed asynchronously, and the results used immediately at consensus.
+6. We considered **pure** EVM hooks with the same conceptual model, but with some severe restrictions. The initial
+   EVM frame would be marked `static`, which prohibits all state-changing operations; and we would also disable the
+   `PREVRANDAO`, `SLOAD`, and `CALL` opcodes. Such a hook could not do anything but apply a pure function to its input
+   data; hence pure hook calls could be computed asynchronously, and the results used immediately at consensus.
    But in light of upcoming general approaches to optimistic concurrent transaction handling, the value of pure hooks
    did not seem worth the added complexity. Nonetheless, the protobufs here are designed to let us add such EVM
    specializations in the future if the calculus changes.