Episode 293 - Exploring Security of ZK Systems with Nethermind's Michał & Albert

Transcript

foreign [Music] welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online [Music] this week I chat with mihao sions and Albert garretta from the nethermine team we find out about the origin story of nethermind and the place it fills in the ecosystem today we then dive into the research that the cryptography team has been doing such as their work on proving

the security of fry the work identifying security lost when using feature as well as exploring topics like ZK malleability ZK aggregation and the work they are doing to build snarks over Rings this is a pretty research heavy episode it was fun to dig in with the team and better understand what security research looks like at nethermind now before kick off I want to share that one of the top sponsors of our recent ZK Summit anoma is on the brink of launching namata a layer 1 asset agnostic multi-chain privacy solution that seamlessly integrates IBC and ethereum Nevada needs you to try out private transactions on their testnet so head over to blog.namada.net and join the pneumata Discord to find out how you can help and

we'll add the link in the show notes Tony will share a little bit about this week's sponsor [Music] polygon cdk is the go-to open source chain development kit for building and launching your own ZK powered ethereum L2 with a shared ZK Bridge polygon cdk deployed chains tap built-in access to the liquidity on all cdk chains and public networks like polygon POS and polygon ZK evm experience unified block space with the security of ZK using polygon cdk build chains precisely to your specs from level of decentralization to throughput to cost and the core devs that polygon labs are on track to develop a type 1 prover that means existing evm chains will be able to be upgraded to ethereum l2s with

polygon cdk this means more ecosystems more cross-chain applications and an enhanced Network effects polygon cdk is the raw material of polygon 2.0 an ecosystem of interconnected chains that create a value layer for the internet check out wiki.polygon.technology forward slash docs forward slash cdk to start experimenting with your own ZK powered L2 today so thanks again polygon and now here's our episode [Music] so today I'm here with two members of the nethermine team mihao Zions and Albert garretta welcome to the show both of you hi it's great to be here hello yeah nice to be here

so the reason I wanted to invite you on was I really wanted to understand what nethermind is as an org I feel like maybe I've seen it through a number of iterations but I remember like I've known the name nethermine for a long time I remember it being something like around client development for as like ethereum was trying to move from its eth1 to eth2 back in the day I've known nethermind as a Dev shop and yet every time we do ZK Summit we get these amazing applications for like ZK cryptography work from your org and I also see some of your papers being featured in ZK mesh and so I just felt like it was a good time to figure out like what are you guys doing and what is

never mind okay you are very right about their mind developing ethereum execution layer client so because that's how the the company started in 2017 uh basically our founder Thomas steinchak wanted to code ethereum client uh he started by by himself then in 2018 he got the Grant from ethereum foundation and he was able to uh to to build a team of developers who were working on on this huge project uh building building the ethereum client uh fun fact uh the the first like company name was actually never mind because Thomas didn't want to think

about his name uh but eventually it was changed to to determined what can be explained as a connection between dotnet uh because um the client is is written in the.net framework ether and mind I'm not sure about this mind part but it's well because I I guess that was the the leftover from never mind yeah probably yes cool and uh yeah fast forward to today and we are company with over 200 people uh doing like multiple multiple things uh so we we have core developers that developed ethereum execution layer

client for for retirement but also for for noses we develop a starting ecosystem so we have developers who work on startnet client called Juno on blocks Explorer called Voyager in past we we had a solidity to Cairo transpiler called warp we do formal verification we do security audits in cairoi in in solidity we do fi and cryptography research we do Tech DDD for investment funds blockchain development for Enterprises yeah a lot of a lot of things yeah yeah and so so here we are we can only represent like a very uh

tiny piece of the company called cryptography research okay got it one question here though is like are you also a Dev shop like could a team hire you to build out a part of their protocol if they needed to does that happen or do you say you're more hired for like specific research projects or more for auditing research the development and auditing we have the various teams okay you do do all and you are building then like but would you also wear the dev shop hat then and not us personally uh but other Engineers are okay so let's find out a little bit about the two of you and then we can talk more about the team the specific

