Exploring SNARKs for Sidechains with Alberto from Horizen

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online in this week's episode i chat with alberto garofalo from the project horizon horizon is a stand-alone proof-of-work blockchain that uses zero-knowledge proofs to move tokens between the main chain and the side chains we discuss how the system zendoo works and how this compares to other side

chain and roll-up designs as well as cover their latest lattice sidechain work now before we start i want to let you know about a privacy focused event happening tomorrow april 29th i'm co-organizing this as part of the xero knowledge validators work and this is a privacy on polka dot showcase so this is the first of many privacy and zero knowledge proof focused polka dot events to come we've also done something similar on cosmos i've added the link to this polka dot ecosystem event and i hope you'll pop over check it out and join the conversation i also want to take a moment to thank this week's sponsor ey blockchain ey is committed to supporting the integration of the world's business

ecosystems onto the public ethereum blockchain and they will be hosting an event to do just that join their fifth annual blockchain summit and education series on may 18th to 21st for a deep dive into zero knowledge privacy technologies accounting and tax rules as well as the future of finance sign up and learn more at ey.com global blockchain summit or check out the other work they're doing at blockchain.ey.com so thank you again ey blockchain for supporting this podcast now here's my conversation with alberto from horizon [Music] so today i'm sitting with alberto

garofalo from the project horizon welcome to the show alberto thank you anna so today what we want to talk about is zendoo a zk snark verifiable cross chain transfer protocol this is unique it's kind of it's interesting because this episode is coming after three episodes that dealt with zk rollups now we're going to switch course a little bit we're going to talk about a slightly similar concept but quite a different architecture but before we jump into that let's start out with a little bit about you alberto introduce yourself tell me and the audience a little bit about you know what you were working on what got you excited about this and what are you doing now oh sure anna thanks yeah in my career

i covered the role of cto uh in sevilla startups for example in my previous experience i was working with ai fashion recognition and this kind of stuff and more in general i always started from the idea from the beginning and then built the team and then following the development of from the very beginning up to the delivery phase and this is exactly what i'm currently doing at horizon so when did you first join horizon or even maybe when did you get excited about like this entire space when a friend of mine talked to me about about verizon and he was already following cryptocurrencies and so on and i got excited i mean this was completely new

for me and i started exploring it was really really really exciting and then i met rob villone one of the co-founder of verizon and boom everything started from there what year was that uh it was 2018. okay and but i mean you jumped in not just to any you jumped into like a zero knowledge focused project didn't you yeah exactly deep end that's the difference exactly i mean for sure i had to learn quickly i mean yeah have you had had you had any experience with like cryptography or like this level of maths before no never i mean i always liked moving from different

areas and bringing my different experience to this area and these provide me ways for having a different perspective and and also i mean if i can uh building something new cool let's discover a little bit about horizon what is it maybe give a little bit of a history i know you joined in 2018 but i i think the project's a little older so yeah tell us tell us what this project is yeah when i joined horizon the project was already launched them and they shared the same code base as as zcash so it's a proof work based cryptocurrency with shield transactions but at the beginning we had the tls encryption between nodes for having this encrypted communication between the nodes

and a system of secure nodes and super nodes i mean similar to the master nodes of dash okay of the dash cryptocurrency and uh i joined some months uh later after the launch and the one of the first thing that i've been working on was a treasury system and also a system for redistributing the funds for secure and super nodes in a decentralized way and this was the reason when i started looking at the possible implementations it was quite clear to me that adding the complexity of managing these funds inside the core software of the cryptocurrency could have led to potential security issues and and the overall complexity of this

of the code would have increased so instead of doing that i was i mean i started thinking okay but why do we need to keep this kind of data and logic inside the core software let's try to organize it in a parallel chain maybe with the specific software with the specific rules but there was a need for transferring how to say the zen token from the main chain to this parallel chains and when when i started looking at what others were doing at the time i discovered that this concept was side chains side chains definitely so everything started started in that way

okay so you are you're actually trying to tackle a different problem on this proof of work something like zcash i kind of want to i want to dig a little bit into that so does it have the same transparent shielded account kind of model correct okay it you started from sort of the z cache or is maybe zerocoin from the z cache exactly the same z cash code base yeah so that code base but did you evolve in a very different direction or did you continue to work with that team because it's all quite open source and like you could oh no no no no no totally different i mean totally different so it's like sprout onwards up to sprouts obviously from um the phdr proving system to the graph system but we stayed on

