WEMIX Kanvas : EVM Equivalent ZK Rollup for dApps by DJ Lee

Transcript

light scale today I'm going to introduce vmix canvas that we are building to solve the blockchain scalability problem it is a lot of based ethereum layout platform so let me start video shield introduction video about remix canvas [Music] thank you [Music]

[Music] foreign [Music] [Music] [Music]

foreign presentation at first I will simply talk about background then I will introduce our development strategies and I will describe protocol details including decentralization strategy finally I will present current status of the mixed canvas and future roadmap I've lived there a lot of you have

thought of blockchain mass adoption to make more people adopt blockchain scalability programs should be solved if the real Network have bleached its throughput limit it's about just one million transactions per day they all have been Multiverse to solve these problems such as shutting slide chain plasma and so on some of them can be grouped into layer 2. layer 2 solves the blockchain through the mobile separating execution from consensus layer 2 rolls the fees and hires the throughputs while inheriting security guarantees of idiom finally Builders can expand their projects into new

applications with improved user experience there are different types of layer 2 Solutions such as plasma State Channel validium virus and so on we are not going to compromise security and decentralization to get more scalability therefore load up is the only practical scalability solution for us there are two mainstreams in Lotus optimistic and decay optimistic load-offs are more widely used because they are evm compatible but they have the late finality in opposite TK roles have faster finality but their

evm compatible and this makes it harder for Dev developers to join the ecosystem to solve this problem several teams are building CK ebm but it's not enough because it still takes too much time to generate proofs according to alter bed total values Latin or layer 2's is more than 6 billion dollars as shown in this figure tvl of optimistic loads is about 90 percent of l2s although table of gkologies increasing still optimistic load-ups dominate the Health Market

from this it is clear that keeping usability is very important for the successful successes of load-ups these are key features that we Define for our system security decentralization low fee High throughput event compatibility First Response and first finality we designed remix campus 2 include these features our philosophy plays on important role of determining many things like development strategy before talking about details of remix canvas I'd like to mention our philosophy the first one is programmatic I think

it's time to make a layer so we mainly focus on making something that works properly for the real use cases adaptive there are so many great contributions to the blockchain technology we adopt them make it better and finally share it to the community again user friendly we are always keep in mind that we have to provide the best user experience following the philosophy we adapt various best practices from existing projects such as optimism arbitrum scroll and so on optimism is one of the widely used optimistic loadouts optimism team have

operated optimism Network more than two years recently they have they have been developing optimism better it has inspired our team so much so we took many things from optimism better modular architecture load up and derivation processing and P2P this makes it possible to bring lower fees higher throughput and faster response options interactive fault proof is very efficient we adapted it to our ZK fault purple mechanism scroll is contributing to the Decay VM so much in conjunction with ethereum foundations we basically started with

their ckvm therefore we will have first finality in remix canvas and even equivalence based on those foundations we added our original ideas to make remix canvas at first we have tried to use tkp to roll us in a way that is practical so we begin with The Optimist model where fault proof is implemented with tkbm we call this kind of fault proof SDK forth proof at this stage Decay proof is only used to resolve disput challenge because we have not yet optimized CK proof

generation sufficiently after optimizing TK proof generation we can move to even equivalentical models we designed a smooth transition mechanism from optimistic load up to GK roll-ups decentralization is one of the important problems we have to address we have been designing and implementing remix campus where validators and proposals can be easily decentralized okay let's look into more details about remix canvas Network participants load up and derivation process about how we mix canvas handles the

parties with rewards and transactions there are two things that I'd like to introduce how TK proof is used in remix canvas the one is Decay fold proof for Optimus to load up and the other one is Decay proof pipeline for TK world there are three types of participants in the women's campus Network users proposals and validators users can deposit or withdraw transactions on Earth by sending data to a contract on ethereum mainnet users can submit arbitrary transactions to proposals just like the layer 1.

proposals accept users obtain transactions and observes on chain transactions usually on chain transactions or deposit events proposals can consolidate both kinds of transactions into Ultra Health blocks with a specific Gathering validators derive L2 Chain by reading data in L1 chain there's verify the integrity and also checkpoint if there is any invalid all solutions validators can also submit dispute challenges on the invalid all solutions regarding the network participants there are some difference between optimism and

