zkAcademy #5: Understanding zk Layer 3s & Unified Liquidity with zkLink, presented by Union Build

Transcript

[Music] [Music] [Applause] hi everyone this is Vince from Z link I'm co-founder of Zink today is my pleasure to present the new platform we're about to launch Zink Nexus the first Zer proof based multi R up layer three uh so ZK link Nexus is a new PL is

a new platform that is zkp based and unified the layer three solution across multiple ethereum Layer Two zops so what does it mean uh being a layer three layer 3es are built on top of ethereum layer two o ups and the layer two rups are built on top of e layer one and the layer 3es deliver higher scalability lower gas cost and it provides more application specific customizability for certain types of applications uh there are already some layer three solutions that you might already have already heard of before such as ZK

sync uh hyper chain stocket Madara or Arbitron orbits and these layer SES are built on top of uh stock neck s sync Arbitron their own Layer Two row up and these layer 3es will use the same Tech stock as their layer twos uh so the differ the major difference between the other layer 3 and Zink Nexus lay three is the Zink Nexus ler 3 is a unified multi ler three it provides aggregated liquidity across these different Layer Two ecosystems and it comes with aggregated assets across different layer toos so it provides users with more

trading pairs which means more trading opportunities and also it comes with unprecented flexibility um also there are additional benefits like you know cross ZK link next to SL 3 Rob compatibility when you can actually uh you know compose transactions among different deployment of layer three rabs because the essential idea of building a layer three stat you only once uh you you want the application specific L three for your own application you don't want to share the throughputs and the resources with other applications So eventually you could potentially make the most maximize the performance the throughput of the

rup setup and also there are unique features compared with other uh layer such as you know multi application recursive proof verification it's which is a new design that we propose and also a new feature like treating specific domain specific language which we call also DS DS TS DSL uh it is a kind of script that gives the application Builders more flexibility to uh build a certain product features such as copy trading such as social trading grp trading uh to build more feature R trading

applications and for zlink the solution this is a general overview this graphic provides the architecture of this is the architecture of the layer three and it is uh on this graphic you can see in the middle there are three different layer to rups ZK rups ZK evm and both ZK evm and ZK VM for ZK EVMS you have here linear and zync for ZK VM uh we have stock here and uh on the bottom is the layer three uh platform of silic link and on the very top it is the layer one of ethereum uh there is ethereum contract

deployed by Zink on uh on layer one and at the same time the layer three platform they of the ru of service on layer three commit States and the Z proof to the layer twos uh you know and then then the state proofs will be sent to the ethereum contract uh uh through the official bridge that this lay TOS deployed on ethereum and then the ethereum contractor will compare will will judge the consistency of the different states roots that the different lay tools received from the layers platform of Zink and then ter contractor will send the confirmation message back to the layer TOS in this

way the multi R of synchron state of synchronization is done indirectly uh with the ethereum contract and why is this step very importantance because any multi up or multi chain infra will have the same security challenge which is a the depos deposit fraud what does mean deposit fraud means that you can the validator can falsely inform one chain about a deposit on another chain which they cannot directly verify because uh multi chain or multi rup infras they are not able to the the different chains are not able to

directly perceive the states of another chain for example uh stocket cannot directly perceive the state on zik sync so if the validator zik link of CH validator tells the uh Zig sync contract that there is 100 usdt deposit on stocket the contract on zync will not be able to directly verify and get this information from stocket contracts instead it always relies on another a third party to tell to tell them this uh deposit information so when you have a multi infrastructure the possibility of deposit from def FR occurs and how to

counter measure this how to make sure that all the deposit information is correct on each of these chains because you have we will have all these assets entering Z links unified layer three and they trade with each other so they have the cont if you have a false deposit uh this process is done exactly as the way I explained so with uh State root that contains like you know all the information on the markco tree on the layer three and this is this state is sent to different layer twos and this layer to send this state rout to etherum contract through the official bridge between the lus and ethereum and then the etherum contractor will judge the consistency of the different states

