The UNIVERSA project was primarily intended to be effective substitution to all mining-based solutions, so it’s main considerations were speed and space requirements.
Instead of bringing the Thermal Death of the Universe closer and rising the videocard prices (thus spoiling the karma and infuriating the gamers), the Universa project gets principle of minimal required effort. The node concentrates on:
- Check that operation (fragment of the chain) is allowed by the source contracts
- Perform atomic transaction: certify new documents, revoke old documents.
Compact Decentralized Ledger
The roster of approved contracts is copied and distributed across the Universa network, it was designed to have small and predictable size and growth rate. Universa holds as few as 132 bytes per an active record. It does not depend on the chain length, or contract size. It is always the 132 bytes.
Really Distributed Store
Universa network does not keep the chains and copies of the contract. It holds only a record of the active document which is less than 140 bytes long active in ledger and less than 90 bytes packed in archive. The contracts, indeed, are kept by the remote parties who need it. It is simple and universal – those who need it, keep it. So the actual chain is distributed among the users and could be virtually of any size.
The Ledger Does Not Grow
The Universa network keeps track only of active documents. History items are removed from the ledger. Suppose, we have an ownership contract. Say, initially it was 4Mb size (why not, with compressed attachments inside). The Universa tracks it for the price of 132 bytes in the ledger.
Suppose in 5 years the contract had changed ten thousands owners and became 10Mb in size (now it keeps all the history). Still, Universa ledger takes only 132 bytes for it. All 10 000 records of its previous state are wasted soon after revocation recycling ledger space for active contracts.
Note that Universa keeps only decentralized ledger, not the contracts and not the blockchains.
The Universa node implements MRU cache of recently accessed documents. With only 132 bytes per entry the major part of the ledger just fits the RAM. For example, suppose the Universa would have one 1G active (approved) documents. Suppose 1/3rd of it is being actively used (it is very pessimistic assumption). Then LRU cache of it requires only about 50G (including some storage overhead. This will fit most of modern server computer RAM, so verification will be superfast.
The Universa nodes do not execute any contract scripts, instead, nodes check the contract state change or new contract data to conform with the rules included. This check is implemented in high-productivity language, currently, Java, and later could be rewritten in C++, what means, close to the light’s speed.
The process of generation new contract generation, executing scripts, changing its state, extending the chain and signing it, is performed on the client. Such resource-consuming operations are not performed by the network, which only checks the results to be in accordance with contract rules.
When the node receives a contract to process, it verifies the source document (what is, as is written above, a very fast and effective process), then propagates it and the local solution over the network and waits for the consensus to be found. While it waits, it could process other contracts without any risk, as any transaction is atomic and protected. This way a node can process at once tenth thousands of contracts, and perform more than 20 000 processed transactions per second in the benchmark tests. So, as long as node’s hardware have enough capacity, the network lags and timeouts could be utilized to process more contracts. As a result, the actual transaction speed will be at the bigger part determined by the biggest network lag between nodes.
Double Spending Attack?
The transaction parallelism is a common point for double- or multiple-spend type attacks, which, in simple form and universa terms, is an attempt to perform 2 or more transactions with the same source contract revision, having a goal to achieve 2 or more formally approved resulting contracts (revisions), only one of which is legal. For example, to change ownership of some object passing it to two new owners at once.
In universa could this attack is repelled by the consensus reaching process. Every contract in transaction, while waits for the consensus, locks the contracts (revisions) to be changed or created for exclusive usage. It prevents obtaining the lock on the same sources by any other contract. So, if the attacker will start two transactions on the same node, the latter will be rejected. Of the attacker starts any number of conflicting transactions on different nodes, only one of them could reach positive consensus, in the case it will be processed before others on on 90% of the network. And if it passes, it will revoke source contract state(s) and further attacks on the revoked state will not succeed.
More likely, each of the conflicting transactions that were simultaneously started on the nodes will soon collect 11% negative votes, forming negative consensus, and will be therefore rejected.
How it works
In short: Universa works very much like the notary of the real world, with an important addition of ability to revoke documents (contracts) that are not valid anymore. So, it performs only two operations, and does it very well:
- It verifies the state of its smart contracts (documents). At any time it can tell whether some document is still valid.
- It performs atomic transactions, the valid operations on the smart contracts, like new contract creation, change and revocation.
In the Universa there are no client ledgers, unlike in other systems. Instead, the participants own one or more private keys that let its holders to perform allowed operation over the smart contract where respective keys are mentioned.
So, in general the system is as anonymous as the private key does. So, when we talk about the participant we mean the corresponding private key holder.
Anonymous Key Ids
Moreover, we plan to allow one-time key IDs to be a replacement of the public key in some cases. For example, the anonymous ownership transfer may protect new owner from being detected by the old owner, as he or she will not expose own key during the transaction, providing the one-time key id.
One-time key ID could be generated almost without limit to any public key, so every new key ID will be different from all previously generated. Still it is possible to detect whether or not some public key matches the given key ID.
Of course, the real key must be disclosed to perform any further operation on the owned object, so it only preserves new owners (or new participants) anonymity until they firm the transaction for the first time.
The smart contract is a packed and signed file, which consist of:
- Roles description. For example, OWNER role must always exist. Each role should have at least one listed key.
- Permissions. Describes what could be done with this contract, when, how and by whom. It means any permission states:
- What roles (e.g. parties) could perform the action. It means, that the change is permitted only when corresponding keys are used to sign the new contract state
- When it is allowed to do (date/time restrictions may apply)
- Special limitations for all permission type. For example, split/join permission can specify minimal fraction to be split and whether it could join with parts splitted from other contracts or only within its own chain, change number permission specifies the allowed value delta and result range, and so on.
- Attachments. The link to some named resource and its signature. For example, scans of the paper contract, results of the work, electronic book and whatever else. These are external links for the Universa network, as the node never receives it.
- Any user data, mutable and immutable
- Issuer and issuing timestamp.
- Creator and creation timestamp, and revision number. This is for changed contracts
- Branch id, if the contract was ever split apart.
The contract structure consist of two big parts: definition, which could never be altered, and state, which could be changed, providing there are permissions allowing it. Either one could carry any user data.
New contract creation
The simplest procedure. The participant(s) creates a valid contract and asks Universa to certify it. The system simply checks that it is not a fraud attempt and that the contract is properly signed with all owners, then registers it. The contract could be registered only once. It also could not be registered again after revoked, the issuer must issue a new, different contract (at least with issuing date).
Changing contract state
It is like changing the contract’s state or adding it as a block to the blockchain. We name this block in the contract chain a revision. First contract has revision number of 1.
The client software takes the contract, generates it’s copy (new revision), updates its state part, collects all necessary signatures, and pass it all to the Universa network. If everything is valid, the transaction is performed revoking old revision and approving new one.
In more complex states more than one old state could be revoked and more than one new state or contract could be approved. For example, splitting apart coin-like contract provide 2+ new revisions, same way joining together such splits revoke 2+ old revisions providing new one.
Mr. Bob has just written a poem. To be sure nobody would claim its ownership, it wraps it into smart contract and certifies it with the Universa. Being shy he has attached the poem to it, so impudent geeks that run the nodes wouldn’t read it. Let’s name it Poem(Bob), where (Bob) means that the owner of the contract C is now mr. Bob.
Ms. Alice has just developed a fantastic recipe of a delicious dish and wraps it to the universa contract Recipe(Alice). Being proud and brave it included the recipe in the contract body, in the definition.data.recipe field.
Aside of writing poetry, Bob was running a restaurant, and, once tried the dish of Alice, was inspired so much to propose exchanging it to his poem. Alice, being secretly fond of Bob, agreed, so they decide to exchange ownership of their contracts.
To do it, Bob has performed ownership transfer from his contract for the Alice’s public key. He has created a transaction which includes his poem and its new revision with Alice key as an owner. He also added the new revision of the Alice’s recipe to it, with his public key as a new owner. He had signed it with his private key and sent it to Alice using any communication they normally use – email, messenger.
Note that Bob has prepared a transfership contract, but he can not approve it, as the second operation, ownership transfer from Alice to Bob, requires Alice’s signature and her private key, what Bob has no access to. At least so thinks Alice and hopes the Universa network.
In turn, Alice received the transfership contract, checked it, found OK and signed with her key. Now she could approve it with the Universa network, or send it back to Bob to do so. The only difference is that the party sending a contract pays for processing.
When the transfer will be approved, the Bob will get the right to possess Alice’s recipe and Alice will become an owner of the Bob poetry. This is done by the universa client, which sends the transfer contract Transaction(Recipe(Alice)→Recipe(Bob), Poem(Bob)→Poem(Alice)) to the network.
The Universa checks that the contract is signed by all owners, source and target revisions are valid, and performs operation, by revoking the Recipe(Alice) and Poem(Bob) revisions and approving the Recipe(Bob) and Poem(Alice) revisions.
Interesting fact: the Recipe(Alice) still holds immutable section with the message that Alice has created this recipe and the recipe itself. Bob has the right to do whatever he wants with the contract. But he can’t remove the Alice’s statement and recipe from the definition.
Moreover, it is technically possible that Alice forbid further ownership transfer, or require her signature to it. This is a limited license, which text could be also included in the immutable section.
And what would happen if the Alice will register the transfer but tell nothing about it to Bob? That is no way a friendly actions, but life is life. Nothing bad! Bob could check anytime his poem and recipe against the Universa network, and as soon as Alice will register the transfer, the network will answers him that the poem is no more approved, and the recipe is now his one.
Suppose Alice did not answer for a long while. Therefore, Bob decided to present his poem to Carol. Very well, he could do it unless Alice had approved the transfer contract which then could not be used anymore as reference revoked state of Poem(Bob)!
By the way, transfer contracts are usually created with short expiration, so it could only be registered within this short period.
Further, suppose the Alice’s boyfriend, Chuck, have access to Alice’s key and wants to cheat Bob and get his poem without giving up on the recipe. To do so, he tries to alter the transfer contract somehow, but this ruit the Bob’s signature on it, without access to the Bob’s key he won’t succeed. Well, much like the real life, Chuck must become a close friend also to Bob to get his key to disturb the deal. Unfortunately, the Universa knows no Bob and Alice, so anyone who possess the respective keys is, from Universa’s point of view, a legitimate owner.