Intro to Radiant programming — Opcodes

The Radiant blockchain introduced a set of opcodes that significantly improves on the capability of the Bitcoin technology it’s based on. All these opcodes will be outlined in this article.

Terms

• Ref: A 36 byte reference, either of normal or singleton type. A reference is created from an input’s outpoint and can be propagated with every spend of a UTXO. For a ref to exist in an output there must be a matching input ref of the same type or an input with a matching outpoint. The ref type cannot be changed once it is created.
• Normal ref: A type of reference that can be propagated to one or more outputs.
• Singleton ref: A type of reference that can only ever exist in a single UTXO. Cannot be propagated to multiple outputs.
• State script: The part of the script before and not including an OP_STATESEPARATOR. Useful for storing state data that can be changed by the contract.
• Code script: The part of the script from and including an OP_STATESEPARATOR. If no state separator is present, the code script is the entire script.
• codeScriptHash: The double SHA-256 of the code script.

Hash functions

SHA-512/256 is the hash function used by Radiant’s proof of work algorithm. It is available in script as single and double hash functions. These can be used to validate Radiant block headers in script.

Induction opcodes

State/code script opcodes

Count and sum opcodes

These opcodes provide a set queries on inputs and outputs by ref, ref hash and code script hash. Counts and sums can be performed over many outputs with a single opcode, meaning an unrolled loop in the script is not required.

This article is part of a series of articles about programming in Radiant.