We have just concluded an almost accidental ZK podcast series on (mostly) Ethereum L2s. We’re not quite sure how that happened, but after the pattern manifested itself we just decided to roll with it. (“Who the hell is we,” you may ask. I joined the ZK podcast as a producer a few weeks back, so I handled some of the backend work on these episodes while working with Anna.)

Layer-two solutions for Ethereum are touted as the holy grail of scalability, especially after the Ethereum roadmap excluded execution shards for the foreseeable future. The new “rollup-centric roadmap” would see Ethereum become a bit of a “consensus-as-a-service” and data availability layer, providing very strong security guarantees and a whole bunch of data storage space for layer-two solutions, which would be the ones to take care of the actual scaling.

The beauty of (most) the L2s we talked with in the past few weeks is that they don’t even need to be decentralized on their own. Cryptographic guarantees in the form of fraud or validity proofs ensure that whatever happens on L2 is verifiably valid, and any misbehavior would either be impossible or quickly rolled back. The key assumption, of course, is that the security and decentralization of the main chain is never compromised.

Let’s now take a deeper look (in no particular order) into each of these L2s to see how they differ and what interesting facts our conversations uncovered.

Aztec’s zk.money

Check out episode 176 about the “zk-zk-rollup” with Aztec.

We spoke with Aztec’s Zac Williamson and Joe Andrews shortly after their launch of zk.money, a platform they’ve dubbed “zk-zk-rollup” because it combines both scalability and privacy into one L2. In that sense it’s a very unique product with an even more unique tech stack.

I recommend reading Aztec’s own write-up on the subject, where they offer a quite accessible and thorough explanation of the development. On the zk side, the platform required developing the TurboPLONK, which added AND and XOR gates, together with optimized range checks and other advances that improved things just enough to make it usable with Ethereum.

Another interesting tidbit is just how hard was it to package all of this proving infrastructure into a browser setting. They used WebAssembly, of course, but even that wasn’t sufficient by itself. For example, Wasm doesn’t support multi-threading so they had to emulate that by spinning up separate web process instances. There is a lot more technical info in the conversation that I’d butcher by summarizing here, so I encourage you to give the episode a listen.

Zk.money now offers Zcash-level privacy on a number of Ethereum assets, packaged in a scalable rollup. But it’s worth mentioning that this is still just “the end of the beginning” as Zac said. Aztec’s goal is to have private programmable money, and to that end we need usable private smart contracts. That’s where UltraPLONK and Noir research comes in, which should get us closer to making them work in an Ethereum environment. But as Zac pointed out, there are many pitfalls involved in making private DeFi protocols. Imagine not knowing the balance of a Maker CDP — how do you expect liquidators to know when to act?

It’s a very exciting direction to take and I do sincerely believe we’ll all be using private smart contract platforms in a few years. That said, the road to get there still seems to be quite long.

The Optimistic Rollup and the “ultima ratio” mechanics

Check out Episode 177 with Ben and Mark from Optimism, and Episode 179 about Arbitrum’s Optimistic Rollup.

We’ve had two Optimistic Rollup builders on the show recently, adding to an earlier episode with Fuel’s John Adler.

For a bit of background, zk-Rollups can be categorized as a very promising and effective scalability technology that relies on cutting edge cryptography—so cutting edge that, at first, they seemed too impractical to be used in production, especially in the context of deploying smart contracts. Optimistic Rollups are somewhat of a polar opposite to that. They’re reasonably simple from a cryptographic perspective, at least in the sense that they use standard cryptography. This allowed both Arbitrum and the Optimism team to design fully EVM-compatible rollups, meaning that existing dApps can just port their contracts over with minimal changes. But ORs involve some usability and security compromises that are worth exploring.

The optimistic mechanic is quite interesting in that it’s largely using a game-theoretical disincentive mechanism. In essence, these L2s are designed in a way that allows the Ethereum main chain to cryptographically verify their state transitions. Since doing this all the time would be entirely too expensive, the system is “optimistic” — it assumes that state transitions are valid, but allows for a challenge period of one week, during which anyone can submit a fraud proof stating that the purported history of transactions is incompatible with the state being published. Since fraud proofs are mathematically verifiable, it is (mostly) trivial for the Ethereum blockchain to automatically resolve the dispute in favor of the watcher(s) and reward them with a portion of the bond put up by the sequencer, essentially the L2 block producer.

This mechanism means that, in reality, it’s unlikely that there will ever be actual fraud — the system is just too bulletproof for it to be attacked successfully. As Ben Jones from Optimism put it, the system relies on MAD (Mutually Assured Dispution), quite similar in principle to the more well known type of MAD.

If this is the case, why is the challenge period so long? The limitation basically means that withdrawals are going to take a long time to finalize, making it a huge UX burden.

The answer apparently lies in the security of the main chain. As Matter Labs’ Alex Gluchowski often reiterates, in an Optimistic setting, miners could decide to censor the fraud proof transactions and eventually finalize the fraudulent state. Part of the reason why the challenge period is so long is to allow for the Ethereum community to socially coordinate to thwart this attack by, for example, hard forking the chain. That is an interesting “ultima ratio” to adopt, but it’s not at all unexpected. Social coordination is also Ethereum’s answer to weak subjectivity in Proof of Stake, the idea that new nodes in the network must ultimately trust the source of the state instead of being able to objectively verify the chain like in PoW.

Another potential issue with ORs is the chicken and egg problem of incentivizing watchers. If the idea is that there’d be hardly any fraud, ever, then there will be no reward in constantly surveilling the L2 chain. Though the OR is set up so that just one honest validator would be enough, it’s also true that this validator would need to be fully altruistic. In practice this probably won’t matter too much, but blockchain security is all about edge cases.