ux canvas first of all I changed node names from console to proposals and from verified to validator I think this is met this match as well to the participants of layer one this makes in more natural to lose layer 1 components in the similar way and optimism consoles not only submit patches but also checkpoints on the other hand in a mixed canvas proposal just submit patches and validators also take points by changing like this validators can receive levers from checkpoint assertions as well as dispute challenges

consequently I think this reserves verifiers dilemma let's see how else blocks all load up to everyone by a proposal Health Plus are built with L2 transactions from mempo at blocks have reference to the iron block so that departs transactions in the iron blocks will be properly included in the health blocks later as soon in this figure around deposits are stored in the first L2 block just after the L1 block L2 plus are more frequently created than L1 for now LT blocks are created at every two seconds so several antiblocks are

encoded and compressed into a channel then the Earth channel is split into Channel frames so that each frame can be stored in a single iron transaction a validator can lead Channel frames for metal blocks as well as deposit events then the validator can reconstruct a channel from this data and finally LT blocks can be built from the channel and deposit events read from everyone these processes are managed by multiple components it's also like the L1 the execution engine manages mempool builds out to blocks manages States and solves our personal requests from the user

the lotto node locates to boot the world knows it has to build a block to the execution Engine with proper payloads the better manages channels and channel frames and some meet Channel frames to a loan Network validator leaves frames from iron blocks and delights LTE blocks Toronto uses engine IPS to build Health blocks there are some complicated issues that we have to consider when we Implement load up and derivation processes but I skipped them in this presentation okay let's see how we mix canvas handles

deposits then L2 transaction with these compounds at first users submit deposit transactions to layer 1. watches deposit events and creates payload attributes with deposit transactions API so that the execution and creates a block with the payload users submit to transactions to the execution engine then the submitted transactions are included in blocks when the low number calls ends in apis the better get the latest block cache from the law of node and then release the block body from the execution energy then the battery submits blocks to the bets inbox in L1

validator gets blocks from bits impacts and transforms them into LT block inputs then the lotto node requires to create blocks with the payload to the execution engine the validated components get the latest checkpoint output from the lotto node the validated component submits the output to L2 a product contract at every 1800 blocks with two seconds block time it is an hour Apple loot is generated with the person type and payload same version number means that the structure of a payload is the same in the current version payloads are made with State loot with royal storage unit and latest block caching

our pollute will be used for compounding withdrawal from L2 to L1 for users to withdraw his asset from L2 to L1 he has to serve in a withdrawal initiating transaction to L2 contract first then a proposal Dot post batches with withdrawal transaction data to better impacts a validator gets the Bloods and also on output that contains withdrawal commitment the user needs to wait until the plug is finalized after blog is finalized then the user can request to finalize the withdrawal to the bridge contract Bridge contract verifies the transaction

with our pollute by checking if the visual storage route contains the withdrawal data if the transaction data is verified the user finally gets his asset these figures choose overall architecture of a mixed canvas without these challenges currently we are using modified co-edrium as the execution engine therefore built-in peer-to-peer Network and transaction pool is used to propagate transactions the same network is used to provide propagate summative submitted blocks and support snapsync either increase Bluffs at every 12

seconds but canvas trades at every two seconds therefore there may be on submitted Bluffs in the Pro in The Proposal those on some limited blocks are called as unsafe blocks they are propagated through another peer-to-peer network of loramnose using those two peer-to-peer Networks execution and can respond to user requests with low returns at every node until now validators only act as an oscillator now let's see how validators act as a challenger let's assume there is a faulty output that is provided by another validator that is an also term

at first the lotto note of this Challenger gets blood data and transforms the data into altitude the alarm node called an engine API with the payloads then execution and build block this validated components leads on output from the L2 up of Oracle and also raise the corresponding local output from the execution engine then compels them if the ulcers an output is different from the local output the validator submits dispute challenges to resolve the challenging the validator first need to find well the difference starts from at a single block level after finding the block the validated component request to generate a Decay

proof to the Decay approver the GK approver gets exception trace for the block from the execution engine and generates a Decay proof the validate component sum is to proved to the L1 contract then the Decay TK verifier contract verifies approved if the proof is verified the Challenger wins and gets the layers if the proof cannot be verified the Challenger lose and his take the assets will be transferred to the elseorter let's see more details about these two parts when identifying a faulty output we

