zkSummit: Zinc: porting EVM smart contracts to zkSync ZK rollup – Alex Gluchowski – Matter Labs

Transcript

[Music] hey uh next up we have alex from matter labs who's going to be talking about bringing evm smart contracts to zk roll up with zk sync please leave your questions in the stage chat and we're going to do a q a after the talk but take it away alex thank you anna thank you for having me and hi everyone welcome to the talk about zika roll-ups optimistic roll-ups uh and evm smart contracts and how this all can work together and we will start with uh uh the intros into roll-ups uh i'm sure

that most of the audience is familiar with it and know what roll-ups are and the differences between optimistic and zika roll-up in principle uh very high levels i'm not going to repeat it because there's been a lot of content on this topic over the past two years uh if you're interested i can send links after the uh the session to to deep dives and comparisons uh but roll ups on the rise ethereum is now officially a rollup centric platform the vitalik butarian recently announced the adjustments in eth2 roadmap and eth1 roadmap to focus on the roll-ups and make sure that they are first-class citizens and

essentially uh it's now kind of official that that roll-up is scaling uh sorry ethereum scaling with roll-ups uh everything else has way inferior security and decentralization properties so roll-ups are the kinks interestingly there are two flavors of roll-ups and we're going to compare them they share the common bases in both types you have one contract on the mainnet which holds all the assets and a single cryptographic fingerprint of a state some for example a root hash of a merkle tree and for every new block which happens off chain

it contains a lot of transactions only this one hash is changed on the magnet contract now for zika roll ups you have to as an operator so whoever submits this block they have to provide a zero knowledge proof of validity of that block testifying that the new hash was correctly derived from the previous one in optimistic roll-ups no modern cryptography is used in instead your land game theory and someone has to monitor the only transactions in the roll-up and have has to submit a fraud proof to ethereum within a predefined period

of time to challenge the fraudulent transactions and in order to be able to do so and and for for both types of roll-ups in order to be able to reconstruct the state and be able to prove that you still have some ownership uh the data for every transaction is posted through ethereum as call data so for each transaction we post either the input which everybody can take and re-execute by applying it to their previously known state or maybe just the delta of the state what changed in the state like which slots get what new value um and yeah so the the uh these are the

technical uh differences which you you as i said you can check extra let's focus on the properties like what is different uh between the the two types of roll-ups and just just to mention zika roll-ups are currently in production so we are for example authors of zk sync which can be used for payments and not only for payments uh for transfers of value of any kind with receipt many fundable tokens uh for example for airdrops uh for um for different um like payments as as a checkout uh in in applications

for example you did with bitcoin grants of our last round i'm gonna use it with a around seven in december um we natively support multisig so you can implement some multisig based applications uh with multisig you can actually do very interesting things such as atomic swaps payment links and like some some basic contracts and you can also send payments to any ethereum address so for example you could send payments to a smart contract and then this smart contract can the request from the mainnet to get the funds back back to mainnet from the rollup so there is a lot of flexibility but it's not a fully functional

smart contract platform and this is what all everybody needs because we all want to scale ethereum in general with d5 with all the cool things which smart contracts are invented for so for that let's see how this does so optimistic versus eq roll up the there are a couple of differences which in my opinion clearly benefits zika rollops uh and it's i think it's very very important to understand these differences in order to to see the importance of uh porting existing contracts to these systems and specifically to zikro so number one the most

crucial uh distinguishing factor between the two roll-ups is the security model in optimistic up you rely on one of an honest valedictor's assumption uh indicator all of you rely on pure math and cryptography uh so z-carol is as safe as the underlying layer one if the cryptography is correct with optimistic roll-up you're supposed to be safe if at least one of the validators is correct it is not not compromised which per se is a reasonable assumption but people often ignore that it's not the only assumption of optimistic role there is another one and it's a lot

nastier you also rely on the mainnet ethereum to be enough censorship resistant so that any fraud proof transaction reaches the optimistic rollout contract and that is actually pretty problematic because there are attack vectors where you can deploy a 51 attack on ethereum magnet and censor a specific smart contract for a week uh which costs not not a lot like the the the brute force cost of this attack is something like 20 million dollars and if it's successful you can just grab