Roots they receive it receive from the different layer toos and if the same means that the multi chain multi roll of State consistency is confirmed and in this case you can always be sure that the deposit information is correct and there is no way to do a false deposit and rock the other R up assets and this is the uh simple graphic that shows the security inheritance of any L three including Zink Nexus so the lay three uh inherits the security of the layer TW is through zero proofs and then the layer the Z of layer twos inherit security of layer one which is

ethereum which the ZK you know Z proof and in through this uh the L also inly inherits the etherum security so you can almost say that their studies are being as uh secure as ethereum but this actually has a you know a condition that l to will uh be mature and they are uh trust minimized which means that you know we will have to wait for the decentralization and the maturity of the layer TOS at this point we're still at very early days of layer Ser because the lir tools are not fully production ready they're not fully

decentralized so we still need the L tools to be more mature to you know have the uh same level of security for lers three as ethereum and this is a uh diagram that shows the Z link access protocol key components um in this in the middle you see that uh we seen the Zink Nexus protocol you have we have uh the broker surveys for liquidity uh to move liquidity to enable faster withdrawal and a move liquidity among different layer tools and also you have the server call which has you know you you there you have the executor and the approver

service and also you have the sender and Watcher and on on layer twos and the layer ones and you we have different sdks uh the de developer tools for application Builders to facilitate and simplify their development work and also we need to um call the public or private RPC nodes to be able to uh access the layer two layer ones and on top of sealink platform you will have application different types of decentralized applications uh including sport per trading rwa derivative trading nft meeting nft trading it cers as you can see from here that the application

types that we right now supporting are very much focused on trading uh there are four key functions that we uh want to highlight uh the these four different functions we consider to be very important and helpful for that Builders to simply found facilitated the dev work uh the first one is native ZK social login why is it important uh the comes with account obstruction of course and with uh with this function that Builders will be able to build the product features that you know like you know to to to allow their users to log on to their platform

uh with their social accounts with email account for example and uh the the reason we're building this are not directly integrating a third party AA service is because we want to minimize the trust assumption for this AA service for example if you today if we want to use web three authentification from a third party service provider like uh partical Network or like uh web web3 off then the these deal store the user uh the sharts of the private Cas of their users on their own service which is not ideal so you have at the same time the trust assumption on the social accounts which for example is the Gmail is your

Gmail account and at the same time you have to trust the service providers that they can securely they uh they can they can store the private keys and and you know secure this private keys but yeah this is with we don't want this additional security assumption so we want to uh develop a native s social login function which own solely did only have one trust assumption which is the social login the social accounts um we also provide your user deposit manager SDK to the builders so they can enable the function uh of deposits that matches exactly the same user of CeX which means

it's from end to end users will not not will will no longer need to have a bid address first they can generate a b address with their social accounts and they can directly transfer their funds from a CX to aex uh without having to sign for the transaction without having to buy a gas token in advance without having to you know select the chain and ZK Oracle Hub is the second key function that we develop for that Builders uh what it does mean for Perpetual contract trading for pebs especially for order book per trading you uh we always need to have high frequency low latency price

fit from oracles and if you fit the price uh each time and you do verification on the smart contract to verify the signature of the price feeds it will be very expensive because it's high frequency and so we want to reduce the cost of this verification by doing the uh uh price signature verification option and and use proofs to to to prove this verification process and then send this proof together with the price V onchain and then the onchain contract just need to do once in instead of 100 times uh so this was significantly save the cost for uh per aut book trading

products and this feature also uh provides enhanced programable price filtering function to the DAT builders for example with this aggregated the price then the application Builders will have the uh possibility to to enable some features on on on this price phase they to protect their Traders this will be very effective and um helpful for uh smaller uh fdv tokens when you we often see um radical price fluctuations and then the that Builders

can enable some certain you know price features to say let's a filterate the extreme price fluctuation to protect the trader under certain kind of extrem Market condition and this provides higher transparency and higher stability to the to the per markets on you on these taxes uh the third key function is the Adaptive liquidity rebalancing uh why this is uh needed this adaptive liquidity rebalancing is certainly not needed on a l three that is deployed on the single row up but if you have a layer three deployed on top of multiple layer toos then you have liquidity

