Enshrined Payment Channels: A Stateless, Post-Quantum, Confidential Rollup Design

Transcript

[music] basically know I'm kind of payment guy and I'm obsessed with our how to make scalable payments uh which is private on Ethereum and I've been know [sighs] I joined the Ethereum ecosystem when the plasma research started in 2018 and you So since then I've been obsessed to how to kind of complete plasma and basically there are many many L2s are on serum uh it's been a while and 99% of L2S

are stateful network and I'm talking about stateless network uh which is a bit or totally different from Stateful networks and what is stateful Ethereum stateful and abitronum base Solana drum they are basically stateful and stateless network it's quite limited number of know product we can see so intimax is one of that and also know lightning network is one of that so I would talk about inmax 3 today. Uh this is what I want to call perfection

of stateless L2. I so to talk about inmax 3 I need to talk about inmax 2 to give you a context. So intmax 2 is also state minimize network and in academic our definition is yeah state minimizing all up and only 0.08 Z eight bytes per transfer is uh it's onchain data consumption is needed to to make um so it's less than one bit so basically say 20 makes no lot of lot of kind of 40 bytes part transfer uh and you know if it's minimize it's

quite limited result we can see but if we go stateless we can have more achievement and hard than uh we expect. So one bytes less than one bits per transfer is totally possible and [snorts] it's fully permissionless uh block producer and fully private and this architecture uh what we call client side validation plus recursive ZP. You know this combination has been followed by shield CSP or Bitcoin and plasma fold blind which is come from uh is foundation and also gashion and this

kind of set of uh trend of stateless L2 and in max 2 or in max one was the origin of that. So what about in max 3? So intmax 3 is enshrining payment channel to the stateless zolab inmax 2. So inmax 2 plus payment channel is inmax 3. What is payment channel? Uh maybe uh it's one of the oldest idea of quite simple. I have a $5 or okay, let's say I have $10 or

I put the $10 to one kind of shared account and you deposit $10 to the same account. No, this contract, this account has $20, right? And in [snorts] that contract, we decide no, okay, uh I have 11 right now and you have nine. It means that know $1 is shifted to you, right? And it means that I paid $1 in this no kind of contract. This is quite simple idea. And payment channel is know this simple. So many people uh know use this idea idea to to scale up know bitcoin and blockchain blockchain

general. Maybe some of you guys remember ride network know their idea is quite know based on that. So okay the payment channel is this kind of very very simple idea and we enshrine uh into max 2 so that we can make fully stateless or no layer 2 which consume almost zero bytes per per transfer and it has a fast finality. uh so basically roll up power long long finality when it comes to conf kind of L1 security level kind of confirmation but you know it has fast finality unlike usual L2S and yet this

time it's independent from being a payment channel we make it [snorts] postquantum and every single balance in payment channel is uh signed by postquantum signature and also encrypted get uh in in postquantum are encryption uh it's called a reg and and also we have our in China we have programmability uh which is a bit limited but we have it's kind of for conditional payments so in order to make their absolutely uh kind of completion of stateless uh L2

uh with private See uh I yeah I wanted to make it kind of final version and I don't want to make in max 4 and I I hope it's the the last version of inmax. So the construction of this enshrin payment channel it's actually quite simple. So intmax is a stateless intmax 2 is stateless or the zigilab where sender and receiver recipient have communication of micro proof uh to include it uh to to their zip circuit to prove their balances and

each account of this inmax 2 is multi-arty payment channel. So not only limited to two people uh which I explained no we have 10k people in the same channel and send money to each other. So each account is designed for that and the channel to channel the cross channel transaction is it's done by inmax 2. So existing inmax is used for kind of no yeah inter channel transfer. So imagine that like the the bank accounts know in one bank accounts know you have kind of

less uh less fees than interbank transaction right know it's a bit similar to that and inmaxu is already scalable and private but it has it doesn't have a fast finality so in inside the payment channel we have a fast finality and close channel it has kind of the one minute half final ity to to do the transaction. Um this is a construction of of inbox 3. So inside multi-party payment channel we have uh eight co-signing cluster uh means that it's uh one one uh of n security assumption and only one honest person

