Hooks

[littletarzan]

This is the discussion page for Hooks, or extension points allowing entity id's to customize their behavior. The draft HIP can be found here.

I believe this HIP will greatly benefit network users and Swirlds Labs because it empowers the community to directly write and install custom entity logic that historically Swirlds Labs implemented via individual HIPs.

Abstract

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 are either pure (using neither storage nor external contracts); or lambdas (like code running in a cloud's event-driven compute offering, which may access a database to use state or call other external services). Users can install multiple hooks at different indexes on the same entity, until they reach a configured limit.

As a first Hiero extension point, we propose allowance hooks. Users can install these hooks on their accounts. A Hiero API (HAPI) CryptoTransfer transaction can then reference a hook allowance just as it does an ERC-style allowance defined in HIP-376. The network uses the hook by calling its EVM bytecode at a specific function signature, passing in the details of the transfers proposed in the transaction. If the hook returns true, the network continues executing the transfer; otherwise the network rejects the transfer. Installing a hook on an account is analogous to adding a function to a smart contract; 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, lambdas belong to a single owner who can directly update their storage via a LambdaSStore transaction. This streamlined design supports fast, low-cost adjustments to a lambda with less overhead than a typical ConsensusSubmitMessage; and far less than a ContractCall.