- Performance overview
- How it works
The Universa project was primarily intended to be an effective and high-performance replacement to all mining-based (PoW-consensus) solutions, so its main considerations were speed and storage space requirements. Due to these considerations and architectural decisions, Universa is able to reach 25,000 TPS and more on various benchmarks; and anyone can run the benchmarks themselves with their own preferred scenarios.
So, the key features of Universa productivity and high performance are:
Instead of bringing the Thermal Death of the Universe closer and boosting the GPU prices (thus spoiling the karma and infuriating the gamers), the Universa project utilizes the principle of minimal required effort. The node concentrates on:
- Checking that an operation (fragment of the chain) is allowed by the source contracts;
- Performing an atomic transaction: certify new documents, revoke old documents.
Compact decentralized ledger
The roster of the 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 storage
Universa network does not keep the chains and the copies of the contract. It holds only a record of the active document (in current terminology: “approved”) which is less than 140 bytes long actually used in the ledger and less than 90 bytes when packed in an archive (extra bytes may be used by the transactions). The contracts, in fact, 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 doesn’t grow
The Universa network keeps track only of the active documents. Historical items are removed from the ledger. Suppose, we have an ownership contract. Say, initially it was 4 Mb in size (why not, if it has some compressed attachments inside). The Universa tracks it for the cost of 132 bytes in the ledger.
Suppose in 5 years the contract had changed ten thousands owners and became 10 Mb in size (now it keeps all the history). Still, the Universa ledger uses only 132 bytes for it. All 10 000 records of its previous state are forgotten soon after the revocation recycles the ledger space for usage by the really active contracts.
Note that Universa keeps only the decentralized ledger, not the contracts and not the blockchains.
The active part of the ledger fits in RAM
The Universa node implements MRU cache of the recently accessed documents. With only 132 bytes per entry the major part of the ledger just fits in the RAM. For example, suppose that Universa would have one 1 Gb of active (approved) documents. Suppose ⅓ of it is being actively used (a very pessimistic assumption). Then LRU cache of it requires only about 50 Gb (including some storage overhead). This will fit in the RAM of most of modern server configurations, so the verification/validation will be super-fast.
The Universa nodes do not execute any contract scripts; instead, the nodes check the contract state changes or new contract data to conform with the rules included. This check is implemented in high-performance language (currently Java, and later could be rewritten in C++), what means, it is close to the speed of light.
Clients take the processing load
The process of new contract generation, scripts execution, changing the contract 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 tens thousands of contracts at once, and execute more than 20 000 transactions per second in the benchmark tests. So, as long as the node hardware has enough capacity, the network lags and timeouts could be utilized to process more contracts. As a result, the actual transaction speed will be mostly determined by the worst network lag between the nodes.
A word on double spending attacks
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 the ownership of some object passing it to two new owners at once.
In Universa 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 by any other contract on the same source contracts. So, if the attacker starts two transactions on the same node, the latter one will be rejected. If 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 90% of the network. And as soon as it passes, it will revoke the source contract state(s), so further attacks on the revoked state will not succeed.
Even more likely scenario is: each of the conflicting transactions (that were simultaneously started on the nodes) promptly collects 11% of negative votes, forming a negative consensus; and therefore each of the conflicting transactions will be 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 the 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 (approved).
- It performs the atomic transactions – the valid operations on the smart contracts, like a 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 a permitted operation over the smart contract where the respective keys are mentioned.
So, in general the system is as anonymous as a private key is. So, when we talk about the participant, we mean the holder of the corresponding private key.
Anonymous key IDs
Moreover, we plan to implement 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.
Any number of one-time key IDs could be generated (almost without limit) for any specific public key; so every new key ID will be different from all the ones 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 only since they received a contract and until they make a transaction utilizing the received contract 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 the 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 the minimal amount to be split and whether it could join with parts splitted from other contracts or only within its own chain; or “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, the scans of a paper contract, results of the work, an 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, provided that 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 the different issuing date).
Changing contract state
It is like changing the contract state or adding it as a block to the blockchain. We name this block in the contract chain a revision. The first contract in a chain has the revision number of
The client software takes the contract, generates its copy (new revision), updates its
state section, collects all necessary signatures, and pass it all to the Universa network. If everything is valid, the transaction is performed revoking the old revision and approving the new one.
In more complex cases, more than one old revision could be revoked and more than one new revision of contract could be approved. For example, splitting apart coin-like contracts provide 2+ new revisions, similarly joining together such splits revoke 2+ old revisions providing a new one.
Mr. Bob has just written a poem. To be sure nobody would claim its ownership, it wraps it into a smart contract and certifies it with 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 some delicious dish, and wraps it into the Universa contract Recipe(Alice). Being proud and brave she included the recipe in the contract body, in the
definition.data.recipe field. (Small pieces of data could be incorporated in the contract
state. Universa limits the maximum size of contracts, so any larger data should always be kept in attachments.)
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 of his contract onto the Alice’s public key. He has created a transaction which includes his poem and its new revision with the Alice key as the 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 method they normally use – email, messenger.
Note that even though Bob has prepared a transfer contract, he still can not approve it, because the second operation, ownership transfer from Alice to Bob, requires Alice’s signature (and her private key in order to execute it), what Bob has no access to. At least so Alice thinks and the Universa network assumes.
In her turn, Alice received the transfership contract, checked it, found it being OK, and signed it with her key. Now she could approve it in the Universa network, or send it back to Bob to do so. The only difference is that it is the party registering a contract in the network who pays for processing.
When the transfer is 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.
Universa checks that the contract is signed by all the owners, and that the source and the target revisions are valid, and then it performs the operation, by revoking the Recipe(Alice) and Poem(Bob) revisions and approving the Recipe(Bob) and Poem(Alice) revisions in a single atomic operation.
Interesting fact: the Recipe(Alice) still holds immutable
definition 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 forbids further ownership transfer, or requires her signature to it. This is a limited license, which specification and text could be also included in the immutable
And what would happen if the Alice registers the transfer but tells 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 owned by himself.
Suppose Alice didn’t 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 ruins the Bob’s signature on it, so without access to the Bob’s key (to rebuild the signature) he won’t succeed. Well, much like in the real life, Chuck must become a close friend to Bob as well, to get his key to disturb the deal. Unfortunately, the Universa knows no Bobs and Alices, so anyone who possess the respective keys, is, from Universa point of view, a legitimate owner.