team and the work that's come out of that team in nethermind mihao why don't we start off with you tell us a little bit about your background also like when did you get involved in this company so I started in Academia uh I was doing that PhD on cryptography at the University of Warsaw I was working on something called leakage resilient cryptography so basically I was analyzing what security guarantees we can have if part of our for example secret key uh got leaked so the adversary of some hacker learned that part of of the secret key after that I I switched to to zero knowledge I I moved to tartu in Estonia it's like a very

tiny tiny town but with with a strong cryptographic research group led by heliger litma and I started to work on zero knowledge uh that was 2016. um wow we we worked on shuffle arguments which are important building block for electronic elections but then graph 16 paper came out so we switched our gears to to snarks so I realized that I was always interested in insecurity assumptions in in modeling security of of proving systems and also there was another paper that that came out in

2016. I think like it's a bit less known than a graph 16. it's better by Belarus balance kafura where they introduce a concept of subversion resilient zero knowledge proofs so basically they they were investigating what security guarantees we can have if the trusted setup that is often required for zero knowledge proofs is generated by a party that that cannot be trusted so so they considered when the trusted setup was generated by by approver whether we can have any soundness in that case or when the trusted setup is generated

by by the verifier whether we can have any zero knowledge any privacy guarantees uh so so we had this uh this paper we had graph 16 so what we try to to check is whether graph 16 is secure when malicious verifier generates The Trusted setup for for the approver and a long story short it is secure uh oh it is secure okay yeah I I always like to to work in in modeling security and also like checking how much we can push a proof system yeah unless until it's it's got It's got insecure got it and I have this feeling that this is

also reflected in some of the other work we're going to talk about yeah in 2019 I I got my first crypto job as crypto like in cryptocurrencies as cryptography researcher and uh I I joined a company I was working on on a system called zeph which was uh we we tried to to build a zikash on on ethereum so I can say that I I was working on Ezekiel rollup in 2019 but not quite or was it what was the missing piece then actually why why would that not have been a roll-up back then what was like the part you were missing I I would

say it was up specific roll up okay okay it was not like General computation yeah and then at the beginning of uh 2022 I I joined nethermind to to build cryptography research team nice here we are cool Albert tell me a little bit about your background what you were doing and when you joined nethermind yeah I'm also I also come from Academia I I was in Academia doing mathematics my PhD was on studying equations on algebraic equations in all sorts of structures like Rings groups also monoids mostly non-commutative stuff I I spent several years studying algebraic

equations there I the problems are related to Hilbert's stealth problem which uh it's a famous problem where you have to find out if there's an algorithm that solves the equations in that structure and basically turns out that in most cases there's no algorithm okay um yes and then um on 2020 I was I was doing these things and I was proposed to to join the blockchain and crypto economy Master a new Masters program that that was formed in my University and I started teaching cryptography there where were you studying I was in in the University of The Basque Country at that point okay cool and I did the PHD in New Jersey at Stevens Institute

of Technology nice and what at what point did you join industry and what made you make that leap I I slow I got slowly pulled into the blockchain world while I was teaching cryptography at this blockchain Masters okay I started getting acquainted with with the area and I learned about you know knowledge and eventually approached nevermind and joined michal's team in 2022. cool what was it about Netherland like why given your background why would you not have gone to one of the like just purely ZK Focus teams what what led you to nethermine for another mind has this great internship program and I thought I'll join the internship program it's

three months and see what happens at the industry maybe I don't like it I prefer to write papers but I tried and it turns out it was super fun and I decided to stay I also wonder do you feel like because of I mean you already mentioned three ecosystems you already work with gnosis ethereum Stark net I'm sure there's others when you're working in an org like that does it mean you can kind of do you can do like ZK work for a much more broad project base where you're not necessarily tied to certain kind of decisions whereas like had you been part of a ZK focused company you would be following the decisions made by that

