ZK Security with Starkware and Aztec Founders

Transcript

Hello everybody and welcome to the July Defi security webinar. We have two fantastic speakers and actually Nathan was the one who proposed the topic and the speakers. Before I go to the webinar today, let me remind you about the main DeFi security summit event which is happening as part of Dev Connect this year in Guano Syas in November 20. We have the already got the the lecture hall from the dev connect team. We got already quite a few great submission and we encourage more. We know that last year we were not able to get all the the talks that we we were were submitted.

But this year we actually got part session. So we're going to accept more talks. We also defy security summit is a very affordable event. The price is only $99. And we cover the event with sponsors. We have already great sponsors. I want to thank specifically Trail of Beat which is sponsoring us for the fourth year. I wanted to have Sigma Prime which is sponsor us for the third year. I want to sponsor thank Lido sponsor us for the third year and have it for second years and hopefully more to to sponsor us.

This is a marketing free event. It's only to educate the community. There's one day 101 which is a to teach people about security and there is also the main talks where a lot of security teams said that is actually the most technical event in the crypto space. So I encourage we encourage more submission. We have a very nice committee. So please submit. So let me go to the today's topic. We have the two of the most distinguished speakers in this space uh talking about zero knowledge. So the first speaker is Zach. I let you start.

>> Thank you very much. Um thank you for that introduction. Um yeah hi everybody. I am Zach. I am the CEO of Aztec Labs and um I'm a former particle physicist by by training now a cryptographer and and an engineer. Um and uh yeah we've been doing this for 8 years. Our mission is to bring for example privacy to Ethereum. Um, and I'm here to talk a little bit about the ASIC network and to do a um a dive into what it is, how it works, cryptography uh and our protocol architecture.

Um, so without further ado, I will share my screen. Um, just give me a sec. Right. And I can show cool. Here we go. So this presentation is going to go through um three major points. First of all, what is even privacy? What do I mean when I say privacy network? Uh and then um I want to go through the critical architecture and our cryptographics text which makes it all possible.

Um so the ASC is um a layer 2 smart contract. So we use Ethereum for consensus. Um and the goal is to to present a uh churing compete smart contracts capable um uh transaction model um but critically difference to existing ones out there um state can be encrypted and instead of the state transition functions being um handled by a um by a sequencer or a Ethereum node or some some somebody in the public domain what happens is users locally prove the correctness of their local private state transition functions and then the zero's proofs are sent to

um the network to be validated and aggregated. And what this means is that the um uh our network can have a state tree that is encrypted um and it enables end to end encrypted blockchain transactions. And uh this exposes the design space of what one can do with a smart contract because with privacy with encrypted data you can now meaningfully put um information personal information on a blockchain network. Um you can put identity um credentials on a blockchain network. Um which means now that blockchains can more meaningfully interact both with web 2 and with the real world. Um previously the enforced transparency was a major bottleneck for this. And what I would say, hang on a

minute. Um, if you're seeing my screen, is it are people seeing the Zoom bar as well? Let's get rid of that. Okay, cool. Um, so what do I mean by privacy? Um, because really there's there's multiple kinds of privacy in a smart contain environment. You have user anonymity. So can you hide the identities of the transaction center? Um, but also do you have data privacy? So the data within a smart contract, for example, token balances. Um, is that um can you hide what functions within a smart contract are being called and can you actually hide the contract code itself. Um and so the goal of a tech and something that we have now achieved with our public test is to is to is to encrypt all of these so that um it is

possible to create fully private transactions where none of this information is revealed by user making a transaction. Uh how do I go on next slide? And the way we achieve this um the contract model really is one where contracts are composed of two different classes of functions. You have private functions and public functions where private functions will um uh can call other private functions. They can call public functions but the main thing is they can modify private states. So there's a encrypted state tree on the um that whose state root is is known by the network. Um and it's a UTXO based model where um much like Bitcoin you have individual uh state notes that are owned

by entities either owned by individuals typically um and that these notes can be created or they can be destroyed but they cannot be modified. Um and one can use those to create more advanced abstractions. Um but it does differ fundamentally from Ethereum's accountbased state model. And one can emit private encrypted events and one can read historical public state. Uh when I say historical, I mean um uh you can read state from a from a version of the network that is not known to be current because private functions have proven locally client side and so users will not um necessarily have access to the latest state of the network. And in public functions, these operate much more like a traditional blockchain

network like Ethereum. Uh they're executed um by the network itself, not by individuals. They public functions and core public functions. they can modify an account-based public state model and they can emit public events and so you can have this hybridized public private ecosystem within Aztec um where some state can be public some state can be private. So to summarize a transaction on Aztec uh so um uh a transaction is really a zero proof of something we call a kernel circuit. So we we borrow this nature from the Zexi paper from 2015. Uh but it's a very different type of architecture. Um uh the kernel circuit is is one um that is written by the Aztec protocol designers

