Basics of languague design

[dr-orlovsky]

Contractum is the high-level declarative language for writing RGB contracts. It is inspired by Haskell and focuses on the robusness, readibility, auditability, formal analysis/verification and low entrance threshold for developers.

At the top level Contractum allows to define RGB schema (schema keyword) and issue contracts under previously-defined schema (using contract keyword). One may think about "schema" as class definitions in OOP world, and "contracts" being instances of that classe.

schema FungibleAsset

contract StableCoin implements FungibleAsset

RGB contract consists of state and nodes, which define/update the state.

Contract state can be owned (i.e. assigned to a single-use-seal) and unowned. Owned state can be void (i.e. declaration of some rights to perform certain action), represented by a zero-knowledge value, other non-zk data or external data attachment.

schema FungibleAsset
  unowned Name :: String
  unowned Ticker :: String

  owned Renomination          -- this is a right, since it has no state type
  owned AssetAmount :: Zk64   -- this is value, since it uses Zk-type
  owned Engraving :: String   -- this is data
  owned Image :: mime:image/* -- this is attachment since it uses MIME string as a type

Contracts are defined with genesis and updated with state transitions and state extensions; collectively these three are called "contract nodes". State transitions always close some of the single-use-seal (one or more, maybe of multiple type) updating their assigned state; they can also define a new owned state and modify unowned state:

schema FungibleAsset
   -- ... here we skip all from the example above

  -- Genesis may be seen as a "class type constructor" from the OOP perspective
  genesis :: Name, Ticker, Image?, [AssetAmount], Renomination?, Engraving?
  -- Question mark following the name means that the argument is optional: 
  -- it may be provided or can be skipped.
  -- Squared braces indicates an array of values of that type, i.e. in this case 
  -- it means that genesis may define multiple single-use-seals with certain 
  -- amount of assets assigned to each of them

  -- A state transition may be seen as a method which mutates the state of a contract
  transition TransferAssets :: {AssetAmount} -> [AssetAmount]
  -- Curly braces indicates a set of unique values of that type, i.e. in this case it 
  -- means that we must close unique single-use-seals with assets ("spent assets")
  -- and define new one or multiple single-use-seals with certain amount of assets 
  -- assigned to each of them

  transition Renominate :: Renomination -> Renomination?, Name, Ticker, Image?

  transition Grafitty :: Engraving -> Engraving?

Validation of the RGB contracts is made at the level of the individual contract nodes. Validation is performed with virtual machines; currently RGB uses two variands of VM: simple "embedded" and Turing-equivalent AluVM. Specific virtual machine used by the schema is defined through using keyword:

schema FungibleAsset using EmbeddedVM

schema NFT using AluVM

Validation code goes on the next line following contract node definition. For EmbeddedVM it consists of simple name of the used validation function from the set of embedded functions provided by RGB Core:

schema FungibleAsset using EmbeddedVM
  transition TransferAssets :: inputs {AssetAmount} -> outputs [AssetAmount]
    zk_sum_eq inputs, outputs

For AluVM a special Contractum languague extension will be developed later on, which may look like

schema FungibleAsset using AluVM
  transition TransferAssets :: inputs {AssetAmount} -> outputs [AssetAmount]
    assert sum inputs == sum outputs

To issue the contract one must provide all information required by the schema genesis:

import MySchemata

contract StableCoin implements MySchemata.FungibleAsset
  Name := "USD stable"
  Ticker := "USDS"
  AssetAmount := 100_000 @ bf13beb50d581f8609f5edef99f7c111e291fde79cb82fc6ec76dfe4b82960f6:0

Normally, contract code will be developed by a qualified "schema devs". Schema serves as a form of "template" for contract creation by the contract issuers, which are not required to learn Contractum in full and can issue the contract as show above "just filling in the form" provided by the genesis defined in the schema (contract constructor).

[cryptoquick]

This all makes a lot of sense. Not sure if this is out of scope, but one thing I'd like to see is the capability to introspect on-chain intrinsics, such as the balance of an address, or block height and difficulty.

[dr-orlovsky]

Yes, that is where AluVM comes into play. RGB Core will use special AluVM runtime environment extended with three sets of commands:

1. Secp256k1 curve point operations (for verifying stuff like Pedersen commitments)
2. Access to bitcoin blockchain data provided by Bitcoin Core connected to the RGB Node
3. Access to RGB contract state data

[cryptoquick]

Perfect!

[saltduck]

contract StableCoin implements FungibleAsset

implements usually represented implements an interface in OOP languages like Java. So I suggest use instantiates instead of implements. Just like this:

contract StableCoin instantiates FungibleAsset

[dr-orlovsky]

Very good point, I do agree