ZKPodcast: zkSNARKs for Scale with Matter Labs

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] in this episode we'll sit down with Alex and Alex from matter labs to discuss how they plan to use ZK snarks to scale up the transaction processing capacity of ethereum before we start we just want to speak to you our listeners for a quick

moment as you may know we rely on our supporters subscribers and sponsors to make this show possible if you are thinking hey I like this show and I wouldn't mind supporting it and there are a bunch of ways that you can do this you can share a monthly amount and die through our get coin grant or join us on patreon if you'd rather do this in Fiat you can also support us directly through our Bitcoin and aetherium addresses as well as our new Z cash address thank you to the listener who pointed out that Z cash might be an interesting option for our audience we want to say a big thank you to the folks who have supported us on patreon and get coins so far we really appreciate the support and you really do help to make this podcast possible if you want to support the show

we have all of our links in the description for how to do that or if your project please get in touch with us about sponsorships so now here's our interview with mater [Music] so today we're sitting with the guys from mater labs hi guys Ayanna and Frederick hello hello today we get a chance to explore a little bit what mater labs are working on this will be a zero-knowledge episode which is kind of exciting kind of one of the first times where we talk about how zero knowledge could actually be used for something other than privacy instead we're gonna be talking about how it could be used for for scaling so what if we start off with a quick intro do you guys want to

just tell us who you are and what you're working on yeah so we're from Manor labs my name is Alex my co-founder alex is also Alex just for the sake of clarity it's the difference in full first names another Alex is Alexi and Alexander but of course no one uses a full name even while it's a distinguisher I'm Alexander you're Alexander I'm Alex okay got it at matter laps we're using zero knowledge proves to scale blockchains we met at Def Con last year and we came from different backgrounds to simultaneously to the same idea that your knowledge probe specifically snarks and Starks the sixth synth is your

knowledge proof techniques can be used for scaling and we decided to use it for scaling theorem in the first place because the theorem is very well suited for this kind of technology where what were you working on before my background is in software engineering I studied in Kiev in Berlin and I was in Berlin in a couple of startups as a CTO building teams worked mostly in the old new economy on the online things like trade show management and camper sharing platform I was co-founder of Paul Kemper which is a largest European startup for cover sharing oh cool how about you what is your background

okay as you remember from ZK summit in the matter of fact I'm Russian nuclear physicist my masters in perigee physics and my PhD is in electrical engineering and now I'm work blockchains as a practical application so it's just one step at a time from pure science to something practical yeah I was working for in a plasma environment for quite a long so I'm much more familiar with scaling solutions in principle and I mean even before it adds a difficult itself where we met I was a member of the plasma panel discussion like discussing what's happening is there what can be done and improved but then we decided that even while plasmas can give thousands of transactions per

second we can use snarks right now to maybe reach not thousands by hundreds but with another different another completely different user experience and other trade-offs and we find these trade-offs and user experience more importance and reaching the ultimate benchmark of thousands of transactions per second so we decided to go this way so you were in DEFCON you were actually on a panel speaking about plasma yeah when you said you're working in plasma environments what does that mean I mean in the sense that when we taluk introduce plasma in 2007 summer like August I think then I was at the first eth global heckles one in Vitello and their second project was

like a first demo of the plasma which we did over the weekend which which which hackathon it is Waterloo Waterloo oh cool yeah and so from Zanna actually there was a around this time there was also a snarks blog post by with Alex there was the first paper for starix with two gigabytes proofs if I remember correctly so from there somewhere from there everything started for me since then I was working continuously on plasmapheresis minimal viable platform or viable plasma what a plasma cache was a plasma primer it's a cumulative all this fancy stuff was every construction having its own benefits and trade-offs and now we have the construction using

Ziggy's nartz for scaling which has other benefits and trade-offs and for now I work in this one when you guys met like what who is the team that is matter well I mean the matter as itself has a bit longer history than before with me and Alex Matt at the DEF CON but in principle is still very smallest like five engineers so to tip the genius innocence card core engineers who work in GPU perverse you know how gross 16 security proof works sorry if I'm too technical you can just say this okay but yeah this is the hell work it's it's very not narrowly focused very very early in principle every one of us could

do almost everything as a person does it just for example I write code is a code very fast efficient but in a hackathon style maybe not too readable Alex and other Alex always tells me this he works in the production mode so much more slower but well it's more readable still I find my code readable - but yeah we're all different by still very well focused and kind of not replaceable but reshuffle I mean I'm curious to hear light come from the plasma space and then moving into Matt what you guys are doing in matter is plasma still involved in this in some sense or have you know

