Smart Contract Summit 2021: Privacy and SNARKS Panel

SCRF has been invited to host an independent research track as part of the 2021 Smart Contract Summit. We’ve chosen to present five panel discussions that touch on some of the most timely issues facing the blockchain space: “Identity and Reputation”, “Governance Theory”, “Governance Implementation”, “Privacy and SNARKS”, and “CBDCs and Blockchain”.

In this series of threads, we will be providing some deeper insight into the panel topics, the participants, and where interested viewers can find their most relevant works.

What is SCRF

The Smart Contract Research Forum (SCRF) is where academics, researchers, and industry leaders from all over the world come together to discuss research, solicit thoughtful peer review, and find new projects on which to collaborate. You can find additional information about our programs, grants, and initiatives in our repo; or feel free to join us in our chat.

About the Privacy and SNARKS Panel

zkRollups are one of the most promising technologies attempting to improve the scalability, privacy and security of public blockchains. In this panel, SCRF contributors discuss the evolution of this technology, critical design decisions and challenges with some of the top ZK researchers in this area.

Full Video

Panelist Bios and Relevant Works

Ariel Gabizon

Chief Scientist at AZTEC Protocol. PhD Computer Science (Weizmann Institute of Science), research at Columbia and Technion, formerly researcher and engineer at Zcash & Protocol Labs. Creator of AuroraLight & PLONK.

Some of Ariel’s work:

Relevant links for Ariel:

Aleksandr Vlasov

Aleksandr Vlasov is the head of research and development at Matter Labs. He holds a Ph.D. in Electrical Engineering from McGill University (2018) and a specialist degree in Physics, Nuclear and Particle Physics from Moscow State University. Before joining Matter Labs, Vlasov was the chief research scientist at the BANKEX Foundation.

Relevant links for Aleks:

Key Questions for our Panelists

Some of the questions we’ll explore during the panel include:

  • zkRollups, and ZKPs more broadly, have been applied to crypto in the context of privacy, scalability, and usability. What was the primary driver that led you to your current projects?
  • What was the hardest design decision when developing the architecture of your rollup solution?
  • Are there primitives at the base Ethereum layer that you wish existed?
  • Are you building your platforms with a specific use case in mind, or is the goal to provide the community with the tooling required to scale?
  • What are some research developments in the ZKP field excite you the most?
  • Do you envision interoperable zkrollups, or will the base layer provide sufficient interoperability?
  • What privacy guarantees can users of your platforms expect? When will improvements arrive if needed?
  • Why is there some convergence around PLONK? What set of trade-offs does it entail?
  • How comfortable should we be about the security of these systems?

Watching the Panel

The Summit is taking place virtually from August 5-7. You can find the most up-to-date schedule and get your free tickets here.


Thank you all so much for a terrific panel discussion.

If you’re looking for some background reading on SNARKs, PlonKs and zero knowledge, be sure to check out @Sean1992076 summary of REDSHIFT: Transparent SNARKs from List Polynominal Commitment IOPs, @Jerry_Ho’s summary of PlonK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge, @tina1998612’s summary of Zerocash: Decentralized Anonymous Payments from Bitcoin and @jasonanastas Discussion Post: Zero-Knowledge Proofs - An Ethics Perspective


I apologize for the second post in the thread, I was listening to the second half of the presentation in the video and you mentioned some concerns with SHA-256, I’d love to hear more about the issue generally, and how you’re working around it.

1 Like

We also just released our first SCRF Interviews video that features Ariel Gabizon and Lucas Nuzzi in conversation. This discussion delves into some more of the specifics of PlonK. You can check it out here.



Thanks, @cipherix and @Ariel_Gabizon1 for this excellent review of the whole ecosystem! (Thanks again Plonk, for bringing us a pain-free development enviroment! : P )

I have some questions from the talk, where I can’t seem to find enough information online.

You’ve mentioned that the hide of the code execution itself is being actively pushed by Zcash, and hoping to achieve that in the future. It’s very exciting that now we have economic incentives(MEV) for it to be done, possibly sooner than a world without MEV.

However, it’s hard for me to come by relevant info about it, so please forgive my seemingly naive questions here:

  1. The manipulation of such data - is it done in the same fashion as FHE? If no, then how are they different?
    (From my naive imagination, they could’ve been achieved by different primitives(zk/fhe), with different security properties, etc. Although the resulting behavior seems similar, the underlying mechanism is different.)

  2. Is the DARK contract being mentioned in the talk referring to this paper?
    Time- and Space-Efficient Arguments from Groups of Unknown
    Order(DARK and Supersonic)

  3. I can’t help but wonder: with the introduction of DARK contracts, does that mean we can have private keys embedded in the contracts, and now contracts can do signatures? (being generous here, not considering hardware level sidechannel attacks, etc.) Or, this question should wait until we have POCs, cause there will certainly be limitations to it?( it refes to dark contracts where the execution and code is hidden)

These are some questions that come to my mind immediately after I’ve heard your talk.
Thank you for enlightening people like me - so that I can recharge my will and keep moving forward. Hopefully I can learn more moon math alone the road from respectable figures like you!


I don’t have good answers to questions one and 3, a good reference might be the zexe paper as to how to get code privacy with snarks. But regarding 2
there is no connection between dark contracts, and that paper…its incidental name collison :slight_smile:


Thanks for providing the material and pointing me a right path!
They’re hard to come by for me…Apparently I’m not good enough. : DDD

Congratz on the FFlonk paper release - I’m currently trying to figure out the constructions to it. Wishing that there’d be a PoC and benchmark so ppl can easily see the significance and the power of it. (It looked hard if I were to even try implementing it…no idea where to start.)

I think ppl will then start using FFlonk, just as ppl started using customized gates in their circuits by ultraplonk. No need to be restricted to groth16 friendly addition gates!

Anyway, I assume that we (or it is just me?) don’t like sidechains or even op rollups, cause they’re not…elegant, for their security assumption not relying on computational complexity, but rather relied on incentive design and yet another consensus layer.

Therefore, personally I’m very much looking forward to seeing all the pieces in Aztec (noir language and evm compatibility, aztec 2.0, plonk-powered efficient recursive proving circuits, or more I’m not aware of…) to be combined together.

If we laid the groundwork for ppl beforehand, thus we can be better prepared for the next influx of traffic - it would be a win-win to all the ppl in the ecosystem. Not to mention that the benefit of privacy being default behavior on Ethereum and/or all other Blockchains.

Thanks again, Ariel - your talk and works are very inspiring to me!


I have a stupid question here after listening to Aleksandr’s talk. However, due to the nature of the stupidity of this question…if someone else other than Aleksandr can answer this, it’d be equally appreciated!

Aleksandr mentioned that he disliked the ambiguous definition of zkEVM. Although the term’s coined by matter labs, people are using it incorrectly.

(X) zkEVM is directly compatible with compiled (ethereum) EVM bytecode.
(O) By introducing intermediate languages such as YUL, and LLVM-based compilers for YUL/Rust/Vyper/Solidity/Zinc zk DSL@matter labs, matter labs aim to make the resulting bytecode 99.99% compatible with zkevm(zincvm) in the future, ideally without rewriting the contract code(with solidity or vyper) to minimize porting efforts for devs.

I understand that the answer is already there, just in the talk video.
I just want to make sure that I didn’t get the idea wrong, as I don’t have previous exposure to OS, computer architecture, and compiler courses. (was not a CS major during univ)