themselves. Um uh and it effectively it it executes what part part of what would normally be within something like uh the GU software um for Ethereum uh where the circuit will validate that if I'm calling a smart contract um that the smart contract uh exists has been deployed that um the um the transaction um correctly exceeds the contract logic via verifying a zero knowledge proof um and then that zero knowledge proof's public inputs will contain um uh information about what that transaction that function called in that contract is doing. Um uh that will be interpreted by the kernel second according to a defined AI. Um so it will read in um uh nullifiers that represent

destruction of UTXOs's um new UTXOs to be created, any messages to be emitted to L L1, um any new contracts that have been created, uh any event logs, and also any other function calls to be executed. Um and uh users will create these private proofs um and then the a third uh the one of the sequencer um entities entities that produce blocks for Aztec will execute and prove the um the correctness of this proof. And so ultimately what's visible within Aztec is um encrypted commitments and nullifiers um messages into and out of L the L2 network that can be encrypted may not be encrypted. It's up to the

contract uh that emits those events as well as public contracts that are deployed and um uh the core stack of all the public functions that were executed. Um and so this is a rough anatomy of what a nastic block is. Again, it's it's a rollup. Um the idea is you know you take individual transactions, you combine them two by two into base rollup proofs and those base rollups get merged in the merge roll up and that will get aggregated into a root roll up. And this treebased type structure just makes it much easier to prove these blocks in parallel using large numbers of physical devices.

And so to try and summarize um this all in terms of protocol architecture um you know we're processing a state transition function. So you have stay hash of the old network, stay hash of the new network. Um but unlike a traditional network, this is all done by launch proofs and unlike traditional ZK roll-ups, um those are rollup proofs themselves verify proofs of individual transactions that are produced locally. Um and so the blocks can deploy contracts to L2. can interact with deploy contracts um pay fees and then we the way that we handle communication to and from L1 uh from the Ethereum network is through um inbox and outbox messages and so there's no real fundamental

understanding of of say an L1 token for example within Aztec um uh this is all handled through the message block abstraction where one will have portal smart contracts on L1 that when you deposit tokens into them will send messages to um a um equivalent contract on L2. Um effectively what one is want to deposit tokens into RL2 one escrow within a special proxy contract on L1 that has a linked L2 contract. Um uh yes so um and to try and slightly um visually lay some of this out. So one the way this all works L2 L1 is your L2

contract um within the L2 network you know will send a receive messages to the rollup contract um and our roll of contract has an inbox and an outbox contract to handle inbound and outbound messages which will then communicate with portal contracts. Um so this is a fundamentally asynchronous way of communicating um it's not really possible with current tech unless you have realtime proving you can't really do synchronous composibility between L21's or between any any blockchain network. um because effectively if if one part of if the transaction let's say we're doing an L2 to L1 flow if the L1 component reverts in a synchronous composibility model then somehow the part of the contract that's executed in

L2 also needs to revert um and so yeah um our our communication model is asynchronous um and yeah you know like one of the things uh this can be a slightly uh dull or less savory part of um uh web 3. But uh I think that identity is going to be absolutely critical to making blockchain mainstream. Uh and the fact that we're ching complete, the fact that you can program contracts with arbitrary encrypted state means that you can perform uh compliance. Um so the example here in this slide is like signature from a KYC provider, but that's that's pretty basic. That's that's pretty centralized. You can do other much more advanced things like for example verify, validate, acquire and validate a proof

of a passport um that was issued by an NFC scanner. Um or you can do basic civil protections like uh you can prove that one has a using zika email or z like prove you have a Twitter account with over 100 followers to get some basic civil resistance into your protocol things like that. Um uh yeah and that's just that's just the start of it. So, um I can't how long have I got? I've got um we only got about a few more minutes. So, I'll try to speed through this uh cryptography section. Um so, the cryptography that we do is very very custom. It's it's descended from the the original Plunk paper that came out in 2019 with an enormous amount of um uh iterations um uh that have come from

all over the all over the design space of of of crypto. uh many many different contributors at this point um um but we use um a plonkish type system and client side incrementally verifiable computation. So all of these functions um they they compiled into circuits um and then uh they're composed recursively um via an IBC scheme to make a single transaction proof. So the requirements for our cryptography is it used to be low memory because we're doing client side proving in a web browser. Um and for example if you have an old phone you've got about a gigabyte of memory to work with. We need extraordinarily fast recursion or an equivalent like a folding scheme because we're doing a very very large number of these recursions client side both to compose

multiple function calls but also to um reduce resource requirements, memory requirements. And the proof size needs to be small. And this is one that's often overlooked. Um, but for a decentralized network like ours um to get the transaction on chain, one needs to send it to a peer-to-peer um mele. Um, and these the where um individual asset nodes are being run by individuals. So that the the the bandwidth of your node operators is going to be that of a broadband connection and the bandwidth of the P2P network that they're constructing will be substantially less than that. And so if you have for example a thousand TPS and your proofs are 100 kilobytes then that's 100 megabytes a second of HP network bandwidth required which is not