completely abandoned that and gone you know ZK zernoff boots are the future of the scaling so in fact when we first came up with a first version of the product we called it zero knowledge-based plasma because with what it's gonna be the easiest way for people to comprehend what we're doing it's very very similar to plasma the difference is that this the each new block or in the Asian state transition is secured by your knowledge probes I think one thing I want to do before we jump even deeper into this I don't think we've ever defined plasma on this podcast so can you actually quickly summarize what plasma is plasma is a layer to scaling solution which in principle relies on

layer one for security but it has strictly sub linear communication complexity on the main chain so we submit less data in terms of the amount of transactions or compared to amount of transactions to the main chain then we actually process in the sidechain however if something goes wrong we always have the main chain as a witness of what's the canonical state is by leverage of commitment cryptographic commitment to the Union state and when use when you first develop the ZK for plasma then you were using zero knowledge proof to do that check in point with the main net so we still do the normal checking point we just commit

this new state to the main chain but then we use journalist proofs to secure this in plasma you rely on game theoretical assumptions other people should shoot or you may be will monitor all the blocks and if you find a mistake malicious or or not malicious then you can go on main chain and protest you use the theorem as a quarter final appeal which will govern the conflict now with your knowledge proof you can rely you can provide the proof that certain computations were correct and that let main chain contract verify this so you can use zero knowledge proof uh scaling in two different ways

one way is to have fraud proofs on their knowledge which is which will be like plasma but instead of having a challenge game interactive protocol of having multiple requests and responses just provide one proof which says for this hash the correct state should be this in this or like this transaction is incorrect so this is proof fraud proofs now you can also use your knowledge in a very different way where you provides proofs of validity for every state which you commit on the main chain and this is what we use because this creates an entirely different user experience well I'm glad we actually made that distinction because I think it's

important to understand that you know the general topic that we want to cover today is also like off chain computation and how that would work starting from plasma adding the zero knowledge did you decide to use it in both ways are you only using it in one with the project as it is so we decided to use it strictly as validity proofs although we made some contribution to fraud pros as well for which plasma can benefit from but fraud proofs always have gained theoretical assumptions somebody has to submit fraud proofs in the case of fraud and if they don't do this or if the transaction doesn't get mine then security is compromised with validity proofs it's impossible for

anybody to commit an incorrect State or you can commit but you you can never finalize the incorrect state because the smart contract will only accept a state as final when the proof is there and this leads to very interesting properties you have a very short finality in a range of maybe a few minutes and then your fonts are at security level of almost the layer one security and nobody has to be online you don't have any liveness assumption yes a life this assumption is crucial for any plasma because there is an assumption that someone is watching set of watchtowers at or every user monitors his own assets this is an important part I mean for there at different flavors and plasmon we can

also talk about all of them of you want but yeah some of those can benefit from Zeki snarks to for example compress the history in plasma cash we actually and in Singapore in Singapore where we showed the first kind of very rough hackathon style demo we also like simplified our main snark to allow history compression for plasma care so other project can also benefit from it indirectly not from what we do as a project but from like code we just release and do it for fun so this is curious to me because it's you're not using ZK snarks or sharks or whatever as in like stock where was talking about or

what roll-up is trying to do in the sense of using the exponential speed-up quote-unquote property of a Stark in that like you're trying to say that verifying all of this computation is a lot faster than doing the computation so you have this plasma like off chain thing and then using this stark to validate that the state-transition function function essentially was executed correctly it's not like compressing data yeah unfortunately this is a misunderstanding when Alex mentioned the linear cast we should separate it further there is a state transition which is just transition from

one state route to another state route which is a result of applying the thousands of transactions for example but it's verified only as one snark proof the same way it's exponential scaling also we have the public data problem and we need to disclose some part of every transaction this is block to resolve some worst case scenarios when the operator doesn't cooperate for example or sensors you completely or something else happens where a data center is completely offline for example there should be a procedure where the operator doesn't cooperate for this we need to post a small amount of every transaction in the block to the main chain and this is a linear part if we eliminate this or just forget about

this for a second this is the same exponential scaling is it I mean there is no principal difference between what we do in tyrol up we just specialized it for set of features but use the same idea of providing the validity proof for every state transition for every new Block in the network this is a part no one likes to speak about because the data availability problem is hard and it's expensive to resolve so I start where doesn't talk about it they talk about this as the proof and how much approval cost but never about the public data which they have to post for the same purpose if they want you have a possible resolution for worst case scenarios we have a sub linear

computational complexity on the main chain and strictly linear communication complexity for data availability you're just comparing this to Stark where is that the difference is that you're trying to make or no I'm just saying no no I mean the principal snarking starts the difference is that your proof size your verification cast is sublinear compared to the amount of computations which you prove it's both it's valid for both our sensors also people usually compares a kind of size of the proves the costume makes a proof for just custom verifies the proof in chain but and this is where a star choir says we have the six million guests to verify a

