Quorum : Ethereum-based distributed ledger protocol

In Simple words Quorum is an Ethereum-based distributed ledger protocol that supports transaction and contract privacy.

The primary features of Quorum.

  • Transaction and contract privacy
  • Voting-based consensus mechanism
  • Network/Peer permissions management
  • Higher performance

Apart from these feature Quorum includes one of the powerful feature that is support of  Private and Public Transactions.

  • Private Transaction :- are those Transactions whose payload is only visible to the network participants whose public keys are specified in the privateFor parameter of the Transaction . privatefor can take multiple addresses in a comma separated list.
  • Public Transaction :- These are those Transactions whose payload is visible to all participants of the same Quorum network. These are created as standard Ethereum Transactions in the usual way.

The treatment of both type of transaction is different for Public Transaction it is sent to an Account that holds Contract code, each participant will execute the same code and their underlying StateDBs will be updated accordingly. But For Private Transaction  it replaces the original Transaction Payload with a hash of the encrypted Payload that it receives from Constellation. Participants that are party to the Transaction will be able to replace the hash with the actual payload via their Constellation instance, whilst those Participants that are not party will only see the hash.

Now let see how Quorum works Internally.


The process of a Transaction in Quorum is describe in the image.including Private Transaction Happening between A and B and there are 3 member in the network [A, B and C]  :-

  1. In First step the  request of Transaction is send to corresponding Quorum Node  i.e. A -> Quorum Node A. [Including Transaction A to B]
  2. A’s Quorum Node passes the Transaction on to its paired Transaction Manager, [Transaction Manager A] requesting for it to store the Transaction payload.
  3. A’s Transaction Manager makes a call to its associated Enclave to validate the sender and encrypt the payload.
  4. A’s Enclave checks the private key for Party A and, once validated, performs the Transaction conversion.
  5. Party A’s Transaction manager then stores the encrypted payload  and encrypted symmetric key and then securely transfers (via HTTPS) the hash, encrypted payload, and encrypted symmetric key that has been encrypted with Party B’s public key to Party B’s Transaction Manager. Party B’s Transaction Manager responds with an Ack/Nack response.
  6. A’s Transaction Manager returns the hash to the Quorum Node which then replaces the Transaction’s original payload with that hash.
  7. In Seventh Step Transaction is propagated to the rest of the network using the standard Ethereum P2P Protocol.
  8. A block containing Transaction AB is created and distributed to each Party on the network.
  9. In this step all Parties will attempt to process the Transaction.
  10. In this step A and B make a call to its Enclave, passing in the Encrypted Payload, Encrypted symmetric key and Signature. But C will receive NotARecipient message.
  11. The Enclave validates the signature and then decrypts the symmetric key using the Party’s private key that is held in The Enclave, decrypts the Transaction Payload using the now-revealed symmetric key and returns the decrypted payload to the Transaction Manager
  12. The Transaction Managers for Parties A and B then send the decrypted payload to the EVM for contract code execution. This execution will update the state in the Quorum Node’s Private StateDB only.

REFERENCES :-  Quorum Github Wiki

Insurance needs to wake up to blockchains!

In an interesting discussion that we were having with our banking client, their insurance department kept bragging about the state of the art technology that they were building. Head of Insurance was eager enough to call it InsurTech enabled and very sophisticated. However, surprisingly when I mentioned IoT and Blockchain and how it could impact the sector, the person drew a blank ( Well, to be fair, he did mention that he had heard it before, but isn’t that what you see when you are in-front of several peers)

I was curios to see how the sector in general thinks and this report from PWC does confirm to the bias that i had.

PWC Global Fintech Survey 2016

As you would see, Blockchain does find a mention even though it is a much much lower than what you would expect. Insurers, like banks, are intermediaries and, at first glance, there is great potential for insurers to use blockchain technology to streamline payments of premiums and claims.

Aso of today, Actuaries and underwriters are now heavily dependent on the data. This data can be brought to them from a lot of sensors now. For example in telematics, insurers are using data from sensors to price motor risk more accurately, reducing the premiums of young safe drivers, and this technology is spreading to other types of cover, such as home insurance.

Till date, Insurance sector, amongst other similar sectors is ridden by huge unaccountable losses in light of fraudulent claims.

As Deloitte mentioned,

In a typical motor insurance scam, for example, drivers deliberately stage or cause an accident or even pretend to have had an accident, and
claims are then made by the various criminals involved. These so-called ‘crash for cash’ scams cost the industry around £400 million a year. 4 Where claims are made against multiple policies held by different insurers, it becomes difficult to detect the fraud unless cross-industry data is shared.

We have been setting the stage a lot for blockchains but how does it help?

Now the way to get around this with blockchains is by building Smart Contracts. These contracts can manage claims in transparent and immutable manner. Both the contracts and claims would be the part of a blockchain. If there is one accident and the claim for that has already been raised then it cannot be claimed again because the chain would have a record of that. Again since this is a decentralised chain, nobody can just goto a central authority and make a change to the claim and re-trigger it. (Haven’t you heard of that friendly claims agent who tells you to file the claim and that he would take care of it or that friendly bank agent who assures that he has access to the main frames to fix your credit history?)

Smart contracts with IoT is a huge win for the insurance and the financial industry in general. With identity management being embedded in the smart contracts the situations for Crash for Cash would be long gone. Further this would be a blockchain which would be public (ideally) or private but shared within the insurance sector then all this information of a person who would jump from one insurance company to the next and not share all the information would be a distant past.

According to PWC,

Reinsurance expense ratios are typically 5%-10% of premiums. Our analysis of the potential for both more efficient data processing and reductions in claims leakage and fraud indicates that blockchain solutions could remove 15% to 25% of expenses, so delivering an industry-wide saving of $5-10 billion. And faster placement and settlement opens the way for a significant boost in client satisfaction and retention.

With blockchains, there would be a win in terms of processing, opportunities for new business lines and immense transparency which has been a thing of the past for now amongst insurance companies. With all companies sharing their information on the blockchain, it would be a different world in which legitimate insurance claims would help bring the cost of insurance down and add value to everyone.

If this sounds interesting then get in touch with us and we would show you how your company can win with blockchains.

Quick example of a block in a blockchain

Further to our earlier post, which describes the data structure of a block in the blockchain, here is a quick example of what does the block look like



Relating it back to the post, it contains the

  1. Size, Version, Bits and Height in the chain as to where it belongs
  2. Number of transactions
  3. Merkle root
  4. Timestamp
  5. Link to the previous block
  6. Mining Difficulty
  7. Nonce
  8. And a list of all the transactions in the block.

Again, each transaction has the following format

Screenshot from 2016-11-28 18-16-28.png

Again as per the details in the earlier post, amongst the technical information, it contains the size, mine time and the block that it is a part of , along with the details of the coinbase in input and output.