company yes I feel that never mind having this client-based approach allow allows to work on all sorts of of projects and not take a aside on some particular technique because sometimes the a technique can become a brand so on the other mind we can be very partial with this and analyze whatever we we believe is is interesting to us and we we don't need to commit to it for five years for example yeah so what when did you join Albert May 2022 okay so you guys have been there for like a year and a half ish or like a year a year and a half cool hey we are working with uh with starkware so there's so many

interesting cryptography research problems there nice somewhat like what kind of company It Is What attracted you to it um you started to mention the different groups and teams I actually was hoping we could do a bit of a broader look at like what is the nethermind world what are all the types of projects and teams and ecosystems that you've been collaborating with or working with and I think we've already mentioned ethereum and gnosis you mentioned starkware Stark net as well what else eigen layer eigenlayer okay yep so that's a new one these like is this research Partners or is this

development Partnerships it depends uh with with eigenlayer and with Stark net is is buff okay research plus uh Blood Plus Development building tools with noses it's more it's more development uh with uh with ethereum yeah we got some research grants from from ethereum Foundation as well we also in the work with with Alex zero uh that's uh on the research side uh we are building a private decks with them we we are also working with with concrete protocols uh within the ethereum ecosystems like like Lido like

like oval cool all right so that's a little bit of a map let's now talk a little bit more about your particular research group and the themes that you're excited about or interested in today I think that there is too many topics that that excites us let's dig down then let's narrow it down to things that are related to the work you do around Starks so tell us a little bit about the latest research or work in that category to start in Stark related research we we work on security of fry based Starks or or snarks we we worked on the security laws that comes from from your

transformation we worked on run by round soundness we worked on non-mallability of snarks we worked on efficient proof aggregation of of starks which can be used for a single slot finality in ethereum yeah and you you're putting all of these still under the Stark category but some of them are snarks and Starks it seems like they're kind of they're potentially also used for for both for snarks and Starks because it's like a very uh very general technique yeah yeah okay okay so let's start with the security for fry based protocols tell us more about what you're doing

there and what are you trying to prove let me start by by saying that in when we have when we build a snark we usually need some sort of of polynomial commitment like and to most uh often use polynomial commitments are kcg and and Fry and the thing is that fry usually is not really a polynomial commitment um so what you mean there is you're sort of you have to twist it into that format right yes the the thing is that right can actually be used as a polynomial commitment scheme um a PCS if you configure it in a way that makes it varies though like very

inefficient so if you configure it in a way that you are inside the so-called unique decoding radios then it WCS but otherwise it's not and the issue is mainly that price a protocol that is supposed to allow you to prove that a map is a low degree polynomial that's the the idea involved but it doesn't really work like that it allows to prove that a map is close to a low degree polynomial so that it coincides with a low degree polynomial and a big set so the issue is that if you want to use fry in inefficient ways you can only prove that a map is close to some local polynomial so so you prove that the map

is close to a low degree polynomial and moreover there are several low degree polynomials that are close to the map and for technical reasons this makes it um not a polynomial commitment scheme so if you have a so-called piop polynomial interactive Oracle proof you can't just put fry in there and and compile it into a succinct argument because of that and that that's one of the the issues we we tackled in in this work what do you have to do then to make it work you said you're saying you can't just plug it in as is you have to do something yeah so what we did was we described a certain class of iops or piops so so for

this white class this white class includes protocols like Starks and bronchito in this case if you use fry instead of a polynomial communion scheme using frying preserves the security of the piop or IOP okay so with the price we paid is we had to take a specific form of IOP and for this specific form it turns out that you can compile it with frying but in general it's unclear that you can take any IOP and compile it with fry um and you're talking about the security of these so like what you're describing right now is just sort of like how it

works but was it not secure before and you had to prove that it was Secure yeah what's the security side of this is it the proof security means usually that you you have some assumption that is widely believed to be secure and you show that if your adversary if like some bad guy that tries to break your your Zillow noise proof system that tries to break fry by for example providing a polynomial of of a high degree the probability that the adversary breaks the system is bounded by the probability of adversary breaking the the security assumption okay so if the