are in uh in cluster in this uh cosigners are protect your asset basically even if you delegate your asset to them [snorts] and so almost All accounts are delegating their no private balance to them and basically when updating uh their balance uh it should be done by clon 3 they can prove that this balance shift is totally correct uh to to clusters and they will cosign it and if when they do not agree no just No go

to L1 exit to L1 to to yeah to end it. Um this is a uh the feature we have has a multi-party payment channel. So [snorts] multi-arty the reason why we need to make multi-party payment channel is all about capital efficiency. So the most difficult part of lightning network lighting network is the network of two-party payment channel and the two-party payment channel is like like know what we talk uh last time there two people deposit to their same account and the it's meshed network uh to relay the the transaction uh with many hops

between many many uh uh payment channels and in multi-party payment channel we have a significant uh significant capitalist upgrade because we don't have to relay and we don't have to pop and in lighting network we need to pay many money separated to separated to too many channels but it doesn't happen in multiarty payment channel and so this is the goodness of the multi-arty dimension now and we can shr en enshrine it in inmax too.

So let's go dive into the detail uh you know overview yeah of that. So when okay $30 is lot is encry encrypted in payment channel and you know another person is $15 and basically it's not known to the other people uh the co-signers clusters they do not know uh the actual amount uh in lattice or encrypted uh balance [snorts] and so when I want to send money $5 to this $15 balance. Uh while I'm not knowing how it's $15, we just I

just make a no lot 5 [snorts] uh lot encrypted $5 and attach attaching PL3 proves that no this is a kind of uh you know correct transaction uh know to to add and you know it's less than uh more than Hello and the co-signers can just add this encrypted uh cipher text is to to lot uh $15 uh to make it $20 and simply because it's homorphic uh encryption

the homorphic encryption which we are using postquantum uh one is uh GB encryption uh it's very very optimized as for uh basic uh odd operation uh for and we don't have fully homorphic uh futures but you know it's quite optimized for that. So uh it's cosigned by eight people and in in channel transfer yeah completed by just know this pronry and signing communication and why

intmax tree is end to end postquantum it's simply because we are using only postquantum signature and postquantum ZKP and postquantum verification on chain. So end to end every component is postquantum and so basically inmax 2 was using uh and is using pron too and we modified that uh to to uh verifiable onchain with MLE. MLE is a subject protocol. uh know like in Nova and Nova itself it's not postquantum but this this part is postquantum and so we use

ML star PNI 2 and verification for we and maybe some of you guys some of you guys know [snorts] uh fry uh which is basically core of stark ziki stark and we is quite amazing cryptography kind of maybe one of the p primitive and it has a rich query and which is a very very uh limited her no size and it's 25% of her fly size. So we can shorten it and to make it

verifiable with 12 million gas. Okay, 12 million gas is still big. Uh even we want to use uh we even we if we use we for that it's still big. So what we can do is uh make it cyclic recursive and dividing them to 100 uh groups which is ordered in in kind of uh recursive way and the verify the last one uh with with uh uh verification. So at last we pay $12

million but their interval intermediate proof. So in the exec chains it's optimistically posted and finally kind of uh proven by our know uh mega gas uh verification. So it's very very uh efficient gas efficient uh postquantum verification and it's about 100k uh per per no proof. So finally we can make postquantum uh end to end postquantum L2 which is utterly efficient and practical. So post quantum is not about road map. It's

already done and this is what it is. So at the last as the result we can say that no this is a comparison seat or and [snorts] I don't claim that it's utterly fair because uh you know it's a bit focusing on uh payments and most of the cases know L2s are compar uh no about their use cases of defi to or scaling that but basically uh in maxu is not so big for that and we don't h we cannot have avi or unis swap on that we have some some kind of programmability

to to make a conditional payment and dexed uh based on that but yeah it's basically for privacy payments and intermax two three has instant finality unlike rollup and we fixer lightning network's problem which is uh capital efficiency program uh as I said and you know we want to deposit uh $500 to one channel to pay $5 to coffee shop and we don't have to make uh such problem with multi- party payment channel and we have a offline safety uh so in light network we need you know run node to watch over

the other marshious actors but we don't have to do that because we we delegate our asset uh to uh you know one of an assumption of clusters. Uh this is why we can be uh offline uh without running node and the other things know we are of course stateless z bytes part transfer uh regarding n on gen data consumption and livveness liveness is the only one problem of in max 3 uh which is you know uh you know one of eight people do not agree we need to exit to L1. So I hopefully you know it doesn't happen so

