DAPPCON 2024: Implementing The Shutterized Gnosis Chain - Jannik Luhn

Transcript

hi everyone thank you all for coming on this last day of the conference in the afternoon um my name is Yanik I'm from shter Network um I'm Mark from nethermind yeah and we doing a workshop uh today on shut R nosis chain which is very timely because we just launched it uh the the protocol on testet on chiato which is the nosis test net uh during this conference two days ago um and yeah if you like during the work we can later send your first uh shut raised um transaction on on the test net um but first i'm going to give or we're going to give like a um introduction in the protocol how how it

works um what we're building exactly and why we're building it and in the end um I'm not sure if there's um validators here on on chain uh but we um also showing you how you can if you're validator how you can support the protocol and um um yeah um help it work help make it work yeah so sh chain is a collaborative effort uh there's many uh many projects involved of course nor chain uh first and foremost but also shutter Network um our side and nethermind uh from the nethermind client which which is the main client on on um nois chain

um the problem that we're trying to solve um one of it is uh front running so uh that's a problem that's possible in um most blockchains today it works like this if you're Ellis and you want to buy something you send a transaction to uh Unis swap for example um the problem is you publish it first for everyone to see in in a public me pool and then everyone else um uh can react to that and they can use it this information and for example B Bob if if Bob is evil they can uh um buy before you and then sell after you so they can wrap your transaction into two in with two other transactions and by doing so they can make a profit because if they uh know

that you will buy after uh after them then uh the price will increase so they buy at a cheaper price and then they sell at a higher price um so they make a profit which is risk-free um and Ellis makes a loss so it's bad for Ellis and yeah this is one of the U in my opinion or in our opinion the one of the most significant limitations of blockchains today um that they allow this kind of behavior for the most part blockchains work quite well for you this but not in this case um another um aspect of this is for the same reason basically because transactions become public before they get included this also allows censorship so um a validator or a block proposer

who sees your transaction they can decide I don't like this transaction and don't include it in a block fortunately most blockchains in particular um nosis chain actually they have many many validators so if One validator sensors you um the next validator or the one after that uh can include it so it won't be it it doesn't mean that your trans transaction will never be included but it might take some time so it will delay um this this sort of attack will delay the inclusion of your trans section um and of course this also has bad side effects um because usually first of all it degrades ux uh but it also might mean that you um miss out on some opportunities uh that you had um so timely execution is important and of

course this problem uh maybe today is not as big um but it can get worse if regulatory pressure for example increases or um or other reasons why users might or validators might not include transactions if those increase as well yeah so that's is that's basically what we're trying to fix and um I already hinted at it the problem is that transactions become public too soon they become public before they get included in a block and we solve this by using an encrypted M Pool so um we make the transaction we hide the transaction by encrypting it the valid data then only sees that there is a transaction but they don't see what the transaction does um who send it

um and and so on and this means um effectively Bob is prevented from front running you or sensoring you not because we restricted um his powers they still have all the options but they don't have the knowledge anymore to do that effectively um yeah um so just to add to this The crucial bit is who gets to actually sequence the transactions um so if you're able to sequence the transactions you can extract me you can front run but um with shutter like when the transactions are sequ sequenced they're still encrypted so we first submit to a Smart contract where they're sequenced in encrypted form um and then when they're proposed the proposer just has

to follow the order that was the determined on the sequence trans uh on the encrypted transactions um so that prevents um any kind of front running exactly so now if we have an encrypted transaction a block uh that doesn't help us a lot we need to execute this transactions and for that we need to execute it um kind of the naive way to do that would be to ask the user after they encrypted it decrypt it now please send the decryption key to the blockchain and then you can execute it um of course this doesn't work at all um first of all it would be very bad user experience because now you have to send two trans or two messages to the chain even though you only did one thing and

