Schnorr Sequencer | Wanseob Lim, Ethereum Foundation | ETHTaipei 2023

okay and let's welcome what's up [Applause] yeah um uh today I'm going to talk about the Snore based sequence sorry uh which is a commitment scheme for mostly for layer 2 Solutions uh I am onesop and working at the PSA team as a researcher and um yeah let's start uh nowadays the mostly for the layer twos we should think like we're gonna commit optimistically and then verify them cryptographically so maybe many of the teams are trying to use this approach like separating the commitment scheme and the verification scheme and what I want to talk today is about the commitment scheme uh mostly when we commit some layer to transactions on chain onto the layer one we usually commit a batch of transactions we collect many transactions and create a batch and commit that onto the layer one but the problem here is that it is not that suitable for low throughput roll-up chains for example you launched your own smart contract and then you want to run your own rollup but mostly specific smart contract does not have that many have a big throughput for example like 0.1 transaction per second so if that it'll be it'll take like a more than a few minutes or more than a few hours to commit a batch transaction serve what we can do here is commit a transaction instead of committing a batch of transaction then what we can expect from here is that having a instant final lady for every transaction and executing the state transition for every transaction right away let's see how we can achieve this uh simply we're gonna let the sequencer give a signature for every transaction index um which means when you submit a transaction you sign a signature but also you were gonna get a signature from the sequencer to so we are completing a one signature as using the multiplier computation from the user side and from the sequencer side both together and the Sonora signature is one cryptographical scheme which satisfies what we want to do here um using the Snore signature uh to be a little bit specific to be more detailed the sequencer and the sender completed signature for a specific transaction index so by this signature the sequencer is committed to including that transaction into the given index onto the layer 1 chain which means if you have that signature later than the sequencer if not include then transaction to that given index then the sequencer will just slash it and um to achieve an instant finality and the instant State transition system actually we have to have a data layer by constructing a peer-to-peer Network each other so for example if I may note and if I have the older snore signatures for the given index indices for example from index 1 to index 173 then I can instantly execute all the transactions from index one to index 173. so it enables the transaction level commitment model uh so what do we expect here is simply we want to do some instant State transition and also uh we want some application specific Roll-Ups which have some low throughputs okay now we're going to start about the cryptography and it's the really the um not that difficult so is a your starting point and I'm pretty sure that you're gonna make some fun just following the cryptographical setup of how this you know signature works okay let's start so don't worry don't worry snore signature is one of the most simplest scheme of the elliptic curve cryptography let me explain you step by step so we're gonna uh would you mind if I sit down here okay so uh you might be pretty familiar with the signature itself right so here for example and also public key and the private key in this setup this more K is your private key so if you multiply your private key to a certain electric curve point then it becomes another point and that is p which is your public key so to sign to a sum challenge which is e using your private key then you can just simply multiply your private key and also the challenge key challenge scholar value to a certain point actually which is called generator then you will gonna get a another point which is SG and then uh only you can generate this small s value because you are the only one who knows more K so this as becomes e times k but actually here is a problem the problem is if you know the small ass and if you know the small e you can simply calculate the private key just by dividing them because k equals s over e so to prevent these key retribute retrieval from the signature and the challenge we add a random salt here and this is called a random linear combination method so we have a small R which is random volume and if you add some random Point here then actually people cannot retrieve your private key be uh even if they do not know the random salt you made here and actually to protect your private Keys securely you should not share your private random value with others so this is how the Snore signature works and in more detail to sign a message uh usually we just do like this Alice have a private key K and public key p and has a message to sign which is M and then we compute the challenge value e using the hash of the uh before that we choose a Randomness to keep the private key securely which is more orange and its public value large or which is a multiplied by our the generator point and then we compute the challenge value small e using the hash of large R and the public key and the message and it becomes the challenge and then create a signature using S equals small R plus your private key times e and then finally shares your small s value and public non large r value with others then this is the house nor signature works and actually there are some pros and cons of this channel signature if you have ever uh just took a look at the ecdsa users feel like oh actually this looks pretty simple and pretty easy then that reason is because it is using only the addition here so shunor signature has an additive homomorphism there is a prose and also it becomes a cons because it has a additive homomorphism we can simply cancel the key like choosing a minus other people's public key value to my random nonce value will cancel others uh public key so which means like uh you and me complete astronauts signature together just by adding our two signatures but if I set some values minus your public key then actually I can cancel the opposite signature so that is called key cancellation attack so to prevent the key cancellation attack we can use the music approach which is multiplying some weight Factor to the each public key so this is about how to complete a signature together by two parties using music protocol is it is something having a my own rate vector and the opposite's Own Way factor and multiplying the waste Factor the public key so it will prevent some other one cancel my signature uh by just remove by subtracting some public key value uh some music works like let's say we have Alice and Bob at least have a private key bubbles have a private key and at least public key a equals Ka times G Bob's probably keep PB is KB times G and also they both picks their own random nonce value which is more ra and the small RB and then we can simply calculate its public Randomness value large ra which is r a times G large RB which is RB times G and then we start to compute the weight factor for each other so aggregate the public loans and compute some public Keys hash of the public key set and compare some weight factor using hash the value so there's nothing some complex logic to compute the weighted Vector the only one thing we want to achieve here is just making deterministic making the weight Vector deterministic so we can get some two weight vectors it's for Alice and for Bob and then we compute the aggregate public key again using the weight factor and then we're gonna make the signature using this aggregated public key so challenge becomes something and then to the signature you should add you should multiply your weight factor to your private key times challenge value so if then we can effectively prevent the key cancellation attack and also we can complete the general signature between two parties actually we can do that between multiple parties more than two but uh I just want to introduce the multi-party signature completion between two parties for now and then I just want to introduce the detailed sequence of the how the chenor sequencer should work like the first step is the sequencer should do the proof of stake so with approval State the sequence of will get slash the sequencer doesn't put the transaction into the given index so here we can say privacy of the sequence result KS and the public key of the sequencer is large PS and then for its next step user creates a random nuns small or user it's a just completing h2r signature together so compute the public nodes large array and uh the user's public Keys pu and hash of the message the user want to send to the sequencer is m we give these values large are you public nouns and public key and the hash of the message to the sequencer then now sequencer can compute the challenge value before they have the exact detail of the transaction and also before they get the partial signature from user so if the sequencer can not now can compute the challenge value e so sequencer creates its own partial signature and Returns the value to the user and when the sequencer creates a partial signature and computes the challenge value e we tweak one thing here that adding index value into this challenge value so also hash the index of the transaction will be included in into the hash function so uh by giving this partial signature to the user uh sequencer is now just getting committed to including that transaction into that given index um and then after user gets the partial signature from the sequencer also the user completes its own partial signature and send it to the sequencer with the detailed transaction data the reason why we share the transaction data here before after we get the Porsche signature is to prevent the minimal map stuffs so actually it doesn't prevent the map 100 but I'm going to explain that how we can mitigate the map uh in other way but actually this is the minimal setup to mitigate the map here so finally user and sequencer both have the completed signature each other so what they have to do is publishing the signature data to the data layer so the data layer don't need to be always the layer one block transaction so people can construct their own network and if they have enough data to execute the transaction then they just can execute the transactions and later when the transactions patch of the transactions are submitted to the layer 1 chain then if the transaction is not in the given index then people can do some challenge retractively so finally the sequencer verifies the signature and completes it and publish it so this is the how the tuner sequencer works and validation is also pretty simple we can validate validation will be used for the challenge system or maybe bundling these transactions or compressing this transaction into one ZK proof using uh proof signature aggregation and validation is uh just validating we have both public key instead of this signature compilation or signature so challenging will be like um yeah it's a pretty easy descriptive but simply if the sequencer doesn't include the transaction into the given index then user can anyone who has the signature can submit a challenge and then the sequence server will get slash it okay so we finished all the some theoretical points now let's go to what we can do with this General sequencer stuff uh in my personal opinion I think we can use Sonora sequencer not only for the layer to sequencer but also the bundlers for the account abstractions too because for the bundlers the account abstractions does maybe I guess sometimes some bundlers will have not been enough throughput so maybe they need to give some commitment data to the user that okay your transaction will be at some time including in the layer 1 chain but actually we are just collecting and bundling the transactions so please read a little bit more so I guess generation logic also can be used for the abstract account abstractions bundlers and also we can combine this with the general knowledge prep together to just compress the signature data obviously and but one problem here is uh to make a most efficient system what we have to do is maybe tweak the hash function to computer challenge value from shot 3 or ecdsa to a more smart friendly function and as I mentioned a briefly that it cannot mitigate the math Attack 100 the reason is because the sequencer can empty a slot and that actually just say complete the slot later and then maybe people if they do not have some enough availability uh to the previous signatures actually it can be kind of a there might be some MAV attack problem to mitigate the hundred percent cryptographically we should use time lock puzzle here we should use time-lap puzzle and um it can also not 100 but you can mitigate the MAV attack for these sequences scheme also there are some other possible approaches the one is just another approach is just combining two ecdsa signature so users submit a transaction to the sequencer using metamask ecds signature and the sequencer also gives back the sequencers only CDs signature and combining it using zkp or Etc but the problem here is like uh not a problem but neural sequencer is a twice a lighter and also it is much easier to implement and aggregate inside of this ekp2 so maybe there might be some trade-off between the user experience that using the existing ecdsa key or creating another eddsa or a snore friendly private key but actually there are kind of some trade-offs and also we can think we can use a BLS signature because I am just assuming that we have only one single sequencer and I actually I believe that the centralized sequencer doesn't mean a multiple sequencer actually we can do some burn auction stuff so we can uh still make a decentralized sequencer even if we have only one single sequencer but if you just think about okay we have a bunch of best sequencers set of sequencers and actually we can also uh get some PLS signature from all the maybe other validators to a given index of the transaction but I don't think it makes sense because if you have a 10 000 validators and if we should make sign to every single index actually it is a too much in network traffic so I don't think it makes sense so the conclusion uh this sequencer scheme is suitable for application Roll-Ups or maybe a current abstraction bundlers and also it can give an economical in some finality and then so you can just say execute the state transition instantly but if the application is pretty sensitive to math for example amm like uni swap or which have a very high throughput actually it might be a good solution to run the application on top of this kind of a structure and we can use a concept section and also show noise forward a scaling okay uh thank you so much yeah my top [Applause] okay any questions oh there please so what's the size of the signature uh 64 bytes thank you very much for the talk um sorry uh so yeah it seems like a lot of l2s or Roll-Ups have decentralized sequencers on the roadmap can you just elaborate on what you mean by having decentralized sequencer but then having only one sequencer I didn't really understand that part oh what was your question I'm sorry yeah so do you mind elaborating on what you mean by having a decentralized sequencer network but using just one sequencer okay so I just mentioned about the boring auction which is like we are just auctioning for a given Epoch to be as a concerned so you should burn uh your stake to be a sequencer so the highest burner will get the slot will win the auction for the slot so for example uh if the network is generating kind of a 10e of revenue for its Apple then maybe I will bring like 5.5 e to be a sequencer but uh for example uh if I should be the sequencer then maybe I can spend like 28 to be a sequencer so it's kind of a permissionless uh sequencer can be considered as a decentralized sequencer okay cool thanks any other questions okay the one X6 so thanks for presentation it was really great you shared about snore's signature being used for account obstruction bundles and I was curious about like if it gets used for account contracts like to be the primary way to verify the signature what do you think are the trade-offs for using snore for the signature verification mechanism for account obstruction smart contract wallets uh I I just can I just think that we can use both so can you please elaborate a bit more like what do you mean by both like um so people can have their own smart contract account and then there are accounts control um public key is the Sonora public key then bundler can just say compress the generosity signatures and then execute the transactions uh okay yeah thank you thank you any other question last one if any okay here hi oh thanks for sharing I'm wondering during the research period is there any other alternative alternative that shares the merits of uh snore signature skin that may be applied on sequence of sequencer scenario like this I am sorry I didn't understand your question like is there any uh alternatives for the signature skin such as share the merits of the snores signature but not snore not what I'm sorry because the Snore sequencer use snore signature skin and during the research period does the research thing found other signature skin that can be applied on sequencers scenario actually they they were these as a combining ecdsa signatures or using the PLS signature but actually the proof size and the ZK friendly start full stuff I just thought shunor might be the best solution for this thank you