Nicholas Pennington, SETL CTO

9/25/2019

What is a Blockchain?

A Blockchain is a State and history that uses cryptography and distribution to guarantee immutability and identity. Multiple computers running the blockchain software (Nodes), acting independently, make the network resistant to compromise and distributed storage makes corruption infeasible. If you don’t understand what this means, hopefully all will become clearer…

But really, what does it do?

The Blockchain consists of a network of nodes each of which has a complete record of State. By ‘State’ I mean the current record of Accounts, Asset Balances, Instrument definitions etc., indeed every live (i.e. current) piece of information recorded by the Blockchain. Non-live, i.e. outdated, information is still recorded in previous Blocks or States and may be needed for ‘proving’ the current State but is not normally needed for ongoing operation of the node.

As participants want to change something, for example to send a quantity of asset that they own to someone else, they submit a transaction to the network, it is propagated (sent to all the nodes), agreed by a majority of Validation nodes and applied to state. Exactly the same set of transactions are applied by each node which means that they all have an identical record. A Validation node is a node that has a full copy of State and has the required permission to contribute to the agreement process. This configuration gives you a distributed record of State, which is not dependent on any central authority, where each node can know and prove that what they see is both correct and the same as everyone else.

Why is this useful?

A provable, immutable history provides a common ‘Golden’ record (the ‘official’ record, good for regulators and record keeping) that all participants can agree to (no discrepancies between parties, good for reconciliation). The Blockchain acts in many ways as a distributed database. A principal advantage vs a traditional database is cost, given that Availability, Cryptography and Identity can be engineered in a Database, but with much greater difficulty if you want to have distributed immutability, but the real difference is in the way that data is organised: A Blockchain is purpose built for distributed, provable, immutability where databases are designed with other purposes in mind.

So, what does a transaction look like?

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 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).

Huh, what’s a Hash?

A Hash is a digital ‘fingerprint’ of a set of data. There are clever 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 cryptographic ‘guarantee’ is, of course, not absolutely certain, however, provided that the hash is large enough (in terms of number of bits) and the algorithm is cryptographically sound, it can be considered that the fingerprint is unique to a set of data and that the data cannot be changed without altering the Hash.

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 roughly the same probability of randomly picking the same atom in the Universe twice in a row. Provided that the recorded hashes cannot be changed without being detected, it is by the use of Hashes that blockchain data is made provably immutable.

OK, sounds great. How do you make a Hash unchangeable?

Well, there are two approaches that we, and other blockchains, take to this problem:

1. Distribution
2. Signatures

Both of which are used at different times.

For any data that has identity associated with it, for example transactions, 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 every copy without being detected.

Now that I understand the nature of Hashes, what’s a Signature?

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 key (no pun intended) requirement is that the Public key is unique to the Private key and that the Private key cannot be derived from the Public key. More about this next.

But how does a Signature confer identity?

Within our 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. Skipping over the cryptographic detail, 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.

Getting back to Transactions, how are they processed by the Network?

Ok, 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 nodes that it knows of. In this way, every node becomes aware of every transaction. 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. 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 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 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.

Why are there separate Voting and Signing rounds?

There are separate rounds in order to be able to cope when 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 should 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. 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.

Where does the ‘Chain’ in Blockchain come from?

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, provided they are sufficiently distributed, means it cannot be changed without detection.

I’m not quite clear, what’s the difference between ‘Block’ and ‘State’?

Quite simply, ‘Blocks’ are each a collection of transactions that have been approved by the Blockchain, that is, they have been through the consensus process and have been approved by a majority of the Validation nodes. They do not contain position balances etc, just changes to be made.

State is the cumulative effect of all of the transactions in all of the blocks. i.e. current holding of an asset or the record of active contracts etc.
State is analogous to your current account at the bank, it tells you what is true now, whist Blocks are analogous to your monthly transaction statements, they tell you what changes have been made. Since all historic data is available to the Blockchain, participants can of course see any historic version of State to see, and prove, what was true at any point in the past.

What part does ‘Mining’ play in all of this?

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 paid to create and approve new blocks. The process of being paid provides participants with a reward for their effort and an incentive to remain honest.  There are a number of different protocols (Proof-of-Work, Proof-of-Stake etc) in use, each with its own set of advantages. In some networks, such as Bitcoin, the rewards of mining are enough that enormous amounts of computing (and electrical) power are devoted to this process.

The SETL Blockchain uses an approach that we describe 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.
The Blockchain data may be distributed to an arbitrary number of non-voting nodes but, since they are not in competition, they too will require only normal (as usually required to sun a server) amounts of computational and electrical power.

Open Source or Closed Source?

This seems like the right point to have a quick word about open source. Many in the blockchain world make a big point about the virtues of Open-Source development, but with regard to Blockchain it seems largely irrelevant : Some are not Open Source (though maybe, one day, perhaps…) others, like Ripple, Corda and Hyperledger, are Open-Source but have such dominant contributors that it is in some ways meaningless and then there are many other Blockchains do not seek to compete in our space. There is an argument around having public scrutiny, but this also means complete knowledge with which to launch an attack.

SETL’s Blockchain is closed source for four main reasons:

1. SETL’s underlying software is unique and has value because of the engineering expertise that has gone into it.
2. The Open-Source blockchains tend towards general solutions. We could quickly lose our technological focus which would impact on our main business advantage.
3. We feel that there is value in the unique IP that we have developed, and it is not in our interests to just give that away.
4. Open source projects can lose control of the technology roadmap. This would mean that we could not quickly upgrade or change the Blockchain in response to Client, Market or Regulatory requirements, again a real disadvantage to us.  In addition, we would have no control of how the software was deployed or kept up-to date, which could expose us to reputational damage.

What makes your Blockchain special?

The SETL Blockchain has been designed from the start with the needs of financial services in mind. There are many other uses for Blockchain, but we leave those opportunities to other providers, our focus is entirely upon financial services. The attributes that we have focused upon, that financial markets value most, are:

1. Speed: It is important that any single transaction be processed and made final very quickly. The SETL Blockchain aims to process all outstanding transactions within a 5 second window.
2. Capacity: The system must be able to cope with high transactional volumes. The SETL Blockchain aims to cope with 10s of thousands of transactions per second, also, the SETL Blockchain has been engineered to cope with an unlimited number of accounts and Balances.
3. Identity: Financial regulation requires that all participants and transactions are identifiable. Identity has been a core consideration of the SETL Blockchain ecosystem.
4. Real Assets: Assets are individually registered on the SETL Blockchain, they are not represented by ‘colouring’ a single Blockchain asset as with some other systems.
5. Targeted functionality: The SETL Blockchain has functionality, transaction types and market integrations, that have been implemented with the sole purpose of making common financial market operations easier, faster and cheaper.

Attributes that we have specifically avoided, that would inhibit adoption in financial markets, are:

1. Crypto currency. Tokenisation against a crypto currency is not desirable, but more than that, having a system where the cost of transacting is subject to external forces and could (quite easily) double overnight is not workable for core market infrastructure.
2. Anonymity. Quite simply, not possible in regulated financial markets.

Why SETL?

When combined with the technical qualities of our Blockchain, the deep financial services domain experience within SETL provides a compelling and best-in-class offering, unrivalled by most, if not all, of our competitors. The experience and market reach of the management and board is extensive, and the quality of the team assembled at SETL is second to none.