proof for is this amount of transaction we don't say this this way because we calculate both contributions verification for this set of let's say thousand transactions plus the amount of data which we have to send for the same thousand transactions so we've put more or less usually say as a final number which will be still required to spend let's dig into the data availability problem a little bit because I don't think everyone is aware of one what what why it needs to be available but also necessarily what that data is or like what you would use it for so imagine we have a new state we have a block in the side chain which applies thousands actions and produces in your state and

this state we compute the Merkel route of the state we committed on the main chain and now in case of plasma or in case of zero knowledge based solution if nobody knows if the operator doesn't disclose the exact details of those transactions to anybody else then the route might might still be correct it reflects the correct state transition but nobody knows the Merkel paths and they cannot expand the data nobody can prove that they own some money at some point of time because the state is just not available so in this case the chain essentially halts and people need to in case of plasma they need to exit immediately all of them because they

will not be able to do patoot to continue operation or even to withdraw the money and this is a big problem with any layer to scaling solution now with zero knowledge base scaling we can at least guarantee that the new state is correct but still if nobody knows the data they won't be able although they the state is therein is correct they won't be able to prove that they own some money in in the correct state so but with your knowledge we can prove it we can solve with this in a very elegant way we post all the Royal transaction data not the signatures but just the Delta of the state change only the very minimum information which is necessary

to reconstruct the new state from the previous one we post it on chain then we compute a hash of the this public data and then we use this hash key as a public input to this snark proof to make sure that the snark not only guarantees the correct transition but it only also guarantees that the data which is being used for the state transition was made publicly available in our case for broadcast on a theorem main main chain now we assume that this data is publicly available because every minor in a theorem needs to use it to generate the blocks and full full archive notes hold all this data but it's much much cheaper than

using the storage because we never need to use any of this data for smart contracts we just compute the hash ones and then we essentially forget it so comparing this to just plain aetherium you know in aetherium and a transaction is submitted it's executed on chain through the EVM and everything else and that's quite a lot of work and then out pops the new state that says you have this balance etc so what you want to do then in your model is you move the execution of that transaction off chain and so but you still want to be able to reconstruct that state in some way and there that's why you need to have the transaction

available if the transaction was submitted off Shane executed off chain but proven correctly executed I mean yeah that proof that it's correctly executed it doesn't really mean that much like what is the result of the computation that's what I want to know and so with your scheme you're committing the transaction on chain so that if someone doesn't share what the results of the execution is you can go back and we execute it yourself and make sure and like you can recompute the state from that you cannot exactly we execute it because we don't post the signatures we don't need to post signatures just for reasons that we prove that a state transition is valid so there was a valid signature which we

know and it was used for the state transition but we pass him like let's say is our simple state is just two balances now zero and one so we give the recent transaction from zero to one and we know what is the previous balance from zero in previous balance of one what's necessary just amount which was transacted so you can reconstruct a same logic applies if you start from empty balances completely and fill them out somehow and then for every transaction back and forth you can reconstruct what we define what would be the final balance if you just go along all the public data which was available and then you can just continue this procedure but by just expanding the number of

participants so you cannot really block you cannot construct a new valid proof that the book is correct but you can prove to the smart contract on the main chain that you own some balance at some point and then you can use just rely on the main chain EVM to be able to throw this to your account I'm still trying to figure out like where is the saving here because if you are what you just described if you make any transaction you're still writing something to the main chain we don't write it we just post it as a part of transaction data there is a difference in pricing for the data which you just submit as a part of the transaction is a data which you store so in principle for this state transition what we do is we

write once we write one storage slot which is a new route if we just go to the bare medium without so details of the contract everything else can be downloaded as a part of transaction data from archive node and if something happens you start with an empty tree you follow every transaction which happens as a deposit to this contract anyone else you follow every times action which was happened as a transfer or exit or partial X it doesn't matter at the end of the day you get with a set of balances for every participant of the network at the final state so the chain will stall gives every snow corporation at some point it will be what's called the final state and if you just go along the history from the beginning of time you will get the content of the state

just from the data which was publicly available through the serum and throws archive notes and then you can just do a simple merkel proof that this was my state at this moment of time and just this data ensures that you know all the states so you can reconstruct the market proof I mean to reconstruct the miracle proof you need all the state and that's it part of the deal that's where I have the question like you're saying that you can't Reax acute the transactions but if you don't post the result of the transaction as well then you have to re execute it to get the final state right so be able to say this is my balance at the end you don't execute it because you don't see the signature I mean in our terms executing the transactions that

you extract also verifies the signature but also you sure if occasionally further done for you already because you're not executing it on chain but you're executing it somewhere you executed locally just one entity in the world cannot execute it for everyone else this pretty much simpler then actually they're doing all the bookkeeping and making the proofs because this is just one database of very small amount of rows which you can just add and subtract which is kind of trivial but that's what I mean I like your still react securing it not on chain but your Silvia like that's why you want to make that data available that's why the date availability thing matters because if you don't have the data then you can't we executed I mean an instrument to your point you're not