you need to wait some time in between so that's not nice um and and it also means that um the user can decide to um to not decrypt the transaction and then we have a big problem because first of all we probably have to wait um a long time uh so every single um user would have the ability to stop the protocol in a way at least for some period of time and um also economically it might uh be a problem uh in some exchanges for example um you can imagine that the user sends two transaction one is I want to buy this token and the other one is I want to sell this token and then depending on the price movement they only um dgroup one of those so they can game a lot of these economic protocols so this doesn't work at all so U because we can't trust

um individual users uh so shutter solution is kind of the um crypto um solution a typical crypto solution to this problem uh if we can't trust one person uh let's trust many many people at the same time and as long as the majority of of those people are honest um the protocol works and this is called in cryptography term often often times a So-Cal threshold committee so we have a committee of notes that um generates these Keys um and we call these uh the the members of the committee the keepers because uh Keys um and they keep um secrets in a way and yeah we have an honesty assumption if as long as two two-thirds of those notes are honest uh the protocol is secure because and if

they're not if they decrypt too early for example if they collude then the protocol is not secure anymore very similar to a blockchain if all the Val datas would collude you also have a problem and to make sure that these members are honest we um have like a subjective selection process we have a um da so the shutter da selects these members and they make sure that they come from different backgrounds um from um uh yeah maybe some companies maybe some individuals um and if they have the feeling that some of these members are dishonest they kick them out yes so this was um the general principle how it works um this is a workshop so if you have any

questions uh we're happy to answer them oh yeah in you you'll have to excuse me because I am not a technical person so when you say uh the shutter Dow if the shutter DA has a feeling that uh uh one of the keepers are dishonest that they'll force them out can you define what you mean by feeling like how how how will the shutter Dow know if the uh if someone's being dishonest yeah that's a very good question um and it is very difficult to do the main thing is because uh there is no objective way to do this so the

keepers they can just collude secretly and if they um have like this perfect uh collusion going on um and no one leaks information about it then this is just not possible to detect so you can't have like objective proof about this sort of stuff so you need some sort of um subjective mechanism to do this um and yeah then this is just how um humans uh and how communities detect this sort of misbehavior maybe there's some messages being leaked uh um maybe um you see some suspicious unchain Behavior so for example if you see some people uh getting front run then you know something is wrong and then probably the keeper said is uh doing something uh

bad yeah but I think the more important uh uh strategy here is to make sure that the keeper said is honest in the first place and so that this simply does not happen that the honesty assumption is um um yeah yeah I mean the hope would be that if the keeper set is uh sufficiently decentralized um then it'll be quite hard to get um 2/3 of them to all collude on on releasing the keys early yeah in an earlier slide you mentioned that if Alice submits an encrypted transaction that the encrypted transaction goes first in the block if

there are multiple encrypted transactions in a block um how are they ordered and does it matter um so the sequencer can or the blog proposer can still order them however they like but they don't really have a reason to prefer one transaction over the other um so what effectively it means that they they are executed first come first s um so the earlier you send your transaction the earlier it gets um included um but yeah in the end what what it effectively means that their transaction are ordered randomly because the senders also don't know about each other so they um uh yeah just send them independently of each other so yeah yeah so just to like add to that so the

important bit is at what time they arrive in the sequencer contract so it does matter the proposer how they order it so they um so the sequencer contract that's what all the encrypted transactions land it doesn't really matter what order they're in at that point but then once the order is defined there it's important then that the proposer does follow it CU otherwise if they reordered those transactions then they could um extract me cuz when the proposed is proposing the block is decrypted at that point uh one one thing to add about the earlier question uh what I forgot to say um there are some fancy cryptographic techniques as well that we might be able to employ in the future it's not

something we do now but something very interesting for the future uh which is something called um um secret sharing with snitching so you kind of a um if uh you you can make a protocol that works that if there is collusion then any single member can can have cryptographic proof that um something happens and then you can that collusion happened and then you can have like a strong financial incentive for them to snitch and to R out the other people basically so that's also kind of a crypto cryptographic and cryptoeconomic way to make it even harder sorry I have another question I don't