practical. Um and uh yeah so um having a small proof size is important. Uh so our cryptography stack is we use something called hawk which is big derivation of pla galaxy which is a descendant of pto star which is a folding scheme to fold these instances. We use something we call Goblin PL which was developed um by us to effectively um eliminate the computationally challenging parts of folding schemes when using elliptic curve base systems. Um and we use a multi-linear polinomial scheme called Gemini.

Uh so honk is a multilinear um as I said plunkish ziknog with many many changes. It uses a sum protocol as it's polinomial if as opposed to um uh um zero checking uh using um quotients uh as in the original paper. Um so uh this was first uh elucidated in a plon scenario using from the hyperpunk paper in 2020. It's pretty memory efficient. So if you have an execution trace take every cell in your execution trace roughly the number of bytes multip by the 1.5 that's roughly the memory. um it can go lower. Um the multilinear PCS is a gives constant size curence um which

means extremely easy folding um because you're just doing basic um like linear linear um exploiting basic linear homorphisms from elliptic curves and the polomial algebra of the system supports a few gate types. So these are not really like these are not really pre-ompiles in a VM sense, but they're more just specific types of algebra that one can apply to a given row in in an execution trace. So these are pretty pretty small modules. Um you can do things like lock up lookup tables, generalized set membership checks, which we use to create ROM and RAM abstractions and fast range checks, big integer arithmetic algebra. So you're doing big integer arithmetic just having special polinomial relations that will do all the limb multiplications.

um and uh something which uh some custom gates that will evaluate um uh one of the besidon two rounds. Um so uh we also use an execution trace width of four which is by modelers very small. Most VMs have many thousands um of columns not four. Um but this is uh partially because we want very small proof sizes uh with um to for faster verification, faster building and for the fact that all proofs um within the ASIC network need to be uniform as in you need a for simplicity a uniform verifier. Um uh so goblin plonk is a um framing system.

It's not an IVC scheme. It's an accelerator for IVC schemes. um depending on that that depend on elliptical arithmetic. Uh I've got one minute. This might be a little bit hard to explain in one minute. Um so if you're folding um elliptic curve base scheme, well the good news is that your commitments are constant sized. Uh so um you don't have a huge amount of algebra to do uh to um create linear combinations of these but the algebra is going to be through non-native elliptic curves. So what we do is instead of doing it within a snark circuit we present as witness a witness a claimed result of an electric operation and then we store the inputs and the outputs of that operation in a transit um commitment. Uh so this is just a column um in the circuit that when the circuit

becomes a a proof will be become a commitment and um per I R I R I R I R I R I R I R I R I R I RVT step these transcript commitments are accumulated into a single commitment. Um again like this is um being h happening through um basic elliptic curve algebra which is non-native but again the non-native elliptic curve operations required to accumulate transcripts is deferred via goblin into another transcript bit complicated and then once one has one of these transcript commitments we have a special snark circuit called the translator circuit which uses a small number of non-native field operations not group operations field operations five per group operation to effectively transform the transcript commitment into one that's um defined over a cycle curve. Um and then we use that cycle

curve to prove the correctness of the transcript um by effectively at this point now performing native elliptic curve arithmetic because you're using the cycle K. Uh uh so all in all um it turns a native a non-native group operation into a native group operation and five native field operations. So it's extraordinarily fast and it makes our recursion um cost you know client side um you know with limited resources prove it prove it in the milliseconds um and this is a a diagram I don't have time to go through um so I'll just uh leave with um the state of Aztec in 2025 you know where are we today with our network with our architecture with everything well the designs are all pretty much complete um the programming language that we used to write smart

contracts noir has 1.0 has been released. We've launched a public test net of Aztec where you can and people have built and deployed applications. Um and we launched our adversarial test net today where um it's adversarial because anyone can be a sequencer and sequencers control the upgrade flow. So um uh we basically are inviting people in to pretend to be bad actors and try to break our test net. Um and hopefully uh we will be launching our alpha um on the main net soon. Uh, and I wish I could give more details, but uh, I'm afraid I I'm I'm being sworn to secrecy uh, for the time being. Um, but we're working very hard to um, progress into our audit phase and finish our security audits, which is the last major step for us.

Right, that's me. Uh, thank you very much um, for listening. Uh, and um, so I just noticed I had some questions. Um, uh, but um, now I'm running out of time. There's a polinomial IOP is a polinomial interactive oracle proof. Um so it's a way of taking a um complicated arithmetic statement defined of a polinomial. So let's say you have like degree 1 million polomials um a a of x b of x c of x and you want to prove that like a of x * b of x - c of x equals z.

A polinomial IOP takes complicated polomial algebra and it reduces it to algebra over individual points um uh uh through generally through some kind of a interactive protocol between a proven and a verifier that's transformed into a non-interactive protocol via a huristic but techniques do vary. >> Thank you very much Zach. So we're going to have Zach again for the QA. Thank you very much for the inspiring talk. So the second talk is Eli and after that both of them will listen to your question. I have also some questions. So Eli why don't you start and introduce yourself in the interest of time. Thank you and I think I need no introduction here but

