Reli­able Pub­lish­ing To The Blockchain

How to up­date your lo­cal DBMS and pub­lish to the blockchain in one trans­ac­tion

So you want to pub­lish to the blockchain what you save in your own data­base? Read on...

Ex­am­ple

Your ac­count­ing sys­tem stores in­voic­es in its data­base. Sup­pose you want to do triple-en­try ac­count­ing by pub­lish­ing your in­voic­es also to the blockchain so you have a copy in the dis­trib­uted ledger. What can you do to make this re­li­able?

The Prob­lem

It turns out it's not triv­ial to up­date both sys­tems in one go. The in­tu­itive ap­proach­es many de­vel­op­ers would use do not work. To see why, let's try:

At­tempt 1: Com­mit in DBMS, then push to the blockchain

In this ap­proach, one would:

1. Up­date and com­mit the lo­cal DBMS
2. If this worked, then push to the blockchain

If there is a crash be­tween 1 and 2 then you will have a DBMS up­date, but no blockchain pub­li­ca­tion.

At­tempt 2: Push to blockchain, then up­date / com­mit in DBMS

Here we go:

1. Push to the blockchain
2. If this worked, then up­date / com­mit the DBMS

If there is a crash in be­tween 1 and 2 then you will have pub­lished in the blockchain, but with­out DBMS up­date.

The So­lu­tion

Er­ror: im­age not found

Use JTA/XA trans­ac­tions and a mes­sage queue to cre­ate an atom­ic trans­ac­tion:

1. Create a JTA trans­ac­tion
2. Up­date your XA-ca­pa­ble DBMS
3. Post a mes­sage to an XA-ca­pa­ble queue re­quest­ing a blockchain pub­li­ca­tion
4. Com­mit the JTA trans­ac­tion

The key point is that the suc­cess of 2 and 3 co­in­cide with the com­mit of 4. If there is no com­mit, then none of 2 or 3 will hap­pen.

Then have a back­ground com­po­nent that:

1. Reads a mes­sage from the queue
2. Pub­lish­es in the blockchain ac­cord­ing­ly
3. If this worked, re­move the mes­sage from the queue

If there is a fail­ure / crash be­tween 1 and 2 then the pub­li­ca­tion can be re­tried lat­er. If there is a crash be­tween 2 and 3 then the pub­li­ca­tion may be at­tempt­ed twice. Either the code de­tects this (and does noth­ing the sec­ond time), or the log­ic that reads data from the blockchain ig­nores du­pli­cate en­tries. We are as­sum­ing ei­ther one of these is pos­si­ble and fea­si­ble.

Added Ben­e­fits

The process that up­dates the DBMS and the code that push­es to the blockchain in­ter­act via a queue. Most queues have ac­ces­si­bil­i­ty in mul­ti­ple pro­gram­ming lan­guages, so the ap­pli­ca­tion that up­dates the DBMS can be writ­ten in a dif­fer­ent lan­guage than the blockchain com­po­nent.