on sprout and then later i will i mean or even now if you want i can explain you why well actually if you stayed on sprout because you know that vulnerability was discovered a few years ago i know well i guess you know what i guess did you like in their case the way that they fixed it for it was to upgrade to sapling what did you do i had quite let me say busy days as you can imagine all right so yeah what did you do like if you didn't upgrade to sapling what was your solution to that oh i mean the way the vulnerability was fixed was also to change not strictly related but they took the opportunity also to change the proven system behind it so

uh they switched from phdr to to the graph 16 provision system i see and so we parted the same uh let me say fixes uh inside our code base by using uh the new graph system implementation for sprout got it but you didn't do the full sapling upgrade no we didn't and we paused that development because in reality we started thinking about using our sidechain system as a possible solution let me say for also shielded transaction because you can see in our model you can see a side chain like a pool of coins where you put in money and you can withdraw from this pool by

providing a snack proof so there is the redistribution of these funds inside this pool let me say and the logic that is managed inside this pool is totally decoupled from the mansion from what is verified by the core of the cryptocurrency and so you can even think about having a side chain that will act as a shielded transaction sighting and so for this reason we didn't integrate immediately settling inside our core because we are planning uh the and we are thinking about the possibility to have a specific sighting for shielded transactions so this i guess

brought up brings you to zendu this work that is i mean like was it always called zendu or is it more recently that it became that that was the name oh we gave the name uh i mean at the time we we published the paper so about one year ago okay so currently i mean if we use bitcoin as a basis the most famous side chain i guess side chain mechanism is lightning we did have bolt i don't know if you know io from bolt he was on the show about like two three years ago and also talked about like these side chain constructions but they're very much connected to the bitcoin or zcash model how do you see what you're doing fitting into that is it similar to lightning

is it similar to a zk roll up like where would you place it the kind of need we are solving with our model is quite similar because we wanted to provide a way for building decentralized blockchain applications the decoupled from from the mansion from the zen core yeah and so we have constructed the model that makes use of snarks to provide the possibility to interact with with the main chain in a totally decoupled way without having to rely on some trusted party or a set of let me say validators because in these sites and models there are some projects

that are making use of validators that are entities that somehow certify to the main chain that uh what is happening on the side chain really happened and for example the backward the transfers that are happening between session and mention are valid actually the names for those vary so i've sometimes have said validator as well but it's also it's been called like committee coordinator uh like basically it's the entity this agent that sits between the l1 and the l2 correct and it's actually decentralized often so there'll be like many of them repeating the same processes potentially for rewards exactly and let's say that our first let me say model was making use of

validators certifiers or whatever you want to call them a decentralized set of them so we have the protocol for selecting them and from from a bigger set and an incentivization scheme for for doing this work and obviously these these actors were responsible to follow the site and certifying to mention that the transfers that were happening from session to mention were valid and we're respecting the sites and rules but at some point we started let me say thinking about also corner crazies where you can even not rely on honest majority and so when you take out this assumption of honest majority there could be some troubles in some of

these scenarios because main chain can only blindly trust what these validators and certifiers are certifying so we wanted to move forward we wanted to have to say provide to maintain a cryptographic proof that the transfers let's call them backward transfers the transfers that are happening from size and dimension were valid and we can see what valid means because in reality if you want to prove the validity the cryptographic validity of such transfers we have to understand better what does it mean got it so you're saying for your construction like when we compare it to say a zk roll up or any of the roll-ups you've opted not

to have one of those entities is that correct like you don't have a validator in your system i mean uh even with rolap you can you can end up with a with the zero knowledge proof of validity of of the transfers the difference is that for example we are making use of of recursive snarks on the on the side chain side and we have a specific let me say protocol on the sidechain side that let you run a whole sichuan network for managing uh the the specific blockchain application logic out there but back to the question which is is there a validator that's what i'm trying to figure out like do you have a role between the side chain and the main chain

