Smart Contract

In Universa, smart contract is a binary document with the expansible machine-readable structure.

Contract lifecycle

For Universa smart contracts, the original author of any smart contract writes its initial version and registers it. Then, the other users of the smart contract, whoever owns it, can edit it somehow and register any new revisions of this smart contract (successfully registering any new revision will automatically and atomically revoke the previously approved revision).

The structure of initial version may (and typically does) impose multiple restrictions on how the contract could be edited in the future by its subsequent users. For example, such restrictions and limitations may specify how some particular field or data in the document may be edited, who could edit it, what values it may accept, what constraints should be satisfied by any document edit, etc. Creating such set of limitations and constraints is the goal of the contract author. These limitations imposed on the document are exactly what makes the contracts smart.

“Smartness” features of the smart contracts

Typically, each smart contract contains multiple sections:

  • definition – the section which contents is never changed between the revisions of the smart contract. It may contain any freeform data, but also some specially formed permissions/references; various limitations specified in this section will live throughout the whole life of the document; and they will be necessary for every future revision of the document.
  • state – the section which contents is usually changed between the revisions of the smart contract. It may contain any freeform data, but also, similarly to the definition section, may contain specially-formed requirements and permissions. Most typically, the definition section contains the rules how the data in the state section could be varied between revisions; though the logic may be more complex.
  • transactional – the section which keeps the “transient” data of the contract during any single transaction/edit only; the data in this section is not assumed to survive multiple subsequent edits of the document.

These sections may contain some other smart contract features, such as:

  • permissions – rules specifying who and how can perform any operations on this document. May specify which fields of the contract may be edited (ModifyDataPermission), how specifically some numeric data in the contract can vary (ChangeNumberPermission), etc. One special permission (called SplitJoinPermission) even specifies how multiple (“compatible”) smart contracts can be combined together (joined) or separated to multiple other smart contracts, maintaining some total value in the process, and effectively adding fungibility to this smart contract, i.e. turning this smart contract into some kind of token. For the whole set of supported permissions, see the source code at Github.
  • roles – (typically inside some permissions) specifying the parties who should sign the document, for some permission to be satisfied. May be as simple as a SimpleRole with just a single private key (e.g. “for success, the document should be signed by the specific private key AAAA”); or a RoleLink referring to some other role (e.g. “for success, the document should be signed by its current owner no matter what private key it has at the moment”). For the whole set of supported roles, see the source code at Github. May even contain some extra references to check (see below).
  • references – extra rules to validate, written using the special syntax. For details, see References article.

To learn further how to create the Smart Contracts in Universa, you may visit the Smart Contract Designer Central section of the KB.

Comparison to other approaches

This “structured document” approach (that the smart contract is a document rather than something else) reflects the viewpoint of most of the business world (which considers a contract is just some specific variant of document, and contract processing is just a subset of document flow).

Though it may contradict the vocabularies/traditions/customs of some other blockchain technologies, e.g. Ethereum, Hyperledger Fabric – which consider that smart contract is some application executed in a distributed environment, a “Dapp”.

In Universa, to create a smart contract, you “write a document”, not ”develop a distributed application”.