all the assets from the optimistic roll-up and interestingly the actual cost of this attack is a lot lower than 20 million dollars because it's enough for you as an attacker to just make a plausible commitment to the threat to override other blocks from other miners who who are not com um uh compliant with you and you so you run the attack for a short period of time and you communicate to everyone that hey guys uh you should be censoring this contract if you don't do this i'm going to override your blocks and you're going to lose money and rational miners being

anonymous and being able to shift hash power flexibly from from one uh mining pool to another they don't have anything to lose if they like if they comply with you but they have a lot of to lose if they don't comply so what's likely to happen is that a large fraction of the power will move towards the mining pools controlled by the attacker and then the cost of the attack will be negligible it will be just like i don't know in the range of one two million so if you put a lot of value in a single instance of an optimistic grow up uh it's an invitation for this attack to happen so it's it's probably

like not secure to put more than a certain amount let's say 50 million dollar is an absolute maximum of what i i would uh kind of think is is like not likely to happen in this attack if you put more money if you put 100 million 200 500 1 billion dollars it's almost a guarantee that this will happen and unfortunately this type of attack cannot be mitigated as long as ethereum remains a proof of work chain so once ethereum moves to proof of stake and everybody migrates then you could have some mitigation strategies then it would be possible for for the community for example to arrange

to have an agreement up front saying that um if this type of censorship happens then we will consider it illegitimate situation it's not just code is low we have some values beyond that and we can see which miners were or which state stakers were validators were participating in this attack we can target them and slash them but this is only once ethereum is proof of stakes this is probably several years away and we need to scale ethereum today because we everybody is of course familiar with the gas prices rising astronomically this summer so this is one big huge problem uh

the second biggest problem is that uh optimistic roll-ups have a very long objective finality so time for layer one to understand that a certain block is final on an optimistic call-up so that you can process exits from the optimistic call up is equal to the fraud proof uh delay so this is a security parameter which is equal to one or two weeks let's say it's one week so any native withdrawal from an optimistic rollout will take one week all the nfts will take one week fungible tokens could be accelerated if you use some

external liquidity which is available on the mainnet so you can ask somebody who is on mainnet to give you immediate liquidity and then wait for for this one week to withdraw it from from the roll up and you're gonna pay for it so of course it's gonna be expensive and it's gonna be complicated in terms of coordination maybe this will work with some smaller amounts of fungible tokens uh or of liquid tokens sorry but like for some less liquid tokens and for very large amounts if we're talking about moving half of some d5 protocol on and like on layer two and back to layer one this might be really problematic uh all of this of course you don't have with

zika roll-ups because in dq roll-ups the time of exit is equal to the time of finality which is just a couple of minutes which are necessary to construct the zero knowledge proof and finally you have certain types of transactions most specifically transactions involving privacy which are going to be a lot more expensive and optimistic roll-ups than on zika roll-ups so for example for privacy you have to publish all the zero knowledge proofs which can be pretty large so a uh a plump proof for example is one kilobyte uh on the optimistic roll up and you can completely omit them in the z

curl up with which supports recursive zero knowledge per verification uh so the the cost of a private transaction in dq roll up will be something like two times normal transaction for an optimistic roll-up it's more in the range of like 20 50 100 text um so it would be from from from this comparison we can see that it would be absolutely awesome if we could just put existing contracts on zqrap and many people consider you have considered it a very difficult task that's why we had a lot of attention to optimistic roll-ups over the past year but this is actually uh not true anymore it is possible to port existing

contracts to zikro up and let's see how we can do this so let's let's go through a migration roadmap which we in the meta labs are uh following and planning to to to to process to get all the legacy contracts on the uh on zika sync specifically we start with just supporting contracts which are zero knowledge pro friendly and to be easier knowledge for friendly the most obvious uh approach is to have a and complete uh contract support which we did this year with zinc what is zinc it's a language for constructing smart contracts

and also doing generic computation like producing zero knowledge proofs based on rust so this is an example of the code of of zinc it follows the rust syntax it borrows these smart contracts elements from solidity but apart from that everything is like like pure rust except for we eliminated all the complex elements which people normally hate and rust and sync comes with some nice features so it's completely type safe you can define custom types you don't have to bother with all this mass in solidity where you use the same you wind 8 for for a number and for for some option and for for some amount