uh let's say that you can see two different uh in parallel uh dimension in the sidechain in the sidechain you can see it as a blockchain as well okay with its own consensus okay for example our lot side chain is using a proof of stake based consensus when the robbers base the browse consensus so on the side inside you have forgers forgers yeah because it's a blockchain so you you have really forgers that are producing block on the side-chain side okay so that's like equivalent to miners but exactly but for proof of stake correct so it's the forger on the side chain that is like the minor on the main chain that's the equivalent

yeah correct because on the side chain side we are not minting new coins and so we have to use a consensus that let you let you let me say run the sidechain in a in a cheap way so let's let's put that away so yes for sure we have forgers on the sichuan side that are producing blocks but when i was speaking about validators previously i was meaning the actors that has to somehow certify to mention that the transfers that are happening from the site into dimension are valid because within the site chain you can rely on the forgers that are and on the consensus that are validating let me say all the transactions and the and are uh verifying that the transactions let

me say are correct and respecting the consensus and so on but when you you want to go out with some coins let's let's do an example you can think about a car registry sighting where uh you transfer the ownership of cars no with its own consensus you so you create this sighting and you customize the consensus for managing this kind of uh transfers so what a user will do is uh transferring coins from the mention to the size and then buying the car by posting a transaction on the sigen so that will exchange the ownership of this particular kind of object that is the car and also the transfer of the money but then who sold the car probably would like to withdraw the money

okay withdraw the coins from the sidechain and and send them to the dimension to a specific public key and then maybe transfer them to an exchange no this could be the the typical use case so let me say that the elements that are involved in this process first the transfer coming from mentioned to sign and this can be easily solved if you assume that the side chains follow the main chain so side chains know the structure of dimension of structure of dimension blocks they can extract for example proofs that something happened on the mentioned part okay and include them in a situation block then within the site and we have

transactions that transfer the coins from one user to another user and the ownership of the car and then you have the receiving user that want to withdraw this coin and you can see this as a specific kind of a transaction on the site inside so let's call it withdrawal request that spends some existing coins in situ and append let me say tua backward transfer request list this request let's say that on a regular basis these requests are collected and then sent to mention yeah mentioned just kind of patched exactly mention receive this list of backward transfers that are public

key and the mount for example each one and mention has to somehow verify that these really happened on the situation set really reflects what happened on the side inside yeah so what does it mean that if they're valid it means that for example this backward transfer is coming from a withdrawal request that spent some existing coins in the sidechain and these existing coins in the size and were coming from another transaction that was spending existing coins and so on so on so and so on so if we want to say the validity of the backward transfer we can simplify saying that the whole history of the coins

behind this backward transfer is valid um but i don't understand from what you described how a side chain and a main chain see into each other like you sort of said that they follow each other and it's like the part where you roll it all up or you prove something and you verify it like that part like that actual cross-chain thing at least for me conceptually works but what you've described is that you're following each other you're actually keeping track of what's happening on each of these even during the batching time no we can assume that cyto follow mention and for follow what i mean the most simple thing would be that all the sights and nodes

follow the main chain network so they they are aware about mention blocks so they can see what happened there and so they can take decisions based on that but that's what i'm wondering how do they see it like how do they see because i'm just picturing like the way i've always understood these things is you have like node operators people running a main chain node like are all of the people who run a side chain node also running a main chain node is that the design this is the simple approach uh we are not using this approach because uh we wanted to do something better so we are including in the sidechain block so it's the forger that is obliged to follow the mention network okay the forger on the side yes this is

on the side chain so this is like the minor equivalent the minor the four people i see so like the main chain miner may not be paying attention to the side chain but the forger is paying attention to the main chain perfect exactly okay so the the forger of the section side is aware of what is happening on the mansion and extract let me say the sichuan related information from the mansion block and includes them in a situation block in fact we have designed also a specific side chain consensus that is let me say making this possible why i'm saying this because for example if you have a forking mention these has impact on the side chain because if a forward transfer

and i mean a transfer happening from mention to saigen was happening in a block and we had included a proof of this forward transfer in the situation and after the mention block chain had it it assumed it had it exactly and used it maybe but you have a mention for for whatever reason i mean you have consequences on the size inside so we have a specific consensus that also manages and handles this kind of situation on the side side that's interesting so is there like when moving from the main chain to the side chain does the person like end up locking tokens yeah yeah okay how it is implemented in reality we on the maintenance side