adversary breaks your system then you can use that that adversary to break some well-known security assumption what was there before like you also sort of mentioned that it affects Starks and plancky too so I'm guessing this work came after the release of both of those yeah I'm just trying to I mean it's it sounds like what the work was was just to like add an extra layer of security and sense basically showing formally why why it is secure whereas it was sort of assumed to be secure but um I'm still trying to exactly understand what the Assumption was before how that was created without having proven it yeah so it was widely believed to be secure and as you say our work is not a surprise

because yeah yeah everybody was operating under the assumption that the security is is what it is for the case of install or of the star protocol the the issue with fry not being a PCS that was already dealt with so that is not that's not something that applies to like like what I just described I were these considerations about fry not being a PCS doesn't apply to Stark because in the start documentation they already dealt with this difficulty okay and in fact our our techniques built up on on some of the work of Ben Sasson and his collaborators and also already carbox when it comes to analyzing fry as a from

polygon yeah he has a very nice summary of a frame the thing that was not true or the star protocol was that it is secure after the future new transform that was a it was believed to be secure but it was not proved for money when it comes to plan Q2 for example it was not formally proved that price could be used as a PCS You could argue that red chief is an academic work that analyzes how to use Prius PCS in a piop yeah however the the security bound provided by the redshift on plancky 2 is wouldn't be usable because the security bound of redshift is exponential on the width of the execution trains and

implant you to the execution Trace is very wide okay so let me see if I can sort of paraphrase here so reg redshift was the first work that plancky II had taken like it was sort of using some of the ideas that redshift had proposed but redshift had only created its security bound of a certain size I guess like it was once you created plancky II you you had a wider I don't know if that's the correct term but like you had a different security bound that you then needed to prove what they did unlike Starks which is like Stark's built around fry from the ground up like the whole thing has you know Starks in or fry in mind whereas plonky 2 is taking snarks and adding fry using using fry as

the polynomial commitment scheme which you're saying you know at times can be a little wonky and so what you were doing here was trying to say actually even though it's using redshift and it's using fry the way it's been constructed remains secure because of XYZ yeah that's mostly correct I I say that plankito uses redshift I think it uses a diff it has a subtle difference between from from redshift it's not exactly red shield okay it's more I would say it's more similar to the start protocol than to what great Chief describes and because of that it is secure actually okay because of reasons similar to why start is secure when it comes to the Fri of using fry as a PCS I see yeah and the

only part you're approving here is fry you were not talking about any other parts of the system just the fact that they're using fry as a PCS in their system or yeah was this also an audit of plonky too it wasn't a naughty um per se but we did prove its security and I think it was a gap before it was not known okay cool why would you work on that exactly like I guess I'm trying to understand the motivation for this work in a way does this come through client work where folks are like we'd like to prove this or is this like curiosity is this the open source ethos I'm just curious yeah what what prompted it I would say it's curiosity really it's like you you see that they are like missing parts in in

the security analysis and and to wonder whether is this thing really secure or or not like yeah what are the assumptions that are used here what is the the level of security what what is the security laws uh that comes if I apply Fiat Samir transformation uh what happens when we apply for me transformation to to parallel parallel repetition of of protocol so these were the questions we uh we tried to to answer and like for example for uh Fiat Samir security law so we we found answers in in some paper but I I think like in general the

security laws that that comes with fiatramil transformation is not very well known to the community so I also like uh think that yeah let's make people aware that actually when they design a protocol and they show Security in an interactive model before well the the protocol is compiled to non-interactive using virtual meal transformation they actually should have some security margin because fetchumi transformation it's like a quite quite a considerable chunk of wow of their security huh is this sort of a bit of a warning that