often but yeah the this is a weakness of inmax 3 but anyway the we drastically upgrade the UX and the safety privacy of payments of Ethereum other payment network of Ethereum. So this is what no stateless uh system uh should work uh on on on [snorts] Ethereum. So yeah I talk a lot and it's not a plan. It's already fully you know uh coded implemented uh and it's also know very formally verified with lean language and know a lot of stuffs uh

maybe you guys are already quite knowledge about >> [snorts] >> uh about in max right now than know the other people uh so you can win in bug bounty maybe and yeah we did so many stuff so you know if any problem from here I I am happy to pay for for the bug bounty and so thank you so much and Q if you scan this QR code you can know make your yeah first private postquantum transaction uh of intmax [snorts] it's already on test net and you can try it so thank you so much and this is uh about our you know what we are doing our

other stateless network. >> Great. Thank you so much, Leona. Amazing. Okay, we got some questions here already. Um, first question I got here is why revive plasma? >> Uh, it's a super critical question because uh no plasma it's dead. It's you know it's set to be like that hard in 2019 and you know we go roll up know this is a vibes we have in the space right and why plasma right now because it's a stateless network uh which is not consuming blob or on gene space so

basically uh L2 it's scaling uh of course but still we are in L2 we are sharing the same blob you know bandwidth is and there's competition and plasma is one of the stateless idea the one of the most you know ambitious idea of ethereum to scale up and it doesn't know harbor kind of bandwidth competition of Ethereum so no basically we don't post so many stuffs on Ethereum right so that's the reason why plasma should be revived without problem the problem of plasma was offline safety problem and yeah the online requirements and that's

things we already fix for plasma. So we have a plasma level scalability uh without problem even with privacy right now. So this is why we are we can say that you know we this is a complete version plasma. >> Okay got another one here slightly long question. You've managed to reduce transaction metadata stored on chain to just a few bytes per transaction. What are the practical up upper limits of inmax scalability if millions of users transacted simultaneously I assume would be the finisher?

>> Yeah. So if we use a payment channel yeah of course each payment channel should be limited to a certain number like 10k or to 20k I don't know uh it's up to the you know uh the row uh node runner of payment channel and inter channel payments yeah it's in max 2 and we already reduce that to yeah you know z no less than one bit and I don't want more compression do that actually I can do because it's just a depth of macro tree for each user but more and more depth of market tree for

each transaction uh it makes more ZKP computation kind of time so it's a tradeoff of client side zap computation time uh or more transaction complex best uh more transfers uh included in one transfer which is represented by yeah one kind of four bytes on chain. So this is all about tradeoff and I think that yeah current deficiting is totally fine for this situation and maybe if agents use more maybe we rebalance that our knowing for each payment channel.

[snorts] >> Okay, next one we have here is many layer 2 projects heavily target DeFi, high frequency trading or web3 gaming. Why did you choose to heavily focus in max on the payment infrastructure like payless and merchant transactions? H so yeah that's the things we are working on and you know it's a payment network uh it's not define network and it's not kind of lay L2 so which is kind of no having the same uh functionality of some layer one and yeah we should focusing on yeah the the merchants and actual privacy payment how we should be settled

B in know 5 seconds at least. And so why choosing that is because simply because we don't have that and we don't have a payment network for for Ethereum right now. So that's the reason why we we made it >> right. Yeah. It's to unlock a new category where rather than going towards categories where there's been others already. Um, okay. We'll we only have 30 seconds, so we'll try and do some rapid fire questions here to finish off. Who's your ideal user? 10 seconds.

>> I don't want to know because know everybody need privacy and know I don't want to know about users actually. >> Fair enough. Okay. And 10 more seconds for the last one here. How much more TPS we get from this approach? >> Our idea way. >> Yeah. Last one here. How much more TPS do we get from this approach? So right now we have thousand TPS for each channel and we if we have our 10 channels start 10K right so yeah we need to scale up like that and maybe each payment company need to have one payment channel for for instance no we have no scale parallelly and you know simultaneously and this is the way we we go >> okay got it thank you so much Leona

really appreciate it we'll be back with just in just one minute with the last talk of today so Please stay tuned, stay here. And uh one more applause and thank you [music]