Transaction processor
When a transaction is being executed by the Radix engine, the initial entry point is a native blueprint called the transaction processor. It acts as a dispatcher for the transaction manifest and invokes the appropriate blueprints to execute the user instructions.
Special privileges
The transaction-processor blueprint is more privileged than other blueprints with certain restrictions on user resources relaxed by exceptions being made for it, both at the engine level as well as at the access-control level of other native blueprints.
Some exceptions made for the transaction processor include the following:
Publishing a new package
This operation is restricted only to the transaction processor by the following access rule:
Auth-zone creation
Auth zones created by a call from the transaction processor start with the initial proofs and virtual resources as opposed to being empty.
Dispatcher loop
This loop forms the core of transaction execution, translating high-level manifest instructions into actual state changes in the ledger through the Radix Engine.
The dispatcher loop consists of three main phases that handle the complete lifecycle of transaction processing:
Initialization
It creates a worktop component, decodes the manifest instructions from the input bytes, and initializes a
TransactionProcessor
instance with provided blobs and address reservations.Main processing loop
It iterates through each instruction in the manifest sequentially, tracks current instruction index for execution tracing and error handling, processes each instruction based on its variant type through a large match statement, and collects outputs from each instruction execution for the receipt.
Output handling
Each instruction execution may produce an
InstructionOutput
. Outputs are collected in order of execution. Any failures during processing will terminate execution and return an error.