Basics of languague design #1
dr-orlovsky
started this conversation in
Languague Design
Replies: 2 comments 3 replies
-
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. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 (usingcontract
keyword). One may think about "schema" as class definitions in OOP world, and "contracts" being instances of that classe.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.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:
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: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:
For AluVM a special Contractum languague extension will be developed later on, which may look like
To issue the contract one must provide all information required by the schema genesis:
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).
Beta Was this translation helpful? Give feedback.
All reactions