we burn the coins so on the balloon destroy them okay uh yeah because on the main they are not enabled you do the mint and burn of the bridge exactly so we have a specific kind of transaction or better a reality is a specific kind of output of a transaction in the main chain so if you perform a forward transfer in dimension you use some mainstream coins and you send them to a side chain but these coins are not existing anymore in the main chain they are part of the balance of the situation and now how they are distributed and who is the owner of these coins in the section is

i mean is totally unrelated with dimension is not connected anymore in fact you can see the site as a pool where you put money and then you redistribute it with some rules okay so you're doing sort of like bulk burns on one side and then pooling on the side chain and redistributing it somehow correct uh in reality are you making it are you minting it on the side chain every time no because uh what happens is that we are not creating a new coins in the size and in reality when a forger includes a proof in a sidechain block that a forward transfer happened in mention the coins appear in the sidechain so the consensus in the sidechain

knows that sidechain public key a now is the owner of that amount but it still sounds like they minted it if it appears if it appears isn't that minted yeah i mean you can see that way but in reality they're not let me say like the coinbase of a block they are they're not part of the block forging process i mean they are oh yeah because what you're thinking when we say mint it sounds like the thing that the miners do exactly i mean i just wanted to clarify that they're not part of the the block reward uh there are let me say something that is coming from from the maintenance to the size and so the forward transfer is is let me say giving evidence of that like the value on the side chain just

goes up correct like the number of tokens goes up and then when you go back you burn them on the side chain so the number of tokens go down perfect and this is very important so uh the main chain keeps tracks of the balance of each side chains and as a safeguard where it doesn't allow the balance to goes minus then zero so even if the sighting has some issues i mean i don't know some flows whatever the balance of the main chain is is is preserved and and there are there are no risk for dimension itself interesting i mean this sounds a little bit more like what i always understood as just bridges like are these not then bridges between chains

with one being considered the main chain how is it different it's a sort of a bridge you can you can call it the bridge the interesting part i think is the next part where we see how the side chain is transferring coins to the mention so how mentioned will be able to validate the other transfer okay yeah so maybe let's bring in the zk part of all of this so you are so unlike lightning which is more locking actually let's make that distinction too unlike lightning where you're locking tokens on main chain and unlocking tokens on the side chain and then going back and forth that way you're kind of like keeping them in a not contract but something like that that's always the way i'm thinking about it

in your case you burn them on the main chain they appear on the side chain that you do things with them and then eventually you come back and this is this is where i'm curious like again like you have two consensuses running and you said that like if you mint new ones it's not like it's the miners minting new ones for themselves it's not their rewards that are being minted it's not like a new token because of the consensus part it's because of this bridge action how does that look like and how is there zero knowledge proof in there because it sounds like there is a lot of proofs involving the whole process okay okay uh yeah that's correct so this is exactly what we're doing so to

explain how we use genealogy because the need of the of the snarks in particular it will be clear when we go back in the part where we verify the backward transfer from from the size and to the main yes because we don't use validators or whatever or certificate in between agents exactly and it's a we cannot assume that main chain knows the rules of all the signs and follow all the sichuan because otherwise it will not scale so it has to some somehow validate these backward transfers and so we want to have a cryptographic proof for this list of backward transfers as we were saying before it's valid the

backward transfer if has a history of valid transaction behind it you know and so if you think about a circuit or or creating a snark proof for it you can think about having verified in a circuit for example that you had a transaction that was spending some existing coins and creating some other coins and you have a snark proof for that that's just on the side chain just on the side wouldn't you just be transferring them from one to another not like spending and recreating are you talking about like in my account i'm spending in your account on the site and receiving

exactly because okay the reality is that if you want to prove the last part that is the transfer from sichuan to mention in reality as we were saying before we you have to prove that the whole chain of things that happened i mean that led to this backward transfer is valid so you can think about for example mina mina is using recursive snarks to prove the state of the blockchain at some point no yes you can think of about the state as let me say the set of utics or the set of coins that are existing at some at some moment in the in the blockchain and you can think about this recursive process as like proving that there is a valid