>> hi Ellie Ben Sasson I'm a co-founder and CEO at Starkware. Um started my research on proofs uh mostly publicistically checkable proofs around 2001. Started implementing them around 2008. Got redpilled uh by giving a talk about them at Bitcoin in 2013. That was the first time someone realized that um um proofs um can help not just with privacy but actually with scaling of blockchains.

And I was very fortunate to be the person realizing that because that changed my life forever and ever since I sort of veered more into um blockchain and proofs. Um the very first thing uh we did was the zeroache paper that then led to uh the Zcash um you know cryptocurrency. I was one of the founding scientists. Um that actually did not involve scale. That involved um privacy. Um but I was always more interested in the scaling and I was always more interested in stuff that doesn't rely on elliptic curves and quantum susceptible cryptography. I I uh so that led to Starks and Stark were founded in 2018. what I want to do for

this talk. Um, I know Star War is behind Starknet and um, you know, I have a bunch of uh, proof systems out there. Stone and more recently stew both are open source. Uh, there's also the Cairo uh, programming language which is the one that powers starknet and uh, I think among its benefits are that it leads to a very efficient um, stark proof creation. Um, but it's also a generally good language for um, smart contracts. Um, I want to state very clearly that even though we're called a ZK rollup, uh, we're not ZK and privacy that stuff that Zach and

Aztec are doing and excelling at it, our even though we're called ZK roll-ups, uh, the systems we have right now do not offer ZK um, and don't focus uh, on privacy. So I prefer to call this technology validity roll-ups because we focus on uh validity proofs and uh you know using them to succinctly prove transactions but um you know just uh you know I try to fight that u you know those windmills of of saying that uh you shouldn't call it ZK roll-ups at least not our stuff I mean Aztec you can call it a ZK rollup but anyways I think it's a lost battle. So it's called ZK rollers but to emphasize what I'm going to talk about is not related to privacy. Uh it

could but it's not. Okay. So what I want to do and this is a talk that I gave already several years ago. I want to talk because we have a lot of uh you know big security experts. I just want to talk about uh and I'll share my presentation. I want to just go over um you know the various um um do you see my my screen? Yes. Yes. >> So I want to just uh talk about the four um attack surfaces that are unique to proof systems and uh then then discuss them you know um what we do to address them or acknowledge them in the context of uh Starks. Um okay so I want to say that there are if

you're if you implemented a proof system that proves that Turing complete uh um programs right generates proofs for them then there are four unique areas of course whenever you're dealing with Turingcomplete systems and of you know Mully is a much bigger expert on me then you have the halting problem which in in layman's terms means you you never you know you cannot ever truly debug uh you know mathematically debug uh a complex enough uh u framework. So in particular whenever you're dealing with uh any framework that allows you to do any computation then you know there's that whole area but it is not unique to ZK proving right uh so I want to talk

about the unique additional attack surfaces or risk surfaces for proof systems and they lie into four and one auxiliary that is uh in the ZK setting which you know I gave you already an introduction saying we're not doing ZK right now but I'll still mention it. So the first one is uh is in the um crypto primitives assumptions right what are the assumptions that you're making and what happens if one of them breaks okay so that's one area that's one risk surface you know we've seen this for instance for RSA a bunch of times over the years where basically new um factoring algorithms and huroristics led to increasing the moduli size for RSA to be considered safe right that's one

assumption And of course you know Shiaan or whatever MD I forgot which MD being attacked and you know that's another kind of uh instance of these uh these issues of the very basic crypto primitives that you're using. So this is true um because all ZK systems they are cryptographic system and unfortunately none of them can be um built without some cryptographic assumptions. So you're going to have that's one risk surface you have to be aware of. The second one is the protocol security analysis. So the way a ZK protocol works and starks are no different is you you basically use a number of cryptographic primitives and then you also use um you build a

protocol and you prove a bunch of stuff. Now you either could have a bug in your protocol itself or it could be that in the implementation of the protocol maybe the white paper is fine but actually the implementation uh leads to an issue. So this is related to the protocol right um that's a second attack surface right a third one is arithmetization so I'll get into details about that but when you actually take your specific computation um you're going to need to at in some way reduce it to a bunch of uh polomial constraints and then uh the question

arises especially if it's a a complex system the question arises is do the constraints adequately represent the computation you want and here I think the analogy is um you know suppose you're going to build a a chip a CPU right some some collection of NAND gates that are connected to have some functionality so you have to worry like uh you have this high level specification of what this the chip will do but then the question is did you place the NAND gates and wire them together in a way that actually captures that correctly or maybe there's some some error okay so that's arithmetization in the case of proof systems and then um finally there's the uh actual um basically code of the system itself

um you know in which you wrote usually the arithmetization will lead to some uh you know either DSL or high level language and then there's of course the question of the specific code which now is a little bit different because it deals with a you know cryptographic system and then the fifth attack surface which is only in the ZK setting is what happens about leakage like you know ZK is about privacy and preventing certain things from uh uh being leaked via the proof but maybe something else in the protocol uh will leak things that you so so maybe the the protocol is fine but you somehow by mistake leaked stuff. So now I just want to go over some you know some of the ways we this these things

