By Breck Stodghill‍

We’re excited to announce that Haun Ventures is leading the seed round for Witness with participation from other investors including Coinbase Ventures and an amazing group of strategic angels. I’ve known both Sina and Joe, the founders of Witness, long before they decided to start the company. I first met Sina at a San Francisco crypto research meetup. From the get go, it was clear that Sina was a 10x engineer and loved to tackle complicated technical problems with extreme clarity of thought. I first met Joe when he was an investor at Framework, where he focused on crypto infrastructure. Joe thinks from first principles and has built an incredible community around himself since first joining the space as an anonymous bird online. As a pair, they compliment each other exceptionally well, which is why we think they’re exactly the right team to bring web2 scale to web3 ownership.

It’s no secret that high transaction costs and surge pricing have greatly slowed the mass adoption of web3 products. First, they exacerbate the user onboarding problem. Most users barely have enough attention to download a new app and go through a trivial sign in flow. Layering on payment for each product action tightens the aperture of new users willing to test and use a new product. Second, they limit the growth for products that do obtain product-market fit. This is particularly problematic when you consider that the further a product grows, the more sensitive each incremental user is to added friction in their experience. 

Witness is different because there are no transaction fees. Rather than pay to post all data onchain, developers can submit data to Witness instead. Witness compresses this data, forwards it onchain, and outputs a proof that this process was done correctly. We call this witnessed data, and it is permissionless, tamper proof, and fully composable onchain. 

We’re particularly excited about this protocol because across all stages the most important question a crypto product must answer is what part of the product should go onchain? Not anymore. All application data exhaust can be witnessed by default, for free. 

As an example, there are a number of creator platforms that have launched with NFTs as their onchain backends. Mixed media creators can post on Zora. Publishers can post on Mirror or Paragraph. Musicians can drop their music on Sound, Sona, Catalog, or Royal. The core interaction for these products is the buying and selling of some digital content, so most of them feel like platforms with embedded marketplaces. But other forms of engagement outside of purchasing are also valuable and potentially more important to form the backbone for transitioning from a platform to a true social network. On Sound, for example, users can engage with songs by commenting, sharing, and listening to the music. But none of that data is captured onchain. If Sound witnessed all user engagements, then artists could take onchain actions such as granting access to mint new NFTs based on those engagements, and they’d be cross platform by default. 

Farcaster has come at this problem from a different angle. As it stands, only identity data on Farcaster lives onchain. All casts, frames, and interactions live offchain on the Farcaster protocol. And as a result, clients like Warpcast have been able to build web2-like experiences, allowing the app to grow much faster. But if every Farcaster interaction was witnessed, we could supercharge the value of the Farcaster social graph. Any developer could persmissionlessly issue onchain NFTs or tokens based on the social graph. For example, a new onchain game could grant access to a special NFT for the first 1,000 subscribers of their Farcaster channel. 

These are just a couple simple examples of what can be possible when more products use Witness to extend onchain ownership to higher fidelity data. If you’re building a crypto product and interested in learning more about how you can bring your data to Witness, check out the docs here.

If the mission and vision for bringing web2 scale to web3 ownership resonates with you, Witness is hiring! Please reach out here.

By Breck Stodghill

With traditional cloud deployment, software apps are able to auto scale their infrastructure to support increased usage. For startups that achieve product market fit this is critical because it means they can more easily provide their users with a high quality of service without having to physically manage their underlying infrastructure. In other words, a startup’s users are insulated from the physical requirements of running the app as it goes from hundreds to thousands to millions of new users.

Crypto apps don’t have this luxury. Unlike cloud platforms like GCP and AWS, general purpose crypto networks do not provide auto scaling as a feature. The ability of a crypto app to respond to increased user demand is constrained by the resources of its underlying network. And as we’ve seen, it only takes a modest level of adoption of a single app to actually degrade its quality of service for its users because the costs to use the app increase. For instance, as more traders want to use Uniswap, they begin to compete with one another over Ethereum blockspace and end up paying higher transaction fees to use the app. In order for crypto apps to be able to reach billions of users this must fundamentally change.

In traditional cloud there are two ways to scale an app: horizontally or vertically. Horizontal scaling refers to splitting the app workloads across multiple machines to gain performance through parallelism. Vertical scaling refers to running the app on a beefier machine with higher CPU, RAM, or disk space. While it’s early, we’ve actually seen some crypto apps try methods of scaling that look like these two familiar approaches.