you're saying or like uh highlighting that even though Fiat Shamir can be secure and even though the system underlying can be secure if you're combining the two of them there could be some security vulnerability added exactly like uh we just need to be aware that fetch Samir transformation is not perfect in the sense that the security of interactive protocol does not usually translates one to one to the security of Fiat Shamir non-interactive protocol that there is some some laws that can can be quite substantial are there certain systems that in that work that you did because you also

analyzed security loss of the future transformation in that work did you find some systems suffered more than others and like what were their properties we found a very nice paper by atema effer and Claus that analyzed security laws of oft Samir transformation applied to to parallel repetition of protocols so I would say that if we have protocols that are run in parallel then this get some neural transformation caused like a bigger security loss so maybe I I can explain why we want sometimes to run protocols in parallel so these things from for example using small Fields

sometimes they're like different ways of of using small small fields in in Starks or or snarks sometimes we can design a snark or Stark that does not provide the required level of security but some smaller level and by parallel composition of this snark we can get the security boost so the security is is actually better when we run the snark in parallel so so the idea is that instead of having proverb running a single execution of the of a snark we ask the prover to to run like free instances in in parallel where challenges are take into consideration

that that the whole transcript of all the threads all executions but this improves the security of the system pre fiatrimir transformation right you're talking about without the transformation it improved the security what's an example of this is like Nova an example of this or Halo to an example or Halo 1 maybe it can be one of the examples however they they do also some some tricks that uh that additionally boosts uh boosts security I can imagine uh folding scheme being like composed in parallel if we use some very small field uh and like very small

groups but usually we see we observe parallel compositions in protocols that utilize fry not not the billionaire pairings um and I think this is mostly because in in Fry we have uh we fry or with uh things like uh Halo uh where we use inner product argument our design space is much wider so we can we have like much more freedom of saying okay I want to work over this uh this group uh I want to work over this field while usually in billionaire curve based proof systems

there's like a number of of proofs that we pick from so so the design space is is actually much more limited and usually when you work over these uh these curves you are say secure Say by default because these curves have like a lot of margin okay for security but I want to go back to what you're saying so you have these parallel composed protocols which you add the parallels to improve security but then doing the Fiat Shamir transformation can reduce the security does it reduce it like what was the analysis was what did you what did you learn so say say that you have an adversary that breaks your protocol with

probability P okay and by breaking protocol could mean either that the adversary can convince the verifier of a false statement or maybe the the adversary can convince uh the verifier over a statement that the adversary doesn't know a witness for we have this probability P when we do parallel composition of interactive protocols the the security of such such composed protocol is boosted to P to T where T is the the number of parallel repetitions right so it's in Sp smaller than than one p2t is is much smaller than than P so what uh

automatel found out is that where you apply virtually transformation for such such protocols for some class of such protocols the security is not actually P to T but is [Music] there is like a big a big security loss that comes from the fact that well the adversary can can start the protocol and try multiple challenges by re-randomizing some parts of protocol I don't know if I can follow the nitty-gritty of the reasons but I guess the takeaway is yes there is some

security loss potentially can I give a rule of thumb of what's the security loss of the Chamber of a repetitive repetition protocol so suppose the protocol has new rounds and you repeat it three times you need mu times more repetitions to achieve the same level of security as compared to the non-fiction year case so if there's three rounds and you repeat it three times in the interactive part the security speed to the tree okay if you then apply this hme transform the security is p it doesn't it doesn't increase has it taken away any of the benefits of that parallel composition in

a way roughly speaking it it yeah it's like if you're given the repetition at all it's it's more costly to attack but okay asymptotically speaking it's I say because if you didn't do any repetition if you want to actually achieve PQ security you have to repeat it nine times if you are going to apply the virtually transform if there's three rounds ah okay so this is sort of the you've you've found some sort of lower threshold where if you go over that in terms of the parallel composition and the number of rounds that you run it then you actually do see some benefit even through a Fiat schmere but then then it's like the Fiat Shamir just removes any benefits that you've come to