manifest themsel when we construct our ZK stark systems and what we do to address them. Okay, so first of all, what are the crypto primitives or assumptions when you build a stark system? So there are actually two modes in which you can instantiate the stark in the purest and simplest way but but one that is interactive um an interactive stark which basically works something like this. The prover sends a commitment, a morkel tree commitment um and then gets some randomness, then sends another commitment, then gets more randomness, you know, for a few times and then finally gets more randomness which specifies a bunch of queries uh to the various Merkel trees and then the

Merkel trees are open and you know some some decision circuit is applied. Okay. So in an interactive start we know to prove that all you need is a is some collision resistant hash. It doesn't have to be a cryptographic hash function just some collision resistant hash. So it's a very very mild assumption. Um and and that is the only assumption that you need. Beyond that everything is proven uh based on math. And by the way when I say proven I I mean even if your adversary is computationally unbounded you know can run a quantum computer can run for time two to the two to the power um no sorry I take that back. Sorry. If it has too much running time, then it actually can probably break your

collision resistant hatch. So, I take that back. But it certainly can be a quantum computer, that's fine. As long as you have something that is collision resistant uh for the um attacker, then then uh you're fine. If you go to a non-interactive stark, which means you basically use the fiat sham, then you require more from your hash function. You basically are going to apply the fiat sham and you want your hash function to be uh something that you believe is a good um you know a good thing that you can treat as a random oracle model. Now the random oracle model for those of you who know is something that is um actually impossible because like from a you know cologor of complexity kind of a approach

you can never have a succinct random oracle. But nevertheless uh for better or worse the world is very uh comfortable using the fiat heristic and treating uh you know things like shatu or ketchuk or blake as random oracles. But I'm saying that's that's you know that's if you want the non-interactive strike that's the kind of uh crypto assumption you have to work with. Uh the nice thing is these assumptions um you know are widely believed to hold also in in a world where you have efficient quantum computers. So you know there's there's hope for using starts um both interactive ones and non-interactive ones um even if tomorrow there's an efficient quantum computer. Okay. Um the

second um the second uh kind of uh let me just see this. Oh this is just something that I took from a a blog that I wrote a very long time ago. There I can share the slides with Mully who can share with you and and with Nathan and he can share with you. Um there's a blog and and a video where I discuss this. U this is many years ago right? This is already uh I haven't updated it in the past I don't know five years so it's not up to date but basically um different proof systems they uh I say the I'd say the big dividing line is ones that are uh require only symmetric cryptography mean as their assumptions and they're plausibly quantum resistant and you know this is some collection of of uh things

that that were at the time five years ago um and then you have the stuff that is based on asmmetric cryptography number theoretical assumptions and those could be break uh you know yeah shor's algorithm breaks a lot of them I think are pretty much all of the ones that that I'm aware of um and you have a bunch of them so so that's like a you know there's some sort of a dividing line between different you know big families of uh proof systems out there um okay second thing I want to say again in the context of Stark is like h you know how much do you trust the protocol uh the protocol security, right? The uh you know the actual protocol that was

designed and you know is it is it is it okay? So here usually what people do is they um you know refer to peer review um you know the test of time in general the more eyes look at it the more times it's whatever quoted or referred to and others look at it uh that's better. So a lot of the core protocols of uh Stark have been uh you know appeared in like leading conferences many years ago already by now from like you know 2018 2013 2015 so they're like roughly 10 years out there um in particular one thing that the Ethereum Foundation um asked us to do as part of the Ethark

project that we did and started in around I'd say 2019 and finished it about a year later. I think they wanted us to do a a second mathematical audit. So we basically um contracted two esteemed you know independent professors professor uh um Venka Gulwami and professor Amnant Tashma and basically gave them all of the core papers on which the Stark protocol was based and asked them to you know scrutinize them try to find bugs in in the analysis. Um and and that's the second thing that we did in that case. Um they filed a report. There was in one of the

soundness proofs of the first Fry analysis actually professor Tashma did point out a bug but by the time that was I mean that was discovered by him there were already two or three better and more um tight analyses of the same protocol. So um now you can always like wi-i with all of these mathematical protocols you have to ask yourself you know do am I confident enough that these things are are sound. I know that by now um folks are starting to talk about using things like you know lean um and you know coaul and other automated theorem provers to try and

give even more robust proofs to various protocols. I think it's a it's a spectacular effort and uh um yeah I hope that all cryptographic protocols uh get to that level. Um anyways I'm saying that is another kind of uh security surface uh that exists there in that context it's very interesting that recently there was a very a beautiful piece of research coming from um Ron Roth Bloom and I forgot who else like it was a year ago that showed a very very nice result something that says like this if you take there's a beautiful

protocol for um you know for a kind of uh um starks or things that are rely only on symmetric cryptography that's called the GKR protocol goes back to a protocol by uh it's based on the sum check protocol but then you know sort of made uh or beefed up for uh general computation and what the researchers found is that okay the protocol is is okay when however you use the fiat sham protocol with respect to it then certain claims can be broken and uh that was a very and and they even have like the kind of claims that can be broken don't

