In his recent blog post, ‘The Three Transitions’, Vitalik Buterin delineates the key challenges that must be addressed by the Ethereum ecosystem. These issues encompass various user experience (UX) facets, such as cost, confidence to store assets, and the lack of data transparency. Ethereum’s long-term competitiveness against centralised services hinges on the ability to offer a similar UX.

Vitalik explores the privacy transition with specific applications in mind, like payments and identity. In this article, we’ll build on that foundation and delve deeper into the challenges of achieving general-purpose privacy.

Consider a scenario where an Ethereum Layer 2 (L2) is developed where the entire ledger is encrypted. In such a scenario, users submit encrypted transactions, which are then processed in encrypted form, and the nodes return encrypted payloads, accessible only to designated users.

Building on this L2 would theoretically enable the development of decentralised applications (Dapps) that function much like typical centralised ones. This is because these Dapps could selectively reveal information only to those who are meant to see it. Whether it’s an online banking customer wanting exclusive access to their account balance or a social media user wishing to share a photo only with select family members.

Developers of Ethereum Dapps, having already adapted to a specific language and environment, should ideally be able to continue with their familiar toolset, even when the ledger is encrypted. Let’s posit that this envisioned encrypted L2 is perfectly EVM-compatible.

However, requirements need to be identified.

At a superficial level, one might think that a Turing-complete language should suffice to accommodate any privacy features. Developers could simply append access control logic to the ‘view functions’ exposing user data to execute any access policy. Sounds like a problem solved? Not exactly.

There are a few nuances that warrant further attention.

• Ethereum-compatible L2s expose the“eth-getStorageAt” RPC call, which enables access to the internal state of any contract, bypassing the “view functions”. This option, naturally, would be nonviable.

• Ethereum RPC calls are not authenticated. For a view function to make access control decisions, it needs to know who is making a call.

• Access to platform-specific resources such as transactions, receipts, and general account data (like native balance, code, and nonce) must also be controlled.

• The most challenging aspect is event logs. These are custom payloads generated by smart contracts, typically used by UIs. Given Ethereum’s data transparency principle, they weren’t designed with access control in mind. However, the objective of our encrypted platform is to ensure data protection by default, providing developers with the tools to establish access control rules, including for events.

• Lastly, the information destined for users needs to be encrypted with “viewing keys” ( or “encrypted keys”)

A user’s interaction with an encrypted L2 should align with their typical Ethereum experience. This can be realised if the user can access necessary data, such as allowed photos or current balance, but without anyone else viewing their personal balance.

As Vitalik also pointed out, this experience demands efficient encryption key management. These keys may be, and preferably should be, distinct from the spending keys.

The realisation of the privacy transition is not only a cryptographic challenge but also an exploration journey of the optimal user and developer experience. At Obscuro, we align with Vitalik’s vision and have been working tirelessly over the past year and a half to build a platform that embodies this ideal.

While we wait for technology like Fully Homomorphic Encryption to become practical, this journey should begin with less than perfect technology, such as Trusted Execution Environments (TEEs), and apply to use cases like gaming, or DeFi that doesn’t need perpetual privacy. After all, numerous successful ideas took their first steps in the world of games.

As we continue to explore these critical themes, your thoughts, ideas, and critiques are invaluable. Head over to our Obscuro Discord server, where our community is constantly brainstorming and dissecting these complex issues. Your insights could be the key to the next breakthrough. See you there!

In his recent blog post, ‘The Three Transitions’, Vitalik Buterin delineates the key challenges that must be addressed by the Ethereum ecosystem. These issues encompass various user experience (UX) facets, such as cost, confidence to store assets, and the lack of data transparency. Ethereum’s long-term competitiveness against centralised services hinges on the ability to offer a similar UX.

Vitalik explores the privacy transition with specific applications in mind, like payments and identity. In this article, we’ll build on that foundation and delve deeper into the challenges of achieving general-purpose privacy.

Consider a scenario where an Ethereum Layer 2 (L2) is developed where the entire ledger is encrypted. In such a scenario, users submit encrypted transactions, which are then processed in encrypted form, and the nodes return encrypted payloads, accessible only to designated users.

Building on this L2 would theoretically enable the development of decentralised applications (Dapps) that function much like typical centralised ones. This is because these Dapps could selectively reveal information only to those who are meant to see it. Whether it’s an online banking customer wanting exclusive access to their account balance or a social media user wishing to share a photo only with select family members.

Developers of Ethereum Dapps, having already adapted to a specific language and environment, should ideally be able to continue with their familiar toolset, even when the ledger is encrypted. Let’s posit that this envisioned encrypted L2 is perfectly EVM-compatible.

However, requirements need to be identified.

At a superficial level, one might think that a Turing-complete language should suffice to accommodate any privacy features. Developers could simply append access control logic to the ‘view functions’ exposing user data to execute any access policy. Sounds like a problem solved? Not exactly.

There are a few nuances that warrant further attention.

• Ethereum-compatible L2s expose the“eth-getStorageAt” RPC call, which enables access to the internal state of any contract, bypassing the “view functions”. This option, naturally, would be nonviable.

• Ethereum RPC calls are not authenticated. For a view function to make access control decisions, it needs to know who is making a call.

• Access to platform-specific resources such as transactions, receipts, and general account data (like native balance, code, and nonce) must also be controlled.

• The most challenging aspect is event logs. These are custom payloads generated by smart contracts, typically used by UIs. Given Ethereum’s data transparency principle, they weren’t designed with access control in mind. However, the objective of our encrypted platform is to ensure data protection by default, providing developers with the tools to establish access control rules, including for events.

• Lastly, the information destined for users needs to be encrypted with “viewing keys” ( or “encrypted keys”)

A user’s interaction with an encrypted L2 should align with their typical Ethereum experience. This can be realised if the user can access necessary data, such as allowed photos or current balance, but without anyone else viewing their personal balance.

As Vitalik also pointed out, this experience demands efficient encryption key management. These keys may be, and preferably should be, distinct from the spending keys.

The realisation of the privacy transition is not only a cryptographic challenge but also an exploration journey of the optimal user and developer experience. At Obscuro, we align with Vitalik’s vision and have been working tirelessly over the past year and a half to build a platform that embodies this ideal.

While we wait for technology like Fully Homomorphic Encryption to become practical, this journey should begin with less than perfect technology, such as Trusted Execution Environments (TEEs), and apply to use cases like gaming, or DeFi that doesn’t need perpetual privacy. After all, numerous successful ideas took their first steps in the world of games.

As we continue to explore these critical themes, your thoughts, ideas, and critiques are invaluable. Head over to our Obscuro Discord server, where our community is constantly brainstorming and dissecting these complex issues. Your insights could be the key to the next breakthrough. See you there!