Thanks for the discussions Mario and Aadharsh, our conversations inspired some of these takeaways.

There’s an interesting tug-of-war at play with privacy-first projects and optionally-private incumbents. By principle, blockchain infrastructure is designed to be public, but the limitations of this design principle when deploying applications has become glaring obvious. Hence, the reason for implementing privacy-enhancing technologies within the blockchain stack. 

On one side of this tug-of-war, you have privacy purists who are implementing alternatives to pre-existing infrastructure and applications, but with privacy technology in-built. These players are exemplifying core Internet security design principles, as stated in my CS textbook from college:

“Trying to retrofit security to an existing application after it has already been spec’ed, designed, and implemented is usually a very difficult proposition. Backwards compatibility is often particularly painful, because you can be stuck with supporting the worst insecurities of all previous versions of the software.” - UC Berkeley CS161

The other side acknowledges the network effects at play with incumbent blockchain infrastructure solutions and is approaching privacy as an important plug-and-play feature to exist on top of the existing stack. This is effectively treating privacy as a commodity.

While I acknowledge the strength of the first argument and the importance of privacy as an in-built design feature, recent advancements have demonstrated the validity of the second approach as well.

For example, going “full ZK” has become easier with Optimistic rollups gaining the ability to implement this PET. I recall not long ago when folks regarded the OP stack as a dead model given the eventual proliferation of native ZK rollups. We’re also seeing modular execution networks layer on top of existing VMs, equipping developers with confidential compute and privacy features without leaving their native development language or familiar execution environment. 

Current infrastructure and application products are relatively popular without having privacy as a get-go feature. They’ve reached a certain scale of network effects. While they may be de-throned, it seems an upward battle to compete with incumbents on the principle of privacy. Like it or not, privacy may be an important add-on feature, but people seem to be comfortable with alternative solutions that offer better user experience or have reached a sufficient scale.

The views and opinions expressed on this article are solely those of the original author and mentioned contributors. These views and opinions do not necessarily represent those of Placeholder Management LLC or its team.

Thanks for the discussions Mario and Aadharsh, our conversations inspired some of these takeaways.

There’s an interesting tug-of-war at play with privacy-first projects and optionally-private incumbents. By principle, blockchain infrastructure is designed to be public, but the limitations of this design principle when deploying applications has become glaring obvious. Hence, the reason for implementing privacy-enhancing technologies within the blockchain stack. 

On one side of this tug-of-war, you have privacy purists who are implementing alternatives to pre-existing infrastructure and applications, but with privacy technology in-built. These players are exemplifying core Internet security design principles, as stated in my CS textbook from college:

“Trying to retrofit security to an existing application after it has already been spec’ed, designed, and implemented is usually a very difficult proposition. Backwards compatibility is often particularly painful, because you can be stuck with supporting the worst insecurities of all previous versions of the software.” - UC Berkeley CS161

The other side acknowledges the network effects at play with incumbent blockchain infrastructure solutions and is approaching privacy as an important plug-and-play feature to exist on top of the existing stack. This is effectively treating privacy as a commodity.

While I acknowledge the strength of the first argument and the importance of privacy as an in-built design feature, recent advancements have demonstrated the validity of the second approach as well.

For example, going “full ZK” has become easier with Optimistic rollups gaining the ability to implement this PET. I recall not long ago when folks regarded the OP stack as a dead model given the eventual proliferation of native ZK rollups. We’re also seeing modular execution networks layer on top of existing VMs, equipping developers with confidential compute and privacy features without leaving their native development language or familiar execution environment. 

Current infrastructure and application products are relatively popular without having privacy as a get-go feature. They’ve reached a certain scale of network effects. While they may be de-throned, it seems an upward battle to compete with incumbents on the principle of privacy. Like it or not, privacy may be an important add-on feature, but people seem to be comfortable with alternative solutions that offer better user experience or have reached a sufficient scale.

The views and opinions expressed on this article are solely those of the original author and mentioned contributors. These views and opinions do not necessarily represent those of Placeholder Management LLC or its team.