In a previous post, I discussed approaching the topic of Blockchain from a top-down point of view.
This approach focuses first on the business logic that interacts with the ledger and not the ledger itself. The business logic simply desires an API to insert new transactions into the ledger and read old transactions from the ledger. The business logic may make some assumptions about ledger characteristics (e.g. immutability, structure, digital signatures, etc) but it typically desires no knowledge of HOW the underlying ledger is operating.
At last week's Cloud Foundry Summit we began to see a discussion on application integration with ledgers.
This integration can be thought of as the "top half" of an application framework (e.g. Cloud Foundry) connecting with new ledger applications via an API.
In this post I'd like to consider the "bottom half". How can an application framework automatically program the ledger for the needs of the application?
While the application itself may not care about underlying ledger details, the infrastructure team most certainly will care that the ledger is implemented in a way that meets a variety of enterprise requirements.
In other words, the next generation of enterprise ledgers will require devops programmability for specific application use cases. Distributed ledgers must present software APIs that allow for on-the-fly adjustments to scale, capacity, horsepower, and a number of other capabilities.
I believe the first step towards automatically programming ledgers is to enumerate required capabilities. Here are some of the items worth considering.
- Consensus algorithms. My colleagues at VMware research have been conducting quite a bit of research into scalable, resilient consensus algorithms. They have pointed out that some consensus algorithms (e.g. Paxos) perform well up to a certain node limit (e.g. 5-7 nodes). Beyond this limit, a different, industrial-grade Byzantine approach must be employed (see VMware research paper). Should there be a ledger API for selecting from a menu of consensus options? Consensus algorithms are closely related to scale.
- Push-button scalability. Sudden surges or spikes of transaction insertions into a ledger may require immediate scaling in terms of how many ledger entry points exist within a system. This can be accomplished in a variety of ways, including (a) peer-to-peer discovery of new nodes, or (b) controlled communication of new nodes to existing peers. Either of these options (or more) could be invoked via API.
- Network Programmability. A ledger may be limited to one geography or it may span the globe. A ledger may exist entirely on a corporate backbone or it may participate in a torrent-like public network. There may be a strong desire for network encryption or there may be a mandate for open, cleartext transfer. Ideally, all of these permutations could be configured and controlled via API.
- Service Levels. Public ledgers like Bitcoin can get away with "eventual validation", but enterprise ledgers will mandate a variety of service level agreements in areas such as performance, reliability, and availability. These SLAs must be programmed into the ledger implementation (integration with the network programmability mentioned above will be critical).
- Smart Contracts. The execution of smart contracts will require strong distributed computing support from the underlying infrastructure. In the same way that flexibility in distributed consensus algorithms is needed, so it is with the execution of distributed smart contracts.
I believe the industry will evolve towards SDDLs (software-defined distributed ledgers) as a result of prototyping activity. These prototypes will stand up a variety of ledger implementations (Ethereum, Corda, Hyperledger, Multichain, etc) and begin to wrap automation around them. The automation will then need to converge to standard APIs that work against disparate ledgers.
Note that there are multiple companies applying themselves to this problem. One of them is Monax/Eris. Another is BlockCypher.
In future posts I will track the evolution of SDDLs and monitor their integration with frameworks such as Cloud Foundry.
Steve
Thanks for sharing.
Posted by: Jayson | July 01, 2017 at 05:42 AM