Programming in Radiant
Radiant uses a programming language called script inherited from Bitcoin, but adding advanced functionalities that allow it to be Turing complete.
To understand it well it is necessary to make a leap in time to the beginnings of Bitcoin.
Bitcoin Script
Bitcoin needed a simple language to manage transactions and Satoshi decided to use a stack-based language, similar to Forth (1970), which is called Bitcoin Script or only Script.
It is a simple language that is not Turing complete, which means that it lacks certain logical functions, including loops. This was done to ensure that no scripts in Bitcoin will cause large amounts of computational power or deadlocks due to a programming error.
Script is used almost exclusively to lock and unlock bitcoins, as you cannot build applications or run programs with it.
OP_Codes
The opcodes are simple commands of the script language and each of them have very specific functions, allowing to interact with the content of the blockchain in a precise way.
These are the opcodes that can be used in Bitcoin
In the following image you can see how the Bitcoin script language works with the OP_Codes in a validation script. The execution flow is from left to right and the operator on the right performs an action on the left if so.
6 2 ADD = 8
8 8 EQUAL = TRUE
Here is another example with a P2PK validation script to validate if a signature with a private key matches the public key of the example.
OP_Codes in Radiant
Radiant adds to the script language a series of functionalities that allow it to be Turing Complete, based on mathematical induction. This is added in the following advanced OP_Codes.
OP_PUSHINPUTREF : The key to everything
One of the big problems of managing tagged UTXOS, as with the current ordinals, is to know the history back to the origin. This can be done in two simple ways.
1/ With an external script that verifies the origin and allows the output (oracle).
2/ Adding all the history in the same UTXO, making it grow continuously.
In Radiant this is solved by adding a unique and global reference in these transactions, allowing to validate the origin in an efficient way without the need of oracles or increasing the size of the UTXO in a constant way.
RadiantScript
One of the most complex parts of programming with OP_Codes is their stack language.
To solve this, we are working on RadiantScript, which will be the first programming interpreter to manage Radiant’s potential with its OP_Codes with a high-level programming language for smart contracts in Radiant.
Its syntax is based on Ethereum’s Solidity smart contract language, but its functionality is very different as smart contracts in Radiant differ greatly from smart contracts in Ethereum.
It is currently in the testing phase and is in the process of documenting the programming since it contains new OP_Codes.
The Future
When Radiant was conceived, it was done with the idea of working from Day 1 and not waiting months or years to add developments to the chain. Right now it is already possible to use all its capabilities, but the most complicated part is to have a software that can program in the new OP_Codes and this requires time and development.
But the future is bright, because this new code will allow to compete with the big chains like Ethereum, Cardano or Solana in terms of potential.
(This will be one of many articles focused on the technical side of Radiant, which is where its full potential resides.)
