Program RGB
RGB is a full-fledged smart contract system which operates on top of Bitcoin and Lightning network. If you think about blockchain as a settlement layer and Lightning as a scaling layer, RGB is the programmability layer, finally adding to the first and most censorship-resistant cryptographic-based store of value properties which were absent and desired for many years.
RGB achieves this through a separation of abstraction layers: the bitcoin blockchain (layer 1) becomes a cryptographic commitment layer, which holds no data but compact commitments to the smart contract state, which is kept off-chain. These commitments do not occupy block space, since they are kept inside taproot tree and not directly visible on-chain.
Such approach also allows RGB to operate on top of the Lightning network, since it can work with any bitcoin transaction, including transactions incorporated into a channel. RGB scripts and state fully exist in the client-side world, are not seen from the outside (hence privacy) - and are not required to be validated by anyone other than the contract participants (hence scalability).
RGB allows Bitcoin to pass beyond the limitations of the CIA triad (confidentiality, integrity, and availability) by achieving different properties on different layers:
- Blockchain provides integrity & availability;
- Lightning network – integrity & confidentiality;
- RGB – confidentiality & availability.
Overview of RGB development
Contract business logic in RGB is defined through so-called schema; the specific RGB contract must implement some schema. One may think of a schema as a "class" definition in the OOP world; in that terms, specific RGB contracts are "class instances" created by the schema constructor (genesis operation). Such approach allows to separate role of contract developer (in RGB called schema developer) and contract issuer: the first one needs to be an experienced developer, while the second one is not required to know anything about coding or security at all. This also promotes re-use of common codebase by different issuers for the same typical use cases (like fungible assets), reducing the risk of mistakes.
RGB uses specially-designed virtual machine AluVM, which is Turing-complete in the same terms as EVM and WASM-based smart contracts (i.e. nearly computational universal, but is bound by number of operation steps, measured by gas consumption in Ethereum-like systems, and by accumulated computational complexity measure in case of AluVM).
Components
In RGB, there is no such thing as "program a smart contract"; instead, contracts themselves are issued with no code. This helps to simplify the life of asset issuers and normies, who just need to issue a token, create their self-sovereign identity, run a DAO etc.
This is achieved through separation of concerns, where the development work is kept outside contracts, thanks to things called schema and interface.
Contract
The contract is a contract genesis plus a history of operations on the contract. Together they are used by RGB to compute a deterministic contract state. To create a contract means to issue a contract genesis, which requires no code at all. The Contract issuer just needs to pick a schema which has all features needed in a contract – and use it during the issuance. If the schema with the required properties doesn't exist, the issuer can hire a developer to implement such a schema.
Schema
If you think in terms of object-oriented programming (OOP), a contract is an instance of some class, and in RGB terms this class is named schema. Schema contains all the contract business logic, scripts, definitions of state types (owned and global), allowed operations, rules for validation, data type system etc. Schema by its nature is declarative, it can be easily read or written with Rust macros, YAML, TOML and other declarative languages. Once created, a schema may be used by many contracts of the same type.
Interface
An interface defines how a user-facing software (wallets etc) can interact with a contract. Interfaces provide semantic information about the contract and defines how its state can be presented to the user. If one can compare schema to a class in OOP, than contract interface should be compared to Java interface or Rust trait. As classes can implement interfaces in Java, or structs can implement traits in Rust, in RGB schema can implement many interfaces.
Ways to program RGB
Today, there are two main ways for programming RGB smart contracts: using rust-based RGB domain-specific language and with a specially-designed functional smart contract language named Contractum. Unlike many other blockchain-based smart contract systems, RGB also allows to create contracts without writing any code at all – even for complex contracts like NFTs, identities, DAOs etc.
Zero-code contracts
Because of the use of contract schemata, most of RGB contract types can be issued without writing even a line of code. All you need is to find a schema and use command-line tools or GUI-based wallets to issue your contract.
RGB Rust DSL
The simplest way of creating a new RGB schema or interface is to use Rust. You can directly compile arbitrary rust data to be part of RGB contract state, and you use macro-based DSL to define new schemata and interfaces. You can export contracts, schema or interface into a binary form – or save them as Base65-armored text for further distribution.
Contractum
Contractum is the forthcoming declarative language for writing safe and easy-to-audit smart contracts for RGB. Contractum is being under an active development and we plan to have it released by the end of the year. Today you may preview how writing RGB contracts in Contractum may look like in a future.