Every action executed on the Savitri blockchain by a user is encoded in a transaction that specifies the action the nodes should take, the action parameters and and data payload, and has all this digitally signed using the sender’s private key. A transaction may be as simple as transferring tokens from one account to another but could have unlimited complexity, so long as its core application logic satisfies the properties that both the transaction validation and its execution are purely deterministic operations which only read from, and write to, the portion of each node’s database managed by the consensus algorithm.

When a transaction is first received from a peer or from a wallet software, the node will first confirm that the transaction is legal. This includes validating that the transaction is closed by a valid digital signature for its sending account address and that the parameters of the transaction are valid according to the transaction type’s rules and the current state of the database (such as having enough balance to send funds).

If the transaction received is valid, the node will propagate the transaction by transmitting it to other connected peers, as well as store the transaction in its local mempool. In this way, valid transactions are echoed across the peer-to-peer network until they are retained in the mempool of the majority of nodes. Upon receiving a valid transaction, each node will also return a special object we call a receipt to the sender. Receipts are used in the Proof of Unityalgorithm described below.

Transaction Application

When a node receives and validates a new block (described in the section on “blocks” below), it will contain an ordered list of zero or more transactions, which the node will then apply in sequence.

For a node, applying a transaction means executing the rules associated with the transaction’s type to update its local database from an old state to a new state. In the simplest example, this can mean deduct- ing the balance from one account and adding it to another.

Transactions Attachments

In future versions of Savitri, transactions will be allowed to specify large attachments to be stored in a distributed file system by the network. While the transaction itself must be propagated to all nodes, the attachment may only need to be propagated to a few nodes responsible for storing the file for others to download. More details on this are given in the section below on File Distribution.

Transactions Escrow

When two parties must swap goods online, it is often useful to have a trusted third party keep the goods in escrow, such that the swap is only executed when both parties have committed their assets. Traditionally, this trusted third party holds both of the assets, and if they are not in fact so trustworthy, they may abscond with both. Therefore, it is useful to have a system in which the trusted third party may only approve or reject the transfers between parties, but in no case becomes the owner of the assets.

To facilitate this use case, Savitri users may optionally include in the transaction the account address of an approver, which may either accept or reject the application of the transaction. Transactions which require approval are kept in an “escrowed” state by the blockchain, such that the funds or other assets they confer ownership of cannot be used by either the sender or the receiver until the explicit approval or rejection is completed, or the timeout returns control of the assets to the sender.

The transaction may also specify:

• a custom timeout: the number of blocks until, or the date/time at which, the transaction is automatically rejected (by default 1 day). The maximum timeout is 1 month;

• commission: an amount of tokens which will be paid to the approver if he accepts/rejects the transaction before the timeout, by default, the cost of a transaction;

• instructions for the approver: in binary or a JSON format if the approver is an application on a server, or in a human language if the approver is a regular user of Savitri;
• the behavior for when the transaction timeout: automatically approve or reject.

In the case that the timeout is reached before the approver sends an approval or rejection, the transaction is automatically approved or rejected and the commission is returned to the sender.

In order to approve or reject an escrowed transaction, the specified approver must broadcast an approval transaction, referencing the hash of the pending escrowed transaction and specifying whether he approves or rejects it. While the approval transaction can be submitted automatically by centralized services, when a user needs to manually submit the approval for a transaction, the technical complexities are hidden by the wallet UI.

One use case of such an escrow mechanism would be to configure a centralized server which manages an approver account and which is programmed to automatically approve transactions only when certain conditions have been met. For example, an escrowed transaction may specify that it should only be approved once 10 Ethereum have been transferred to a particular ETH account and set the approver to be a server which will monitor the Ethereum network to determine whether to release the funds.

Alternatively, any account may be configured to require explicit approval to accept any transaction addressed to it. In this case, if an approver account is not specified, the recipient account automatically becomes the approver. The rest of the mechanics defined above apply in exactly the same way, with the receiver of the transaction functioning as the approver.

To achieve the current normal behavior of blockchain transactions, any transaction which does not specify an approver account, and for which the receiver is not configured to require approval to accept transactions, is applied immediately upon its acceptance in a block.

The owner of an account may at any time enable or disable this mandatory approval behavior on the account by broadcasting the desired account property setting with a required approval transaction and specifying whether mandatory approval is enabled (default is “no”).