achieve through this parallel composition yeah okay but this is our rule of thumb for some particular protocols maybe what I just said it's not exactly true but internal for most parameter configurations that that's what we found interesting the reason I find this cool is to also understand the type of work you're doing you're kind of like looking for I guess optimal applications of certain techniques the number of times which ones go together best you know it's like you're you're sort of you have a lot of different tools but if you use the wrong tools together you're going to negate each other's benefits you have to sort of like think a little bit deeper about how

you're combining them yeah let's go to another uh problem or like area of research that you've been working on you sort of mentioned also like the malleability of proof systems tell us a little bit about that and the kind of what kind of research are you doing around that we usually want to have our snacks to be non-malliable uh that means if someone sees uh a proof for a given statement then this person shouldn't be able to to coin for example a new randomized proof for for that statement or even like to to build a a new proof for some related statement and

this is important in in applications where we use snarks to to show knowledge about something so one of the examples could be could be for example a tornado cash so in tornado cash when you want to withdraw your money you you need to show that you know some particular secret you know nullifier and and some secretly related to to a coin you have in the in the pool um so if if snark that you you are using to do so that if the snark was uh malleable then someone who eavesdrops uh over the

network can can take your proof and change it in such a way that actually the proof would send money to to his account instead of of yours account it's the malleability of the proof but is it the malleability of like the note the actual digital item that you're using as a proof would be altered or is it the proof itself is altered that's very good question so you may want to alter either the the proof itself or the instance and the proof so instance is is what you are proving using the proof so for example

in the totor nado example in your instance is your so you the nullifier of of your note so so this value that make sure that nobody can double spend uh cash in tornado cash it's a public information regarding the the tree where the the notes are stored and it's a value which is uh ethereum address where the funds should should go so you build a zero knowledge proof for that showing that you know a secret corresponding to a node with particular nullifier being in in particular tree uh

and and the transaction should be processed to to the address that is stated in the in the instance as well so if you could Mall the the this this instance and proof pair for example you could change the address where the funds should be sent to to some other address so the attack would be that you eavesdrops communication in the network you see that someone tries to withdraw their funds you pick the accompanying proof and you modify the instance and you modify the proof such that the money

goes to to your account instead of of the account of the person that wanted to withdraw so fortunately in tornado cache uh it was used graph 16 proof system which is to some extent malleable so for example you can generate a different proof or for the say statement you can re-randomize the proof like add some Randomness but you cannot change the instance so so fortunately in the the tornado cache example like no one could steal your your funds but it was not shown that this proof system graph 16 is actually not malleable but what was the work then

that you were doing were you showing that it is non-maleable or that certain systems are non-maleable I I was working on different proof systems I I was working on on the Planck marlin so let's say like the the next generation of of proof system and yeah we were showing that that they are non-malliable non-allible in a very strong sense that you cannot even re-randomize the proof well what gives a good good security guarantees especially when you use your your zero knowledge proof to to show knowledge and maybe this like maybe you have a system where showing knowledge about some secret gives you access to to

some data right so so in that case if the proof system is malleable for example like if you use grot16 and you you want to to get access to to the data is some some adversary can can take proof generated by by Honest user and just like uh change a few few bits add some some random elements and also get access to to the data protected by this bye by disproof System other than like fry security and all these Stark security Fiat Shamir non-malliability we we also work on say a bit more

constructive things like not only analyzing security of existing schemes and one of such projects is uh is a joint proof aggregation for for Starks yeah we are working on this with um a couple people from Yerevan State University I apologize for coming back to their names I had to practice more sorry and the the idea is is the following so recently there's this folding and schemes that came out and there's a fry based protocols have a incompatible with these folding schemes because all these

folding schemes use an additively homomorphic Vector commitment scheme or polynomial commitment scheme yeah which is isn't this like this is specific to kzg this is like a property that kcg offers but that fry doesn't correct yeah it's not specific of kcg but it's something that Pride doesn't have okay because fry uses Merkel trees for the Electoral commitments and those are definitely not thermomorphic so you cannot just use them these folding schemes on Friday protocols but however there are some we are working on some aggregation methods for for fry based protocols the key observation here is that the fried part of the protocol is very aggregatable

