On-chain Privacy through Decentralized Private Computation?

In one of my previous articles, I touched on the transformative benefits Zero-knowledge-proof can offer to online identity solutions while drawing attention to the transparency issues (public) distributed ledgers currently face. Privacy, security and scalability are all factors that currently hinder the integration of decentralized technology into valuable applications. In this article, I aim to shed some light on how private computation can further the development of privacy orientated decentralised applications.

What is Decentralized Private Computation (DPC) and why should I care?

Essentially it’s a process that allows computation of sensitive data to be executed in an encrypted or secure environment across multiple remote servers or nodes. Depending on how we, as individuals, classify sensitive data, private computation offers value to those of us who are concerned with keeping sensitive data secure through transit.

That being said —decentralised private computation solutions have recently begun to provide value to blockchain and DLT, partly because they enable an applications internal state functions to execute privately in a trusted/trustless system as opposed to transactions (payment details and function calls) executing visibly on-chain, as is the case with such applications (Dapps) based on Etherum.

If we intend to use blockchain/DLT as underlying security for a new internet (WEB 3.0) we need to be able to develop Dapps that don’t just cater for financial trading, games and gambling but can securely process users application data in a fast, trusted and secure manner while giving the end-user control and interoperability over their data…. (If only it was so easy!)
Of course, there is always a trade-off between privacy and performance…

So is it possible to execute code privately for Dapps without adding to exhaustive latency times?

Well, let's firstly identify two main proposed solutions that currently attempt to do this. After that, I will attempt to briefly outline the main comparisons between them and the issues they face in terms of scalability and effectiveness.

I would like to draw your attention to two recently published papers — (don't worry I will try and keep it concise)

1. Zexe: enabling decentralized private computation (DPC). https://eprint.iacr.org/2018/962.pdf, A recently published paper that provides an alternative solution to hiding application functions using homomorphic encryption processes’. Namely, a combination of ZK-STARKS and ZK-SNARKS technology, co-authored by scholars from UC Berkley, Cornell Johns Hopkins University and Z-cash.
2. Blockchain and Trusted Computing: Problems, Pitfalls, and a Solution for Hyperledger Fabric. This paper focusses on TEE’s (trusted execution environments) Namely Software guard extensions (SGX) that enable private computation on hyper-ledger. https://arxiv.org/pdf/1805.08541.pdf Co-authored by Scholars from TU Braunschweig and experts working at IBM.

Both articles aim to solve the same problem of on-chain DPC in distinct ways and have been published by reputable schools of thought.
Zcash, who initially integrated ZKP protocols for on-chain transactions, is partly to thank for by combining this technology with real-world use cases (in their case currency) and kickstarting a new field of research and development around ZK-SNARkS and ZK-STARKS.

The first paper (and more recent) outlines the components necessary to develop a first use-case that allows rich decentralised applications (Dapps) to process data off-chain privately using homomorphic encryption methods.
This unprecedented proposal argues that private computation can be executed in a decentralized network using zero-knowledge succinct cryptographic proofs (zkSNARKS) to verify private code executions carried out on an external clients CPU. Meaning anyone operating in a decentralized network could securely execute private computation on their personal CPU for the benefit of Dapps.

Usually, the cost to produce cryptographic proofs is high in terms of latency. However, Zexe manages to reduce their transaction verifying times to tens of milliseconds, where a transaction size is typically 968 bytes. Something that ‘Zexe’ argues can be improved over time through “more efficient engineering”.
This is good news compared to other attempts that try to implement similar zk-SNARK systems.

This protocol has apparently been tested and is technically open source to those who are able to understand the papers technicalities. The goals are ambitious, and they stress on their Github page that the protocol is not yet ready for production use.

The comparable solution, examined by the second paper is that of TEE’s (trusted execution environments) such as SGX: Software guard extensions that are essentially a type of TEE relying on the security of the hardware as opposed to cryptographic protocols (although there is cryptography used in both solutions)
As Andreas Slammer summed up in his article on SGX:

“It (SGX) hinges on the hardness of breaking the hardware rather than the hardness of breaking a maths problem.”

SGX is particularly interesting as it is a solution that is currently available and already in use.
So let's quickly look at the two 2 main components of SGX before discussing some of the issues it still faces.

Enclaves and Attestation

If you are unfamiliar with any of the above words I will attempt to clarify them…
The core component of SGX is to understand that computation can be executed in a separate hardware area called an Enclave.

Enclaves: This is the main area of a TEE that can process code securely. An enclave is an isolated section of a CPU that enables certain code to be processed securely before sending it back to the application that has embedded it.
Hardware enclaves can be used in ledger based systems such as Ekiden: to achieve privacy in smart contracts, https://medium.com/zkcapital/ekiden-a-hardware-approach-to-privacy-maintaining-smart-contracts-c75ba67915b2, and can be used to process rich applications in a satisfactory time period.
(A decentralized use case: could be a node executing a contract in an enclave.)

Attestation: (most of you will know) just means that a declaration has been made through a type of verifiable ‘proof’.
In this case, Intel is responsible for verifying that the code had been processed and signed by one of their secure Intel CPU’s through a report that is sent to the user verifying that it has been executed privately by Intel’s root key. (This is a simplified description, so for more on the details regarding this process please see here.)

Sounds pretty robust, however, there are still some issues with SGX… as you might have already noticed.

1. Accessible root keys: The solution has been developed by Intel and essentially they need to sign off the authentication. This raises further questions regarding Intel accessing enclaves if needed. As Victor Costan — PHD at MIT noted:

“It is very unlikely that you will be able to use SGX in your software products. Intel’s documentation has some pretty subtle hints, but if you follow the trail, you’ll realize that SGX enclaves have to either be signed directly by Intel, or be signed by a key that was signed by Intel.”

2. Hardware can still be hacked depending on the development process (see china hacks: https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

3. Centralization, It is not really a decentralized solution as the code is still executed at a single centralized point governed by a private entity.

So, if you are happy with Intel providing the security for your ‘private’ then a hardware solution might be the best bet to experiment with.
On this note, it is worth mentioning that some companies are already making noticeable headway in the adoption of private computation for decentralised services such as Enigma. They managed to integrate both SGX and secure multi-party computation into their protocol.
Recently partnering with Intel they stated in a blog post from December:

“ Today we announce that Enigma is partnering with Intel on research and development efforts to advance the development of privacy-preserving computation technologies. As a part of this effort, Enigma will utilize Intel SGX (Software Guard Extensions) in building our groundbreaking privacy technologies. With Enigma’s solutions, data is protected while still allowing for computation over the data as part of a scalable, secure solution.”

So both DPC solutions have pros and cons depending on the individual use cases. But are they an alternative (better) solution to simply having hash pointers on-chain that are used to retrieve encrypted information from centralised databases?

Zeff is a DLT Enthusiast with a focus on network governance and works as a community-driven and content marketing expert.