react securing it in the like if you're my VM model button within your normal off chain model but you only will need to do this in the very unlikely event of complete operator yeah but that's why I need the data availability as well in that case exactly yes I mean we need it only for this purpose for everything else it's you could just not post it ever and if you assume that your operator will live forever and survive the nuclear winter as a cerium two-pointer once then fine you can just saying that operator will give the content of your account at any moment of time if you don't assume this and we don't assume this then you need this

worst case resolution procedure and the wind for the chain is like we haven't I think it's a one on one episode from a while ago that talks about the difference between history and States and sort of the the different storage models there and many of the problems that we're having in aetherium like why it doesn't quote unquote scale like why why it's so hard to sync etcetera is because there are so many nodes in the Merkel tree of the of the theorem states and this doesn't bloat the states it just floats history which is fine we don't care about history necessarily well I wouldn't say no one cares about history people do care about history

several proposals how would you kind of at some point clean up and forget the history but since there is no proper way how you can sync with a network it's a problem which should be resolved with earlier one and we work with conservative assumptions that it will not be worse than it is now and that's it right now all full node store all history and there is discussion around how we like to say how we can get rid of history and not require all full notice or all history but then it's still within the model like it's incentivized somehow to keep the history around so I buy people don't care I mean like normal users don't care or have to look at

history like when you sink in aetherium node you don't look at history there is no syncing scheme that that actually record we execute solve history anymore so he's discoverable if you wanted to find yeah exactly so I feel like in previous episodes we've talked about a little bit about just off chain computation and we hinted at different ways of sort of coming back to the main chain do you see this as like what's a comparable project to what you guys are doing well for me the inspiration of this approach was the coda protocol the 16 block chain where they tried to compress the entire block chain into one start proof which I thought we can apply for plasma because having an isolated block chain is a

little difficult because the code that also faces the data availability issue and they need to solve it still with with the same consensus algorithms which other block chains struggle with and it's better to rely on something existing and proven than try to reinvent everything from scratch and also it's the new philosophy of the theorem to have the layer one as the data availability and consensus layer and have all the computations on top of it and layer two anymore it's like what you guys are working on recursive ah no we decided in favor of a different approach on the one hand due to limitations in current etherion protocol because we only have efficient

precompiled for a very specific elliptic curve from the end to 5/6 so we cannot use recursion yet on the other hand because it allows us to scale with a lot more power parallelism so what we do instead of relying on the previous proof we compute all proofs for all blocks in parallel so we can we can make a commitment for the first block start producing the proof it takes on it takes a while meanwhile we can make the second block and we start producing the proof for the second block and so on and so on and then finally the first blog gets proven and then we submit the second transaction on aetherium and finalize this state so this allows us practically arbitrary scale parallelism we can just use as many as much harder as we need so

this is the difference to code up specifically because they have to wait for the previous proof to be ready in order to start generation of the next proof I'm very curious to hear more about what kind of transactions do you support is it completely generic evm transactions only balance transfers or is it even outside of EVM like generic x86 programs this is great question we want to start with very simple functionality which is going to be as universal as possible for the first version so we're only gonna support simple transfers of your seat when you talk it's atomic swaps of ear see 20 tokens is mutual transfers and also

state channel updates because we we can provide all the UX benefits also for state channels with all these stations frameworks being able to build on top of of this layer is your knowledge layer in the future versions as soon as recursion becomes available to us on aetherium we will be able to write arbitrary smart contracts on your knowledge in in snarks they're not gonna be tearing complete they're gonna be bounded in computation and they're gonna be somewhat expensive to compute it will take some seconds maybe minutes on local laptops or cell phones but we will be able to support very complex operations for example we

will be able to breed a cryptic ad and only spend gas on the [Music] state update like just one 1k guess instead of currently it costs I guess two hundred thousand yes in the example so like I think it's almost a year ago we had Eric Tang from live pure come on and they were doing like video compression off chain could this ever be used for something like that or is this an into totally different ballpark I think that I mean this part because we work must epicenter even while we see that at some point was especially with recursion we can support much wider

functionality and this functionality is still to be defined completely so of course there are obvious technological limitations of your contracts or any execution like any progress which right will not be true incomplete they will have also limitation for any snark based programs but still for now we cannot even make a very well educated guess about what will be possible or even while while we understand what's going to be possible we don't know if people and how people will use it as a problem there is no killer a feature for Assyrians there's no no killer feature for blockchains in principle there is no killer feature for snacks I think yet at if at some point someone makes it we would want to support it yeah I think with video compression and stuff like

