Mar 15 2017
- last edited on
May 26 2021
While some application can leverage the benefit of distributed trust that a Blockchain solution inherently offers, they might need certain information visible only to certain participants of the contract. Does the Azure Blockchain team have on their roadmap a layer to allow private data to be shared over the blocks (in the likes of Quorum)?
Mar 15 2017 09:21 AM
Confidentiality is definitely a requirement for most consortium scenarios, and is something that we on the BaaS team spend a lot of time thinking about. Quorum is already available in the Azure Marketplace as a single-VM template, with a multi-VM template coming soon. In the future, Cryptlets will allow you to perform off-chain computation that can be private to two or more parties, only writing to the ledger when necessary.
Mar 15 2017 09:39 AMSolution
This is a great question.
On the public networks, in the absence of fancy crypto like zero-knowledge proofs or homomorphic encryption (both of which incur time and space penalties), there is no way to prevent double-spending of tokens other than posting all transactions in the clear. Even if counterparties are using addresses and keys that provide anonymity, the basic details of the transaction are visible to the public, and the anonymity of the keys might later be unmasked in whole or in part in subsequent transactions. One option is to take transactions off chain, say using state channels. There are tradeoffs involved in this design choice as well - for example the requirement to commit enough resources to a state channel up front - which may require commitment of tokens that aren't spent in the end, and that could have been used as working capital elsewhere.
In the enterprise context privacy gaps can preclude the use of blockchain for many scenarios and we have heard clearly from customers that they are looking for solutions. There is a lot of great work going on across the industry (e.g. Quorum's support for private transactions, Chain's support for homomorphic encryption, R3 Corda's ability to limit transaction propagation to counterparties with non-validating notaries). Many of these capabilities are either already available on the Azure Marketplace through partners or are coming soon.
We have some research going on in this area in partnership with teams in Microsoft Research that we hope to be able to share soon as well.
Meanwhile there are two patterns we're looking to support in the near term. The first is to use the blockchain to anchor identities represented by public/private key pairs. A participant can post a transaction that establishes the public key representing a person, place or thing; with a payload that points to off-chain services for this identity. Identities established this way on the blockchain can then transact off-chain with whatever protocols and privacy guarantees that they like. This is suitable for many scenarios, but not all scenarios. Daniel Buchner is our resident expert here - see https://www.linkedin.com/pulse/were-hiring-come-work-open-source-decentralize-identity-buchner for example.
The second pattern is to package up logic and data off-chain for use in cryptlets, which can then post results on-chain. The off-chain code and data can remain private - but the assurance provided is still strong because the attestation of the off-chain code is used to authenticate the on-chain result. This seems to be a pattern that works well for enterprise applications.
Is this helpful?
Mar 15 2017 10:12 AM - edited Mar 15 2017 10:16 AM
This helps a great deal in what to expect in the coming days. I find both proposed patterns intriguing. Especially the anchor identities that Daniel Buchner is working on. This pattern if I understand correctly, will allow applications to leverage the identity trust over a Blockchain while sourcing Business logic over traditional services. This makes adoption easier.
I will be exploring Cryplets in detail over the coming days. I've found the documentation on Bletchley a bit scarce; I'll be making an effort with what is available.
Thank you for your response, and good luck to your team :)