SNARKs, and PLONKs, and Merkle Trees – oh my!

A quick rundown and overview of some definitions you’ll need to take a deeper dive into the coming zk-wave in crypto

Hi, folks. Sherpa here again with a continuation of our series on privacy-focused zkRollups. If you’ve been following along, we started with a quick overview of Optimistic rollups & zkRollups, before moving on to zkSync by Matter Labs. Next week we’re going to check out Aztec, but before we do I’m going to give you a quick refresher on some terms you’ll be seeing fairly often in these overviews.

I started this article as a “quick dive” into Aztec, but to be honest the terms & definitions already had us pushing four pages before I even sniffed at the project, specifically – so, next week. For now, on to…

Terminology

Merkle Tree: Think of this as a “family tree” for data. Everything has an origin/parent, and then children branch out to “leafs” based on activity. It’s all a lot more complicated than that, but what you need to know is that this makes hashes & data traceable to where they exist in a ledger.

zk-SNARKs: The TL;DR for SNARKs is that it’s a way of creating a transactional proof while maintaining privacy. There are many, many different approaches to this, but they are rooted in this fundamental idea.

Think of it like your friend, Alice, is in a central room. You have a key that lets you enter through one door, and exit through another – so you can get to Alice, but at the same time Alice knows nothing about the key or where you came from – just that you’re approved to be there. zkSNARK stands for “zero-knowledge Succinct Non-interactive ARguments of Knowledge” – so if that isn’t clear enough, let’s just say it’s a way of proving something without the other party knowing anything other than that you can prove it. SNARKs are not to be confused with zkSTARKs, which is still another rabbit hole we’ll need to explore at some point.

Traditional SNARKs, like Groth16 (which is generally used as a benchmark), had some serious drawbacks, as Coinmonks explain here:

---

---

UTXO: UTXO is short for “unspent transaction output”, and this is how Bitcoin handles balances. Try to think of UTXOs as you would denominations of paper currency or coinage: you have so many pieces that add up to your total “balance”; you have $50, but what you might really have is five dollars’ worth of quarters, two tens, a twenty, and a five dollar bill.

PLONK: “Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge” – no further explanation needed there, yeah? I mean, we all know what…lagrange-bases for oec– NOPE.

So, a PLONK is an attempt at a universal SNARK. You’ll see variations like “Turboplonk” come up as renditions of this concept, but the basic idea is that SNARKs require a trusted setup so all programs/contracts are working off the same ruleset & get the same results when verifying things. PLONK is a more trustless/secure version of that, with less need for trust in a central party, and a universal setup for all programs. Vitalik explains it like this…

“The first improvement is that while PLONK still requires a trusted setup procedure similar to that needed for the SNARKs in Zcash, it is a “universal and updateable” trusted setup.

This means two things: first, instead of there being one separate trusted setup for every program you want to prove things about, there is one single trusted setup for the whole scheme after which you can use the scheme with any program (up to some maximum size chosen when making the setup). Second, there is a way for multiple parties to participate in the trusted setup such that it is secure as long as any one of them is honest, and this multi-party procedure is fully sequential: first one person participates, then the second, then the third… The full set of participants does not even need to be known ahead of time; new participants could just add themselves to the end. This makes it easy for the trusted setup to have a large number of participants, making it quite safe in practice.” –Vitalik.ca

Suffice it to say, this was an improvement on existing zkSNARK tech, namely Sonic.

We could dive even deeper into the history, origins, and evolution of SNARKs, but these definitions should give you a basic understanding of the underlying tech & why it matters. Next week we’ll be diving into Aztec before moving on to other zk-plays in the space. Until then, DYOR & do it religiously.

Related: Aztec Connect zk.money