movement from one layer to another so some of the time you will see for example uh you know user funds or liquidity is moving from for example stag it to zync or the other way around and then you the the the users that want to uh withdraw the funds to zync will have problem because there might not be enough liquidity there then you need to rebalance the liquidity the total sum of the funds will be equivalent but you can have more one more much more funds on one change comp or one layer to compareed to another one so that for for this types of need is we provide rebalancing tool for multiun tokens such as ethereum such as Stables usdc usdt or

other Alo Stables that are Deo native on multiple layer tools function is liquidity broker service this is uh very important for user experience because for any zabs any Z Zab Layer Two or Layer Three is the finality time uh although we believe that the finale time of ler TOS will be significantly faster with the maturity

with the progress of ler to as a whole but still they might take you know hours to verify onchain to batch to batch the transaction and generate proof and verify the proof onchain but what if a user want to ex their funds to layer one more quickly than that uh quicker than that then you probably want to have liquidity broker that can transfer the funds to you once you make the request and then they the Brokers will can wait for uh the verification to be finished and they receive the phones back from the smart contract with these four functions uh we believe that we will be able to greatly help our

developers and to simplify their work and save their cost development cost and save their time and this is um also one important feature of the architecture zlink spl3 platform it is it comes as modular solution to which means fast and a flexible integration uh there are two aspects of modular solution cability uh one is the customizable data availability deployments uh we uh as as the L is deployed on across multiple L tools you can choose one of the ler TOS as data

avability there or you can use external data avability like youda or celesia or you can also you know organize can organize their own data Avail uh committee D daac or they can you know choose to certainly put uh poster da on ethereum this totally depends on the type of application that you're building and also depends on the cost Effectiveness that you want to have and for business reasons you could you know have the DSC or you know could there's a you know external modular da layer like cesa da

although they are slightly more expensive than DSA and then you have ultimate DS solution ethereum which is the most cons which is considered to be the most secure one most reliable one as ethereum full nodes are Mo most decentralized and also the second aspect of the modular modularity of uh the L three platform is the customized Network CLS so some application might say I want ethereum I want znc I want a stocket I want Linea I want Tao I also want polygon ZK evm I want every zkm zkm available from the market yeah that's fine another type of application which

is maybe more focused on a demographic region or focused on on a different group of users they may say Okay I I only want stocket zik sync and and scroll why not so you could have the you know uh one to many any collection Network Collection as for your business use case and for your uh specific needs uh the zig link LL platform has done a lot of work uh to provide enhanced the performance to the applications uh there are few key points

that we have listed listed here the first thing is the posidon hash adoption uh posiden hash um as a new hash function provides extent performance and the security and it results in Faster hash computations this is you know relatively speaking compared with uh secure hash that we used to use in our uh implementation and the second is optim mation we've done is uh circuit disc cuter refactoring uh we've done quite many EX extensive optimization and refactoring of the xero circuits uh that we develop that because

we are application specific platform the the approach that we're taking that we write the circuits for each of the up codes needed for the use cases that we aim to support so the circuits need we we are uh spending a lot of time and efforts on the optimization of these uh specific UK application specific circuits and the third point of our optimization is the parallel processing Innovation we uh have done some deep work there for the server core to be able to paralyze the process processing of ordering the there

and accelerating a winess generation maintaining efficiency during High transaction volumes and also we are doing currently we're exploring the possibility to implement the uh new proof system uh we have done internal Benchmark work with uh Nova hypernova and Supernova the folding schin is very interesting for our implementation because our circuit is a midsize circuit compared with uh type two or type one ZK VMS that's for One op code uh our circuit is actually slightly bigger compared with the up codes on Z EVMS but

at the same time the total scale of the uh Z Circuit of Zink is significantly smaller compared with Z evm because for ZM you need to be hundreds of op codes but we only need like 10 20 op codes for the use cases that we support uh we are were actively um contributing to the uh Nova implementation because were still early there are still there still needs to there are still a lot of work to be done there we will open source of work once it's ready this this is also something i'

like to talk about which is the multi application recursive proof verification um why this is needed and why this is interesting because it can signicant significantly reduce the cost of the verification there not proof verification on chain uh there are two parts M there are mainly two parts of the cost when you operate a ZK system uh the proof generation and the proof verification oh actually the proof verification together with the da so you could also say that there are three parts proof generation proof verification and da and here we consider the proof verification together with da