you can define types for every single thing separately and make sure that you don't mix them up um it has type inference which makes the syntax a lot nicer so we have some syntactic sugar built in the language uh it's immutable by default and it supports safe math which the newest version of solidity also supports but we were there a year ahead of solidity so natively with operators all operators are safe you cannot have another overflowing in the operations of simple math immutability is really important so rust is a functional language and it allows you to have a lot less side effects and make the code a lot cleaner

and a lot less buggy and for smart contracts this is very very important so you can check it out at zinc dot zika sync dot io uh a nice thing is that zinc comes with a packet manager called called zargo on the analogy to cargo in rust which gives you a lot of lots of options so you can go and have you can create projects you can build them you can manage uh your files in uh um with like you can have a project consisting of multiple modules broken down in several files you can run tests you can do benchmarks and so on

and so on like lots of useful functionality all from common line following a nice common line syntax you will also be able to generate documentation and format the source codes but testing is is really really important you can write your tests also directly in zinc and have a really nice unit testing experience a lot nicer than in solidity essentially i'm of course biased but like every single aspect of the language is better than solidity in my opinion but i encourage you to check it out and experiment yourself um so we have zing and you can do contract zinc is not your incomplete so it doesn't contain unbounded loops

and recursion you like recursion in a single function call you can have recursion by calling the contract itself but it's it's going to cost you like an external call a really really nice property of zinc is that you can do we we paid a lot of attention to debugging and you have for example console log traces which can be run on transactions which are running on testnet or mainnet so you can have a smart contract call which does something and fails and in solidity it's it's totally difficult to understand what happened in zinc you can just add more debug points

with console traces and just re-run so you can modify the code and re-run the same transaction on the exact same block in the exact same same spot with the with extended logs and actually see what's going to happen and why the transaction is failing it's really a lot simpler to debug this guy with this kind of approach so okay we have that uh and it actually works so you can take existing smart contracts and just manually rewrite them into zinc today and this is what we did with curve the original curve is written in viper which is also a non-turing complete language

it doesn't allow bound unbounded loops and recursion so what we did we just took the code and rewrote it uh line by line into zync so the the code is public you can go to to exchange and see how it looks it's almost exactly like line to line uh compilation translation of uh the original contracts and if you go to the curve homepage you will see oh sorry you probably don't see my screen you i'm gonna show this one okay so let me let me just go back here here is the the contract code

and under metal apps slash curvesync in in github this is how it looks this this is how the tests look like the code itself and if you go to the curve homepage you will find a link to the zk sync testnet right there which is also hosted by curve and you can have you you can just try it out so you can go and connect your wallet which will open the separate tab so you won't see it now if i do it but you you you're welcome to experiment you will get some test stable coins on the rink bit test net to play with

and you can just do a swap and see how this works with any wallet uh which supports web3 so with metamask wallet connect uh or even with with the burner wallet which will even inside your browser so this works you can do this now okay so this was the second step now the third step is we can automatically convert legacy code into zinc

even if it's written in solidity since zinc and solidity are structurally isomorphic except for the turin complete part every aspect of the language is like though they are they are following different syntax styles uh they're the same so you just define your contract you define your state you define your public private methods uh and we actually implement this okay let me just share my full screen i think i can do this okay we have a [Music] an experimental transpiler from solidity

into zinc which is called soul z and yes this is how it works so i'm i just transpiled the uni swap code and produced a unisop.dm and here is how this code looks like it's almost complete in terms of uh because it compiles some uh lines of code still commented out because they are unsupported but we are almost there with the full support of

solidity using transpiler and it will be possible to compile anything uh except for the turing complete parks which you will have to rewrite the good thing is most d5 contracts do not require training completeness so uniswap is non-turin complete most other things even if they have some loops mostly what you need is just to iterate through a couple of things so they they are not uh most of of different protocols like if you look at the top 10 from from the capitalization standpoint uh they only iterate through some fixed number of items and maybe number of uh

pairs in the in the trading loop for uh for curve or something like that so like most of the most of the time you can just easily convert it with minimal modifications and it will just work [Music] okay and finally so yeah this this is how the the uh the uni swap code looks here again and finally we are currently working on adding during completeness once we can add during completeness the transpiler will of course easily support transpilation of any code uh