begin with the two checkpoint outputs the first tech checkpoint output should be the same to the challenge local album between those 1800 plus there must be an initial block where the challengers up then the Orthodox output are different The Challengers get to know the initial block position by interacting with the also who submitted the voltage checkpoint output at first the challenge submitter 46 are produced that evenly dispute distributed between these blocks to his local outputs and finds the first

different output then there are sort of old outputs between those blocks again the Challenger Compares those outputs to his local outputs and find all these different blocks then the Challenger generates a proof that shows his output is valid and submits the proof to the Colosseum contract finally this figure shows the state Transitions and the Colosseum contract the Challenger starts are challenging by staking his asset in a checkpoint light Afters taking his asset the challenge

submits output segments and our assorters should respond to within a time limit in Most states there are some time limits so that the challenge processes ends within the reasonable time in the previous example the faulty the 40 block was found with just two interactions but there may be more interactions with different segmentation schemes interactions must be an even number so that a challenge can start the interaction and submit the proof after the also to turn we tested several segmentation schemes among them these five nine eight nine segmented scheme consume the least gas

oh we inherit ckm of either foundation and scroll to reduce the probing time we use a TK try instead of a vocal Patricia tray Who is Poseidon has instead of keka and CK tried to compute the path to account or storage slot we added additional specs for layer 2 such as Auto deposit and load of gas P processing this shows the circuit structure there is a super Circuit that invests many circuits designed for the specific purposes

with this public inputs and this private input we can obtain a block proof circuits are not fully implemented yet but I hope it will be finished soon yeah this is the previous architecture without challenging now we have the full architecture those are additional components to use general knowledge proof and optimism load ups and TK logops we mixed canvas have TK friendly data structure enhancing schemes from the initial stage therefore even though we start from the optimistic a lot of we can move to

tklore without heavy migration process approvers they also take pointer outputs with the TK proof okay let's see proving pipeline once a Blog is created approval will generate a proof for the blog while plots are created at every two seconds generating a proof usually takes much more time so multiple approvers need to generate proofs in parallel at the same time and this figure except the first proof others include previous proof in their Pros then the checkpoint can be verified

using only one proof created proofs will be propagated among Proverbs through the peer-to-peer networks of lorm nodes if we submit the checkpoint with Ros interval rise public input should be addressed to verify the proof if we submit the checkpoint with a small interval the cost to submit checkpoints will get higher therefore when you move to GK roll-offs we need to determine the proper checkpoint interval considering this trade-offs if we reduce the probing time sufficiently we can move to GK log there must be a coordinator for the transition

and this figure from The Blog pi plus K the checkpoint output is verified with the proof after the challenge period the blood talk can be considered as a ZK row without any further changes there must be more issues that we have to address this is the basic idea how we can Transit from the optimistic load up to the TK world there are two types of decentralization in remix canvas validator decentralization and proposal decentralization at the first Pace we are focusing on validator decentralization

I mentioned before validators can get levers by asserting checkpoint as well as challenging invalid checkpoints this will motivate node operators to join remix canvas as validators we are finding proper parameters for the stakes and levers for now we are going to use trusted execution environment when we adopt proposal video separation I think this is simple but can support strong censorship resistance and blocks and maybe abusing currently we are researching in conjunction with external research teams for this issue

I hope we will have practical implementation for this in the near future there are many challenges that we have to address the first one is gkp optimization which is what we are focusing the most at this moment we are using possession and GK try this make execution engine work slowly so optimizing execution engine is another important is we have to solve we need to modify our components according to the Prototype prototank sharing and I already mentioned the PBS just before

we support or contact abstraction and we mix canvas as soon as possible this is our load map we have finished the POC and now we are preparing to open our public test net within a month at this time there will be a single proposal and multiple validators operated by private members the cabin will work but not cover all the specs yet various of full peer-to-peer propagation which means you can have fast response time at every nose I hope that we have an even equivalency

camera in the next year yeah you can visit this site to see our teaser and you can take our source code in this GitHub soon and we are going to provide full resources when we open our first test lab thank you for your attention do you have any questions yes thank you I'm sorry

you mean the test test timeline mainnet yeah we are playing the third quarter of this year but it starts as an optimist tomorrow I'm sorry I'm actually we are not have any plan to issue tokens for this layer too so thank you have any questions [Music]

[Music] [Music] foreign

[Music] [Music] [Music] foreign [Music]