with the data we post down chain and for the uh for the opin part the proof generation part by our estimation it takes roughly 30 maybe 20 to 30% of the total cost of the operation operational cost of ZK and the O cost the da and the verification takes another 70 to 80% which means that the oing cost is still more is is still higher than the option and cost so we think about we think a lot about how to optimize the cost the of the verification and also the DA for

the da cost as I explained there are different types of imitations and the deployments possible for different types of use cases for defi they probably want to post the on ethereum or maybe another you know slightly make like you know another solution that is not as secure as sa terum but it could be very close to ethereum like like in da or uh you know a new type of application maybe nftd Trading or a gaming platform that has game game asset lot of game assets might not need as much high level of security for the da that they probably need more like you

know rraa activity from their for their assets rather than you know to reconstruct the full State of the State trade uh of chain then um for so for the da you have different solutions to mutative diverse demands to reduce the cost to find the best balance between cost and the security you want and for the Zer proof verification if we will be able to bring down the verification times in total then we'll be able to bring down the total cost of proof verification to operate the system and because each of the verification takes roughly the same

amount of gas consumes roughly same roughly the and moment of gasp so if we could do less uh verification Times by uh use using recursions recursive proofs um this would be uh very interesting for any types of application that be able to use this so on zigging uh Nexus platform we are Implement implementation the Mr MPV multi- application recursive proof appication designed by ourself and also we will be providing a

developer friendly treating specific DSL domain specific language with it comes with uh a lot of benefits in such as improved efficiency so uh the the traders that want to have certain type want to do certain types of Trades will be able to you know do Alo trading copy trading great trading and this will unlock uh new types of user experience on dexes which we have never seen before and it also you know empowers the Dex

Builders uh with less complexity when they you know compos the products using DSL com if you compare compare DSL with programm language and DSL is a type of script that is a lot easier to know and a lot easier to use uh so this will be more cost effective for developers and also the DSL adaptability makes the Strategic trade more flexible and more cost effective for the Traders and the Dex dep can Implement complex trading strategies with thist s DSL uh I've been talking about the

technology and implementation a lot uh right now I want to talk a little more about you know why we're doing this why we're building a unified lay stre platform across layer TOS what are the benefits why would uh developers care about this layer three platform I would the users care about this uh ler three platform the benefits are many but out of the many benefits the most important are still the the the cor vision of aul Link we want to empower the next generation of products with the best user experience possible

that can match and compete with centralized platforms when you go to balance when you want to do a on balance you don't really think about you know which chain you are using right you make a deposit to the platform and then then you buy alien token that is listed on the platform and then you probably you can park the funds there your you can withdraw funds to a chain or to another wallet uh through many different chains for example you can make a trans transaction of stables through three or four different chains uh the user experience has been very intuitive but the user experience on taxes nowadays is still very broken but with

the zinks uh unified PL L three you developers will be able to list the token across multiple rups and enable the trading of this native assets there's no roing process of these tokens as these tokens are locked in a smart contractor then then um Mar to the layer three platform through the Zer proof uh they system uh this is not only for funable tokens but also for nonf funable tokens and FTS and this will unlock um more abundance trading opportunities for the users on daxes and also uh you can a user can

manage their portfolio of their moding token portfolio using one wallet unless unified user interface is and yeah uh another important aspect of this solution is that uh this unified l s will be much needed as the liquidity fragmentation becomes more of a problem when layer TOS grows bigger than today uh each of the L to will have their own liquid system and will have the users and users go to each of the L they they will need to bridge your funds over and the the more layer tools the more WS we

have the more liquidity fragmentation we're going to see and the liquidity silos on these rollups needs to have uh you know when you would need we would need either we use caution bridge to move funds liquidities uh among these different tools or alternatively an application can deploy um zing three and access to the liquidities on different layer twos uh so this will greatly simplify the user experience because any user can enter the L3 directly from ethereum or they can enter the L3 from any Layer Two and once they

enter the once you know the the the use different users from different ecosystem enter to the LPL platform you have aggregated liquidity on one un on one unified platform one unified user user interface uh for the tokens that exist on different multiple chains or multiple rups such as Stables or ethereum uh the tokens enter in layer three from different layer twos will be merged to the same token uh just as shown in this graphic right and so the liquidities are merged to a single token and you have like deeper liquidity on this SLE trading pair uh think about you

