What this framework appears to do is enable your endpoints to participate in a one-way fashion. So they will get just enough information to facilitate a transaction but nothing beyond that.
It seems like a bit of cloak & dagger tomfoolery where the blockchain is just being implemented behind-the-scenes on a specified collection of servers but I haven't looked very deep yet. I can see the benefit to Microsoft from having a setup like that--they can allow customers to participate in a blockchain-utilizing system without giving them full access to the blockchain but to me that seems like defeating the purpose and unnecessarily trusting a 3rd party to handle all your transactions with no independent way of verifying said transactions.
In other words, it's no different than just standard server-client architecture except instead of handling transactions through a database (the traditional way) they utilize a blockchain in the background. When you want to verify a transaction you're really just making a request to their central server and asking it to do the job for you--and trusting whatever it tells you.
Not exactly a proper blockchain if you ask me.
The key is who is running that "specified collection of servers". If they're all yours, then yeah, there's no advantage to just running your own sql-ish cluster.
However, what if now your p2p miner pool includes a few machines run by your regulator? Yes, your business logic endpoint nodes are participating in a one-way fashion, but their transactions are now being automatically logged by the regulator (regulator doesn't need to know what the underlying business logic is, just that the reportable transaction results are being logged in the blockchain they're part of). Something like a third of financial firms' business is around reporting requirements.
Or consider a large supply chain... again the miners aren't just one company, it's everyone in the supply web or the consortium. Allows for coordination without necessarily being open to the public.
>This is because existing systems were designed to function—and to achieve consensus—in public scenarios amongst anonymous, untrusted actors with maximum transparency. Because of this, transactions are posted “in the clear” for all to see, every node in the network executes every transaction, and computationally intensive consensus algorithms must be employed. These safeguards, while necessary to ensure the integrity of public blockchain networks, require tradeoffs in terms of key enterprise requirements such as scalability and confidentiality.
..
>Coco achieves this by designing specifically for confidential consortiums, where nodes and actors are explicitly declared and controlled. Based on these requirements, Coco presents an alternative approach to ledger construction, giving enterprises the scalability, distributed governance and enhanced confidentiality they need without sacrificing the inherent security and immutability they expect.
(This assumes the public chain is unsuitable for scalability or confidentiality reasons.)