and it will not be required to do manual changes at all it will just work so it will be possible to just take any existing solidity code and deploy it to zika sick without uh need of modifications and what made this possible were two things number one is recursion which we implemented uh for ethereum with flonc in summer for the edit challenge uh so if you go to reddit logicscan.io you will see the block explorer with uh with their recursive blocks and they are coming to mainnet actually next month uh so this is fully functional with uh

ethereum uh verifier on uh on rigp test net and this allows you not only to to have arbitrarily many blocks verified with a single proof but also to have separate runs for every contract verified in one big block so a block can contain multiple transactions and each transaction will have its own smart contract call with a separate proof and you can aggregate all of them together so this is one approach another approach would be to build what one generic circuit uh which i think cairo is is following but uh we think that the what we're doing with recursion is a lot

more flexible because it gives us ability to have contracts which are using some very advanced crypto like using some non-zk friendly crypto like sha-256 hashes or k-chocks hashes or ethereum signatures uh and we still are able to efficiently verify them because they will run in in this separate circuits written in zinc [Music] and so this is this is one breakthrough which made it possible and the second is the second thing is uh tier incompleteness is very expensive it adds a lot of overhead on top of the lots of overhead that zero

knowledge proofs in general are adding so we need a lot faster proverb and we are achieving this with uh fpgas so we have an fpga solution which are now being adjusted for uh bm256 uh and is uh zlink and aws f1 compatible and we're gonna bring it live probably by the end of this year uh with the um a lot faster proofs accelerated by fpgas so the cost is actually not reduced by a large factor compared to cpus but the speed so latency of the acceleration and accordingly the

ability to produce proofs for a large number of contracts and support high throughput is increased massively and we're going to publish the benchmarks soon but this is the the final element which gives us this ability to build during complete contracts and that's it from my side uh we reserved a large fraction of the stock for questions because we suppose there are going to be a lot of questions so and i'm giving it over to you great thanks for inviting me back um so there's a number of questions i had a question as well but let's start from the top where kev asked is this an okay is this an alternative to solidity or an alternative to something like

sircom uh so zinc is of course an alternative to something like zircon circum or uh or socrates where you can just write your code uh your circuits and and produce circuits uh produce proofs and verify proofs for the circuits it's written in rust so you can embed it into any application so if you want to use it for zero knowledge per generation for circuit building you can do that it doesn't require any specific zero knowledge proof skills so any programmer who is capable of writing solidity code is or or ras code or python code will be able to write zinc code so you don't have to understand

math uh behind that you don't have to understand like fields uh overflow like you're not gonna make any mistake if the code is readable you can be sure that all the constraints are there it's completely deterministic we on purpose we did not allow any non-determinism you cannot have external business we have a rich library of gadgets which you can use which are efficient for example sorting and other things in crypto primitives signature verifications but yeah you can use it for that uh but if you if you want to use it for contracts we have a separate flavor of language which is just supporting smart contract features and then you just describe smart contracts in a normal way and we do all the work

behind in in the back i actually want to ask my question as a follow-up here because in the curve example that you shared i was curious if curve itself is running on a zk roll up on test net or if it's like the code was rewritten in zinc because it wasn't completely clear as we like the code was written in sync and then we run it on our testnet and it would be on as like once it's in production once it's out there it would be on a zk roll up yes so if you like with with any layer to solution uh your you will have to deploy a new instance inside this layer too and you will have to move your fonts from layer 1 to the into this layer 2

through some asynchronous process so it won't be it won't be smooth you cannot just like put existing code on player 2 and make it interact the same way with layer 1's smart contracts as you did before what you can do though is you can you can gradually migrate from layer one to layer two so curve balancer and other particles uh could just deploy another instance in the layer two lindsey k sync with with just a small amount of liquidity and then gradually with increased demand in layer two they can move funds from layer one to layer two gradually like shifting the balance towards