and this is thanks to the so-called batch fry which is an amazing protocol that allows you to take two functions take a random linear combination of them and then if you apply Fry on the random linear combination and you pass you can be certain that the verifier can be certain until negligible probability that the two original functions are close to a polynomial what was the name of that was it batch fry batch like batching yes okay yeah basically you take you want to prove that a collection of maps is close to a polynomial or is a polynomial as I said we would like that pry proofs that things are polynomials but it only proves that they are closed so what you do is you take a

random linear combination of these maps and apply Fry on the on the result this is reminiscent of of folding a folding scheme because you have several statements and you produce a new statement and if you verify the new statement all the premium statements are true why did you call it batching fry not folding fry well we didn't call this this is an a stand where Star Wars were okay well someone should make the folding fry then it sounds good and it came out when folding was not trendy so named okay there was actually a folding slash accumulation wording battle it meant the

same thing and I think folding is sort of like the the people who created the accumulation line of work I think have accepted that folding's a little catchier so they've gone with it all right technically speaking the butterfly cannot be considered folding if we get into technical talking but it is reminiscent okay okay it has Echoes of it yes so that's one one observation for aggregating a Firebase protocols but fry is a sub protocol of these big protocol like style Pro the star protocol uses fry as a sub protocol there's a check that checks that the state transition is correct and then there's batch fry this is

basically the star protocol so if you want to create two proofs you can create two proofs that the two straight transitions are correct and then fall or badge the fry part and so with this scheme you can basically just fold all the fry text of several star proofs into a single one yeah so so all these snarks and Stark have one thing in common really that the relations uh for them are defined over fields and that actually allows you to do very sophisticated mathematical

machinery and you have like your um your tool stack is like really enormous for working on on fields however we don't need to limit ourselves only to to Fields uh sometimes we we don't want to represent our computational field elements because for example in CPUs it's quite natural to represent computation modular like 2 to the 64 for example and operations modulo 2 to the 64. they don't make make a field they're actually operations over rings so another top topic that we are investigating are snarks where where we

are not limited uh to to relations over fields but uh snarks for relations that are defined over Wings when you say Rings though what do you mean bring signatures what is Rings is this like the thing that Monero was built with or what yeah so so no no ring signatures it's an algebraic structure it's like a field but not all elements have inverse multiplicative inverse a field is a ring where all elements have multiplicative inverses okay but the typical ring example is the integers there's no multiplicative inverses in in the integers except for one okay minus one because the multiplicative inverse of

two for example is one valve but one half is not an integer you're saying snarks over Rings though are you then like what is integers the thing you're going over then or what what other category of of rings are you using the main drink we are interested in is that modulo to 2064. so basically it's like field and its method but instead of using a prime or the modulo we want to use 2 to the 64 for the module and the issue here is that not everything has inverses pretty in the weeds for me I don't know if I'm fully following but yeah the the main blocking points if you want to modulo something that's not a

prime is that you don't have this participle which means that polynomials can have a huge amount of roots instead of the number of roads being bounded by the degree and you also don't have univariate polynomial interpolation um with this I mean I sort of understand that you've like you basically said I'm going to build a snark over just a different category of numbers and like how what numbers you're allowed to work with but like are you yourselves then just experimenting by building a snark over that and seeing what properties it has are you trying to make a more efficient snark like what's the point of doing that yeah that is reasonably efficient and gets around this limitations I just mentioned

which limitations in an Ideal World we would be able to build a snark that works modular tutorial 64 for example and it's as fast as the fastest Narco start you can think of no if this happens it means that we can prove computations modulo 2 to the 64. without paying any overhead okay that currently you pay by transforming the program that works modular 2064 to work module of B the idea for building snark or Stark or over Rings is to to have more efficient arithmetics model uh 2 to the 64. so so for example like uh that's