Horizontal Scaling (General Purpose)

We’ve seen some crypto apps attempt to horizontally scale by deploying to multiple, general purpose chains. But attempts at horizontal scaling have not meaningfully moved the needle for crypto apps. For example, Aave V3 was first deployed to Ethereum Mainnet but has since deployed to Optimism, Arbitrum, Polygon, Harmony, Fantom, Avalanche, and Metis. Uniswap has followed a similar trajectory. But unlike cloud horizontal scaling, the multichain deployment of an app does not create a true load balancing effect. Instead, crypto horizontal scaling feels more like restaurant franchising where brand and user experience are shared, but separate liquidity and networks result in very different product outcomes. In practice this strategy has been minimally effective. The majority of usage continues to occur in the initial deployment context.

Vertical Scaling (Customized)

In contrast, we’ve seen some crypto apps attempt to vertically scale by delegating more of their custom app logic offchain and only using the underlying network, where resources are most expensive, for the most critical logic. By delegating more logic offchain, the app is able to leverage a “beefier” compute engine. That offchain logic might manifest in the form of a rollup, a sidechain, a validium, or simply a checkpointed data structure. The more logic you defer offchain the more performance you can get, but the more decentralization you trade off (assuming that offchain compute is more centralized). dydx is a good example of an app that’s attempted to vertically scale having first been deployed to Ethereum Mainnet, then StarkEX, and is now working towards its own appchain. Zora is now running a similar playbook by expanding from Ethereum Mainnet to its own L2. In both cases, the app first achieved product market fit on Ethereum, but needed to get creative with how it used Ethereum’s blockspace in order to continue to grow and provide high quality services to its users.

Don’t get me wrong, I’m excited about the many teams that are laser focused on researching and building horizontally scalable, general purpose blockspace, but I think it’s time that apps currently dealing with scaling bottlenecks take matters into their own hands and push the boundaries on more custom, vertical scaling approaches. As a founder the top priority is to provide a good product to your users. For many crypto apps, I believe that trading off aspects of centralization to increase your user base and build a better product is not only sensible but well worth the endeavor.

This piece was also published here.

By Breck Stodghill

Zero Knowledge Proofs (ZKPs) are an exceptionally powerful method of cryptography that will have far reaching applications as infrastructure for the new internet. ZKPs enable an entity (the prover) to verifiably demonstrate to another entity (the verifier) that some computation took place without revealing certain underlying data or requiring the verifier to execute the computation. With this property in mind ZKPs are an incredibly promising class of technology for privacy preservation, verifiable computation, and data compression — all of which are core, unsolved problems in web3. ZKPs are highly practical because the proofs generated are very small and computationally fast to verify, and are quickly moving from theory to application as proving hardware rapidly accelerates.

We are extremely early in our exploration of the potential use cases of ZKPs, but today, there are three primary applications in web3: privacy, scalability, and interoperability.

Privacy. Blockchains as they were originally developed are public by default. All transaction history, account balances, and smart contract execution is available for anyone to inspect. But web3 cannot scale without unlocking privacy, for the simple reason that mainstream participants and institutions won’t use technologies where all of their data is available to the public. ZKPs are a great tool for shielding some, if not all of this data in a compliant way.

In 2016, the Zcash protocol launched using ZKPs to obfuscate the details of user transactions in a Bitcoin-like payment network. In the last few years, advances in zk circuit constructions, accelerations in prover efficiency, and more efficient software implementations have paved the way for ZKPs that support private general purpose smart contract execution.

A few of the teams building privacy focused infrastructure:

• Aleo is building its own zkVM for developers to define private applications deployed and executed on the Aleo blockchain.
• Anoma is building a private, intent-centric counterparty discovery protocol.
• Aztec is building a privacy protocol for shielded assets on its L2 to interact with defi on Ethereum.
• Espresso Systems is building an asset privacy protocol to define private ERC-20 assets with configurable viewing policies with compliance and other new use cases in mind.
• Iron Fish is building a shielded payment protocol that greatly lowers the resource requirements to run a full-node.
• Mina is building a recursive SNARK protocol for developers to write smart contracts in typescript, only requiring a small proof to be submitted on the blockchain.