depend on like no matter which hash function you instantiate fiat with um you could still make a false claim and uh that's a very interesting uh discovery. So uh so you know that's like one case of a protocol that uh let let me just clarify the GKR just like in.1A above there's an interactive version of the GKR protocol and the non-interactive so the interactive version of the GKR protocol actually is one of those few cases where no cryptography is needed no cryptographic assumptions is needed however it works only if you have a very large number of rounds of interaction

So that part is completely safe and there's no issue with the protocol. However, in many cases the GKR protocol is then instantiated in an interactive setting and then uh the attack was was shown on that thing. So that's just an interesting case from recent times of of this kind of attack surface on a protocol. The third kind um is arithmetization and just want to explain what arithmetization is. arithmetization. You take usually a problem about computational integrity and convert it into a problem about some relation between a bunch of polomials.

And here's just some examples. So someone wants to prove to you that uh a string Z um that is 256 bit long. Bob claims he knows a pre-image of Z under shot. Okay, that's a computational claim, right? It's something about the way SHA 2 works. So what is an arithmetization? It reduces this uh this problem or this claim to a claim about uh polomials right um the sort of the verifier produces two polomials and some degree bound d and now there's a new claim that the verifier is saying you know Bob you want to you want to prove to me that you know that there exists some some y such that shu of y equals z instead of that please uh present four

polomials a b c and d all of them of degree at most is such that a certain relation exists. For instance, if you plug, you know, replace the v various variables in Q with all kinds of polomials. Um, then then you get some equality. So that's an instance of arithmetization. We started with a claim about computation. We ended with a claim about uh polomials. And uh this is very efficient because it's very easy to test using randomness whether a claim about polomials holds true. And I won't go go into this. So arithmetization just means you know who said that you did this reduction correctly like what if uh you know the four polomials sorry the polinomials Q and R um are not really

the right things to for you to check in order to know that the pre-image of Z is Y right that's the question of that's the risk surface so what did we do about it the way we addressed it with our Stark systems is that we designed arithmetization essentially for a very lean uh virtual machine that's Turing complete the Cairo virtual machine it is so lean that it has something like uh you know 50 polomial constraints and many of them are very very simple ones and then what we did is we applied actually the lean automated proving system um and and showed that the specification of the virtual machine equals the set of polomials there arithmetization works and by then there've been a number of other white

papers um by Jeremy Avigad, Professor Jeremy Avigad, you know, an expert on automated theorem proving from Carnegie Melon and a bunch of folks from our team led by our CTO Leo Gold to discuss this. Um but but I would say that maybe arithmetization could be the the three and four are the parts that I think uh are most scary. Um and then four um just means that you know you you in the end you implement things like the verifier um by by code in particular when we run our layer 2 it's going to be code written in solidity uh that verifies a stark uh system and then again you could just have bugs there. So the way we

approached that is we did a bunch of audits by crypto experts and others and then a whole bunch of audits also for the recursive part of it by internal independent team and I guess this thing that says soon this was like three years ago so by now we've done it. Um so just summing up there are four uh you know unique attack surfaces um to uh cryptographic proof systems. I described a little bit what we did in our case. There's a fifth one that is very interesting very interesting in the context of uh ZK leakage but uh you know that's not something that we're dealing with and with that I end my presentation. Thank you very much.

Thank you very much. Thank you very much Eddie for inspiring and and talking to us about the potential risks and maybe Zach will join too. Let's see if >> okay so I see that so far no question I I start by one question it's a bit generic I'm sorry about it but I think for both of you it would probably mean something what are the biggest I mean you have been both leading this space but what are the biggest mistake or at least one big mistake you can share along the route I mean early you go and you went to the Ethereum and later on to

Bitnet And and Zach in in your approach here is is that something that we can you can have done. I mean Zach you did not yet launch but you will soon soon launch. But I understand you cannot if you could change something. What is the one thing you you guys can change? >> Well that's a big question. Uh should I go first? What could I change? What mistakes have been made? I mean, you know, it's uh I've been doing this for eight years, and I mean, I've gone down a lot of blind alleys in that in that in that in in that time, you know.

Um um you know, we're close to shipping the thing like the Aztec network, which is something I've been wanting to build um for about seven years. Uh and you know, if I'd known how to do it, as if I'd known the cryptography, if I known the technology, I could have got it done about five years in the past. But instead um you know like I think I've probably spent I don't know like uh like probably like two like roughly like two years working years entirely on trying like trying to solve snark recursion like the various random schemes I've come up with over the years um you know it's it's uh enormous amounts of time spent um and then schemes turn up and it's like oh okay well that's that's solved then uh um uh but what other things I I think um

honestly okay so when I start sorry my rand bit when I started Aztec like the hardest I thought the hardest part was going to be like um like effectively inventing the required technology inventing the doing the research getting the papers out and then once I done that I realized actually no maybe the I think the hardest part is probably actually um productizing this and like turning an idea of like a paper into actual software into code into products and now later on a few years later I'm like actually no that's not the hardest part the hardest part is is literally organization building it's actually building a team of people around around you that um have the the the the the skills, the mission, the narrative, like the drive to to to execute on this because what we're trying to do is so much larger than what one person with