how like CPUs perform the operations usually and and currently we can do uh operations modulo 264 in snarks and Starks over uh over fields but with every operation we we really need to check whether we uh we got like Beyond two two to the 64. so every time we perform some pressure we need to check whether we need to uh to reduce modulo to the 64 or or not and other application quite quite naturally is also also showing statements about fully homorphic encryption for example because early homomorphic encryption schemes

give Cipher texts which are ring elements okay right so you don't need to translate these ring elements into field and then making operations over it like proving statements like with these translated elements but you can work you you could work like natively wow on the on the elements uh on the cipher text of from some fully homorphic encryption schemes interesting where does this project come from on your side like is this also a curiosity project is it sort of like wow if we could do this we could do more stuff with fhe what's the motivation

I would say motivation is uh showing statements about uh fully homomorphic encryption efficiently so say you have some blockchain that where you perform your operations in an encrypted way and you use fully homorphic encryption to do to do that so by using the scheme that proves the correctness of computation of some operations over ciphertext you don't need to perform operations over ciphertext in in a blockchain because these operations for fully homorphic encryption schemes can be very computationally heavy like especially when you do something called

bootstrapping but you can offload these computations and make a zero knowledge proof for for the computation and verify if I disproof on chain right let me also mentioned another application which is for floating point arithmetic floating pointer rhythmatic it's it's much cheaper to to model over a ring so an area that relies on floating Point arithmetic is a is it KML for example so if okay if you want to put off statements um about a model that uses floating points and and you have as a fast snark that works over one of these rings and it's much better because you don't have to

translate the floating points into like the following Point operations into operations over the theme interesting so I feel like everything boils down to a point that we actually do a lot of computations over Rings sometimes we don't do computations over fields so it would be only beneficial to have a proof system that natively works for for rings and don't need to have all the ring elements translated to to field elements cool we are close to time but I feel like there's so much research to mention shares share a few more highlights maybe for us before we sign off in the research team we don't always work with

zero knowledge we also work with with protocols so we work for example with Lido with with o ball with Lido we we are working on making Lido more permissionless I would say so so currently uh when you want to be an operator in in lidoor you need to be approved by the Light the dial and like the ones to make this process more permissionless where everybody can join as an operator and this actually Rises a lot of security questions and questions about like how to maintain the good quality set of of like the operators so

in in that project we were working on white labeling protection for for Lido so so for Lido it is essential so that light operators run their validators on their own and don't use some third-party services because such Services could be malicious against the protocol for example could could steal Mev or or could introduce a single point of failure so we were working on providing measures how to detect operators who who use white label operators with with apple we are working on Obel V2 so in the current protocol

all ball allows you to create a cluster for a distributed validator with nodes you you trust so if some of the members of the cluster some operators in the cluster is down you can basically only politely ask the operator to pick up his job and in other V2 actions of the cluster will be accountable so the operators who perform correctly won't need for example to share their reward with an operator that is performing subpar hmm right now we are collaborating with the starnet

foundation on some open problems around the incentivization of of the protocol and also cryptographic problems and the cryptographic problems involve for example analyzing some conjecture level of security of of the star protocol and analyzing how collisions in the hash function that is used whether finding collisions is actually dangerous or not how dangerous it is if you manage to find a collision and also it's slightly related to our talk about Rings designing a protocol that can work over different types of fields okay because sometimes you want to combine statements about computations that happen on different fields cool so

I feel like we're going to wrap up here but I can tell from talking about the year that there's so many more bits of research that you're kind of like starting to work on maybe want to mention it does seem like the work of nethermind is just really quite Broad and I think it's pretty cool to see how much the org has evolved and the fact that you're so focused on the ZK community and the ZK topics I think it's a great kind of addition to our ecosystem so yeah thanks for for being on thank you it was great fun to be here yeah it was a pleasure thanks I want to say thank you to the podcast team Rachel Henrik and Tanya and to our listeners thanks for listening foreign