In this post, I’ll explain what computational privacy is and how it’ll unleash a whole new wave of applications for Web 3.0.

Let’s start with where it all began. Eric Hughes, one of the founders of the cypherpunk movement and the author of ‘A Cypherpunk's Manifesto’, wrote on March 9th, 1993:

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know. Privacy is the power to selectively reveal oneself to the world.

If you’ve not read the whole thing, you really should. It provides a beautiful backdrop to everything that’s happening in the space.

We all know what followed. Satoshi publishes the Bitcoin white paper on October 31st, 2008, and it’s here again we can point to the brilliance of Eric Hughes:

Privacy in an open society requires anonymous transaction systems

And for a long time, this is what Bitcoin provided. However, over time, this became less and less true as it turned out that with complex methods of parsing and analysing the Bitcoin graph and, in particular, people’s on-ramps, the anonymity that Bitcoin provided began to erode.

What followed was attempts to improve on the anonymity of Bitcoin using the technology developed by “Nicolas Van Saberhagen” (another entirely anonymous author) with Bytecoin in 2012. Monero (a fork of Bytecoin) and Z-Cash followed afterwards.

All of these were attempts to provide ‘transactional privacy’. That is, the ability to empower individuals to reveal their identity or intentions only when desired; this is the essence of privacy. In practical terms, this implies privacy over the participants in a transaction, what they’re transacting and the outcome and impact of any transaction.

In essence, we know a transaction has taken place, **but **all the contents of the said transaction are obfuscated.

What if we wanted to go further and not only obfuscate transactions but completely shield their very computation on any computer from anyone?

What if we wanted absolute certainty that the code we think is running really is running, but without actually seeing it run?

Now surely, code has to run somewhere, and someone is always going to have access to the machine running the code?

What if I said computational privacy delivers on all of the above

• Complete privacy over the entire processing of any data

• Absolute certainty that the code we upload really is running

• Nobody, not even the owner of the machine, can access the running code

The above scenarios demonstrate:

1. No privacy. Alice sends 1 BTC. It gets verified on the Bitcoin blockchain and is now allocated to Bob. Everyone sees this.

2. Transactional privacy. An unknown sender sends an unknown amount of BTC. It gets verified, and balances of an unknown amount are updated. Everyone only sees this.

3. Computational privacy. Nothing at all is leaked. Nobody even knows there was a transaction, let alone who was involved or what amounts.

Let’s add some further context by running through an NFT use case.

Apymon was an NFT project released back in early 2021. The idea was novel. An egg-shaped NFT, and a good looking one at that, probably something that could have acted as an NFT in its own right.

To add to the mystique, Apymon had a secret, a secret contained within the egg. It was a little monster. In addition to this, there was the promise that some eggs would contain Cryptopunks and other popular NFTs as well as Ether.

But with everything being transparent, how was this possible? It wasn’t.

It was impossible to build a solution that kept the contents of the eggs hidden in a fair and decentralised way. The only solution was to centralise. And this immediately was met with claims from the community that the developers had purposely allocated the hidden rewards to eggs held by them and insiders. The project was a failure.

How would this be different with computational privacy? If we think back to what computational privacy gives us:

• The code for the project along with verifiably random initialisation functions could have been deployed to a network that provides computational privacy, like Ten.

• With this, we’d have absolute certainty that every egg being minted has been allocated hidden rewards in a completely random way — private even from the developers themselves.

• Nobody (and I mean nobody) would ever know the contents of a particular egg until the owner of that egg had ‘opened’ it.

• This act of opening would be completely private — an action between the owner and the ‘network’ only.

It turns out, that there is only one solution that can provide this type of computational privacy. It’s Trusted Execution Environments (TEEs).

A Trusted Execution Environment is a secure area of a central processor or CPU. It guarantees that code and data loaded inside are protected with respect to confidentiality and integrity as it is processed.

TEEs provide the ability to:

• Keep cryptographic key material secret.

• Prevent other people from spying or seeing transactions happen, including the owner or operator of the TEE.

• Search encrypted, sensitive data.

• Sign with cryptographic keys.

• Execute code with complete privacy.

• Attest to the code to provide guarantees that what you think is running really is running.

Solving all of the above is an unsolved problem without the use of TEEs. Zero-knowledge proofs cannot solve this set of problems, and homomorphic encryption is still in its infancy. TEEs provide a pragmatic, elegant solution.

The blog post here by Gavin Thomas, presents a great mental model.

If you’re interested in learning more about Ten, check out our litepaper or dive into our whitepaper. Chat with the community on Discord and follow us on Twitter. You can also follow our announcements on Telegram.

