Some hard truths about blockchain: Privacy isn’t EVM-compatible. Smart contracts aren’t ZKP-compatible. Business isn’t ERC-20-compatible. So where does that leave you as a business or enterprise wanting to take advantage of the opportunities blockchain presents?

Enterprise Needs Privacy

This first hard truth is fully understood by the blockchain community. I previously wrote a piece dedicated to why we need privacy. If you want further reading on why enterprises need privacy, I can recommend that post as well as the sources referred there that make the point concisely:

• Katie Haun and Fred Wilson on Web3 "Blockchains as they were originally architected are public by default. This is not suitable for most applications. Imagine if your email, banking, and social data were public for everyone to see on a blockchain."

• Vitalik Buterin on the future of Ethereum "The big future challenge for this ecosystem is privacy. The status quo involves putting large amounts of information on-chain, which is something that is "fine until it's not", and eventually will become unpalatable if not outright risky to more and more people."

  
  

But the even better evidence for how critical privacy is to enterprise adoption of blockchain is the ongoing race to solve the privacy problem for blockchain. To name just a few projects in this space: Aztec. Aleo. Midnight. Nightfall. Oasis. Obscuro. Polygon Miden. Secret. Starlight. Zokrates.

Along the lines of my opening statements, I argue that none of these projects are on a trajectory to solve blockchain’s privacy challenges in a way that suits enterprise adoption in the near future.

Privacy isn’t EVM-Compatible

Credit where credit is due: The statement “Privacy isn’t EVM-Compatible” comes from Aztec Noir, and they are absolutely right. The Ethereum Virtual Machine’s (EVM) memory and execution model are all designed around a fully public blockchain where the EVM has full access to the entire blockchain state. Channels or side chains do not solve this problem, or at least introduce new problems that are at least as challenging as the lack of privacy.

Another approach to sidestepping the inherent lack of privacy is to run the entire EVM in a context where nobody can access it—a trusted execution environment (TEE). The idea of TEEs is that you trust hardware manufacturers (CPU manufacturers in particular) to keep a corner of CPUs secure even from the operators that have physical access to those CPUs. A bit like the copy protection mechanisms for media and consoles, or the jailbreak preventions on mobile phones. Do you trust hardware manufacturers to guarantee that security? You. Probably. Shouldn’t.

Think blockchain networks that use SGX are not exposed to this? Think again.The authors claim to have extracted the master decryption key for the entire Secret network using this method. The crypto world doesn’t seem to care; the SCRT price barely reacted to that news. But you, as a responsible enterprise, probably should. TEEs are not the solution. They are debunked as an effective means of preserving privacy in high-stakes environments.

Oasis and Obscuro also use TEEs, so they may well be in the same boat. Oasis did write a defensive post of their security with respect to the known TEE exploits, but redditors have their doubts. DYOR.

The main point is: TEEs have been breached multiple times already, and they’ll be breached again. It’s the security community bloodsport of the moment. If the data you entrust to TEEs on untrusted, third-party machines is valuable enough, it’s only a matter of time until somebody extracts it.

TEEs are a valuable technology and can add a lot of security to a holistic layered security design. Microsoft’s CCF or IBM’s confidential compute services are examples where TEEs are used in combination with other security technologies and deployed on cloud hardware operated by trusted service providers. In this context, incentives, risk, and impact are mitigated to a degree where the TEEs add a great deal of genuine and secure privacy.

Simply sticking the EVM in a TEE for a public blockchain isn’t enough. Privacy isn’t EVM-compatible.

Smart Contracts aren’t ZKP-Compatible

Zero-knowledge proofs (ZKP) are one of the most exciting areas in cryptographic research today. Their premise is attractive. In cases where they work, they really do seem to work in the sense that they preserve privacy. Anonymity is a different matter, but not the topic of this post.

The first thing to be aware of is that the vast majority of projects that use zero-knowledge proofs in the blockchain world are not privacy-focused, but rather are scalability solutions. Privacy is strictly harder, so any challenges you need to solve for scalability, you also need to solve for privacy, but there’s much more. That’s why on the scalability front, the race is to build the best zkEVM, a version of the EVM that is able to compute the required circuits and proofs to do ZK-rollups to Ethereum mainnet on the fly. Read all about it on Vitalik Buterin’s blog or this post by Alchemy.

However, these “ZK” projects for scalability can give us an idea of the core challenge for this approach: scalability and performance. Let’s take Polygon zkEVM’s performance figures:

"Polygon zkEVM Prover is able to validate 500K gas units on a single CPU server (64 cores) in about 5 minutes time."

