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.

[Chris0x88]

Is this the answer I've been looking for? My dream is to drop the cloud robots, upload my program for say "Bitcoin re-balancing strategy" to a lambda/hook ----- WITHOUT CUSTODIANS and AMM BS ------ ; and just let my cloud based bot fly with the swings of the market. I've got my allocations set in stone for 4 years (either in formula or CSV if we want to get super basic) and the re-balance only depends on current BTC price and datetime. The trigger would do something like auto-trade with a DEX to re-balance... or send out a HCS message for an open-cry style atomic swap to come trade with me.

If this solves to eliminate or rather encapsulate my cloud based robot inside native crypto rails I'd be so happy. In principle what I'm trying to do is the easiest thing in the world with good tech - kill the business models of BlackRock and Vanguard. Can't be that hard!!! Simplest job in the world and it only exists because fee cost at individual account level is too expensive to re-balance.

Last remaining puzzle if this system is actually legit is DEX fees of 0.80% round trip - still too high. We need more affordable markets here on Hedera, and more Bitcoin liquidity... It's the energy of this whole system and always will be. Surely someone can link hooks up with real P2P transfers at the cost of a HCS call + atomic swap fees and we're in business!

Great development, thanks for sharing! Keen to learn more.

[Chris0x88]

Oh follow up... I'm really here because the Ethereum EVM smart contract fees are too high! So hopefully this offers a good alternative in some ways.

[littletarzan]

I believe you are referring to round trip costs of using common DEXes with smart contract enforced swap fees and possibly frontend interface fees. I agree with you that the swap prices are too high in general and not competitive at scale, and I hope this HIP enables a more affordable trading experience.

Another important point is the cost to create, modify and delete hook storage should be much cheaper in this Hook model. Hook storage can be modified directly without involving the significant overhead of an EVM ContractCall. Let's hope the powers that be at Hashgraph price these storage operations appropriately :)

[Chris0x88]

That's a good point I'll take a look into. Duly noted.