Hooks are small, efficient web assembly modules designed specifically for the XRPL. Hooks can be written in any language (compilable to WebAssembly) and most business logic and most smart contract concepts can be implemented in a hook.
Hooks are set onto an XRPL account using a SetHook transaction. Once installed on an account, a hook can:
- Block or allow incoming and outgoing transactions on the account.
- Modify and maintain internal state and logic specific to the hook on that account.
- Emit new transactions on behalf of the account.
Hooks are deliberately not Turing-Complete. While often touted as the holy grail of smart contracts, Turing-Completeness is actually inappropriate for smart contracts. The Halting Problem describes the mathematical impossibility of predicting whether an arbitrary program will halt or run forever on a Turing-Complete system. Obviously this is undesirable, as we need to be able to determine ahead of time when a smart contract will complete execution. Therefore without restricting the general range of computation available to hooks, the hook code is required to be guarded against arbitrary run-time looping. This topic will be discussed at length in part 2 (to be published next week).
The Hooks Amendment for rippled (to be xrpld) is being actively developed by XRPL Labs with the following planned releases:
- An upcoming Developer Preview release in the form of a docker container within the next few weeks.
- An Alpha Dev-Net in Q1 2021
In addition to these releases we will be publishing our rippled-hooks repository and example hooks for developers to test and run.
The Developer Preview will ship with three example hooks.
Outgoing transactions on your account trigger an additional transaction to be emitted from your account for 1% of the spend of the original transaction. This emitted transaction is sent to a carbon offset account controlled by an NGO which will spend it planting trees.
Malicious small transactions containing memos or outgoing payments to confirmed scam accounts are blocked. The hook has the ability to fetch a blacklist from another hook installed on a different account. This means the user does not need to update their firewall to remain safe. Additionally spending limits can be imposed by the user to prevent, for example, more than 10,000 XRP being withdrawn per day (i.e. every 21600 ledgers).
Lite Accounts Hook
Installing this hook on an account turns the account into a multi-user pool. The operation of this account is according to the internal rules of the hook as follows:
Each lite user nominates a public key.
To set up a lite account they need a friend to send a small opening balance to the hook, using the nominated public key as the Invoice ID.
The hook then records the public key and assigns the user a Destination Tag.
That destination tag now uniquely identifies that user.
Any third party sending funds to the hook with that tag will call the hook to internally credit the lite user's account in the hook's state.
To spend their balance, the lite user signs a message with their private key.
This message is then attached as a memo to a regular transaction and sent to the hook account.
Ideally the master key on the hook account would be disabled and the regular key black-holed to prevent unauthorised drawing of pool funds and leave the hook completely in control of the account.
Hooks run on a three part stack:
The Hooks Amendment is written in C++ as a modification the rippled source code.
Hook Runtime: Wasmer.io (Rust)
Wasmer is used as the Web Assembly run-time within Rippled.
Hooks: WebAssembly (C and Assembly Script)
Hooks are written in C or Assembly Script (but can be written in any language that compiles to Web Assembly).
The Web Assembly runtime can be swapped out for another, however Wasmer is currently integrated and will be released with our first two releases.
Discussions: here »