The Smart Contract
The smart contract (or simply contract) is immutable. This is an advantage: upon the contract is properly composed, signed and registered, it will never be changed, what is guaranteed by the design. Instead of changing contract’s state, we, like we do in the life, create new contract based on the existing one, often obsoleting it, forming contract chains, simple, agile and robust set of electronic documents covering virtually any usage pattern. So, when we talk about changed contract state, we mean the new contract in the chain that obsoletes old one and have therefore a different state.
The contract undergoing changes forms the blockchain of revisions, where each revision of the chain represents a valid contract state at some instant, obsoleting previous states, and reference the previous state and the origin contract of the chain, e.g. the root contract. Universa ledger approves the latest contract in the chain, which, in turn, approves the previous state and the original state, as the references are signature-based, and this way the whole chain is approved through it’s latest revision, which represents the current state of the contract.
The contract revision in the Universa network has only 2 states:
Approved by the Universa. It means, that the contract is valid, active and could be used in any permitted way, which are, in turn, described inside the contract itself.
Unknown to the Universa. For example, the expired, or obsoleted contract that is no more valid is the same unknown as if it never existed.
When new revision is being approved, the parent revision is revoked in an atomic transaction, what guarantees that no contract revision could be double (or multiple) used.
Universa does not keep track of the contract history, and it does not keep the contract itself for the time longer that it is necessary for the processing. It keeps only the set of approval records for the active, approved contract revision – not the contract itself. It’s up to the involved parties to keep their contracts. Still, the storage service can easily be implemented as an add-on service.
The Contract Chain
Suppose, Bob has bought an unified coin from the bank. The bank charges Bob’s credit card and issues an coin-type Universa contract, UNC or simply the coin, to Bob. This type of contract is, in short, represents the commitment to redeem the coin or convert it to some other form of liquidity (which is clearly stated in the contract body). At this point, in rough, exists only once contract: Bob’s coin, and it is approved by the universa:
Now, Bob makes a present to Alice and transfer ownership of his coin to her. This operation is allowed by the UNC contract, so it just does it:
And now, there is again only one coin, the Alice’s, approved by the Universa. And Bob’s coin does not exist anymore, it is revoked. If someone ask Universa about it’s state, it will be unknown, as it is obsoleted by some new state. As we see, Bob’s coin does not mutate, instead, a new coin revision was created with Alice’s ownership and the previsous Bob’s revision was revoked and discarded. It is an atomic operation which uses the transferring ownership permission: the object is cloned creating new revision, except the changed owner, and approved by the Universa, and the old revision is discarded in one atomic operation.
In the sample above, the root contract – Bob’s coin – was used to derive the coin for Alice. This operation had revoked the Bob’s coin contract. Not all operations are revoking the parent, some of them does not change the parent contract but create new ones referencing it. For example, the smart contract of the public offerta can produce a bunch of derived client contracts as the clients accept the offer.
The derived contract always references its parent, using parent contract origin, and the parent contract could provide details on the child contract fields and references, and provide limits on how, when and by whom the child could be created.
Each participant in the Universa is represented by the notion of the party. The party could be completely anonymous or physically identified. There are several ways of identifying a party In the root contract the party could be identified by:
- By the public key, mentioned in the contract body (for example, as the issuer or owner).
- By the anonymous public key Id which allows identifying the party’s public key without disclosing until to the first usage (for example to make anonymous purchases).
The party could add any other details of itself (name, nick, social security or passport number, whatever) in the contract record.
Inside The Contract
- Definition. Immutable part that can’t be changed in revisions. Contains issuer, issuing timestamp, permissions (some permissions could be also moved to the state), and any data the creator want to be immutable.
- State. The mutable section which could be changed in revisions. Contains revision number, creator and timestamp, reference to the origin and previous revision, changeable roles and (rarely) permissions and any mutable client data.
- Attachments. Any file, mentioned by mean of the signed reference in the definition or state.
Universa network knows only definition and state, the rest is never sent to the network. It is important part as attachments may and often contain a sensitive and private information. While this information is well protected by mean of signed references in the contract state and definition, it is even better protected by not being transferred to the Universa network.
So, the full contract is only exchanged between parties involved, where any appropriate transport could be used (email, messengers, clouds, USB flash, whatever). The immutability of the attachments is guaranteed by the signed references in the contract, which are in turn signed by the parties and approved by the network.
So, the chain of trust is:
- Universa network approves the revision of the contract, provide the registration time and the immutability of the state and the definition.
- Parties that have signed the revision approve (by signing it) that the state and definition are correct, and that they possess all mentioned attachments and agree with them, whatever they are.
- Signed references in the state and definition guarantees immutability of the corresponding attachments located somewhere in the client storage.
The scripts are executed by the client software and in the client’s environment. The Universa network does not ever see the script, but it always check the result to conform with the contract definition and state. It means, that even if a script will perform some forbidden operation, the network will not accept the result. Generally, it is always simpler to specify few permissions and conditions limiting the allowed operations than trying to check the script source for hidden vulnerabilities. The permissions DSL is clean and straightforward, comparing to the script, and permission check performed remotely by the Universa can not be bypassed by the script, which works locally and is never even transferred to the Universa nodes.
The usual script execution cycle is: scripts is being activated by the user or, in the server environment, some event, like incoming contract or payment notification from our Bitcoin integration service. The script then execute, modify its state (each script have some local storage to work with and can access its contract chain), create and approve with Universa new revisions and derived contracts, and, if need, send it over the network using any connected communication tools. Actually the script could be allowed to connect to any network service using HTTPS API.
Smart contract is a tree (structure or hash) of objects and could be stored in any modern format, such as JSON, YAML, XML, BOSS, whatever else that can hold arrays, structures, strings and numbers. YAML-based DSL representation is often used as new contract templates, inside the network contracts are always serialized with BOSS, as it is the best to keep binary data that are widely used in Universa (keys, signatures and binary IDs).
Each smart contract is packed to the heavily protected signed container – the capsule. The capsule consist of the body and set of extended signatures. The body includes a packed binary contract itself and set of extended signatures. Each extended signature signs the body and the own type, fingerprint and timestamp, so many types of electronic signatures could be used at once. The corresponding public keys (or it’s anonymous IDs) are normally mentioned in the contract body so the system can check whether the mentioned key was used to sign the contract.
The contract’s capsule contains no encrypted data, as the part of the contract known to the Universa network should not include any sensitive private data. Instead, such a data must be attached to the contract as signed references (to external files, for example) and will never be transferred to the Universa network, both reducing the unnecessary traffic and protecting private information.
Source: Russian version in Universa VK group.