want to hog the mic but um so I as I understand it for validators they opt into validating the shutter eyes nosis chain but for from the user perspective how how does a user opt in to use the shutterz nosis chain as opposed to nosis chain yeah we will see this further in the next session of the talk and also then in the end uh when we actually try it out hopefully it works um but in short um they just have to encrypt their transaction locally or their front end has to encrypt their transaction locally or they have to use an RPC especially RPC that does it for them um and then it just happens in the background yeah so with the encrypting

like hopefully that we have that all in like a nice front end so essentially it's just like very easy to send a shuts transaction will do the encryption for you all right then let's go on to the next section implementation and to start it off um kind of there's many ways to implement these kinds of protocols and you can get um can make many different protocol uh many different trade-offs so and The Guiding principles that decided which trade-offs we took um are the following first of all we did not want to make a hard fog so we did not want to change um the like fundamental rules of the protocol

because for nosis chain it's one of the um yeah important features I would say is that they're compatible with ethereum with main chain ethereum and we didn't want to change that um another one is we wanted to minimize complexity want to keep the protocol as simple as possible um at least in the beginning because already that part is uh not not as easy and um we want to reduce risks as much as possible we wanted to have um the best us experience that's um that's possible that we are able to achieve and we want to be able to iterate and improve the protocol from that starting point where we are now basically less important is kind of perfection uh we

don't need uh full trustless in the beginning we're fine with trusting um some of the validators in first place we're fine with trusting some RPC uh servers in the um in this in this first version in future versions We won't be fine with that anymore and we will improve on that but for now it makes our our job much easier yeah um so now we just go through like different aspects of the protocol one of it keep Asset Management uh where does the keep asset come from we have um a contract a simple uh normal standard ethereum contract that's deployed on nois chain or forado and that defines keeper sets in

terms of sets of addresses and each of those sets has an activation block number which says from which point of time this set is active if a set is supposed to be replaced um another set is added at a with a higher activation block number and then the other um the old set becomes outdated or yeah replaced immediately or when this block happens and this uh keep ass at management contract it has an owner uh that's uh will be the shat um that can add these um sets in the end it cannot change um sets that they're already there of course because it shouldn't be able to change history that would be strange um I don't want to go into too

much detail about the um how the key generation protocol works because it's quite complicated and no one likes uh math formulas on on slides especially not on the last day of a conference so but I want to highlight kind of the main ideas or the main idea um typically these distributed key generation protocols they um are expensive in terms of communication overhead because every member of the set has to communicate with other with every other other member of that set because they every member has some sort of secret and they need to able to to share it with all others so that in case they are offline this

secret can be recovered um and that means that yeah we have this quc overhead if there's four notes like in this example we have 16 messages if there's 100 notes we have 10,000 messages already so it scales very poorly unfortunately it's fundamentally necessary that we have this um so therefore um and one more thing of course or two more things we want to have our set as large as possible um as Mark said earlier the larger the set the more secure the protocol is because collusion becomes harder um um and we have to be quite fast so we want to be able to create keys for every block uh which means a no chain every five second seconds so we

can't do this sort of process with say 100 members um for every slot so therefore our protocol works like this that we run this phase only once so we only we have a setup phase and this setup phase um gives key shares for every member and then it outputs one kind of master key we call it the Eon key which is because it's supposed to be valid for a very long time as long as the keeper set is active and then for every slot we only um we are able to generate the decryption Keys very quickly by just um one message per um per note which is optimal um so like just to talk about how this looks from the user perspective

so this Eon key is essentially the the public key so when I want to um encrypt my transaction I'm going to use this um public Eon key um and then the keepers so like every 5 Seconds they're publishing a new set of decryption Keys um and the cryptography is designed such that they can just um produce the decryption Keys only for the transactions that have um going to be included next um and then they'll be repeatedly broadcast every slot just for the new transactions yes yeah once this key is broadcast this will happen basically before the before the key pass gets active um they know