one mind and two hands can can achieve. Um and so I have had to learn a lot of lessons the hard way uh in that journey. Um but um uh yeah, I I I can't think of anyone like there there's many so many I could come up with. Um but basically yeah like spending so much time researching blind alley snark curtian methods was big waste of time in hindsight. >> Okay well I let you answer and then we have many many question from the audience. Let's try to answer them one. >> Can you just repeat the the question?

>> So the question is what's the biggest mistake that you have done since you started the stockware maybe? I mean you you worked before on on snack I guess but what's the biggest I mean decision or I don't know if the mistake could be a different one. >> Yeah. Um >> maybe not the biggest. >> Yeah. Like okay first of all I'm sure we made many many many big mistakes. The only issue like with mistakes is that it's very hard to say I'll mention a few things where um we had like huge debates and I'm not sure we made the right decision but the reason I'm I'm not saying that it's The mistake is that I haven't seen the other route of it.

Right? So, let me just mention a few things. I uh our first prover was over very large fields and that was unnecessary that stone which led to something that's much slower. Um and now stew like over small fields is much much faster. And I remember that it pained me even back then. But so so like I if I had a time machine maybe I would go back and insist on it more but I'm not actually sure that it was a mistake because uh there were very good reasons at the time like it's simpler and Ethereum you know gives the same cost for verifying small numbers and large numbers. So like in some sense if that's your metric and it was the limiting metric for a very long time um it's sort of even more efficient to use like very large numbers. That's one example. The

other like really large example that I really don't know is like you know we went with the Cairo VM and led to a completely different stack right that is not EVM compatible and right like this really big question is was that a good uh a wise choice or not a wise choice and I don't know uh like the jury is still out in the following sense like I think we ended up with something sorry I know we ended up with something that is way more efficient and scalable for generating proofs and I also strongly believe it's because it's like a second generation smart contract language. I think it's actually better as a smart contract language. However, certainly uh you know in terms of like integration and you know dev uh dev x and stuff like that yeah it's like a new language. Um

but the jury is still out because like um I think that like if we have like one killer app and one use case that everyone wants then you know this may solve for the second problem. people will come in and they'll say, "Oh, you know what? Actually, Cairo is a better language." And uh so I don't know, but those are like two very strong cases where I'm not sure if we made the right decision. Uh you know, large fields from the start and then uh Cairo is a dedicated VM. Um yeah, I can start answering. I see there are like some uh >> yeah, do you want to so the the do you want to answer? I think this is for both of you. What are the key issue by Fabio?

What are the key use cases where Aztec is preferred over snack and vice versa? Who who wants to take it first? >> I can take it first. Uh I'll take the first two questions very quickly and then uh so the first question is like what are for me I think uh the huge trade-off between something that is privacy focused and let's say scale pro focused is really about like uh well privacy like if you really care about privacy definitely you want to use Aztec and not Stark. But the trade-off, at least as best that I remember, is that you have to understand that you'll probably pay in UX mostly like the UX won't be as easy. You know, the various integrations coming in and coming out and stuff like that won't be as smooth.

So, I think if you need privacy or the more you need privacy, you must use Aztec. If you if you are somehow fine like most crypto users show with their choices uh and you want good UX, you want that. And I just have to answer the second question. you know, why would you rather hold most if not all blah blah blah and startnet versus ASC. So, first of all, there's an assumption here um that you know that you're assuming that we each uh you know that I'm not like uh don't have a large bag of Aztec or not long. So, uh you know, I'm not going to answer where my uh where my beliefs are. Um but um I think there is something like generally right uh I think there is something a little bit uh emotional about like uh you know projects you're somehow involved in but you may be right

that the rational choice for any sort of uh crypto person is to diversify not just among uh you know Aztec and so and a bunch of other things but you know not investment advice I'm very very uh supportive of Aztec I think it's a great project and I'm long Aztec again not investment advice I don't know what the tokens is going to do. Um, I also like uh starting it in STRK. Again, not investment advice. So, anyways, that's my answer. >> Exactly. >> Yeah, I think when it comes to use cases, you kind of hit it on hit the nail on the head there. Um, and obviously I'm just I'm way too biased to invested in Aztec. Um, so I think uh I mean um imagine if if if uh if the for either of us, you know, like um if we

withdrew a bunch of tokens and then you put it in into another project, it doesn't really it's not not a great sign. But one of the key advantages of Aztec is that if you as a founder get kidnapped by French bandits um and they they they demand your money at knife points, then you can you can give them you can give them 10% and claim it's all you have and they won't know. They won't know. Interesting. >> That's a bit dark. >> That's a good one. Yeah. Now there is another one I guess in Belgium. So the the the third question I I don't know. Can you use ZK proof to verify that contact are signing from your hardware is verified and not malicious? So who wants to take this?