that I mean ultimately whatever you compute off Shane needs to be provable in a small historic and so you'd need to write a video compression snark which it seems pretty impossible right now but who knows in the future like as snark programming languages get better and we get better abstractions in place and they become more performance they think video compression is like the worst case thing that you could possibly do but there's there's definitely like if we can get to a generalized EVM more like a what the assembly thing then you know we can get pretty far with that and it's also contingent on hardware if we have specific hardware for snark or zero

knowledge proof generation in general then it's gonna be much more efficient that's actually really helpful though to just place this like on that sort of timeframe and like like where basically what I was trying to figure out there's like where is it actually at and it sounds like it's very far away at this point from being able to handle something like video compression that's fine it's not a good system it's more like for us to understand like at what level this sort of technology is that well I mean the entry bar for any snark based application is high anyway people usually given examples that you can prove the inference step of the neural network using some geeky snark even

while it's technically possible I even agree that it's possible it's another challenge how we can make the neural network which is efficiently provable in snark so I mean if you try to prove the normal neural network you will end nowhere so we need to change the neural network with the primitives which use these numbers in a neural network itself to be able to efficiently prove it and this is the limitation of scenarios because they work over fields not over normal numbers which were used to work with when we write just normal programs this is obvious technological limitation too if your application allows you to work around this or use field elements instead of numbers for example and you

know how to use and begin several parts which had quite not so obvious then sure you can try to prove your local computation used in Dickies market so I want to ask a question about the roll up project and how this relates to what you guys are doing because did you have you been working like is this a roll up project what is roll up roll up is the name of the concept it's we were struggling to find a better name which is settled on ZK roll up which is currently being used as is common name for this kind of solutions so it's a general umbrella term for sure knowledge-based state transitions with data availability solved on chain I would say this is

definition so I started working on roll up yet before I met Alex I was working with very white hat and the ideas we developed there flew into what we implemented with matters matter was just the we as a research team were the first to actually implement a working version of her robe and who was it initially a berry-like was buried the first person to kick this off his name is often associated with it yes Mary was bears role was to be the pioneer of your knowledge in general he created mixed symbols and created a group I found him online and there were a couple of people having discussions

about that my making specifications making some prototypes and we progressed from there we discussed different directions we had different libraries and frameworks which we could use Berry was working with it was leap snark we decided to experiment with bellmen which is a library written in rust by guys from Z cache by Sean Ball specifically mom for the most part and we thought it might be a better fit because the rust is a really interesting language for writing secure applications and for writing cryptographic protocols and because it has a very nice set of constraints certain things you can you can define things which are not possible or are not allowed to do and then the language itself will take care of these

limitations and it's also more modern more concise the programs are shorter you don't need to write the same code twice because you can reuse generic functionality of Frost and it turned out to be a good choice allow that to make the progress much faster so roll up was this initial idea and there's a group of people online who kind of rallied around it and out of that came the project that you guys do what is the name of the exact project because I know you as matter Labs but what's the project what's the technology so we are working on a network now which we're gonna call frankly it's going to be the platform for generic execution of zero knowledge

on top of layer one so we're we call it layer 2 network but it's maybe it's just an extension of layer 1 we're not sure how to position it so like all projects which are now layer two can just build on top of this we're not going into any specific functional vertical which is going to provide tools for other projects to build on top you can use transfers they can use atomic swaps they can use state channels with all the existing tooling which is currently there just with better user experience and better security and is it always gonna have that zero knowledge component or is it more focused on just general scalability no it's it's escy its scalability based on zero knowledge because your knowledge is the only

technology which allows us to scale with his benefits there is nothing else it was a breakthrough in technology I want to dig more into how this is built and sort of that what the architecture looks like what pieces are off chain and how they communicated and some stuff like that but there was one thing that I wanted to cover first and something that I talked to Barry about and I know there are some issues in just how aetherium works and with roll-up or roll-up architectures in general you get the maximum scalability if you fill up every block with one single transaction that's very very hard to do and it's also like questionable if that's you know if you

have a generic off chain structure that can execute anything then you know you just force people to go to that place to execute it instead of executing an all chain but if you have something like a Dex that focuses entirely on this then you know every block just serves this one Dex and no other application can make it on chain so obviously this is problematic how do you think about this first of all it's about economic efficiency but of course you can just wait longer to fill the blocks then it will increase the delay which is going to introduce inconvenience for users so obviously yes this is the correct correctly identified problem we want to fit as many technology transactions into

one block as possible and this was our motivation for starting frankly we realized that if every project will go with their own solution then they're going to all compete for guest on theorem and they will have to wait very long time to to fill the box and for some projects which are not yet as that massively used is going to be inefficient and our motorisation of the gas cost per transaction is going to be low so that's why we decided let's figure out what are the basic universal blocks which all products can build on top and let's make a very broad broadly accessible network so that all these

