Batch contracts

In the recent Universa network release (v3.7 and newer) it is possible to put multiple contracts in the single batch, as new items. Though not a whole new feature (it was possible since very beginning), nowadays this feature has some very important improvements:

• Now the contracts that are created within the same batch, can be referenced from it (via references or even multiple revisions).

• The contracts included in the batch could be implicitly signed when signing the whole batch; e.g. these can have only the creator role but no signatures, provided that all the required signatures exist in the containing batch.

Lets discuss it in-depth.

Referencing the contracts inside the batch

Scenario: company/DAO contracts

Suppose you have a contract that creates some ltd company, and list the owners, and need a assignment contract of the new director and transferring some funds at new director’s disposal.

Before, it has required a set of smart contract registrations:

• create the company,
• assign the company director (as it references the whole company smart contract, which should be approved by the time),
• and only then, we can register the contract that transfers the company funds to the director (as it, in its turn, references the contract of director assignment).

Now this whole sequence could be done in a single batch, a single atomic transactions. This could be done because of the above mentioned improvements: all the included contracts are assumed valid if the whole batch is valid, and become APPROVED altogether, therefore the references are valid.

Scenario: OLTP/event logging

Suppose the distributed ledger is being used as a secure/irreversible alternative to storing the logs, and the system records regular updates of the documents and multiple creations of new revisions. One similar (though different) scenario is when a single token contract being often split, with minor quantities being sent out to various recipients.

Normally, each new revision of the contract should be registered independently. But, if the underlying system can cache the changes for some time period, it could aggregate multiple similar changes (e.g., document A changed revision from 17 to 18, then to 19, then to 20) into a single batch. In the example above, registering the whole batch with multiple transactions will end up the revision 20 being immediately registered as APPROVED; and the revisions 17, 18 and 19 will end up registered as REVOKED, as if each of them was independently approved, and then revoked by the consequent revision.

In the example with the token contract, a single token contract (say, revision 5) initially contains 100 TKNs; during a first operation, 2 TKNs are split to the recipient Alice (and the base token contract gets the revision 6); then, on the next operation, 3 TKNs are split to Bob (and the base contract gets the revision 7); then, we split 5 TKNs to Charlie (and the base contract should get the revision 8). We can register each split independently; but actually, if we batch them together, it may end up being more optimal, registering a single batch with all this splits, and the token contract of revision 5 jumping to the revision 8 directly.

Scenario: optimizing proxy

When the low latency of Universa network is not required, some intermediate “caching server” can be used to optimize the network fees. It will collect multiple contracts to be registered, but not send them all immediately. Sending them all altogether in a single batch, may end up being U-cheaper than sending them independently, providing a chance of “arbitrage” between the desired latency and network fees.

Signing the nested contracts with the batch

Suppose you have a bank and are going to transfer funds from your asset contract to the 500 beneficiaries. You can happily save your time and U by putting them all into the single payment, we name it a split, so it will be performed in a single transaction, which is very fast operation in comparison of 500 chained single payments.

Before the feature, has appeared, you had to sign every token in this contract separately, and the whole payment contract too; what leads to 501 digital signatures to be first generated by the client, and then checked by the Universa network. Checking a digital signature is a rather slow and CPU-consuming operation, and such an approach will end up in major U costs when there are hundreds or thousands of them. So, this whole transaction will require 500 payment signatures (one for each payment) and 1 signature of the overall paying contract. Too bad.

Actually, signing each token in the containing contract is an overkill: all of them are already signed by the containing batch: the signed batch includes IDs of the tokens, so the signature of the batch contract guarantees also the included contracts are genuine.

Since the new batching feature, the Universa network checks the creator role of the included contract; and if there are no signature in the contract itself, it looks for the matching signature in the containing contracts (the batch in our case).

This way, we save time and registration price by factor of 500. This is a very good result, especially because creating and verifying the digital signature is a very costly operation.

Real-world usage

The technique of signing the outer contract allows very easy escrow contracts, the working example is the UUTN service which is used also in automatic balance keeping feature (paying for transactions in UTN: auto-purchasing of U blocks as needed).