Over the past few months I’ve been looking into banking infrastructure, and what it could look like if it was re-engineered with our current knowledge of software. I’ve touched on the UX experience for OTP, as well as started writing the payments portion.
As I continue development on this project (feel free to follow along at Github), I continually question assumptions and look for the best alternatives available. My understanding of the banking industry at a software and hardware implementation level (server organisation, regulation application, failovers, etc) is fairly limited, but strong enough to make a decent attempt on how it could be done.
As part of the payments processing I am currently tackling, I have started doing the database store. For now MySQL is being used for the transactions. Having a relational database is necessary and MySQL can be performant enough for most applications but the other choices included PostgreSQL, RethinkDB, and the likes of Hadoop and Apache Storm. At least some of these will be used in the application at some point, as trend observers and for statistics on bank usage as two examples.
The problem
The current client-server setup has many clients connecting to a single server (or servers cluster) which connects to a single database store (or database cluster). The problem this poses is that there are single instances of these servers, even if they are clustered. Database stores can be distributed through replication, and with MySQL it becomes fairly expensive.
Ideally, the architecture would have a multitude of servers and a multitude of databases all in sync with each other, where any single server can be used as an access point.
The blockchain
The blockchain provides a resilient option for a distributed database implementation, ideal for the above scenario. With each server having blockchain access, one could write a transaction from any server and it would be available to all other servers. Many clients can connect to many servers without concern on the underlying data validity. As a result, multiple banks may share access to this blockchain, allowing for interbank transfer regardless of geographical positioning.
Bitcoin and the blockchain
Bitcoin uses the blockchain as its underlying store, reading and writing to the chain and letting the chain propogate. Cryptography is used to check validity of transactions, and fees are taken implicitly on the blockchain as payment for miners on the network.
Our implementation would exclude Bitcoin as we do not need a currency store and we need to do more than have a single type of information stored on the chain. Bitcoin transactions have a sender, recipient, amount deducted from sender, amount received by recipient, and implied fee (see here for a detailed explanation of transactions). This is suitable for transactions, but not for anything more complex - loan origination, asset handling, contracts, etc.
Multiple companies have addressed this by creating their own chains (or side chains), or writing new ones completely based on the blockchain. These chains are either company-specific or proprietary, and many involve some currency. The ideal we are searching for is: an extendible, open blockchain which allows for any asset to be written to it while maintaining the cryptographic standards currently available in the blockchain.
Finding a blockchain sans Bitcoin
Certainly this idea of using the blockchain has been thought of before (hence companies being built around various implementations), so it would make sense that there is some code or literature detailing how this is done. To date, I have found nothing close. All bitcoin code is available, in various implementations and languages, but nothing that is an accessible blockchain. This could be for several reasons:
- It is a technically complex task to do properly
- Companies already involved in this space want to maintain early mover advantage
- The demand is not yet high enough to warrant the development
Whichever reason it is, the result seems to be the same: if a transaction agnostic blockchain is needed, it will have to be developed.
Note: if this is not the case, and you know of a codebase or tutorial, please get in touch and point me in the right direction.
The net result is that a blockchain is a far superior data store for what I am aiming to achieve with the banking infrastructure I am currently building out. Being fairly proficient in Go it is my language of choice for this project, and I managed to find an implementation of the Bitcoin code in Go. From initial observation, I have found some places of interest where message length and type could be altered.
Conclusion
The blockchain has garnered some great interest in the financial industry for good reason. Having an accessible blockchain to use in development for any application would be helpful, and building it will give great insight into the Bitcoin core. The next steps are to build out the bank using simple database stores for accounts, transactions and more. The blockhain will then be separately researched and built out. The goal is then to replace transactions (and perhaps more) with the blockchain.
Definitely a long and exciting road ahead.