[tmail21]

The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see everything" are not the end user, whereas, in Blockchain because the nodes are untrusted, one must assume that the end user can see the entire Blockchain state.

This limits the number of use-cases tremendously to those where "everyone-can-see-everything" is an acceptable tradeoff.

There are several ways around this.

1) Zero Knowledge Proofs. But these are highly specialized and resource intensive. To my knowledge we don't have these for generalized Smart Contracts.

2) Split the overall state into Channels, Subledgers etc. with narrower "viewing rights". But again this typically involves an application compromise.

3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts.

4) Use frameworks like Microsoft's recently released CoCo Framework which relies on Hardware Trusted Execution Environments (TEE). The issue here is that a compromise of a single TEE negates the whole scheme.

In my opinion the privacy characteristics of Blockchain are a critical factor that needs to be taken into account while deciding on the suitability of Blockchai for an application.

[hobozilla]

Can you clarify the disadvantages of the application compromises required for option 2?

I'm currently looking at Hyperledger Fabric and it falls into that category.

[tmail21]

Sure. Hyperledger Fabric 1.0 has the option of "Channels" to limit viewership rights. In particular it restricts rights to a subset of the community. For example, you may have a 1000 parties in the community, but a particular channel may have only three (say A, B and C).

Now, if one takes a Supply Chain example (a domain I'm quite familiar with), most transactions cannot be restricted to just parties A, B and C. Some will involve A, B and D and some will involve B, C and F etc. So, it is difficult to come up with a suitable Channel membership model.

Even if the transaction is between A, B and C often the view rights are not symmetric. For example in a drop ship case where A is the Buyer, B is the seller and C is the fulfiller, the price attribute may need to be visible between A and B but not C. This is not possible with the Channel approach.

So this particular type of hard partitioning only works for the simplest Supply Chain examples.

Another type of hard partition is to partition by Transaction. But this involves issues such as synchronization between transactions. This becomes an off-chain concern with major consistency issues.

Hope this helps.

[hobozilla]

Thank you that was a very helpful answer

[colordrops]

> 3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts.

This will change once homomorphic encryption is feasible.

[kolinko]

He mentioned zero knowledge proofs in point (1) - that includes homomorphic encryption if I'm not mistaken.

[mhluongo]

We're working on 5), a privacy option for public blockchains using secure multi party computation. Few application trade-offs (mostly around availability logic and additional cost), no private or trusted chains.

[devbug]

My recent work focused on applying sMPC.

Garbled circuits don't scale.