projects Dex's defy products which you need to you to use skating the kiddies simply payment solutions which need to transfer tokens can all reuse and the of course there there might be conflict potential between all all these projects because who's gonna control this so we came up with an idea to make a decentralized network now it's important to explain that the decentralization is not strictly needed in our case because zero knowledge proof make sure that the state is always correct you can never commit an incorrect state but we needed for censorship resistance because if we only have one Operator this operator will be

able to censor anybody they want so for censorship resistance we want to decentralize this and we will have a permissionless set of validators anybody can become a validator and they will just produce the box in turn and yeah so the this is what I want to dig into as well I think a comment on the filling up every block and like I said if you make this a generic structure that can execute any type of transaction and it's a proper decentralized network and have censorship resistance etc I think it's fine to fill up every block with one transaction but at that point if it's truly successful and this is how people want to build their applications then

it's questionable if we should keep ethereum as it is or we just ditch the EVM completely and say this is a blockchain for making data available and and validating their knowledge proofs and that's all the purp like that's the only purpose of layer one and we don't have to have this more contract thing going on well you want the smart contract just to be able to support generic proofs maybe in the future we'll come up with better protocols which need to be verified and you also want to use aetherium for other purposes as the court of final appeal because you will still have cases where you need to escalate on the main chain for the sake of flexibility so you want to keep the flexible generic computing

functionality helpful on on layer one just in case just for situations where you need to result something there but mostly yes this is gonna progress towards a vision which you just described do you think that that would mean like okay according to this vision would like the one etherium would be saying theorem 1x theorem that we have today that could become something like this court of final appeal but then I'm curious how do you interact with e 2.0 have you like like what are you are you guys does it matter do you need to care are you looking at this will it change the way that you build things no we can we can build this as well fennili yeah was the Sirian 2.0

it's even well it's we don't need cross shard interaction it's the first if the user deposits part of his funds or uses what we built for his purposes the user actually never touches the sharding structure as a test after he's already in the network so for Charlene the only entity which will care it will be us as the developers but if we operate on some shard yes we take quite a lot of capacity of the shard but for purposes of proof verification and date availability but then we don't need directing the core shard interaction and Lazarus a deposit X is procedure but while this will require pressured

interaction anyway but others in this we can operate in one shard and for in this sense charging is very much beneficial we take much smaller share of the total network capacity just to verify the proofs this was something that Frederic and I were talking about just a little bit before this interview and that was you kind of tipped you touched on interest the idea that when you go off chain you actually are no longer in this decentralized mode you're actually that all of this could be happening in an extremely centralized way and then sort of checks in to the decentralized Court of Appeal or the you know data star mover validate or somehow I know that's the wrong word here could get confusing from people but anyway um but then you sort of mentioned that the way that you

want to decentralize it is to create sort of a decentralized network in itself how do you do that before I explain how we do that I want to add one more motivation for doing this in the first place and this is trust set up because for snarks in the current with the current iteration which we use is the protocol is called cross 16 and it requires an application-specific trusted set up this was the biggest problem why snarks have not been broadly used in the past the only application which which takes heavy use of snarks is z cash and z cash had two rounds of trust set up the second round was more efficient with over a hundred participants but most of those people

were either closely affiliated with Z cash or they were just random participants who are not very well publicly known we didn't see any large credible organizations taking part in the trans to set up which of course is giving reason to some people to doubt the credibility of the set up and yet in general so of course if you're building something very so this this problem faces every project faces this problem because if they create trust set up just for them just for their application how are they gonna attract large number of credible participants to to make it publicly compelling so now stock where

it comes and says hey let's let's you starts because we have a transparent arguments of knowledge and then you don't need a trusted setup which sounds like a very good idea unfortunately for blog chains for this out of efficiency reasons because the proofs are two orders of magnitude larger than four snarks with hundreds of kilobytes of code we just cannot use it now the sighs or the gas block limit is the main bottleneck on the public ball chains so the proofs must be short otherwise you can like if you provide if your proof is costing you six million gas then you don't have any space to put data availability on chain and then it

becomes a very tricky solution and you just get you cannot build roll up and start on starts right now for this so that's interesting but how does that so talk about the design if we have a single Network which can be reused by many projects which only supports generic functionality not going into depth of every application but allows any application to build stuff that they need we can have a broad set of projects who are interested in this in using this network who will participate in the trusted set up which will make the trust to set up much more convincing for the public and this is what we're striving to do with Franklin so we're actually in the process of creating what we call a

zero knowledge blockchain Alliance an organization which will include these projects and first can the condition for participation will be taking part in the trust Isetta and it also will balance incentives and it also will provide a broader set of validators which is decentralized which will which will eliminate the risk that one party controls most of the network and they can censor everybody else that's interesting that you consider because the trust it's set up is very sort of broad like it can be very broad in its scope and you can have a lot of different individuals from different walks of life that that would somehow give them any power over the network