>> Well, I think what what does verified mean? Because like uh uh >> like uh if if it is already signed by something it's like verified means signed then then you just need u right digital signature u if you mean that like uh someone has uh passed it through uh some code that checks it and then you have a proof that that that is secure. Yes, then definitely you can do that. Um >> okay then there is a question actually by our audience actually that's very important for people are attending here the lot of people who want to learn I guess Cairo noir we are seeing so

actually tell us yeah so what what actually is the biggest problem from a actually interesting for me to what are the biggest issue from assuming the infrastructure is right I know it's your you have most complex infrastructure but what's the user level mistake and and for security researchers who are looking to learn things what's the background do you need to go and uh study PCP or things like this to to be able to to understand these things or can you just read code and find bugs >> I I can I can tackle I can start with this one um so I mean there's many layers of abstraction within networks

cars. So um uh you know what layer do you want to specialize in really uh because it's it's a struggle to do all of them. Uh I don't think that a security expert at this late stage really needs to learn about cryptography from a from a fundamentals or first principles level. We've been they need to know cryptography at all. um because you know networks like Aztec like Stocket we have lang domain specific languages not Cairo and and so there's a huge amount of understanding those languages and architectures is is a huge is is a great place to start because um take for I'm not entitled about the specifics of Cyro but take no what it does is it compiles into an intermediate representation um uh called abstract circuit intermediate representation which can which relatively directly

translates into constraints and so um understanding the level quite deeply will is sufficient to detect um things like for example um whether there are under constrained bugs. That's the main class of bugs in circuits. It's you know you you're you you're performing a computation. You're proving that computition being performed but the proof isn't complete. Um uh the checks aren't complete and so some some issu some issues can leak in. Um you know there's also just basic critical architecture like a lot of standard blockchain security practices apply and transfer over um you know at this point you know like the the the cryptography is buried so deep within abstraction layers that um just being understanding

our language at a deep leveling and understanding our particular architecture is um 90% of the battle. Yeah, I'd say it's the same. Uh we have a different programming language and intermediate representation, but it's the exact same answer. Almost all of the security folks uh working with us and there are many of them uh you know a lot of auditing firms and so on they they you know what they specialize in deal is with that and for that you don't need to know um uh any of the cryptography it's about either the intermediate representation or the high level language in our case Cairo and the intermediate one is called Sierra and that's where everyone focuses on um of course if you want like uh you could

like uh uh study the cryptography and look at the actual protocols but for most security folks that's not uh needed and it's not what they want to do and there's more business in the just you know auditing and checking security of uh the smart contracts I think >> and and is there something specific on the sort of the application level that you need to understand something about the or it's essentially you're implementing anything >> maybe for privacy I would say things like well leakage and like um assuming that the ZK is fine so like whatever you but there is this distinction between you know witness which is the stuff that's supposed to be you know preserved

and the zk preserves that but like I could easily see cases where a programmer you know wouldn't be aware of this and then do something where u stuff that you know passwords could somehow leak somewhere so like this distinction is in the case of zk in the case of like starknet It's irrelevant because we're not offering privacy and then it's just like uh you know auditing solidity codes or move codes or whatever Solana code smart contracts. >> Yeah, totally. The the the um uh you know the book around like safe private smart contract development is yet to be written. Um and so there's likely going to be a lot of mistakes made along the way. Um yeah, as you said like because our our our protocol supports both

public and private state. Um it's very easy as a to to write a contract where you know everything's public. Um and uh so just the fact that one is using Aztec does not make it private. Um the contracts have to be coded up correctly. That requires an enormous like the meta around doing that securely is is is still a work in progress. Um, and uh, yeah, there's I mean I pretty sure we even have grants open uh, if you go to our website, go to our grants page if you uh, to to help us with that. >> By the way, I'm just thinking online here. I'm guess I'm guessing that Zach and the team have already done such things. But if there could be some sort of I don't know like debugger parser that as it looks at let's say u you know a bunch of uh noir programs would sort

of just highlight oh look here are here are things that are actually shielded and here are things that you know you just like green and red like this stuff is you know be aware that this will be known because whatever it's exposed somewhere like uh like what things are actually being protected and what things might leak. >> Yeah, that would be nice. Um that would be nice. Uh I I think it it should be fairly I mean um because we already have a separations into public and private functions is is fairly straightforward where like if stuff's turning up in a public function it's it's not public. So I mean it's not private. So um uh but yeah like having visual descriptions having actual debugger information >> but then when you compose them and like you know start you have libraries and

like uh you know how do you track that and say >> I mean you know was it was private somewhere but now by mistake was >> yeah so in programming language people have information flow unfortunately >> reach out to our grants team we'll pay we'll pay anybody wants to do that we'll pay you >> okay so we have to wrap I'm sorry about it thank you for your time uh you can feel free to reach Ellie and and Zach on question. We're going to publish the the YouTube very soon. Thank you very much Ellie and Zach for teaching us and security. Thank you everybody.

>> Thank you so much. >> Thank you. >> Cheers Elliot. >> Bye. It's been great. Thank