uh more allocation in layer two but always having an option to go back should there be something like if you need this money back on the main ad because there is some hot projects going live and you want to participate there and do your liquidity mining you can always do this right so you you don't you have full optionality you don't have the fear that you won't be able to move them back for one week like that's going to be the case without mr collapse way jay asked which proof system does zinc target uh we have backhand in plonk uh which will automatically work with redshift once redshift is complete uh redshift is our proof system uh which is which

is based on the plonk arithmetization but uh uses uh fry uh for polynomial commitments instead of gate commitments so it means the redshift is transparent it doesn't require trust setup plonk requires the universal transfer setup which we reuse from the ignition ceremony from last year um so yeah it's it's like plonk arithmetization uh so anything which is based on block characterization is is you will be able to extend zinc to produce proofs for that system so yeah why why is that important because we're going to use some specific things from plonk like some custom gates and lookup tables which

are making certain things very efficient asked i wonder how zinc handles 256 bit numbers and the arithmetic uh like longer arithmetics so you you you have just like uh no processor has 256 bits uh native words you have 64 bit words and then you you have like some number of limbs in your number which is being multiplied like with long arithmetics uh the same thing happens here we can negatively support 64 bit numbers because they are not going over for even if you multiply two numbers uh in the field uh but uh yeah then we

have four limbs in in the representation of a single u two five six isaac was asking how our non-snark friendly things like i don't know how to pronounce this kick hack or whatever k shack with custom gates it's handled in the trench pilot casting gates and plonk we we managed to bring down the shatter five six constraints from twenty five thousand in uh it's like that yeah twenty five thousand r1cs constraints down to five thousand gates in plonk just just one example so you can do a lot of nice things there with like uh plonk allows you to construct something like

starks for certain elements uh and use them as like the single custom gate a star had a question about recursive zk snarks but i'm not sure i understand this it is recursive zk snark used to support smart contracts and i don't know if you understand that well yeah this is what i said like we we support so we we we aggregate uh multiple proofs recursively into one and we can have it in a tree like structure can have arbitrarily many proofs being aggregated into single one and each of them can represent a smart contract call for example and without that it would be really

difficult then you have to construct one single huge circuit which does everything which might work with starks but will have other problems so i think with starks you won't be able to as flexibly uh have the the ethereum constructs like a check and shutter f6 uh but you at least on the on the other hand you can have one single uh block which contains like lots of transactions with plunk it won't work because we have a trusted setup of a fixed size so we can only fit as many constraints in one single proof but having recursion allows us to combine these proofs arbitrarily many times so we can have like as many

contact calls or execution trace as we need sergey asks does it support ethereum pre-compiled like bn it doesn't no we we excluded so we ethereum pre-compiles like uh shutter f6 yes so the basic ones not the uh bn or uh like the smaller crypto like ap uh 1962 no we don't support that so contracts that would that rely on this will have to be rewritten using the crypto primitives from zinc directly this is one exception yes lasso was asking is the recursion unbounded recursion on the level of calling the contract itself is unbounded so you can

you can just schedule many calls of the contract in solidity you can do message message what's it called uh message sender dot call back right but you cannot have it inside the function of zinc it's slightly more expensive but yeah you can you can have it in unbounded way you can structure it this way cool hang was asking are the common zk friendly crypto primitives already built into sync uh we do have a number of common crypto primitives such as hashes signature verifications we support music which is a very popular signature scheme

based on our signatures which which allows multisig and just generally is nice uh to work with uh yeah hashes that merkle trees um i i don't have it out of the top of my hand but we have a really nice documentation so if you get if you go to zinc you will find a complete zync book with like uh the standard library and all the constructs contracts non-contracts circuit operations everything is explained i just tried to put it at the bottom there i hope i got it right uh i'll send this link to the

stage to the chat chat yeah that would be awesome yeah yeah great so kev asked does this use r1cs flavored versions of plonk or is it standard plonk with custom gates it's standard plonk with custom gates and lookup tables and soon redshift uh your redshift is work in progress it's uh it would work now we tested a recursion as well it it supports recursion the same way a uh block uh like k based long support recursion but it's just not as efficient with regard to hashes so once we can bring down the uh the cost for hashes uh for recording it will work if you don't need