transaction that is a transitioning a state to another and what i mean that there is a transaction that is spending existing coins in the state that has the right signature for spending them and then the new state contains the outputs and yes the balance of the transaction is exactly so i think i i think i do follow you here i think it was just a bit the language that you used when you said like spend and because then it sounded like it left the system and came back but what you're talking about is like it's been moved around in the system in the system inside the system inside and there's there's almost like a you're going to like lock that in you're going to prove that that happened

or something exactly you're proving that it happened i mean that you transition the state from from a to b and and so on and you do for every transaction that is happening in the in the session but the additional thing that we do for example is a keeping track i mean also about the withdrawal requests that happened in the site so instead of just enforcing regular transactions that are exchanging coins uh between users inside the site chain we manage this kind of specific transaction that is able to withdraw coins from site chain to mention and what do we do for example we remove we verify that we have the coins in the in the state that we are spending

in the session and we add the amount i mean the backward transfer to the list of backward transfer that we are batching and we don't add to the state of the size and these coins because these coins are then burned in the side chain and will be available then in dimension and but where yeah where does the zero knowledge proof live then does it live across both of them or does it live in the side chain this process of generating all the proofs for the whole history uh is is living in the sideshow okay so from from the mentioned perspective mention we receive a transaction yes a sort of a transaction we call it certificate where you have a list of backward transfer

so public key and amount simplifying and at zero knowledge proof that validates this list and let me say behind this zero knowledge proof there are all the other proofs that recursively were messed on the side chain that recursively validated the list of backward transfers but is is the verifier still on main chain then you have a verifier that's verifying the proof that was created on the side chain so we have the certificate that goes in the maple in dimension okay then is added by by a minor in a mentioned block and the miner itself verifies and each node that received this certificate in the mempool

verified the snark proof behind it and the curious thing is the snark verification key what is the snark verification key for verifying this proof is the specific snark verification key that was declared when this situation was declared in mention so the point is that each side chain can declare its own snark verification key and this will provide the possibility for any side chain developer to implement his own logic that is reflected by a specific snark circuit run on the side chain side and the main chain will be able to verify

the validity of the backward transfer in a totally decoupled way because from mentioned perspective the only difference between two different side chains is the is the verification key that was declared at the time of declaration hmm so i think what you described i don't fully follow what you mean with this like anyone can be a side chain and still use these zk proofs kind of the way they want like i figure isn't there some formal logic or something to this like if you're doing recursion don't they all have to do recursion in the same way maybe you can elaborate yeah absolutely okay let's start from how a side chain is declared dimension what does it mean declaring assassin so we can declare a sign from the mainstream perspective

with a specific kind of a transaction in this mentioned transaction you have a situation id that will be the unique identifier of this session and you associate simplifying as an arc verification key for this side chain and this narc verification key is reflecting the rules of that specific size okay so do you almost have like on the main chain a way to program your verifier is that what that is in a way it's like it's a utxo model i believe so it's not like it has programmability the way ethereum would but that are you offering this little kind of piece on the verifying side where people can plug and play which

kind of snark they want to use a little bit or i mean the proving system that we are using and and maybe we can even expand it later it's always the same okay the point is that uh if you give the possibility to a situation developer to declare when it declares the sighting also the snark verification key in reality you give to him the possibility to implement the citizen rules however he wants because from the mainstream perspective the only thing he knows the mainstream knows about the side chain and has to know about the side chain are the backward transfers how to validate these backward transfers because what is happening on the sidechain side i mean

stay on the sides and stays on the sides inside okay maybe you should define what these rules are because maybe i don't understand what you mean by rules like what are different rules of side chains like i actually don't follow that is it like are they like domain specific or something like that exactly like for example you can have a car registry as we mentioned before a car registry sidechain that is something that a specific transaction for exchanging the ownership of the car and you can have specific rules there that prevents someone for doing something without having some information or whatever okay or you can have other kind of situations that have totally different rules can you give me another example actually of another side

chain and like what those rules might be because then i can see what that means so for example we can think about a real estate tokenization section where you transfer the ownership of other kind of objects that are not cars for example and so where the rules can be totally different uh for example the kind of objective that you're managing in a car registry sergeant are cars so in a unique transaction for example we want to transfer both the ownership of the car and the amount for paying for that and you have a sell order a buy order i mean there are domain specific verifications that are

