Daiwa to adopt blockchain for Myanmar stock trading | Hacker News Reader

Daiwa to adopt blockchain for Myanmar stock trading

asia.nikkei.com

47 pointsayanray21 comments

I started writing a furious "why would you even do this?"-style post, but this paragraph stood out:

>Blockchain technology shares transaction records with multiple computers. Stock trading is typically saved in servers at bourses, but records cannot be referenced when communications infrastructure fails.

>Using blockchain systems, brokerages can continue a minimum of operations, such as checking past transaction records and outstanding balances even when failures occur, although new transactions cannot be checked.

The "blockchain as a distributed transaction DB" concept is more interesting than I thought, and it's probably really easy to get started given all the bitcoin tech around.

Traditional offline storage can do that too, right?

well it's distributed, so just caching a DB is a bit of a tricky question. What are you going to be caching in your offline storage?

If you just used flat-file CSVs, and don't want to re-download the entire DB twice a day, you want to now come up with syncing strategies, merging strategies, and probably conflict resolution. If you just have a blockchain, then you get all of this for free (so long as your data fits the blockchain shape).

Though I imagine there's something else that can be used here as well...

Why would you need merging and conflict resolution when there's a single source of truth? All you need is a stream of messages and some way to record them. If you want to distribute them P2P, add some metadata to sort them.

per the article, in the Burma case, you have multiple banking branches with only intermittent internet connections, and therefore want to be able to work offline easily while still querying the (albeit stale) database state.

Streams of messages don't work as well when you're multi-party, and the default state is offline, not online

In what way do stream of messages which are recorded by the receiver not work in this case, and how does the Blockchain differ?

That something else is called rsync.

> Though I imagine there's something else that can be used here as well...

Running transaction logs; you don't need to re download the entire DB twice a day. If you are disconnected, when you reconnect you give the last sequence number received. It is already built into FIX and other systems. Disconnects happen all the time in real trading systems and the ability to query past transactions doesn't go down.

Exchanges are a textbook case of a shared ledger. They have separate systems that must work in sync with very low latency between them: order processing, the ledger (for clearing) and price advertising.

The main advantage of a blockchain is with the ledger price advertising between exchange members comes free.

I guess they can even implement OTC markets between peers, but I am not sure how do they plan to work with dark pools where parties want anonimity. Maybe they will just implement an internal blockchain with APIs for anonymous trading.

> The "blockchain as a distributed transaction DB" concept is more interesting than I thought

Not particularly. It's using the wrong tool for the job. A distributed database is helpful in many ways, but you don't need an attached proof-of-work system.

> Not particularly. It's using the wrong tool for the job. A distributed database is helpful in many ways, but you don't need an attached proof-of-work system.

Blockchain doesn't imply PoW. You could consider each block minted with e.g. a M of N signature scheme, in the case of a stock-trading system you don't need open anonymous/participation and it's quite fine to rely on trusted parties.

I suppose, but at that point you're really blurring the line between 'blockchain' and 'authenticated database logs', and it starts to become a mere buzzword.

Yeah, every invoicing software in my country hash chains the documents for validation purposes (it's a requirement for SAF-T[1]), yet we don't call it a "blockchain".

[1] https://en.wikipedia.org/wiki/SAF-T

Because there are no blocks, no transaction ordering and no distributed consensus?

A block is just a structure with a set of transactions, a date and the hash of the previous block. SAF-T has all that, except the "blocks" have a single transaction. Transaction ordering is provided by the chain of hashes - each record/block links to the previous, just like in the Blockchain.

There is no distributed consensus, but that's the point - there doesn't seem to be here either.

'Blockchain' pretty explicitly specifies the data structure, the method of securing a block is an implementation detail. For example Proof of Stake is basically a variation on a M of N signature scheme.

At this point "blockchain" pretty much refers to a hash chain, transactions signed by private keys, and some kind of distributed consensus, which could be proof of work, proof of stake, or traditional byzantine consensus if you know who all the node operators are.

Without an incentive to "mine" blocks (cryptographically solve).. Anyone can write blocks to the network. How would the network ensure a trusted actor is writing blocks?

The way I understood the proof of work system is that it's there to determine which block is accepted as truth. So during a conflict, the first to solve the proof of work puzzle has their block accepted.

For distributed databases, when there are multiple conflicting transactions that touch the same data, I could see the proof of work as a method to determine which transactions win, especially in a global, multi-master model. When the proof of work puzzle is solved during conflicts, the transaction is accepted as truth and moves to a COMMITTED state. It seems kind of wasteful if you are paying for resources to solve challenges, but maybe there's a better way to decide who wins for trusted vs untrusted environments.

As an aside, Spanner I think acquires locks globally before writing. Maybe there's an interesting global-lock free model that just works using block chain, even if it's just for trusted parties (I.e. Google-internal).

You can have multiple winners at the same time. Proof of work doesn't solve the problem of conflicts. Everyone still has to pick which fork to follow, and you can't really consider something committed until it's buried under multiple blocks that you're confident the majority agree on.

Oh, you're right, I forgot about proof of work. I guess you can go in and remove proof of work to make a simpler blockchain. But then you're losing some of the plug-n-play aspects.

Reply on news.ycombinator.com