hashes if you so if you don't need recursion you could use redshift today if you are if you have applications which require a transparent proof system you can write proofs in zinc compile them into uh into our intermediate representation and then it will be possible to have action i'm not sure how like the code is is uh is already public or not for foreign but it's certainly possible you can talk to us if you need that just talk to us and go goofy girl daryl was asking did redshift always use plonk arithmetization or is that new but then followed up oh already yeah we used to use pure r1cs

based on belmont uh and we used to use belmont gadgets and now we created a bunch of our own gadgets because we needed to bring the costs down so now we're switching to the block based recommendation okay um isaac asked do you have custom gates for all non-snark friendly eth op codes uh says can you sir can you repeat the question oh sorry do you isaac asked do you have custom gates for all non-snark friendly eth op codes uh no it doesn't work this way it's it's slightly more complicated than than that we we don't do evm so this is the the the thing i i missed probably in my talk

when we talk about bringing evm smart contracts to zika roll up it does not literally mean bringing evm to zikir this is not what people need what people need is to bring the legacy code which now compiles into evm which is written in solidity or viper or partly in assembly or yule take this code and make it work in zqraw this is the demand not just like specifically evm uh and we accomplished that by recompiling the codes into zinc vm like degree compiler there is a nubian okay just not evm

yeah got it uh brandon asked what is what's the constraint cost for recursively verifying a redshift proof in circuit i don't remember um it depends on the hashes so the the bulk of computation of uh verification recursive verification of redshift goes towards hashes so you have to to see how many hashes you have it's comparable to to to start so you can just look at starks see how many hashes you have and then then uh pick your hash which which has to be like super efficient very snark friendly uh it can be a non-binary tree it can be a tree of uh area t8 or something because you've got

you have some hashes like poseidon which take more than two inputs and then you just multiply by the number of constraints so but i don't have these numbers out of top of my head alex philosoph would be able to answer this question better so if you just drop a line to us we'll reply uh is zinc stack fully open source it is open source we just like we are opening the code once we complete a milestone and we have a stable version with we like we we work on things we polish things internally before we open them so that people who like whenever we open something it it it should be very very smooth and functional but yeah

everything will be eventually open source completely 100 including hardware ronald was asking is there a difference in syntax between the standalone version of zinc like the previous 0.15 version and the new contract the new smart contract version of sync no differences in the syntax of the language itself we just added features required by smart contracts so like we added keyword contract and the the syntax for storage definition from public methods private methods but inside the methods they they look exactly the same as as normal using like previous versions of things so zinc is evolving we're adding some new features so obviously like the the the

this uh the language just supports them but they're they're going both into the smart contracts and into the circuit modes cool dara's asking can redshift be combined with the accumulation scheme idea uh i'm not familiar with the scheme is it's the third one from the bottom but dara do you want to give a bit of context to the question maybe and we can come back to it i'll ask the next one okay kev asked is the 1k proof size for all custom gates plus lookup with kzg

um i think the question is i think it's like one kilobyte uh like we're one at 1.5 kilobytes something like that so like i'm not exactly sure but it's on the order of magnitude of one kilobyte it will for for everything um cool jek asked what's the outlook to disassemble evm bytecode and recompile for zk sync uh it doesn't make sense because you're gonna you're gonna lose a lot of important information for example yeah if you are using uh um

imagine you have a hash map uh within in in ethereum right this hash map uh has very specific sequence of uh derivation of like the way you address your storage so you take the uh the slot number uh you take the key of your hair of your mapping you make a ketchup hash out of it and you use this hash as the the key for the storage slot like the index of the storage slot in media so if you just take this natively this code written in uh in in like i mean the the byte codes from evm for for this part of code

you will construct a very expensive operation uh whereas if you know that you're dealing with a hashmap you can do things slightly differently and way more efficient so it's it's a lot better to work with the original source code because you can derive a lot of information from the source code from the context there see it's possible to do evm uh transpilation directly but it's just not going to be as efficient as working with source ronald was asking is the default access scope of functions the same as in solidity public by default uh i can't answer this immediately i think in in uh in the last year like we have

explicit modifiers for each function so you cannot have like you i think it's it's the other way around like you you have to do bob but let's see let's just look at the uh at the code and functions and oh i have to go yeah so you you have to do pub for a function which is public so by default it's private so as i said like every element of the language is better from the security perspective than solidity like every single thing you look into is most likely better uh because we like rust is now lingua franca of uh of all security if you look around facebook libra is