specific for that application and so this is what i mean for specific rules i want to go back to this though what is the example of another one like the car example i understand but what's another rule set that would need to be proven i just i'm trying to figure out like what part of the rules change like would it be something like a stable coincidence okay so then there i can imagine like the entire construction is there's that exception it's pegged to something when you move things around there's like all these other correct you know aspects to the transaction okay so that that's what you mean maybe by rules like the rules in the side chain could be quite distinct from one another and the

proving system's the same but like what changes in the verification on main chain for those two examples the coolest thing is that it does doesn't change anything okay just the snark verification key changes but when you say snark verification key what does that mean is it the type of key is it the number is it like does it have a specific like private key kind of key or is it like let me say when you have to verify as narc proof you verify it against a circuit i mean something that reflects the rules that you want to enforce yes and on the very fire side you have a verification key as an arc verification key that reflects that rule so if you if i create a proof for

some some kind of rules i will have a specific snark verification key but when you when you say that do you just mean like you get a different key but it's always the same string or is it like a very different thing is it a much more complicated key in this case let's say a key is a set of bytes uh yeah oh it's still bad okay i thought maybe it was more complicated okay i mean you can see it for example the public key private key yeah no i under the proving system is the same so from

the maintenance perspective the backward transfers coming from sigen a and session b are verified in the very same way okay the only thing that main chain will have as a difference is the verification key is the narc the smart verification key that was declared at the time the site chain was declared in engine in such a way you will be able to add the possibility for developers to let mention know which kind of rules are behind that specific section without having even mentioned not knowing what are these rules because they mentioned just know the verification key that's not verification key

that would that would verify whatever's in those circuits exactly if it's acting correctly i guess you're always looking for correct action okay exactly because when we saw it before if to verify a backward transfer you have implicitly to verify that the whole history of the transfers that happened in that section okay and so if you have different kind of sites you have to verify different kind of rules and this means that you have to associate a different verification key is not verification key and dimension and this is the way we allow developers to customize different applications okay now i have a question who makes the proof and that's another like is it the forger you said there's no agent right there's

no other so i'm curious now what is that the first option would have been to have the forger producing the proofs because we have to create a lot of proofs because we are providing a proof for each transaction but remember we want to end up in mention with just one proof yes it's funny when you do snarks and like can you do a merkle tree of snarks correct like a dark snark snarks i think that's actually how mean is built too yeah perfect exactly and so let's say we have to provide i mean simplifying one proof for each transaction that proves the transition of the state no but let's say for a block we want to

provide one unique proof so you can have the forger doing this work but using such kind of approach the other forgers will stay idle unless they are working on a specific block okay you can't have them all forged the proof at the same time i guess ah you had to have a protocol for them collaborating and this is what we did so we created a specific incentive scheme for creating a market for provers okay to work in parallel and work in part and producing proofs and having let me say a reward for producing proofs and also having a market for them competing together to provide the proof set

let me say at the fair price and so currently the proofs are created by these disprovers in a decentralized way and also the merging process is done in a decentralized way and there is a a specific let me say incentivization scheme that also is part of a of a paper that we just published that describes in details how this model works what's that paper called i mean it's a the lattice incentive scheme uh white paper and um and goes into details about uh disprovers how the marketplace is working how you have them competing together and so i mean and

how also you organize this sounds weird but how you organize this decentralized work to also reuse the proofs that were not able to be used in a specific lock so what's the issue usually you have a certain block rate in a in the side chain or in any blockchain you have a certain block rate and if you assume that you have to provide a specific proof for for a block and all the transactions within the block are proven and has to be merged in a single proof could happen that some provers were working on something that were was not able being included in in the final proof for this block

okay so we even created them uh let me say an incentive and a mechanism to incentivize the net the next forger to reuse the same order and uh to be able to reuse the proofs that were created for the previous block so i mean there are many details also behind it that's interesting when you're talking about this larger construction this main chain all these side chains it sort of sounds a little bit like it's a sharded block chain and i'm wondering do you think about it that way or do you really think of it like like maybe as another idea is like do these side chains live forever or do they like pop up die like that's that would sort of define maybe how how sharded it is i mean situations can can leave forever