they will become active in maybe um tomorrow so they start generating the key today once it's done they publish that key um and since it's very difficult to verify that key it's just it looks basically random um the keepers run some sort of voting protocol so every uh keeper says this is the key that we generated and as soon as enough votes basically 2third of that um set are collected then this key can be accepted as valid and will be used and this voting um protocol is done or implemented um or the outcome of the Voting is published to this key broadcast contract um which checks the keepers at manager that the right um the right Keepers voted on it um and this is

basically where the user would get would go to to uh fetch that key and encrypt that transaction so it's we use with key kind of this contract basically as a billboard where um the keys are published valid datas uh this is what we are going to do at the end of the workshop and they have to register so we don't want to um um require validators to do things because that would mean uh we have a hard fog so we want to want to make it optional validat is are supposed to opt in to these additional um duties that they would have um um if they follow the protocol namely decrypting and including transactions

and they do this by um registering they sign a message I want to participate and then they send this message to the valid data registry contract um if they want to deregister for some reason they decided I don't like this anymore um um then they can also send a message to this contract and then everyone uh can look at this contract and see which Val datas are participating most importantly the keepers because the keepers will have to decide for every block do they publish the keys for them do they produce the keys or not and of course they only do this if there is a uh validat or the if the proposer for that slot is register because otherwise um they would just ignore the key and it would be

pointless and also if they were to release the keys um at the wrong time for a slot when the validator wasn't registered then you're essentially making all of those transactions public so someone else could then um include them and extract me or or do something like that so it's quite important to only release Keys when there's going to be a valid proposer afterwards who's actually going to include them and follow the prot cool yeah yeah so now we had kind of the main management components in a way now we can see uh what happens when we actually send a transaction users as I said they um earlier they encrypt their

transaction by fetching the key from the Eon key contract and then they submit it to the so-called sequencer contract and the sequencer contract now um it's called the sequencer contract because they this contract basically does the ordering so the order in which these encrypted transactions appear in the sequencer contract this determines the order the encrypted transactions are executed as well and since the sequencer contract only sees encrypted transactions um we already know that there's no um no chance to um yeah front run or use private knowledge to uh to order them um now the sequencer contract is observed by both the proposers and the keepers the keepers do it because they

check uh for every slot um which keys they have to produce which transactions have to be executed um and then they publish the decryption keys for those uh transactions the proposers um watch that contract because they take U the encryptor transaction from there then they take the transaction from the keepers and um then they decr them and include them in the block at the front of the block according to the order that the sequencer contract told them to yeah um in val transactions for example users might um encrypt junk um or they might not even have enough money to um to send the transaction um or they might

not um might have chosen a wrong nons those transactions will just be ignored because otherwise um you couldn't build a valid block and also I mean for those transactions that are invalid um the user would still have to pay the initial gas fees to actually get them into the contract so that would prevent them from just uh you know spamming invalid transactions yeah that's a very important Point um you need to pay the fee at at the sequence your contract because at this point it's already decided that the transaction will be included and um yeah we need it as a sort of spam prevention um already mentioned it earlier in response to to the question

we had um ideally you encrypt your transaction locally in the front end or in the in the wallet you should do it yourself because only this way you ensure that only you know what your transaction does but um we want to first of all we want to have a good ux and we want to have it as soon as possible we don't want to wait for front ends and for wallets to integrate or or support this sort of protocol so in the meantime until we have this support we implemented the encrypting IPC server the encrypting IPC server is a very simple um IPC server it does what a normal IPC server does but instead of sending trans when it rece you you as a user send a transaction in plain text to that server and then this server will

handle that encryption and um sending it to the sequencer contract this means you have to trust this server um they could front run you um but um if you do that then you have like a very good user experience basically nothing changes for you you only have to change your UPC server and um everything just works as normal yeah and this is what we're going to try um after this um yeah during the workshop part uh questions so far about the implementation perhaps you'll cover that later but do you have any incentives in