In this post, I’ll explain what computational privacy is and how it’ll unleash a whole new wave of applications for Web 3.0.

Let’s start with where it all began. Eric Hughes, one of the founders of the cypherpunk movement and the author of ‘A Cypherpunk's Manifesto’, wrote on March 9th, 1993:

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know. Privacy is the power to selectively reveal oneself to the world.

If you’ve not read the whole thing, you really should. It provides a beautiful backdrop to everything that’s happening in the space.

We all know what followed. Satoshi publishes the Bitcoin white paper on October 31st, 2008, and it’s here again we can point to the brilliance of Eric Hughes:

Privacy in an open society requires anonymous transaction systems

And for a long time, this is what Bitcoin provided. However, over time, this became less and less true as it turned out that with complex methods of parsing and analysing the Bitcoin graph and, in particular, people’s on-ramps, the anonymity that Bitcoin provided began to erode.

What followed was attempts to improve on the anonymity of Bitcoin using the technology developed by “Nicolas Van Saberhagen” (another entirely anonymous author) with Bytecoin in 2012. Monero (a fork of Bytecoin) and Z-Cash followed afterwards.

All of these were attempts to provide ‘transactional privacy’. That is, the ability to empower individuals to reveal their identity or intentions only when desired; this is the essence of privacy. In practical terms, this implies privacy over the participants in a transaction, what they’re transacting and the outcome and impact of any transaction.

In essence, we know a transaction has taken place, **but **all the contents of the said transaction are obfuscated.

What if we wanted to go further and not only obfuscate transactions but completely shield their very computation on any computer from anyone?

What if we wanted absolute certainty that the code we think is running really is running, but without actually seeing it run?

Now surely, code has to run somewhere, and someone is always going to have access to the machine running the code?

What if I said computational privacy delivers on all of the above

• Complete privacy over the entire processing of any data

• Absolute certainty that the code we upload really is running

• Nobody, not even the owner of the machine, can access the running code

The above scenarios demonstrate:

1. No privacy. Alice sends 1 BTC. It gets verified on the Bitcoin blockchain and is now allocated to Bob. Everyone sees this.

2. Transactional privacy. An unknown sender sends an unknown amount of BTC. It gets verified, and balances of an unknown amount are updated. Everyone only sees this.

3. Computational privacy. Nothing at all is leaked. Nobody even knows there was a transaction, let alone who was involved or what amounts.

Let’s add some further context by running through an NFT use case.

Apymon was an NFT project released back in early 2021. The idea was novel. An egg-shaped NFT, and a good looking one at that, probably something that could have acted as an NFT in its own right.

To add to the mystique, Apymon had a secret, a secret contained within the egg. It was a little monster. In addition to this, there was the promise that some eggs would contain Cryptopunks and other popular NFTs as well as Ether.

But with everything being transparent, how was this possible? It wasn’t.

It was impossible to build a solution that kept the contents of the eggs hidden in a fair and decentralised way. The only solution was to centralise. And this immediately was met with claims from the community that the developers had purposely allocated the hidden rewards to eggs held by them and insiders. The project was a failure.

How would this be different with computational privacy? If we think back to what computational privacy gives us:

• The code for the project along with verifiably random initialisation functions could have been deployed to a network that provides computational privacy, like Ten.

• With this, we’d have absolute certainty that every egg being minted has been allocated hidden rewards in a completely random way — private even from the developers themselves.

• Nobody (and I mean nobody) would ever know the contents of a particular egg until the owner of that egg had ‘opened’ it.

• This act of opening would be completely private — an action between the owner and the ‘network’ only.

It turns out, that there is only one solution that can provide this type of computational privacy. It’s Trusted Execution Environments (TEEs).

A Trusted Execution Environment is a secure area of a central processor or CPU. It guarantees that code and data loaded inside are protected with respect to confidentiality and integrity as it is processed.

TEEs provide the ability to:

• Keep cryptographic key material secret.

• Prevent other people from spying or seeing transactions happen, including the owner or operator of the TEE.

• Search encrypted, sensitive data.

• Sign with cryptographic keys.

• Execute code with complete privacy.

• Attest to the code to provide guarantees that what you think is running really is running.

Solving all of the above is an unsolved problem without the use of TEEs. Zero-knowledge proofs cannot solve this set of problems, and homomorphic encryption is still in its infancy. TEEs provide a pragmatic, elegant solution.

The blog post here by Gavin Thomas, presents a great mental model.

If you’re interested in learning more about Ten, check out our litepaper or dive into our whitepaper. Chat with the community on Discord and follow us on Twitter. You can also follow our announcements on Telegram.