know the daxes that uh of today if you bridge a token from bin for example to ethereum it will be a different token because you it is robbed and by doing so uh Z GL platform will be able to unify liquidities of these staes or maraging tokens and also aggregate the liquidities of from different types of assets and by Theory we hope that the next generation of dexes will be able to serve millions of Traders will on board millions of Traders and the more liquidity you have the more aggregation you have the higher Capital efficiency you can have there on the Dex uh so the conclusion here is z want

to be the for to cross through layers fle to unite the etherum L to ecosystem to help on board next billion of Traders on chain if you want to learn more about the solution and the platform uh you can Al you can visit our website and go also you know follow our Twitter there will be up to-date information about the new exciting launches of different features that I just discussed here H thank you very much very good Vince thank you so much uh for presenting this is uh very information it kind of like opens my mind to the

mental model of the Omni chain that I think we heard about for you know quite a while as like some of the layer one started to pop up um and then we kind of continued to fragment the block space a little bit further with layer twos now even further with layer threes but then we're getting these interoperability solutions to link them all together um I'm curious in general like is ZK link the the Omni chain mental model h i I guess I'm curious in general how do you how do you picture this block space do you think it continues to fragment or do you think we continue to we continue to unify it what is your mental model for Block

space uh it's actually a very good question um there are Builders uh want you know a lot of Builders you building new layer tws new rups we're probably going to see hundreds even thousands of news uh in in the next few Quarters at the same time we have another group of builders that want to combine and Aggregate and unify these these new new rups right Z is one of the Builder team that wants to connect wants to unify uh the uh liquidity fragmentation wants to abstract the comp complexity the among these hundreds of rups right so and we

want to uh solve the problem from different angle there are a lot of teams building crushing bridge to facilitate you the user funds transactions from one CH to another one Rob to another from layer one to layer one layer one to layer two layer two to layer two layer two to layer three maybe layer one to layer three we'll see a lot of bridge for sure but for some applications that are already on layer three we think it is very interesting for them to have a unified uh environment across multiple a tools they so the this great simplify the user experience they say this save a more a few steps for user so they no longer need to bridge use a crossing bridge current cossom bridge is uh still costly and uh it's user UNF friendly at

some point and if you have the user coming from different chains on one UniFi the user interface then users don't really have to care about you know which CH they're using or which row up they're using and uh then they will be able to trade they just want to the trade this is also kind of like you know user Centric approach user user experience Centric approach and back to your question I I I think the the future of blockchain is for me is evidence that is going to be multi chains and multi rups horizontally there will be multi chains and vertically there will be multi multiple layers and and multi rups uh there will be many layer twos and

there will be many layer 3es uh more uh with more applications you know getting users uh on their onto their applications a lot of these successful applications will ultimately need to deploy their own rup and layer three very likely or the some of these will also maybe adopt some other approach like uh di idx going to Cosmos building their own application chain and we we'll see the layer three application specific layer 3s will be competing with some of these Cosmos uh up L one cap chains uh

either way think this this will you know lead to a future that there will be a lot of chains and a lot of rups and we need definitely need the solutions to address to the F fragmentation of liquidity address to the inter interoperability and know every step we simplify and save for the user will help us to acquire more users yeah yeah I was curious on this slide here um on the liquidity aggregation since since these are all ZK EVMS like linear orm yeah General purose yeah um I believe that they all

share the same kind of properties in that uh in that they use the same codebase like uh like gu and op codes and different things but there are definitely slight differences between you know linea's model and Tao and ZK sync so how do you guys from the tech side how do you guys what are you guys doing to be able to aggregate uh different types of uh whether it be op codes or uh ZK provs or for example Tao Tao they don't they're not gonna have a sequencer they've got this interesting model right um so how are you guys able to uh on the back end kind of aggregate those and build a top each different Tech stack um you know abiding by the

