- General network architecture
- Smart contracts
General network architecture
Universa Network is the worldwide network of Universa nodes, providing the functionality of distributed and decentralized registration and validation of smart contracts, and storing the data in decentralized manner with the means of Universa Blockchain technology.
You can check the actual status of Universa Network using the Universa Network Scanner.
Each node stores the copy of Universa Blockchain data and synchronizes it with other nodes. Also, it is available for connection from clients, and can:
- register the new smart contracts – or new revisions of the already registered smart contracts – validating them in process;
- say whether a smart contract is currently approved by the Universa network, for a given smart contract (or Hash ID of the smart contract).
If you are interested in running your own node, please consult the Node Owner Central.
Crypto Cloud is the web service developed by the Universa team; this web service is not a part of Universa network.
It is used by some systems and clients, including the Web Client, to store the Universa-specific data (in particular, smart contracts or private/public keys), with the end-user encryption – that is, all the data is encrypted and decrypted only on the side of the user, with the user-provided keys (making it impossible for third parties to access it without the private key of the user).
As it is capable of storing the smart contracts and keys, and used by the clients – it is one (but not the only possible) of client data storage implementations.
In Universa, smart contract is a binary document with the expansible machine-readable structure.
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
definitionsection, may contain specially-formed requirements and permissions. Most typically, the
definitionsection contains the rules how the data in the
statesection 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
SimpleRolewith just a single private key (e.g. “for success, the document should be signed by the specific private key AAAA”); or a
RoleLinkreferring 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
referencesto 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”.
Normally in Universa methodology, a smart contract may be any general purpose document. But, if, among all the permissions, it has the properly defined
SplitJoinPermission – it effectively becomes a “fungible asset”, and can be called a token.
Any token contract will have the following features (according to the definition of the
- It has some numeric value, which can vary in a specified range (and with a specified minimal unit).
- It can be split to multiple (otherwise compatible and alike) contracts, changing the owners of some contracts in process if needed; the total value of these contracts will be the same as of the original contract.
- Multiple contracts (most likely, created previously by the split operations of the compatible contracts) can be joined into a single contract, if they are owned by the same owner; the total value of these joined contracts will be the same as of the result contract.
The split (1:M) and join (N:1) operations can actually perform simultaneously, joining multiple contracts (if owned by the same entity) and splitting them to new owners (N:M); the only requirements are similar: the contracts should have the compatible SplitJoin definition, and the total value “before” should be equal to the total value “after”.
The SplitJoinPermission defined in the contract, may be configured differently, making some token contracts split-joinable with some other compatible token contracts, but not with some other incompatible ones (e.g., “UTN tokens can be accumulated with other UTN tokens; GOLD tokens can be accumulated with other GOLD tokens; but UTN and GOLD tokens are incompatible with each other”). In layman terms, these compatible contracts comprise the contracts of some specific token.
Client of the Universa Network is, broadly speaking, any application (service, site, library, API) capable of connecting to Universa Network, create or edit the smart contracts somehow, register them in the network and validate as needed.
General-purpose official clients
There are several pre-made Universa clients (both applications/services, and programming APIs) providing wide spectre of features working with the smart contracts in general.
Some general-purpose Universa clients for end users (see also the End User Central for other important articles):
- Web Client – a full-featured web application with friendly user interface, providing most features to work with the Universa smart contracts. Uses the Crypto Cloud as the Client Data Storage.
- Uniclient – CLI (command-line interface) application for advanced users and software developers. For the Client Data Storage, uses the local filesystem of the computer where it is executed.
Broadly speaking, if an application uses the Universa network somehow – it is a Universa client.
Functionality of such clients depend on how they are going to use the Universa Network. For example, some “crypto-kitties” style game may act as a Universa client, connecting to the Universa network; and, if each “cryptokitty” has its own smart contract, this game will update the smart contracts, register them, using some nifty and playable game interface. The client functionality will obviously be limited, though – supporting, most likely, just the smart contracts important for this game.
Another, more actual example: as MyDocuments.io service is using Universa to register each version of the document, it acts as the Universa client as well. It is not a general purpose client, either; it has no need to support other smart contracts besides those needed for the functionality of MyDocuments service.
Comparing to other blockchains (like Bitcoin/Ethereum), the specifics of Universa network and Universa Blockchain technology is that the Universa Blockchain normally does not store the data of the contracts in its distributed ledger. The Universa Blockchain works as a storage for contract validity only, but not for the content of the smart contract.
Thus, to work with the Universa contracts using some Universa client, it is not sufficient just to know the private key of the user, and get all the data of the user from the blockchain; the client should actually store the smart contracts (and private keys, if there are multiple of them) which are being worked with. Thus, each Universa client should have some Client Data Storage, which keeps track of all the involved and processed smart contracts.
There are multiple approaches of Client Data Storage, e.g.:
In Web Client
The Web Client stores the smart contracts using the end-user-encrypted Crypto Cloud. It also allows to export the contracts into downloadable
.unicon files, and to import these
.unicon files into the Crypto Cloud.
Storing the contracts in Crypto Cloud is extremely convenient and mostly transparent to the user. Using the Crypto-Cloud-enabled features like Chat, one may easily re-register the smart contract to another user and immediately send it to the new owner using. But please note that some other Univeras users are not necessarily using either the Web Client or Crypto Cloud, so for them to access the smart contracts, you may need to transfer them using different means, even fallback to sending them the
.unicon files of the contracts.
The Uniclient CLI tool may work with
.unicon files directly, as well as have some basic means of storing the contracts on the filesystem. Please note Uniclient doesn’t support the Crypto Cloud storage.
In hardware Universa clients
For other blockchains, the “hardware wallet” (like Ledger Nano S, Trezor, etc) is typically just a secure device (in the flash drive formfactor) storing the private key and performing operations using it, but not allowing the private key itself to be copied out and stolen. Basically, each such a “hardware wallet” is just a “secure key storage”, while some apps running on the computer (where this device is connected) are working as the clients.
In Universa, it is really possible to implement a fully hardware client running all the operations on itself, and using Internet just to register the contracts, or check their state. Such a hardware client will even contain the embedded Client Data Storage, not requiring any external storages (even the Crypto Cloud) to keep the smart contracts being worked with.
In client APIs/libraries
The software developers using the client APIs are usually assumed to implement their own Client Data Storage for their own means. For some more specific details, the Software development: best practices could be consulted.
Wallet is a feature that can be provided by some Universa Clients, be those the usual end-user client applications/sites/services, or the software developer-oriented client APIs/libraries, for special-purpose working with the token smart contracts.
For a client (or API) to be considered having a properly implemented “wallet” feature, it should satisfy the following conditions:
- It has the specific handling for the smart contracts having the SplitJoin permission (i.e. tokens).
- It can aggregate the tokens to the groups upon the compatibility of their SplitJoin permission (i.e., grouping the by specific tokens). That is, “UTN tokens go together with UTN tokens, GOLD tokens go together with GOLD tokens”.
- For the aggregated tokens, it keeps track which tokens are actually approved by the Universa Network, and filter only for currently approved ones.
- The client may support a single or multiple private key of the user; the wallet feature must be able to filter only those tokens which are currently owned by any of the user private keys.
- For each specific token, the wallet feature must be able to filter only approved and owned by user, and calculate their total sum. It will act as the total balance of this specific token in the wallet.
- Its should be able to receive tokens: i.e, to receive/import the token contracts from external sources (i.e. if some other owner/client generates them), store them in the Client Data Storage, and aggregate them with the existing token contracts as explained above.
- It should be able to send tokens: to perform
SplitJoinoperation on the stored token contracts, splitting out the desired sum (and joining the existing contracts if/when needed) to a new owner (and storing the remainder for the current owner); to register this operation in Universa Network; and to send/export the contracts for the new owner.
What “wallet” is not
- “Wallet” is not some account in the network. You don’t “sign up” anywhere, you don’t create it in Universa Blockchain. All you create, is your private key, and you create it locally on your computer.
- The existing general-purpose Universa Clients, such as the Web Client or Uniclient), are not wallets. They have much wider sets of features. Though, they may have “wallet” as one of their features.
- Wallets do not have the addresses (though the private keys in these wallets do). In Universa, you cannot just send some contract “to some wallet address”. You have to 1. re-register the contract to the new owner address, 2. deliver the contract to the new owner (and their client, with their wallet feature) somehow. Some specific compatible clients maybe have shortcuts, though; e.g., using Web Client, you may easily send some contract to another user of Web Client.