mind for validators to Comm in reg Asis um yes uh so not at the moment uh at the moment we try to keep keep it as simple as possible so we built the um the simplest protocol imaginable um so at the moment it's just um yeah there's no incentive at the moment except for kind of something intangible like you want to support the protocol um you have some sort of incentive because you get free transactions basically validators want to have as many transactions to include in their blocks as possible and this is it's kind of an additional path for them if they wouldn't do it then they these transactions are off limits for them so

that's kind of a small incentive and we could imagine that in the future there's like uh Tok incentives or um they get like um yeah special rights in the Dow or something like that yeah but nothing concrete yet thanks uh what would this mean to Hardware requirements um and second question would be who will be running the RPC servers do you want to say something about Hardware requirements um yeah so there isn't any certainly for the validator side there isn't really any additional um Hardware requirements um on top of just running a

normal nethermind validator um yeah I think running the not is already um kind of way more difficult than adding this shutter um functionality um who will run the encrypting IPC server anyone can run it it's open source software um I think for now for the test net uh we run it like from um shutter um in the future hopefully um uh we hope that we can convince like the the main uh RPC providers and noes chain to to either make it the default or add like a variant of of theirs um to to do that

and you can like I said you can run it yourself in theory that might actually be a practical option if you um if you want to if you don't want to change your wallet or your um front end you can run it locally um and then you again don't have to trust anyone I think that was a question simple question I'm just wondering if the sequence contract is doing any specific sequencing of the transactions or it's just first come first served and if changing the sequencing in the contract could have any other impact on the rest of the

system so at the moment uh there's no um no complicated rules it just first come first Earth which which essentially means that the um block proposer who included the encrypted transaction uh can decide it um you could imagine that uh you could come up with more complicated rules for example you could um do some sorting by gas price or you could do some um auction system in that contract to to change the order uh I think there's like it's actually a very interesting design space because it's it allows the protocol itself to determine the order of transactions which is not being done right now um but yeah for now we don't have any um any specific uh rules for that and to be honest I think

in practice first comfor surf is kind of the um close to the best solution anyway so I don't think we will do anything fancy there okay and you mentioned you could sort by gas price does that mean that there are certain parts of the transaction that are not encrypted at that point so I mean yeah so as it is you wouldn't be able to do that like potentially using some kind of like crazy cryptography is is possible to do this kind of sorting on encrypted transactions um where you just reveal like certain or yeah you can order them without necessarily like um with them still being fully encrypted but this is like more theoretical at this point okay all right thank you um also the

transaction itself is fully encrypted um and you can't get anything from there um but kind of the submission transaction the transaction that calls the sequencer contract that of course is public fields and this transaction as we mentioned earlier it has to pay the transaction fee in advance um and this is done by a kind of a value transfer so in a way there's a gas price in there implicitly is it possible um encrypted transaction to be leaked in case of chain reor yeah that's a very good point um this protocol is generally not reor resistant so if you are able to reor um

the encrypted transactions while all already knowing the decryption key then there's no protection against this um two solutions uh in the future potentially one um is I forgot I single slot finality that's kind of uh very easy for us to say because other people would have to do the work but let's ideally we would have that then the pro is just solved the second one is um also not a perfect solution but we might be able to make transactions or at least messages that are only executable um in a particular slot um and this or before a particular slot and this would would prevent most

reok attacks because even if you're able to induce a reok um usually you can only Pro propose blocks in the future um so you can't and then this transaction would just not be executable anymore um use using just the public fields that you referred to before could you imagine a scenario where an adversarial um validator could juristically sequence transactions and still potentially extract some me or would that be completely Inus um I think in practice no I think in practice it's uh the transection is

encrypted so there's no um information leakage at least in in in theory you could imagine that so this becomes very complicated and the question is you you can probably do it or potentially do it St statistically and then the question is can you do it efficiently so is the value you can extract more than the transaction fees you you pay on average um there's probably some scenarios you can imagine uh one is if you know um I don't know if you if you see on Twitter that a new meme coin is rising and then you probably can guess that most of the transactions or that and there's like lots of transactions then