but also can at some point if the application is not used anymore and they can die so from that point of view it's a it's a bit different no and so these are applications that are proceeding in parallel and have a way for interacting with the mansion but they have their own life i have to say okay i mean but that's i mean if you look at some of the like even the the eth1x roll with all of the roll-ups it sort of mimics a little bit of sharded system with these like you know domain specific side chains that interact but it sounds like you don't think of it that way you don't think of what you're building as sharded no not exactly i mean okay is there any

communication between the side chains in your model other than through the main chain apparently we haven't yet defined a specific protocol for communication between the side chains but this is something that we are currently taking in consideration and and we will like to expand the protocol to specifically rule this uh this kind of exchange one other question about this like given your use of zk snarks and the sort of recursive snarks like are these things all private too is privacy the thing that you're preserving here or is that just the proof mechanism between the two things we're using snarks as we are who have described them here for the protocol itself yeah but

we also use zero knowledge and snarks inside the sighting for example for providing privacy for data and there is a specific example we're working on where we use on a sidechain zero knowledge to protect privacy uh of of transactions and data for a specific use case if you want we can go for it yeah actually i'd be curious to hear that because that's sort of it you know we started this conversation learning a bit about like horizon being somewhat of a privacy project with the shielded account model so yeah i'd be actually curious to bring that back like how is privacy kind of reincorporated into this scheme that you have

developed we extended the privacy concept for for just transfers of of of money to also privacy for data and and we envision side chains also a way for developing the centralized blockchain application but also preserving the privacy for the users in terms of data so one of the specific examples we are working on is for celsius where we are creating a specific site chain that is has to provide a proof of having received a certain amount of funds so we have a side chain that is i mean the consensus is enforcing let me say a snark friendly version of the bitcoin blocks let's say

and then we have zero knowledge proofs that proves that there were a set of transaction happened on bitcoin that led to a certain amount of funds without leaking the information about the transaction that were behind these funds and the blocks interesting this is a bit like this selective disclosure idea of like thresholds like proving that some amount of funds exist somewhere without revealing what they are but in this case you're what you're talking about is a side chain to horizon talking to a bit or looking at a bitcoin account huh correct okay and the coolest thing is that there's a public blockchain exactly and the current thing is that i mean bitcoin is not constructed in a snack friendly way so we are keeping let me say these these two things together that the version the

snark friendly version of bitcoin block and the bitcoin block uh with the consensus and then we use the snarks and zero knowledge to let me say hide the information about the transaction that were behind the funds that we are declaring that's an interesting use case so you mentioned the lattice side chain you kind of gave us a brief description of that but now i i want to bring now privacy into that context is there any like you talked about a snarks marketplace does the snarks marketplace interact at all with the shielded assets currently not okay currently is not meant that way is end is not structured that way it's something that is interesting uh i mean for for

additional and next improvements and would lattice itself be a unique side chain or is it is latches something that would live across all the side chains uh we can see laddus as the model and a specific size and model that can be extended with the specific logic for for the sizes so and also from the development perspective we are developing an sdk and a side chain node let's say that implements all the basic functionalities i mean nodes functionality the forgers the basic consensus rules i mean the proof of stake stuff the creation of the proofs um the base the basic circuits i mean everything that uh is covered by

the protocol and then on top of these the developer can add his own logic and can customize also the circuit for covering the specific rules he had on that specific section so the lattice model is covering all the aspects that are also implemented in the in the sdk and on top of it you can add your own specific logic where does the marketplace live is the marketplace just like a separate thing is that even on-chain or even on-site is off it's off-chain it's off-chain and you have these nodes that are uh how to say the kind of connection for exchanging the proofs is the same

as decision notes but in reality these kind of information are running off chain i see okay so it's like a web to marketplace not really but like we can think of it like there's no blockchain aspect to that it's just people being like we want to run proofs and make some money exactly and so if they have some computational power that they can use i mean they they will be provers and they will be rewarded for for being approver okay do you expect though like the behavior to be that a minor is a forger is approver like do you expect individuals to run all three of these usually probably yes okay like what's the requirements to set up one of these provers um currently we also optimize the proving system and

