Last week you could read about the structure of a smart contract in Universa. It has parts which are either mutable or immutable and it’s possible to add some specific data to a payment (or revision, like invoice numbers).
The terminology for these sections are state, definition and transactional. The next step is to explore what you can do with these smart contracts. To understand this, it’s good to start learning more about ‘being a smart contract’.
The Universa Blockchain is based on verifying, not executing. In the world of Universa, a smart contract is a binary document with a machine-readable structure. It’s like a .doc Word or an .xls Excel document, not an .exe file.
Another thing which you might remember, is that Universa sometimes calls a smart contract a ‘smart document’. This matches with the approach of the ‘Ricardian contracts’.
This approach of ‘structured documents in a distributed environment’ reflects the viewpoint of most of the business world. This world considers a contract as being a specific variant of a document.
The ‘blockchainized’ document is part of document or process flow. Not a file which is ran continuously.
In Universa, the approach is to ‘write a document’ instead of ‘executing a distributed application’. This brings us to another new term: Ricardian contracts.
The Ricardian contracts is a method of recording a document as a contract at law, and linking it securely to other systems. This can be systems for accounting for example.
It can be identified by several aspects:
- Robust through the use of identification by cryptographic hash function;
- Transparent through the use of readable text for legal prose;
- Efficient through markup language to extract essential information.
- Defines elements of a legal agreement in a format that can be expressed and executed in a software. This matches the approach of ‘smart document’ and linking it to other software to execute and process it.
So this is in short the background and identity of a smart contract in the Universa blockchain. But what can we do with it? Let start with an example.
The first example is an escrow contract, also called an atomic contract swap. It can be seen as a safe way to exchange contracts.
Take for example Bob. He has 0.1 uETH and he wants to buy 500 UTN from Alice. This can be done in a decentralized and non-custodial manner.
First, Bob makes sure he creates a payment contract (with the split-join contract which is explained in the previous article) with 0.1 uETH for Alice and the rest for himself.
He does not sign these coins, but sets his creator address in it. Then, he wraps it unsigned in a contract batch and sends it to Alice. This contract type is also known as compound.
Secondly, Alice checks if Bob’s payment is in the document. If that’s true, she adds her 500 UTN to the compound contract. Because it is still not signed, Bob can do nothing with it without the Alice’s key.
After that, Alice signs the the compound contract. It is completely safe to her, because the compound also contains payment from Bob, so Bob would not be able to register the compound without signing it with his key.
And if Bob properly signs it, only then he could register it; but he therefore will also register and confirm his payment to Alice. Both parties can check if the owner address and tokens are correctly added to it.
If everything is OK Bob signs it with his key and registers it with the Universa network. As soon as the network approves the compound, it will approve their new possessions in the same atomic operation.
After that we have a finished escrow deal without any other services or line of code.
Signing a contract
Either both of them exchange their tokens the way they have signed in the contract, or nothing happens at all.
- neither Bob nor Alice can cheat during the exchange;
- if either of them skips signing the compound, the Universa network will reject it;
- if they both sign the compound, the registration will transfer ownership of both items at once in a single atomic operation;
- both of them are guaranteed to have a copy of their purchases.
Read more about this kind-of complex contract at our Knowledge Base website.
This is just one small example of smart contracts with the Universa Blockchain. It perfectly shows the way of thinking: by adding tokens to a compound contract, signing this document from two sides, and registering the status of this exchange to the network is all what happens.
No computational power is needed, the process is transparent but also robust due to the cryptographic hashes and the network only verifies the state of this exchange.
In our traditional world, we would need a trusted third party to exchange digital documents. This escrow agent is the arbitrator. With a smart contract, everything happens digitally and trustless. Check out the Contract Service for more information about using the codebase escrow contracts.
Ricardian and dApp contracts
Finally, let’s conclude with the differences between Ricardian Contracts and the typical dApps-kind-of contracts. One of these is not better than the other. With dApps you have to write some executable code for each purpose you want to digitize or automate. In that case you have to be a programmer. You want to make a “multisig wallet”? In that case you either write some dApp from scratch for that, or launch some existing code (and then work with it like a programmer).
With Ricardian Contracts (or with the Universa Blockchain), you have to write or update a document. It’s easier. And if you want to make a multisig, you can update the document and specify its fields like “the owner is a compound list-role of three signature owners A, B and C, and ALL three of them must sign this document to change anything”.
In the next article we’ll dive deeper into other kinds of smart contracts. How does this work with utility tokens; and how about neutrino payments; and how about registering multiple revisions in one contract?
If you would like to help translate these explanations to your language, feel free to contact @starnold. Stay safe!