In this episode, Marley Gray from Microsoft joins the show to discuss enterprise smart contracts–why you would want to use them and how they can be architected. Marley has worked on banking and financial technology for over a decade, and makes some strong arguments for why banks will adopt smart contracts, and the timeline for how that might take place.
I thought this episode was particularly interesting when Marley talked about how an enterprise integration might occur between businesses using a shared ledger.
When doing something a stateless integration probably with REST, you can often end up coupling systems together through some variation of schema(probably JSON). You have types, often nested associations, and field names that each system needs to support. If you need real-time coordination between these information systems such as when a contracting company is fulfilling some services for a shared customer, having a stateless API doesn’t fit the bill very well. Both systems probably have very different implementations in place, and the complexity of polling, authentication, authorization, and handling record changes can get pretty complex when you’re dealing with database conflicts and reactive logic to said changes.
A good description of some of the challenges involved with using this sort of API in Elixir/Ecto might be Dennis Beatty’s recent talk at Lonestar. The gist of it is Podium is polling a Google REST API for Reviews, and processing changes for updates, handling conflicts etc. You end up running into some troublesome limitations with Postgres sequencing and what-not dealing with these upserts and conflicts.
The obvious alternative solution might be a messaging, pub-sub type integration where the two systems are coupled by a set of ubiquitous events that can then be handled by either system as needed. This could be done with a central server (Elixir/Erlang is a great fit) that runs some handshaking for authentication, sets up channels, and delivers encrypted events to the subscribers.
The problem with doing it this way is dependency on this central service. Which company is running this middle-man event-messaging service? What if there’s a conflict? What if one party distrusts the message being sent from this service? This is where having a distributed ledger becomes interesting. Both companies can host a node of this middle-ware service and maintain a copy of the ledger of the events. Now there’s no centralized dependency on a service hosted by either party, the same (potentially event-sourced) capabilities are supported.
Instead of the Google Reviews API requiring polling of stateless resources, you throw up a Node, download the ledger, and consume events into whatever architecture you prefer. You get an audit-able, event-sourced, Kafka-esque functionality between multiple parties that doesn’t have the same technical problems as stateless API integrations.
Anyone know similar systems being built like this? I find these patterns really interesting.
Great write up! Thanks for sharing that.
I did find this excellent list of use-cases for blockchain technology over at Hyperledger: https://wiki.hyperledger.org/groups/requirements/use-case-inventory.
Just one of the use-cases:
https://wiki.hyperledger.org/requirements/use-cases/use-case-find-a-provider
The more integrated is a health care delivery system, the less advantage there is to maintaining a provider directory in a blockchain. Conversely, as the relationship between the system and the providers becomes more fluid, the more compelling it is to implement both a consumer facing and a provider facing directory as a blockchain.
I’d consider that list and those related pages great sources of inspiration for anyone getting into blockchain development.
I also found the Golem blockchain platform (https://golem.network/), which was used to render CGI:
https://blog.golemproject.net/the-first-business-case-cgi-rendering-ad6f8942137f
Golem also has a monetary aspect in terms of their software marketplace, and seems they are putting software developers at the helm. Current market cap at $350m:
IBM is using Hyperledger as far I know. You can check theirs twit IBM Blockchain (@IBMBlockchain) / X
Hyperledger Foundation (@Hyperledger) / X
Be aware that that project (while probably great!), is not maintained by the Ethereum Foundation: It’s not hosted under the ‘Ethereum’ organization on GitHub, but under the ‘Exthereum’ organization.