post trust it set up because isn't it just that you have all of these people weigh in to create the secret key private key and and then it's used once and then sort of set free like then it then however the thing is managed after that is not related necessarily to the trusted set of group like I don't understand I don't exactly understand how that decentralize is it well what kind of half step back let's say there are 10 projects building their own kind of sikhi based solution for actually for a particular application not for some functionality which can seat a lot of pressure but just for one particular one let's say tax or something like this and

10 such projects each of those will compete for gas price verification public date availability some solutions which I have seen have some enormous requirements for a date availability at unless they Sultan I mean unless they actually do it which will be very expensive they can be actually called centralized networking because it can just not disclose the data if they all do it it's another critic it is and to do it they all need to do so Trust has set up individually each of them each of them separately and EVDO Lee just because the girl 16 works this way so if you somehow manage their interest merge them together or just make something generics which they all can use maybe with some

limitations but still usable it's one verification costs public data availability which with much smaller data which is necessary and one trusted set up which can include participation from all those 10 entities so this is high quality trusted to that because those entities are potentially competitors so they have no incentive to try to come together and try to keep all this large share of entropy well we will persuade ourselves and I mean just destroy our to be anyway but to me the trusted set up and all of that is solving a different problem like that is to make sure that the that the whole

system is secure but that doesn't necessarily decentralize it it's a part of decentralization having more participants than the chance to set up but let's also that deep dive into the technological architecture how we can make a decent lies so to decentralize things we just need to produce do to give the right to produce blocks to different participants in turn I produce the first block then I pass it to you produce the second block then alex produces the third book and so on and it goes in in circle now with with plasma it's very difficult to do because the participants need to share data availability and if

one of them refuses to share data availability we have something called a speaker listener dilemma it's not attributable if I if I say publicly that I told you something and you say publicly and you never receive this message there is no way for anybody to understand what it was right that's why plasma must be centralized with with roll-up specifically because we put all the data provably on the main chain and make it available to everybody else all operators can just take the data from there and continue producing blocks and we can have something very simple some simple rendao some some smart contract which determines randomly sequence of who is producing the next

block and this is all we need in order to decentralize now if some of the validators will censor you somebody else want because they will have incentive of obviously you will have to pay for your transactions some small fee because they've proved generation costs someone has some have some costs so somebody will be happy to include your transaction and this way will guarantee the absence of signlessness do you intend to set up like a separate blockchain for this or like a beacon chain to to be able to do validator selection or do you plan to have that as a smart contract on on main it we will have a smart contract which determines randomly the sequence of ideas and we

will of course have a side chain in this state itself is going to be stored off of the main chain so will produce nodes which people have to run which store the state in some database and they exchange to stay through the first sending it on aetherium now as far as randomness is concerned we are not sensitive to any bias and randomness we don't need very fallible dia functions because all we need to do is sum sum we can we don't even need randomness we can just produce it in the sense you can do a round-robin around the validator so that's assuming it's not too large so I think that brings the question of like how do you add and remove validators from this set and what's the mean the incentives of being a validator is you get fees but how do you get civil

resistance why can't I just sign up with a thousand validators and be the only one ever valid hitting well for this the on blockchains we introduced tokens this is the the simplest and most obvious version how we can make it permissionless how can allow anybody to just join the network without any bias without control of anybody else alright so there there will be a Franklin token yeah they're able something like frankly not forgotten yeah I mean just because Jimmy Dean's approve requires some capital it can be not even direct led to participation but you can just delegate your right to potentially make like this share of blocks in this round to someone who is willing to take this capital casa

front for a purpose of potentially collecting the amount of fees which is profitable for them we don't want to limit any form of such cooperation so we'll need to make some form of delegation procedure but then still surround this finite time if you delegated your right to someone and see that this is not not the best validator you delegate your right to someone else well because we cannot produce it in value blocks worst thing can happen you can commit to some block and never produce the person you just slashed we don't have all these severe problems like yours protocol we still get hit proof of stake and potentially prove us take particles in principle yeah the

worst thing can happen it if a validator screws up and the next one steps in earlier than should be and there's the only transition mechanism and error resolution which will we'll post a small denial of service risk on the system if I don't produce box then it will be some delay but then the this validator who did not commit the block will be slashed for the amount of time it make because damage on the system and this will discourage such behavior one thing that I find sort of fascinating about this project and even exploring it with you guys we started from like this like off chain solution and then in to this platform of tools and it's going to a like and as you go through it you

guys are basically coming into your you're facing the challenges that every large-scale blockchain project not every but like many large-scale blockchain projects face the question of like how validators are dealt with the question of should you be delegated the it's very it's been a very interesting journey even through this interview to sort of understand where you guys are going and where you've been and yeah anyways it's definitely it's an ambitious project thank you but luckily for us we rely on security properties of zero knowledge proof and this solves a lot of problems for us yeah and just from purely technological perspective it it's the centralization is not strictly necessary