slight slight differences and keeping safety privacy and decentralization in mind uh thank you for your question Andy this is a great question uh so to to answer your question first the liquidity aggregation the liquidity aggregation has nothing to do with the tax stack because the tokens they have like in e erc20 the similar you know so they all have the they the same token so the ethereum on this tyo on linear on they think on stocket they are all deposited ethereum from E ethereum they are not issued on these layer TOS they're not native token on these chains so they are ether locked in the smart contracts on ethereum and enter the layer TOS from

ethereum layer one and then for this ether these ether can enter to layer three uh Zink L three and they will be merged to the to to ethereum that the total sum of the the total sum of uh you know tokens will be strictly equivalent to the uh you know the the tokens locked in the smart contract on layer one ultimately right so we don't need to differentiate this uh you know Lether from different layer twos it's the same for Stables as long as this stable is issued by the same entity for example you USD is issued by circle on different layer tools the they considered to be the same then you can directly merge

them but careful we don't want to merge USD with usdc because they are not from this entity and they have the price variation there and uh we do we do have consider lot about you know you know the stable to eliminate the disparities among different types of staes um but this is quite risky and for the second part of question is the the attack stock difference among different ZK EVMS there are four types of roughly type one two three four and also ZK VMS there are more different zms in the future and how do we elit the the differences and on different Z Zer layer TOS uh the answer is that we do not we actually build and

we WR the Z knowledge proofs verifications contract in solidity on zms and then in Cairo on stocket or there maybe a new Z new zvm maybe will come up with a more efficient new language and then we'll write the verific contract in that new language and we deploy this D Pro verification contract on these ZK EVMS and ZK VMS and we post H St the states and the post the da and the post the ver the proof to these contracts so in by doing so uh the developers the application builders on our platform will no longer to you know build uh on different layer

tools and learn different programming language and uh use different devop develop tooling exactly this is our you know part of our uh core value pration to facilitate the development work for application Builders we do the heavy lifting heavy engineering development work for them on the back end and then they focus on the front end the consumer facing Trader facing the product features Financial product design liquidity management user acquisition assets and managements and listing uh they they build the user fac user facing features they build a product that is easy smooth intuitive that users love and when and and we facilitate the work

on the back end for them we do this hard work on Zer not proof circuits zik circus developments uh you know we we build across different uh ecosystems and they just need to connect to zik link with our API with JavaScript very easy and low cost in development and yeah with that we we we think this is were very valuable for tax Builders and we we are solving the real problems that they're facing today on every on a daily basis we we have talked to quite many uh developer teams and they love the value pration here love the solution because they we solve real problem and we save cost of save time for

them certainly yeah the shared liquidity model is a win-win for all of these decentralized exchanges because they can pass Capital efficiency and better prices to the end users exactly user experience on the Dex means you know the price yeah ultimately it comes down to the liquidity and the price you can have that if you can provide the best liquidity you have the best price and then you will have for sure we have Traders amazing Vince thank you so much for for coming on I think we're we're out of questions now um I'm just going to pop up the uh the last slide here for anyone who uh is curious to check out your

website and your Twitter um again thank you so much for coming on is there any closing thoughts or anything else that you'd like to share uh before we roll it up thank you much Robi yes um maybe just one more uh s maybe a few more words on L Rel in general as we as I already mentioned in the beginning uh of my sharing that we're still at the very early days of layers 3 because now people are still talking about ler tools we're still waiting for the layer tools to be fully production ready and user ready the user experience and the cost to to to to to make a transaction on the layer two now still pretty broken right and we need we're we we still need more uh work to be we're still yeah we're

waiting for the L TOS to to be more user friendly and decentralized ultimately with you decentralized approvers decentralized the sequencers and uh with you know you know battle tested Zen circuits and then the lay s will be you know we'll be able to say that the lay s will be strictly uh inheriting the security of lay one because you know layer twos in the middle they are very important for the success of layer 3es so we are we hope all the best for this the general purpose layer to zkm ZK VMS and we definitely bullish on the future of this zkm and ZK VMS they will you know uh build uh we we we think

we believe or bullish that they will be able to build uh prosperous ecosystem with the you know technolog because there not proof s the problem of security scalability and yeah we will help to scale from their on there on top of their platform and yeah we are excited for the future thank you very much yes sir thank you Vince thank you Andy thank you Robby