maybe you can guess that many of these transactions by this mcoin um but then the question is do you actually react to information that's in the transaction I don't think so that's so I I'm not sure if that if I would call that front running anymore yeah I mean there's quite a lot of information that's potentially leaked so like you have to as Yanik said pay the transaction fee up front so you have that you have the address that sent the transaction like the size of the transaction the time maybe the IP address um so you could definitely take more steps to um obscure more of these things but I mean hopefully it's it's kind of hiding enough that would prevent a lot of the worst kind of front running and stuff and then this is like other areas that

we can look into and develop further yeah you can probably um yeah CH like for example you can make the um arbitrarily increase the size just to hide the size um that's something you could do you can use a different transaction um or different address to uh send encryptor transactions to the actual execution um that's another way to um to hide information yeah could also use toour like to hide the time as well like if you send lots of sort of like dummy transactions I guess in a way you're wasting money but then you know

you can't tell the time cuz you don't know what's a real transaction and and what's not what's the key size for the encryption that used is it somehow going to determined by the user because it has some impact on the gas right because the bigger the key size the bigger the payload that needs to be stored in the in the smart contract so we only publish the encryption key like this Eon key and we only only do it once so once per um key per set so this is not going to be done very often the decryption keys are actually never on chain the transactions are decrypted offchain and then only the

decrypted transaction is sent onchain so the size of the um um key doesn't add any overhead the encryption itself of course adds overhead first of all you have to the transaction ends up in the state twice once in encrypted form and once decrypted so there's some overhead um and you we have to add some padding and kind of the encryption itself as a constant over it as well okay thanks okay um if there's no more question right questions right now we can maybe take a look into the future um there's as I said a few points where the

transactions or the where the protocol is not perfectly secure um one is that we have a lot of trust in the individual validator if they decide to ignore the order that the protocol tells them to include transactions nothing happens at the moment for them um so to make this more safe uh we in the future we can Implement slashing conditions um we can yeah we can require them to uh to deposit um some tokens and then then slash these tokens if they produce an invalid block if we are able to make protocol changes in the future uh then we might even be able to make these blocks simply invalid and

then those blocks would be ignored by the network that would of course be the ideal solution and also at the moment it's oped in we require valid datas to opt in um at some point uh maybe we can make it mandatory that they don't have a chance they always have to follow these rules um at the moment if the rate or the fraction of registered Val validators determines kind of how long you have to wait for your transaction to be executed if all transactions if all validators are um um are registered then transactions will be executed in the next block if it's only half of them you have to wait um yeah depending like two blocks on average so this is something we can do

on the valid data side um on the keer side uh we can also require staking we don't have that at the moment um but probably um we'll have that very soon um we can have social slashing this is what uh what we talked about earlier um if there's um kind of reasonable um um conviction that uh a keeper um cheated then we can socially slash their deposit and potentially also something I mentioned earlier we can have fancy crypto um that makes collusion um yeah much harder and we can have this snitching uh feature yeah so this is the end of the

presentation um we have 22 minutes and 35 seconds left that's plenty of time to send some encrypted transactions and then in the end we also want to do this or show you at least how the um valid registration Works um yeah you can maybe follow along do uh um we we can show on the stage how the um how the process works how you can register we have like this small read me file um that describes what you can do um you can scan the QR code or enter this URL maybe you can make it a little bit bigger tiny url.com

YT jm6 mbw and what we have to do is um first of all just add this encrypting RPC server I didn't think this true now I can't scroll without you having to um um being oh maybe I can open a new window uh okay so I guess most people are um very familiar with crypto and and and all the uh yeah lots of the things you have

to do there uh you probably have already added an RPC um in uh in your crypto life uh we now have to add this encrypting RPC server we use metamask um in this demo we click on network add Network um then we go to the very bottom add a new network manually we enter the network name shut chato new RPC [Music] URL this one oops the chain ID 10200 that's just the CH chain ID um currency symbol XI and the block Explorer block Scout

