I was talking with a colleague today about practical applications of blockchains outside cryptocurrencies, and he defended the opinion that blockchain is nowadays used more than ever, but the vast majority of these uses are for private, intra- or inter- company applications.
Which is all fine and good, but... why bother?
Assuming that what businesses really want is "trust as a service" (how's that for a nebulous but catchy idea?), why introduce all the complexity of current blockchain solutions, without making use of the trustless, globally distributed parts of the technology at the same time?
So, here's how to implement *all* the functionalities of a private PoA blockchain with completely traditional, proven technologies - and without even mentioning specific products and / or vendors.
Authority in the context of "proof of authority" in blockchains refers to two things: assigning authorship information to blocks, and having the authority (permission) to create blocks.
Both can be implemented by having an ordinary Certificate Authority (CA) or a similar way to issue keypairs - even PGP can work here - and assign keypairs to nodes. Nodes which group transactions (records) into blocks can sign the blocks with their keys in ways which are industry standards for at least the last 20 years. Serialisation of transactions into blocks can be done by using any existing technology from XML, to JSON, to BSON, to Protocol Buffers or anything else.
Original, signed block data can be stored as binary blobs in a database or in the file system, and unpacked block data can be stored in a SQL database for easy access (or just go the easy way and use SQLite for both).
tl;dr:
In fact, several highly exposed blockchain projects do more or less exactly that: HyperLedger and Stellar.
An important feature of most blockchains is that there are business rules enforced for transactions (e.g. the sending account needs to have enough coins to send), which in modern blockchains is partly done with hard-coded rules (such as that one about having enough coins) and "soft" rules which are changeable / dynamic, implemented as smart contract code (there's also the case for a third, middle layer).
Distributed consensus simply means all nodes verify blockchain data in exactly the same way - those nodes which arrive to the same conclusion are considered "correct" and "friendly." Luckily, rules for verification are also just data which can be transferred in transactions.
Transaction data can be either structured or unstructured - it doesn't really matter as long as it can be serialised into a binary blob which can be a part of a block's blob, in a way which is stable (always exactly the same). This means that, if there's an ordinary SQL table, and we have a way to serialise a row in a stable way, this is enough for this table's data to be a part of blockchain blocks.
The concept of smart contracts becomes a bit tricky to implement with just the database. While we could, in theory, create triggers and stored procedures from code which arrives in transactions, this is a nightmare to maintain, especially since stored procedures in modern databases can do literally anything, including executing operating system tools. Embedding a scripting language (like Lua, Python, or JavaScript) into an app is reasonably easy nowadays, but carries almost the same security risks.
tl;dr:
Unless there's a compelling reason for grouping transactions into blocks, for example if the block creation process involves a special kind of verification of its contents, or we can't easily establish the order of transactions because there are too many of them, we can do without blocks, and chain transactions together.
Even more, if we can rely on digital signatures to ensure data immutability, and we can ensure sequentiality of data in some other way (a counter?), we don't need to chain any data together at all.
In fact, if there's a stable representation of data records which can be digitally signed, we can almost always do away with any blockchain-like structure and simply store a digital signature of the record, either in the same SQL table (or a NoSQL document) or another.
For a reasonably small number of nodes, we don't need any special software in addition to existing database replication capabilities. The exact number where this becomes tedious depends on the choice of the database.
Database replication for modern databases usually includes mechanisms for SSL client validation and / or logins which limit which nodes can distribute data to which. This basically implements the same mechanism as the PoA blockchains use.
For more flexibility or to implement missing features, a reasonably thin replication layer could be implemented on top of databases which would perform data replication on the application layer. Since blockchain data is append-only, this layer doesn't have to deal with any data update conflicts. If there's need for it, this API can participate in the consensus part of the blockchain workflow, i.e. it can validate blocks and / or transactions as they are passed from one node to the other.
tl;dr:
This is the easiest step of them all - REST APIs for web applications are being built by the thousands daily. So just do what makes sense in this case.
Same as before, if there's need for it, this API can participate in the consensus part of the blockchain workflow, i.e. it can validate blocks and / or transactions as they are passed to / from the node.
Instead of maintaining a blockchain network, esp. if they are of the large "enterprise" variety, all of its functionalities can, in case of PoA, be implemented with a generic database, with some thought given to db schema design, with a modest knowledge of cryptographic APIs, and with a thin API layer which is likely to be implemented with around 500 lines of Python code.
We really don't need expensive products for this.