These are just a few examples of the teams focused on privacy in web3. More privacy focused infrastructure will lead to more privacy focused applications. We’re particularly excited about the new protocols, primitives, and products that will surface at the intersection of ZKP-enabled privacy and existing and new use cases in defi, nfts, gaming, and more. While we are excited about the potential for more private applications, we also expect that they will introduce new challenges for the ecosystem. We are starting to see this play out with the U.S. Treasury Department’s sanctioning the Tornado Cash application, a piece of privacy preserving code running on Ethereum. Read more about our position on the matter here.

Scalability. ZKPs are extremely useful for blockchain scalability because they can summarize a complex set of computations into a succinct proof that can be quickly and cheaply verified. Given that scalability has been at the forefront of blockchain research, this has been the predominant area of focus and investment for ZKPs. Rollups (L2s) and new L1s are leveraging ZKPs to further scale.

Rollups are a scalability method by which the execution of most transactions and the calculation of intermediate state updates are moved off the L1. Zk rollups generate validity proofs that verify the execution of a batch of transactions leads to the accompanying state. Zk rollups rely on ZKPs for verifiable computation not for the obfuscation of data. As such, the transaction data, the proof, and the updated state are periodically committed to an L1 allowing the rollup to inherit the underlying L1’s security.  Newer concepts in rollup designs such as recursive (or fractal) roll-ups are largely theoretical today, but incorporate ZKPs to present a path towards the arbitrary scaling of execution without trading off security. Furthermore, sovereign rollup designs leverage ZKPs to not only scale up execution relative to traditional L1s but also scale down the work and resources required to sync the chain. Such super-lite clients are made possible with the inclusion of DA layer consensus in the rollup proof. Super-lite clients have a similar trust model to full nodes, but are able to sync the chain in the time it takes to verify a single ZKP.

Some of the teams building  zk rollups:

• Matter Labs is building zksync, a zkEVM L2 on Ethereum.
• Polygon is building a zkEVM L2 (Hermez), a STARK based zkVM L2 (Miden), and a Plonky2 based zkVM L2 ( Zero) all on Ethereum.
• Scroll is building a native zkEVM L2 on Ethereum.
• Starkware is building a suite of STARK based zkVM L2s  on Ethereum.
• Sovereign Labs is building a zkEVM sovereign rollup using the RISC Zero zkVM.

ZKPs are also being leveraged for new layer 1 designs that enshrine the use of ZKPs for native data compression, verifiable computation, and more efficient gossip protocols. It’s simpler to build a new layer 2 solution with a centralized sequencer / prover than it is to build a new layer 1 with decentralized block production and block proving so there are fewer teams working on this. That being said, Aleo, Espresso Systems, and RISC Zero are working on new, high throughput ZKP-based L1s.

The common thread among all of the techniques outlined here is that ZKPs have opened up the design space for how blockchains can scale. In the short term as some of these techniques make it to production, we expect to see ZKPs increase blockchain scalability by 10-100x and in the medium to long term as hardware acceleration converges to a theoretical asymptote we may see ZKPs accommodate arbitrary scale via fractal rollups and recursive proofs.

Interoperability. Existing blockchain interoperability protocols rely on trusted systems which have led to many billions of dollars worth of exploits. ZKPs replace crypto-economic trust assumptions with cryptographic guarantees. Most cross chain communication protocols are backed by a multisig or an incentivized validator set for relaying block headers from chain to chain, but a protocol that accepts block headers along with a ZKP to prove their inclusion and finality would have much stronger security guarantees. Moreover, the use of recursion in zk interoperability protocols may remove the need to maintain pairwise bridge contracts and further reduce the surface area for exploits.

Among the primary applications of ZKPs, interoperability is the most nascent. There are only a handful of researchers exploring this topic. As access to the technology accelerates and experts converge on best practices we expect to see more focus and innovation in interoperability.

Since the launch of Zcash, ZKPs have made great strides moving from theory to application. But it's extremely early. There are still vast discrepancies in performance benchmarks across proof systems, software implementations, and prover hardware. Over time we expect to see the industry converge on best practices and many of today’s most notable differentiators may be commoditized. This is a feature and not a bug. ZKPs are a revolution in computer science and unlike previous iterations of the internet, will be built in public. As the zk ecosystem accelerates we are excited to partner with and invest in the very best teams who are using the technology to build innovative solutions to core problems in web3 – from the earliest stages to those that are well on their way already.

If you are a zk researcher, engineer, or founder interested in collaborating please reach out to me at breck at haun dot co.

Thanks to Alex Pruden, Dan Boneh, Preston Evans, Scott Sunarto, and Ye Zhang for their review.