we save we switch to that Network and now whenever we send a transaction it will be encrypted so let's try that and hope that it works we click send you can just send to ourselves .01 XI and confirm so now we have at the moment about 1,000 uh Reg reged validators um there are about 6,000 validators on ch right now so um at the moment it will take uh six blocks on average if my math isn't wrong so it

might take oh much quicker we we got lucky uh so the transaction was actually confirmed um yeah we can look into the sequencer contract um there we will see a bunch of transactions and one transaction that was sent 32 seconds ago this is the transaction that the sequencer contract um that the encrypting IPC server sent to the sequencer contract we don't see a lot of information there because it's encrypted so um we don't even see that we sent this uh but we see if we click on um we can of course check the metamask confirmation we can view it on a Blog Explorer and see that the transaction is what we expected uh what

it was a transaction from us to us 01 XI um yeah so this is how it works so there are like two transactions there the first one where it was sequence encrypted and then this one we had to wait a little bit until the proposer included it in it decrypted form maybe we can try it again and we get unlucky this time U maybe it takes longer um kind of the same thing [Music] confirm we see the transaction from the

encrypting IPC server is pending right now was just sent here should get included in the next block was included and we're still waiting for the next um yeah participating validator to uh be in charge of producing a block yeah so it's just pretty um random like as to when the validator gets selected and if it happens to be running shutter so it could be like it's average 30 seconds a moment but could be like potentially longer

um and that's why we need lots of validators to participate does it work did anyone try can we help oh yeah I wanted to I forgot about this I wanted to add a link to the um to the faucet now our transaction was confirmed good question does it say included this one was included in Block 94 and the sequence area transaction was included

[Music] in uh 81 81 so 14 blocks so a bit unlucky twice as long as it should have been sorry yeah at the moment it's uh D crypting RPC server so um you get uh free Block space if you use it um you still have to pay the transaction fee for the actual execution in the end though in the future uh if I mean transaction fees on uh noses are relatively cheap so it's possible that this will run for um for a while um

but we could imagine that you have to um prepay some amount and then you get like a a certain amount that you can spend um ideally yes U but that would probably require um yeah a wallet integration basically yeah I mean ideally we'd have the the front end so you know you'd just be paying for it yourself yeah yeah so you just can just pay for it with your own wallet or or people can run their own um PC servers as well

oops okay um maybe I could just quickly um talk through the how you go about registering a validator one second did someone send a transaction because I see a transaction in the sequencer contract yes awesome thanks let us know if it works because we won't get any confirmation because we only see the encrypted transaction so we won't even know which um uh which transaction us is all right maybe we can yeah yeah

are there any nosis chain value that is here just out of Interest one oh many awesome so I mean for now it's just chato but uh hopefully we will be on minute soon so then uh this is uh for you hopefully okay yeah so to um register your validator should be like um um pretty similar to like normally registering a validator with a couple of extra steps um so one thing you'll have to do is ch your execution client um to use the the shut version of nethermind um I guess in future we'll merge this into main so you won't even have to do that um and then you have to generate your uh validator signing Keys um in the

normal way using the generator tool um and we're going to need to use these to um sign the um shutter messages to um prove that it's you who's um registering a validator um so another step you have to do is creating a burner address or just like any address that you're happy to um just put in a bit of XI just to actually submit these transactions um on chain um just set up all these parameters here um so you need the beacon node endpoint put in some information about your burner address um and the the path to your um key store files um and then you can just sign and

submit the transactions so um I already have my um config set up um so I'll just quickly demonstrate what it looks like so I'm just going to run the script which is going to sign the transactions um so yeah it gets all of the information from the beacon chain about the validator um and loads the key stores and then it generates this this bunch of bites which is um the shutter registration message and then it signs it using the validator keys um and then I just have to run the other script um and then this is just taking the previous sign message um and it's