maybe we'll cover later about the proven system but uh just to answer briefly here we optimized it to use a gpu and so if you have gpus you will be able to let me say provide the maximum speed and in producing the proofs and it will be the the most efficient way for being approver well so you did mention it what what are the proving systems that you're using okay and and i think we're actually close to the end of the interview but i think there are there's going to be some listeners who'd be interested to hear a bit about this okay so just a couple of words about it so as we mentioned we need a way for uh compose the recursive proof in a in an efficient way you know

and so at the beginning we took inspiration from koda at that time now mina let me say that we was using a full pairing friendly uh cycle of cures but we saw that the performances and they saw the performances were not enough uh and so we started looking at other possibilities and we also looked at what halo was doing uh and so hello you mean hello here oh yeah yeah sorry and in terms of deferred arimatics accumulators and so on and we wanted to use uh r1cs stay with r1cs and this was one of the reason we decided to go on

with something a little bit different so we started from modeling from the modeling proven system and we started working to make it uh more recursively efficient by introducing this i mean some of the same concepts that hello did but also with addition of other parts interesting and so uh we created a a specific proven system based on modeling and uh we are currently formalizing it in a in a new white paper that will be published quite soon and we are also already developing it uh because i mean we will need in the next delivery cool so yeah what is the timeline on this

we've talked about like three things basically in this interview zendoo the lattice sidechain and this new work um we can share links and papers potentially to the first two you have a new work coming out but like are any of these built this is still conceptual like yeah how far along are you and what's coming up okay we target to release dimension modifications that means the full then do support in around a month and so we already developed all the changes in mention for uh the interaction with the site chains and so on we are almost at the so this is like may june 2021 you're thinking exactly exactly within the same year we we will also finish the development

of the system sdk and the whole proven circuit and and the full proven system recaster proving system and so this this will be the next delivery but from the proving system perspective uh the verifier is going to be included in the in the next delivery i mean in one month and what we are finalizing uh from the province system perspective is uh the prover side that will be part of the next delivery of the sdk did you stay with marlon in the end or did you switch to something else after that you sort of said you started from marlin uh we stayed with marlin but with these modifications for making it

uh recursively efficient no okay so we applied for example the third arimatics accumulators and and all this stuff to make it uh recursively efficient will you be running a trusted setup then or will you be sharing a trusted setup because there's a bunch of other ones running too you can take parameters from someone else maybe we choose to not have a trusted setup i mean to go with a proving system that doesn't need it especially because we we want to give to the site and developer the possibility to customize the circuit uh freely without having to run another

trusted setup so this was another uh important part of the um although couldn't you just make it like universal how are the parameters generated for this in the first place uh i mean we we have to also take in consideration that we needed a recursive efficient proven system and for this reason also uh we couldn't stay with some other proven system i mean for example with pairing friendly curves and so on and so for this reason we decided to go with marlin and and let me say make it more uh recursively efficient then we would have stayed then with something that doesn't need a trusted setup i always thought marlon does have a trusted setup like i know projects where they're using marlin and they still have to do

phase one of a trusted setup maybe not the full thing but they have to do like the powers of towel uh i mean the kind of commitment scheme that we're using doesn't need trusted setup i see okay got it what is the commitment scheme then it's the i mean the polynomial commitment skin what is it is it known uh yeah it's known i mean it's a it's a well known polynomial commitment skin that is the d log polynomial commitment skin that we're using okay and most of the projects are using like this kate one i guess exactly okay so yours is yours that's where the difference is where you don't need to have a trusted setup correct is there a trade-off to not having a trusted setup i mean there are trade-offs because of the of the

performances i mean this is another important part but we needed to have recursive snarks and the problem is that the currently known full pairing friendly cycle of curves have a huge field size and these lead to poor performances and so for this reason we couldn't stay with a full pairing friendly cycle of curves and then uh we moved uh to something else sounds good well listen thank you so much for coming on and and letting me explore this kind of news like i in my mind don't exactly have like a

comparable model to what you're talking about so this has been quite interesting to explore yeah and good luck with all of the work you're doing on the new proving systems and the optimizations there and yeah launching all of this stuff thank you very much it was a pleasure staying here and we'll for sure add some links to this in the show notes thank you i want to say a big thank you to andre the podcast producer and henrik the podcast editor and to our listeners thanks for listening [Music] you