Both the conversations with Optimism and Arbitrum dive deep into these game theoretical aspects, as well as the technical differences between the two constructions — for example, Arbitrum’s fraud proof mechanism is more interactive and thus less burdensome for the Ethereum blockchain. Highly recommend giving a listen to both.

The “zkEVM” by Matter Labs

Check out episode 175 about Matter Labs’ latest developments with their zk-rollup.

The chat with Alex serves as an important reminder that the initial raison d’être for Optimistic Rollups is no longer quite as valid as it used to be.

A few years ago, the Ethereum community shifted their excitement from zk-Rollups to Optimistic Rollups primarily for two reasons: they could be developed more quickly, and they supported EVM smart contracts. Back when this shift occurred, it kind of made sense: zk-Rollups seemed unlikely to be able to incorporate smart contracts, being instead limited to some basic payments functionality.

Then, research into recursive PLONKs allowed Matter Labs to come out with the Zinc language, promising it’d be at least as feature-rich as Vyper (which is used much less than Solidity, but still). But even that wasn’t quite enough. Zinc is a Rust-like language, ill-suited for Ethereum devs who are by now quite used to Solidity (which will remain entrenched as Ethereum also dropped its eWASM plans).

So now Matter Labs is developing the zkEVM (a semi-official name) that would allow developers to use Solidity on a zk-Rollup. Of course, with the limitations of SNARK circuits being what they are, this version of Solidity will be compiled to a “SNARK-friendly” virtual machine. Still, from an architectural perspective, this “zkEVM” should look and feel like what’s currently live on Ethereum.

The zkSync 2.0 rollup will not suffer from the dreaded one week withdrawal period issue, and it is in general more resilient to attacks on L1 since at most they’ll result in temporary denial of service and not a faulty L2 state. Even the release timing is quite close to Optimism, with May and August as targets for testnet and mainnet release, compared to July for Optimism’s full mainnet (and similar time frames for Arbitrum).

Of course, these are just words and roadmaps for now. We’ll need to see concrete results before expressing judgement, but it seems that summer will be an exciting period for Ethereum.

Alex also talked about what will come next after zkSync 2.0, namely zkPorter. It’s essentially a proposal to introduce sharding at a rollup level, adding more scalability by moving data availability to a validator community (a decentralized Validium, in some sense).

dYdX and the StarkWare rollup

Check out Episode 180 featuring dYdX’s founder Antonio Juliano.

The episode with dYdX is a bit less technical than others in this series, but it’s valuable in that it showcases a dApp developer’s thoughts on choosing the scalability solution to adopt.

For dYdX, the congestion on Ethereum during the DeFi Summer in 2020 hit particularly hard: transactions on the exchange used about 5x the gas of a Uniswap trade, magnifying the pricing issue. If paying $40 for a DEX trade is bad enough, imagine paying $200 (and even more during sharp spikes in activity). Deploying to a scalability solution became imperative, and that’s where StarkWare and its StarkEx came in.

Unlike many of the solutions mentioned before, StarkEx was already available in production when dYdX began their search for a scaling partner, and it provided enough flexibility to build a non-custodial exchange with a centralized matching engine. In the episode, Antonio and James explore how zk-rollups may actually offer a significant benefit over other constructions like ORs, primarily because they allow to only record the differences in balance after a batch of trades. ZKPs ensure that the orders were matched correctly and thus remove the burden of publishing data about every single trade. For market maker orders this is particularly important, as they’ll be conducting a huge number of trades with barely any change in their final token/position balance.

It’s also interesting how dYdX decided to go for the rollup mode instead of Validium, the mode adopted by DeversiFi. That ultimately comes down to a product decision about where the platform sits on the decentralization spectrum. Using rollups reduces the effective performance while removing the requirement of trust in the data availability committee.

Horizen and the trustless sidechain

Check out Episode 178 with Horizen’s Alberto Garoffolo.

This episode is a bit of a break from the others in that it focuses on Horizen and its UTXO sidechain, a somewhat different world where smart contracts are not quite as relevant.

In “classical” terminology, a sidechain is a separate blockchain that uses another blockchain’s bridged token as its native currency. Sidechains don’t have to inherit the same security infrastructure, although that is generally something that the community should welcome. Of course, now the term “sidechain” has become more of a philosophical pledge of allegiance than an actual technical term (looking at you, Polygon).

In general, sidechains are more of a Bitcoin thing, with RSK and Liquid being the two most well-known (and Lightning being a bit of an undefinable scaffolding on top of BTC as well).

The problem of any non-LN network is that the bridging process is usually at least somewhat centralized. In Liquid’s case this is particularly pronounced, with the bridge being a standard N of M multi-sig holding custody of bridged funds. The signatories are a number of centralized entities, primarily exchanges and businesses that were accepted into Liquid’s federation.

It’s easy to see how this weakness makes sidechains highly suboptimal in a decentralized world. The bridge presents a natural bottleneck where things like KYC checks could be introduced quite easily, given the nature of the federation.

For this reason, I was excited about Horizen’s design. They modified their blockchain to provide a framework for seamlessly adding sidechains, called Zendoo. The second part of the proposal is Latus, a sidechain that provides ZKPs to let the main chain verify its state transitions. The combination of these two actually makes this the first fully trustless UTXO sidechain ecosystem.

I don’t know if this will actually find usage — the community’s focus seems to be all on smart contracts and account-based systems these days. But it offers a glimpse into what these UTXO chains could eventually become, especially given Bitcoin’s L2-centric roadmap. Adopting a solution like this could actually make the Bitcoin of the future a much more decentralized network, although it’d take an unprecedented number of changes to Bitcoin Core.