going to use the burner address to send onchain and then that's just the uh receipt um so I guess I could may as well show this in the block Explorer and probably oh [Music] yeah okay yeah here we go so this is um and that's it so the validator is registered as easy as that um okay you're running like 50

validators do you this for each data um you can do it yeah so in in the um the key store files um when you generate them it will generate all of them and the scripts will just run through all of them and and sign and submit um so for one it's very quick but it can actually take a while for if you have a few hundred or something to sign all of these messages and submit them we could potentially um have like an aggregated signature something like that to make it easier but for now we just wanted to keep things simple and it's only one time thing you have to do so we didn't think it's a you don't have to do it 50

times yeah no the script just goes through and does it all for you all right I see many uh calls to the sequencer contract I hope all of them go through as I said we can't confirm them because of uh yeah it's easy difficult to see them because encryption um if not please let us know uh it's a test n so things are expected to break that's a question I have a question so when I sub the transaction multiple transactions right on the sequencer is that normal behavior and just to understand no if you send a transaction it should be converted into one transaction in the sequence or

contract but maybe many people did it right now at the same time uh so maybe you see um those transactions as well there okay I hope so we had we actually had a bug this week that we had one transaction which resulted in lots of things I think we fixed it yeah but it should ideally only be only one transaction yeah okay I'm just interested to know bit more about how you pay for the transaction so you said that when you submit your initial transaction includes the encrypted transaction you make a payment

at that point to cover the cost of the encrypted transaction could you just going into the details of how that works and I'm guessing that you might need some new UI elements at the wallet level to enable setting that uh new price and I guess that right now the RPC encrypted server is handling that for you but could you just yeah a bit deeper exactly what you said basically so at the moment the sequence the encrypting RPC server pays a fee when they send the transaction to the sequencer contract they do that by a simple value transfer so the sequencer contract is payable and they have like a minimum amount that um

uh that so I mean it it sets essentially like you have to set a limit on how much it's going to cost um and then you pay up front the whole cost and then if if it exceeds that amount then it just won't be included and it's am at the moment no um at the moment you uh pay double basically or at least the sequencer the the encing UPC server pays and it doesn't get refunded this is because um mostly because we can't do protocol changes if we could do protocol changes we could make it much nicer that you only pay in the in advance and then your executed decrypted transaction then this

wouldn't pay anymore at all and maybe the remainder would even be refunded this um we do the so shut network is also we also implementing it on op stack uh there we able to do protocol changes there we there you get a refund um in optimism right now this is not possible we could imagine that you can do fancy things like to afterwards like a your knowledge proof you you had this transaction paid this much you paid this much in advance so you get the money back from this quer contract but for now this is uh yeah we thought this would be too complicated and not necessary initially anyways because uh no such chain transaction fees are so low anyways and

one how are the fees distributed from the sequence of contract to the validator in question that processes the transactions at the moment they're just burned so the fees in sequence that contract uh don't go anywhere um yeah in the future we could imagine that uh maybe the um either the block proposers can withdraw them or um uh nois St can withdraw them okay and and the validators would still get the the um you know the tip from when the transaction is actually included as well okay so as understood the sequence of

contct is kind for work list for the validators to work it off right so they will go through it and just submit it uh so are there any any measurements on your side to prevent that one of those items in the contract could be executed twice I mean they will proba will fail in the second time but it would most probably some cost so um if a transaction is working or synchronization that you make sure that the is not Tred to be decrypted and submitted twice yeah um it's normal transaction so they have a nons and if you would include it twice um this it wouldn't be executed or this transaction would just fail uh would be invalid because of a duplicate nons okay so

there's no extra protection on it you could just get it rejected by the by the note after once the Val data tries to exactly or actually the value data checks this before that the transaction should can is includable otherwise they don't even Pro Force the block like this they um kick it out before that even thanks all right if there's no more questions I think this is the end um thank you all for coming uh and yeah catch us us afterwards if you have any more questions or um tried it out and it

didn't work or tried it out and it did work because uh would would like to hear about it and yeah thanks [Applause]