A simple ETH transfer costs 21000 gas. So 64 CPUs can do the proving for about 0.08 TPS. Imagine what this would look like for an interesting smart contract that’s part of a business application.Since privacy is even harder, as far as I know, nobody is even attempting to do zkEVM for privacy. Privacy isn’t EVM-compatible, remember?

The approach pursued by Aztec, Aleo, Polygon Miden, Starlight, and other ZKP-privacy projects for smart contracts is to design languages, trans-/compilers, and runtimes specifically designed to generate ZKP circuits: Aztec Noir, Aleo’s Leo, Miden Assembly, Zokrates.

These languages all have something in common:

• Restrictive native type systems consisting of integers, booleans, fixed-width arrays, and structs
• Surprising semantics or significant performance impacts of even the simplest control flow (if-else)
• Lots of arithmetic and boolean operators
• Security pitfalls
• Impossibility to audit whether security bugs were exploited

The reason for that is simple. The core mechanism of turning a general purpose computation in a smart contract into a zero-knowledge proof is to convert it into a polynomial that serves as an arithmetic circuit. Here’s a simple explanation of arithmetic circuits. The above frameworks are far more sophisticated than what’s described in that explainer, but it illustrates the basics:

1. Convert your program to an arithmetic circuit—a polynomial
2. The proving process gets more complex in the complexity of the polynomial

The privacy-focused ZKP frameworks make you develop in languages much closer to arithmetic so that the arithmetic circuits are simpler. The result: You, the developer, have to arithmetize your application. The Leo battleship example aptly illustrates the programming yoga that’s necessary. And even with that extra effort, scalability is a long way away from where it needs to be for complex enterprise applications.

So, where are we at with zero-knowledge proofs and smart contracts?

• ZKPs for smart contract scalability are pre-production and barely scale
• ZKPs for smart contract privacy require expressing programs in arithmetic
• ZKPs for smart contracts don’t scale in complexity, which is a showstopper for non-trivial applications

Smart contracts aren’t ZKP-compatible. At least not yet.

Business isn’t ERC-20-Compatible

Back to the earlier statement: In cases where ZKPs work, they really do seem to work in the sense that they preserve privacy. ZCash is the most prominent example where zero-knowledge proofs are used to “shield” token accounts. The network can see that there’s something happening, but they can’t see how much you have in your accounts or how much you are transferring to other shielded accounts. Neat for payments.

EY and Polygon recently announced Nightfall 3 and the Nightfall Mainnet Beta launch in May of 2023. Their pitch is compelling: enterprise needs blockchain privacy, and now they have it. The announcement blog and related videos talk about disrupting $50 trillion markets, strawberries on the blockchain, and…

• Traceability

• Proof of authenticity

• Provenance guarantee

• Efficient data reconciliation

• Affordable, secure payments with fast settlement

  
  

What’s really in the box? The principle is simply explained: ZCash shielded accounts for ERC-20, 721, and 1155 tokens in a ZK-rollup. Paul Brody in the above linked video is effectively saying that the entire automotive industry could be done as track’n’trace in ERC tokens.

Do you believe that? I don’t. I don’t believe that the value of the crypto ecosystem is in the tokens themselves. It’s in the DeFi applications that link the tokens together. The DEXes, liquidity pools, exchanges, and games. It’s in the smart contracts. And in terms of complexity, all of the business that’s happening on blockchains today pales in comparison with traditional finance. You can’t reduce that to fungible tokens and NFTs.

I’ve previously written about why I think tokenization as practiced in blockchains today does not represent real world business in a meaningful way.

Business is not ERC-20-compatible.

So Where Does That Leave Us?

Financial enterprises see the opportunities in low-latency, reconciliation-free markets. They see the demand for direct asset ownership and asset mobility. They feel the allure of public blockchain networks. But enterprises need scalable smart contracts with real privacy to take advantage of these opportunities. Spoiler: here comes the pitch.

At Digital Asset, we’ve been working tirelessly to approach the problem from a completely different angle. Rather than adding privacy to existing UTXO or account-based ledger models using fancy but compromised tech (TEEs) or cutting-edge but unscalable crypto (ZKPs), we have developed a ledger model (the Daml Ledger Model), consensus protocol (Canton), and smart contract language (Daml) that work hand in hand to offer general-purpose smart contracts with unparalleled privacy, using completely standard private key encryption and signing schemes. Enterprises are using this technology today to solve real-world problems, moving more value in TradFi assets every day than any crypto network—with privacy. And yes, we can also do games.

You don’t need to waste your time with dead-end PoCs because the networks don’t scale. You don’t need to perform blockchain theater on public chains, synchronizing your trades into an ERC-20 token after the fact because the public chains don’t have the privacy and controls you need to move your actual books to blockchain. Join the growing network of organizations building the privacy-enabled and scalable financial infrastructure of the future on Daml and Canton.