based on rust alia is based on rust polka dot chose rust uh uh like lots of new things are being based on rust because it's just it turned out to be a very good design of a secure language with all the elements which are necessary to prevent common mistakes and like yeah uh that that's why it wasn't just for us there was a little bit of conversation about fry and this uh accumulation schemes but i think i'm gonna let you check that out after um but dara did have a follow up which is more about redshift here so what's the concrete efficiency proof size prover speed verifier speed of redshift relative to halo i'm not able to answer this question

it's a reference to alex v uh okay he's the person who designed it or has really he is our chief scientist yes he like we have multiple people working on this stuff but he will be able to answer the question so dara i encourage you to just ask him is he here is he in the chat or can we get him to come into gather.town later maybe we can try yes okay i think that would be awesome um martin was asking apart from imp from implementing migrating from um smart contracts to zinc what else would be required to run a solution end to end locally or on a test net example of zinc vm and layer two operator code available for local operation

is the zinc sorry yeah is it available so for a uh for local operation you just need to run a node on the test net will support deployment for multiple public test nets so you don't have to worry about that and um i'm not sure i understand like what what specifically your question is all about so you like you just have to run a node right you can do it with uh gas locally and um if you want to have it you're on your own ethereum testnet you can just have a local test net and a local installment

of zika sync and then it will work kind of cool kev asked did you also copy rust demand driven compilation process um what is demand driven compilation process and maybe if you can clarify also i'll say it i'll say it now if there are any last questions we should probably put them in the chat now um i think we have a few more minutes to take to take some there's some really good conversation happening here and i like that you know isaac and you're answering questions this is fantastic i'm i'm wondering if there's a way for me to export this after

i'm gonna have to check it out yeah kev if you wanna maybe just give a bit of context on that uh rust demand-driven compilation process you mentioned also alex you know that there's a 30-second delay so we have to wait for a moment sure um i actually i had a little in between question maybe which is about uh the git coin project that you did with that was there a zync vm running like is that also smart contract enabled or was that no it's not it's very simple it's just payments okay are very stable now they can be used for

uh with wallets we're integrating them into smart wallets uh they are like simple running for a long time and have proven themselves robust uh contracts are more experimental okay uh ethereum working asked alex could you explain more how the permissionless network of zk-sync operators working together to ensure the surface availability sure we'll have a consensus in layer two with uh validators uh requiring like they will have to put some uh as the casing tokens at stake to become a validator and produce blocks and so the the way they produce blocks is

similar to a normal side chain with the only exception that once they produce a block in order for this block to be uh actually happening on ethereum they also have like the the block producer who is elected to produce this block will have to generate zero knowledge proof and submit it to ethereum but the coordination will happen in this off-chain consensus cool so kev came back with some clarification on that earlier question is the new architecture that rust is employing where compilation is no longer multi-pass when you need to type check an expression for example you query for the expression type and there's a document that is linked there

i'm not the expert on compilers so i add that exactly but we uh simplify it for us we uh we have a um i'm not sure if it's multi-pass so it's probably multi-pass but like we we don't do a complex type inference and the reason for this is that a lot of people are having difficulty with rust because of uh unreadable error messages like they do something and then the compiler is so smart that it's it thinks that it should do some like very complex type inference with templates and it's probably some some some difficult construct which he doesn't understand and it outputs a

compiler error which is absolutely uncomprehensible so we wanted to avoid that we definitely wanted to people not to have this experience and be like that every error message is very uh helpful and and helps you understand immediately what's going on so for because of that we have to simplify something so like the type inference is very simple uh it doesn't require like and and that's why we don't have like full templates also you don't need them in this smart contract way jay uh going back to the custom gates just to clarify does zinc have custom gates for sha-256 is there a full list of operations with

such custom gates uh we will publish it with like with the release of uh of the next version of zinc uh but uh shot of f6 sketchup we do have a custom desktop cool well i'm going to assume that there's no more questions because it's been a moment since we've seen one if there's any missed i'm really sorry we're going to head to gather.town just after this so maybe alex if i can get you over there too we can continue the conversation there sure so thanks again thank you guys for listening see you soon