Transactions

Transactions are the only means of changing the ‘state’ of a ledger and might, more accurately, be called transformations. The state of a ledger is everything that the ledger knows in its golden record – this might include the record of instruments, balances and the state of arrangements such as outstanding contracts. So, creating a new instrument is a change of state and requires a transaction. Changing a contract to record the acknowledgement of one of the parties is also a change in state requiring a particular form of transaction.

Elements of a Transaction

There are a number of different Transaction types in use, each of which is designed to make a different type of change to State, e.g. Transfer Asset, Register an Address, Create an Instrument, etc., but they all have a common basis:

  1. Transaction Data, e.g. for a transfer, ‘From’ Address, ‘To’ Address, Asset identifier, Quantity, Transaction Reference, Time stamp etc.

  2. The Transaction Hash, a cryptographic ‘fingerprint’ of the Transaction Data (see below).

  3. A Digital Signature: Authorisation for this action. (See further below)

Hashes

A Hash is a digital ‘fingerprint’ of a set of data. There are cryptographic algorithms that, when given an arbitrary amount of data, will return a fixed-size ‘fingerprint’ that is ‘guaranteed’ to be unique for the provided set of data.

The Hash algorithm that we use is considered sound and the chance of collision, where two different sets of data arrive at the same Hash, has been mathematically proven to be of the same order of chance as picking the same grain of sand from a beach, twice in a row.

The hashes cannot be changed without being detected, thereby proving the immutable nature of that blockchain data.

We are also conscious of rapid advances in technology (e.g. quantum computing) and have built our algorithms to be parameterised – we can easily ramp up the order of complexity if processing power appears to be getting close to overwhelming our encryption.

Immutability via Hashes

There are two approaches which are generally used to ensure immutability:

  1. Distribution

  2. Signatures

Both of which are used at different times.

For any data that has identity associated with it (e.g. a transaction) a signature by the authorising party is provided for the relevant Hash. Any change to the Hash would invalidate the signature.

For other situations, for example State Hashes, the Hashes are distributed to such a degree (or published publicly sometimes) that it becomes infeasible to alter the underlying data without being detected. It is, for example, be possible to publish in a national newspaper a single hash which represents the end of day state for a ledger. Such a proof could not be circumvented as the paper is widely distributed and cannot, afterwards, be easily altered.

Signatures

A signature is another cryptographic construct whereby some data (the message) can be ‘combined’ with another (small) piece of data (Secret) to produce a signature.

This signature can be verified (‘proved’) by using a third (small) piece of data (the Public Key) that has been derived from the Private key. What is proved is that, given a known message and a public key, the signature relates to this message and must have been produced with knowledge of the Private key.

A vital requirement is that the Public key is unique to the Private key and that the Private key cannot be derived from the Public key.

A number of public/private key schemes are widely used including RSA and Elliptic Curve schemes. SETL uses the latter as it is more secure and faster to compute.

Identity via Signatures

Within SETL’s Blockchain, identity is asserted using what are known as Public-Private key pairs. The Private keys are closely guarded and access to them is restricted to only the relevant authorised users.

Practically, what this means is that something can be signed using a Private key and the signature so created can be verified using the associated Public key in the certainty that the signature could not have been created in any way except by the use of the Private key.

Where a signature is used to make an authorisation, for example in a Blockchain transaction, the cryptography guarantees that only the related Private key could have been used to create the signature and thus, that the authorisation must have come from the entity that has control of the Private key.

Public keys cannot be used to create signatures and are intended to be freely available for verifying signatures and so validating the authorisations made on the Blockchain.

Processing Transactions

Communication between nodes

The first thing that a node does when it receives a transaction is to verify the signature and then, if it is valid, to send that transaction to all the other Validation nodes that it knows. In this way, every Validation node becomes aware of every transaction.

Proposals

Periodically, one of the Validation nodes will take all of the outstanding transactions, combine them into a single package (a Block) and ‘propose’ that block to the network.

Consensus

When a Validation node receives a proposed block it will validate the transactions as a group and, if it is a valid collection of transactions, send the block to all connected nodes and then publish a Vote in support of that proposed block.

The Validation nodes record the positive Votes that they receive, and all being well, they will receive supporting Votes from all of the Validation nodes in short order. Once a Validation node has a threshold weighted majority of votes in favour of a particular proposed block, then that node will ‘Sign’ that block and publish that signature to the network.

As with Votes, the Validation nodes collect Signatures until they again have a threshold weighted majority in favour of a given Block, at which time they will save the Block (with its signatures) as the next block in the chain and finalise the changes to state that this collection of transactions produce to produce the new State.

Collectively, this is the process whereby new transactions (in Blocks) are applied to the Blockchain and is known as the ‘Consensus’ process.

Voting and Signing Rounds

There are separate rounds in order to be able to cope if something goes wrong.

It is possible, under situations of extreme network latency, clock de-synchronisation or server failure for there to be multiple blocks proposed at the same time.

Then, depending on network topology, it is possible for the Validation nodes to vote for different blocks such that there is no clear majority. If this happens, then after five seconds, they all vote again, but by this time all of the blocks will have been fully copied to all nodes. In the presence of multiple blocks, the nodes will rank them according to set criteria and as a consequence in the second round they should all vote for the same block, and then the next block in the next round, etc.

Having reached an agreement in the Voting round, they will proceed to the Signing round and finalise the block, that-is, save the block and update State.

Chaining of Blocks

The ‘Chain’ in question is an unbreakable cryptographic association between each Block and State in sequence.

In the SETL Blockchain there is an alternating sequence of Blocks and States, each time a new Block is agreed a new State is created, each with an incrementing index - the Block / State Height.

Starting with the ‘Genesis’ State (the starting State, height 0), every subsequent Block contains a record of the State Hash upon which it is built. i.e. Block 0 will contain the State Hash of State 0 (Genesis), Block 1 will contain the State Hash of State 1 and so on. The State Hash is included in the calculation of the Block Hash and so cannot be changed (without detection) after the Block is signed.

Similarly, every state (after Genesis) will contain the Block Hash of the Block that was applied to create it, as with Blocks, the Block Hash is included in the calculation of the State Hash which, upon means it cannot be changed without detection after achieving consensus.

Mining

SETL Blockchain has been engineered to not need a ‘Mining’ process.

On the Bitcoin network, and many other Blockchains, ‘Mining’ is the process whereby participants are rewarded for creating and approving new blocks.

There are a number of different protocols (Proof-of-Work, Proof-of-Stake etc.) in use, each with its own set of advantages and disadvantages.

In some networks, such as Bitcoin, the rewards of mining are such that enormous amounts of computing (and electrical) power are devoted to this process.

The SETL Blockchain uses an approach known as ‘Proof-of-Identity’. Only authorised parties may contribute to the consensus process, irrespective of how much computing power they control. As a result, our Blockchain consensus requires only a small number of servers (configurable, but usually less than 10) to maintain its integrity and in consequence uses comparatively small amounts of power.