there is a there from the day once there was a worst case resolution scenario even if there is just one super validator dissing solution as a test is kind of hard this is the decisions that we want to make it this way so just not even that this worst case never will never happen and well should not happen in a decentralized setting but if we can do it we don't need a super power oh I mean the building all the previous parts and continued provisional work is already a lot of work and like being a validator is not the funniest part of it funniest funnest yeah I mean you do need the the decentralized ask me to have

censorship resistance I suppose but I I want I want to ask one final question around how you guys are building things because I can't I said it's an ambitious project there there will have to be validator nodes that are producing proofs and collecting transactions and you'll need a transaction queue and you'll need Mountain p2p networking and everything else you said you're building stuff in rust like how are you building out these different components and which p2p net like library are using so a nice thing about being the validator is that you're not exposed to a risk of the operational security risks because you never expose your private key our only hot wallet machine you just

produce the person if the proofs are incorrect and they get declined so therefore the security requirements for us are are less we need to make a lot of effort to provide the to make the the the snarks the protocols inside your knowledge proves very secure but the rest can be can like all these communicational things can be written in languages like goal and maybe which take much faster in development so we used rust for really difficult parts and the rest we will see a rust is an interesting language might be a little it's it's a matter of trade-off of speed

of development and cost of development and the security which we need to achieve there so how much is is finished like how much is actually built right now and how much is there still on the horizon and so we we have a working the snark circuit for the first version is very close to I would say 50% yeah I mean we finalize the features which want to put because actually just limiting the features it's a difficult task in terms of implementing the snarks well still not many people really like to do it but we it's not a problem first everything else is more or less is much closer to more or less standard software development yes it requires people in

principle that's why we don't cut we try to find get some funding even after we got the Syrian grant but I mean it would allow us to get more people because this part is purely purely software engineering it's not to related to scenario directly I mean we can cover already is a snarky part so in this sense our goal is to provide the validators set of tools we basically four lines of code Oh not even a code just four lines for Union the network like to what what address you want to get collected fees or something like this so you can just start it and run even communication like ptb communication as well there are wonderful libraries for

it at the first place or we can equally use it as a round is finite so everyone knows who will be a participant in this round and they can all agree upfront about like what will be the common storage where they put all the data just even for public to download it it's not a big difference if it's down if it's a storage for public or a storage between operators so this part is purely software engineering without touching the key part the zk part is really difficult but we also have to to explain that we have a few other lines of research we were also working on the GPU prover which alex can present the benchmarks we will also work in on the sonic implementation which we

haven't touched yet because this is a new promising direction office which is especially important for smart contracts and snarks and this we will have to decide it will depend on funding whether we can pursue all the directions or just focus on the Franklin Network I happen to know of a very good framework that gives you networking data basis and validator notes and everything else on what you just mentioned I actually have a last question which is about the use of snarks the snarks that we have spoken about on this podcast and like do you

are you constructing this in a way that you could eventually replace snarks with something else or is this 100% built around the concept of snarks oh well snarks s is important we need em we need for verification purposes everything something which skills exponentially with the number of competitions just to just to compress this part which ensures the validity that's why we don't need signatures and chain we just need the small Delta's so this part is any solution which will allow us to do this we will be willing to spend the time in the research and and evaluate how it works a person pyre this is the most important one I mean

sonic sub snarks because they they are succinct I mean this just sonic as a proof system was called this way across 16 16 is Elzear proof system but all of those had basically starts to Eve service annex proof system even more and more efficient with Universal trusted setups and potentially other benefits then we will pursue this direction I will check and evaluate how its how expensive to make Genie proves there how expressive its to verifies approves there and if it suits the needs while the definitely will upgrade observer benefits but snarks Sonics are snarks in their essence Russ is the same way is another proof system but the area is the

same do Sonic's don't need trusted setups you need to trust it set up but not for every application only once for any application up to the given size and up to the given size basically the amount of computation which you want to run inside of the circuit but this is so powerful feature at for example food L want to upgrade the functionality would have to do another trusted please part of it with Sonic's we just say this is the new functionality today and we can have a much broader set of participants in the trusted set up because everybody will be interested because they can reuse it it's not only Universal but

it's continuously updatable maybe we're due to do an entire episode just on Sonic's but yeah pretty amazing what we talked about cool do you guys have anything else you want to share with the audience before we sign off where can people find you they can go to manner - laps dot IO uh well just because we code the github I mean but they will find links to Twitter medium-heat hop Gator everything from from the mains I want to say thank you

guys for sharing a like a little insight into what you're working on and also I think we've uncovered a few different topics through this conversation we've talked about plasma I've talked about on chain and off chain computation that trusted set up again and like the new advancements this is pretty cool so yeah thanks for coming thank you you're welcome thank you very much and to our listeners thanks for listening thanks for listening [Music]