DappCon 2023: Exploring The Future Of Gnosis Chain - Philippe Schommers

Transcript

hi yeah so well the talk title was changed a bit um it's not going to be that far in the future or long-term Vision more I mean closer to like shortterm and Midterm maybe for the next year or so so what's next for nosis chain so we'll go through um what nosis chain actually is because I get this feeling that a lot of people maybe associate nosis with Stave or don't really know what the chain is although do we even have one uh so a quick reminder might be quite interesting we then go through the Denon hard Fork which is the next hard fork for etherum mainnet and this also for nosis chain and then talk about two research projects which are uh this idea of potentially turning nosis chain into a

layer two um and the shiz Beacon chain so what is nosis chain uh so as a quick summary so it's quite similar to eterium actually so we have um the same architecture we have the beacon chain uh we have the same clients so on the execution layer we have n mind and Aron uh on the cons layer side we have um Nimbus teu load star uh Lighthouse and prism is coming as well actually on the execution layer s uh we are also working on G so it should be quite similar in those regards uh we also go through the same hard Fork

which is actually um a nice property of also having a beacon chain we are the only well we were the only chain with a bacon chain um up to I think well when Luxo launched which also has this a similar architecture um but this is actually quite good because for example polygon also has a fully evm compatible um chain but they cannot go through the same hot Forks uh or not exactly as at least as ethereum because they don't have this peaking chain right um and of course we're also super focused on uh decentralization we actually have 150,000 validators on nois chain uh it is quite a bit less than ethereum of course which has 780,000 I think um but

still it's quite good and we're actually uh incentivizing this with nosis VIP uh which basically uh rewards people for earning nodes in uh countries where there's not too many nosis noes uh of course we also have a few differences uh from ethereum so we actually we were never a proof of work network uh we were based well a proof of authority network based on Aura and PDA with a fairly limited set of validators uh we use gno as the staking token so actually gno is an nc20 token at this bridged from ethereum mainnet uh and our native token so the one you used to pay for gas is Xi which is a stable coin right it's just die bridge to NOS

chain uh and this also has some very interesting properties uh well the fact that you have a stable coin as a gas token right um and in addition to that we also have 5sec block times uh instead of 12 for ethereum so 2.4 times faster and only 16 slots per ebook which means that the finality is for is a 4.8 uh sorry is 4.8 times faster than ethereum which can be nice for Bridges or just making sure that there's no reorganizations or things like that all right so here's a quick timeline uh of nosis chain incp into ethereum so our Beacon chain was launched in December 2021 which is one year after um ethereum and then we

merged um on September I think no December sorry 2022 uh which is three months after ethereum and then we did chapella on August 1st uh so very recently actually a bit more than a month ago which was then four months uh after after etherum minet um the next hard Fork is DAP as previously mentioned and our objective is to be well to be able to hard Fork way closer to ethereum mainnet uh so we want to kind of um yeah hard Fork around the same time maybe a few weeks later uh depending on of course uh our capabilities of actually doing this um and then after that well for Denon

actually um it might not be late uh end of this year because I guess even at the EF I mean there's no date set there might be some um delays coming we'll see um so technically the Shad R speaking change should come afterwards but if Denon is delayed then it might happen uh before I mean the sh R speaking chain before D Den sorry uh so what is Den that's as I mentioned the next hotw for ethereum uh and it has five eips um so yeah as the self-destructing being able to copy memory it's also possible already but it will be cheaper and easier but I mean we're going to focus on E 4844 which is also known as

Proto dung Shing and it's basically the biggest feature um for this HW Fork um so as a bit of context for EIP 4844 that is in theory called Shard BR transaction but again most mostly known for being Proto sharding uh so it would provide cheaper unchain data uh so right now if you want data to be onchain to arrive onchain basically you have to do this with the call data and it it costs 16 gas per BTE and with Proto langing this will go down to uh three gas per B the caveat being that this data will not be accessible by the evm so basically contracts cannot interact with that data um and the data will also be Emeral

so after about 18 days I main it uh it can be deleted so for n chain this would be around 3 days because well we have faster ebuck uh so this would have to be tweaked for us but uh yeah so the important thing is that data can be deleted which is quite important for ethereum right now because uh of course there's this like State crib we're constantly adding data and never REM deleting it so it becomes more and more expensive basically to run nosis um etherum sorry and does also nosis chck uh and this always will result in uh cheaper and more scalable relayer tools right because they rely heavily on data um so there's a few issues with uh

AIP 4844 at least well Forum as well but it's even worse for nosis chain uh so of course in comparison to etherum you have faster blocks faster blocks means uh more blobs blobs blocks not the same thing um and there's also more um well Hardware requirements storage requirements band rate requirements uh so basically it's a bit harder for on nosis than on ethereum so there two solutions uh to this uh the one would be to reduce the Target and Max U blob gas per block so basically for each block you can also have blops which would have a certain size and we can reduce that which is the solution we're going to go

with and the second solution would be to basically require better Hardware better networking and all of that but of course you don't want um every no chain node to be like connected to a tier one ISP and have like huge servers to be able to run so uh we really don't want want that it that's a lot of centralization which is not good for us at least um the second issue is actually quite linked to that and it's related to probation time and bandwidth so blobs could potentially add up to 40 uh% more uh size to the blocks so it could go up to to 2.625 megabytes per per block so every 5 Seconds we would technically have to

propagate this through the entire network but there's this thing in ethereum where basically you only have onethird of the time to build a block and propagated through the network and then one third of the time for attestations and one third of the time for aggregations so we only have actually 1.66 seconds uh to build a block and propagate it to the N through the network which is really not that much especially for uh bigger blocks um so um this could actually already be an issue for NOS chain right now because well our chain is not that uh well the blocks are not that full at the moment let's be real um and so we don't really know how it would behave if every block

was actually completely filled uh and we expect that some nodes might actually already I mean would drop if in the current state we had bigger block uh simply because they maybe don't have the hardware requirements or um they don't have the bandwidth or uh any combination of those things so currently we're running a big block experiment uh which is basically to spam the network with bigger blocks to well test how it uh behaves right and how everyone like every validator on the on our chain uh will react so some will drop out maybe uh and then they will know that they need um better Hardware or better Network or to fix some setup maybe use a different um client whatever

um but it's it's very interesting data so there's two solutions to this uh propagation time and bandwidth issue the first one um would be to increase the parts of block build well of creating a block so of those 12 seconds um so the the time allocation for Block building and propagations so as I mentioned right now it's 1/3 1/3 1/3 uh we could change this to actually so for a 5 seconds on nosis uh chain have 3 seconds for Block building and propagation and then 1 second forestations and 1 second for aggregations for example there's actually a a PR open on the consist specs repo from on the duck from sadus uh it's quite interesting and I think a

lot of people think it's uh a good potential solution um but it has the caveat that it might make veral Tre a bit more complicated so but I guess that's issue phone another a time um the second solution would be well pretty much like for the previous issue so just reduce um well the size of blops uh and the third solution would be to significantly increase um like or improve the algorithm for Block propagation and building uh but we're probably kind of already reaching the limit of what we can do at this point uh even though status did a fantastic job in improving gossip sub and all those protocols uh we might just

be reaching like the limit of what you can do at least currently and third solu uh third issue sorry is that um IP 4844 relies on the communication protocol between nodes that is called e68 and uh nom mind actually which is our um main client on the execution layer does not support that yet uh so we have another mind being the majority client and Aron Aron support is just fine so that's good uh but NE mind relies on the get noes data field in e66 uh for its fast sync implementation and this was actually removed in e67 so they don't support e67 and will

not support it 68 at least for the time being that's not uh the case um and it 68 basically adds um data to this protocol that says okay I have a block of this size or a blob of the size and then other notes can choose which data they um download and this is actually quite important um while it's a big optimization basically because maybe you don't want to download blobs um and this would basically save a lot of bandwidth um and uh yeah so there's two solutions to this of course ideally NE mind will Implement like a slap server similar to G which also has snap sync but doesn't require this field anymore um and then

of course enable e68 and actually this is already being worked on there a pro request for that uh it is a bit old and need some work but um I guess there's something being work done on that regard and this would obviously be the best solution the second one would be to stay on e66 but then basically you would be spamming the network bit it would be not it would not be efficient at all it would even impact Aron no so that's really not great uh maybe maybe this could be done for a few like weeks or whatever um but it would not be efficient and it would have to be replaced um in any case down for a down line all right so let's talk about a bit

of research now research and development so this idea of turning NOS chain in a in a layer two uh comes from I guess there's a few other projects namely maybe shello or other projects using validium um and I guess there's a bit of hype around this and it's quite interesting actually um so as a bit of context uh of course there's tradeoffs between L ones and l2s right um and the most well the the the most important thing I guess about layer 2os is the security they have from the layer one and the bridges they can do with it uh and the cons of course being uh that in most cases uh they use centralized

sequen ERS um and they don't have a neutral block space so basically the sequencers can decide in which order they include transactions they can also decide not to include a transaction um and this gives them a lot of power and could lead to censorship in some degrees it's not actually that easy because you can actually Force transactions through a layer two but uh it takes some time it's also expensive and it's not great in general uh and so we are kind of exploring this idea of implementing this for uh nosis chain and this could maybe be done I mean again it's early stage exploration so we have no clue if this actually will work but uh it might be done by actually staying a l one and

then adding like L2 features on top of that just in case something doesn't work with nosis chain um so for example if it stops validating someone takes the chain over which is basically impossible but who knows or if the chain holds for some reason um then you could go on L one on ethereum for example and um still get your funds back for example but I'm not going to do go more into details for this actually because lion has a talk about this um in two hours approximately so I would highly recommend you to go to this one if you're interested in nosis potentially becoming a layer to again um that's not like a direct plan for now

it's just some research it's just interesting and uh why not explor it basically all right and then the research the last project sorry is the shiz Beacon chain um so basically this all comes from the fact that we need a shielded mol uh basically we want to prevent me um front running getting sandwich all of those fun things uh and there is we actually have solutions for this kind of like flash buts for example or me blocker um but they well first things first of course of course they are centralized and they rather provide a a private mol not really a shielded one uh in the sense

that um basically you well use the RPC they get transactions in CeX they can still include them in whatever um order they want or not at all if they want to censor you um and yeah so we want something decentralized censorship resistance um and neutral basically um so why do we need censorship resistance well I guess that's an important topic as well so currently on ethereum minet actually more than 90% of the blocks are produced by just four billers and obviously it's quite a bit easier to uh censor four entities or four Builders than the 780,000

validators that are currently active on ethereum right for one of the examples of this would be to require those four Builders to become ofac compliant uh so that's that list from the United States that says that basically you are not allowed to interact for example with Tado cash or um some other privacy presolving projects and basically a list that the US defines um and if you interact with them then you might have some issues um so those Builders um yeah so it's it's not great they can they can be censored and uh actually I I think around 98% of the

blocks on eum don't content any transactions that interact with ofac s sanctioned contracts um that doesn't mean that 98% of the blocks are actually censored but it means that um well maybe that just wasn't any transaction supposed to be in that block but only around 2% of the blocks actually have those transactions so we might assume that there's a lot of sensor ship currently and also uh builders in general have um I guess some competitive advantages another issue is that uh it's actually possible to um censor all Hal production of valid transactions or kind of sensor um transactions for a short amount of time

on ethereum uh so SMG was actually able to basically fill an entire block so prevent anyone else from getting into that block for only 05 e which is not that much and some um applications May rely on Fast transaction times right so maybe you need to be included in the next minute or so because well for for some reason for example nois pay um has this uh requirement when you tap your nois by card on a terminal actually only have six seconds uh for a transaction to go through so if you get sensored that might be an issue right uh if you if you're at your vendor and then your card doesn't work that's not great um and so the general idea of the shiz

begin chain is to well um fix those two issues uh and the idea would be for users to encrypt a transaction well their transaction and then post it on a sequencer contract the sequencer contract basically is just a list of transaction in a given order uh that will be included in the sh I mean in the block uh and then a decentralized network of keyers creates or generates Keys uh decryption keys are different for each transaction actually um well so when you post a transaction on chain you will say you will give the encrypted transaction and also the um gas limit on which they are going to execute and then the keyers generat decryption Keys

um only for the next transaction so they know how much gas they are going to consume so they're never going to decrypt or to generate keys for too many transactions uh so you're sure that uh no transaction will get get decrypted while not being able to make it into a block um and then so the keyers generates those keys um the proposer decrypts the transactions and then adds them to a block and they have to basically add them at the very front of the Block in the order uh that they appear in the sequencer contract so if I'm the second transaction in the sequencer contract I will be the second transaction in that block assuming of course the vator is sh enabled which might not be the case for

all of them but if it's not then at least my transaction will not get decrypted and no one knows what I was uh going to do with it um yeah and so um we well we we want to build this in a kind of plug-in architecture meaning that we don't want to alter the the well the con layer or the execution layer too much because of course you want to remain compatible with ethereum so if we change the those consors um protocols too much then it would be harder to basically get back on track with eum points for example it might not be a we might not be able to execute the next out Fork whatever so we want to build this as a pring

architecture basically and so this is the general architecture we're going to use so it's basically what I just said but you have those uh users that uh post encrypted transactions on the sequencer contract and then the key birs generate thetion keys and the The Proposal puts them in the block so basically what I just that maybe this helps you get a better representation of it um and how are we going to implement this so uh as kind of mentioned before uh this will be done with a like this will be op in basically so you will have to register your validator to become like shutter enabled basically um and this is done because we cannot force

well technically we could but it's complicated to force everyone to become a sh enabl speakon chain uh validator sorry uh without modifying the consensus later um and it might also require additional stake for security and slashing purposes because again we cannot slash the the validator like etherum would do um without modifying the contest clients um ideally at some point those uh well the shoulder enabled rers will become monitary on the Chain um but for the time being that would not be the case um we could also have like a step in between that of course would not be optimal but basically we could provide

an RPC that would that would you would just use in your metamask like if you were to use Flash pods for example and that RPC would then do the encryption for you and you would not have to do anything and you could just use the normal tools like always but of course this stays well you lose all the advantages basically you're still um using a centralized service you're still giving them all your information so it's not great but it might be a good middle step um to get something out basically and this is being worked on in collaboration with uh Sher and Ne mind so Sher is doing the spec and some contracts NE mind is doing the reference imp implementation and well those is doing a bit of everything in between um

so the current progress is that we already have the dkg so the decentralized key generation or more specifically shutter has it uh and actually already used it uh to Shield snapshots on ethereum we already have a spec so you can find this actually on the nosis Chain spec uh repository and we have some contracts being worked on by sh and the reference implementation or at least some P2P components that are being uh worked on by NE all right so that's it for me uh if you want some more information that's a few relevant links uh of course you can always find us on Twitter telegram this Discord wherever uh you can come talk to us of course we have a booth right here

um yeah so thanks for listening and yeah feel free to ask a few questions if you have some thanks for the overview of of no chain are there any questions inside the audience there's a question in the front here uh thanks for the presentation so about the shuttered um blockchain so if I understand correctly the idea is that if you have just one honest Keepers um then you're guaranteed that they will actually provide the decryption key and even if Rogue Keepers would use the decryption key to actually decrypt your transaction and try to front run since

you force this decryption to happen at the beginning then everything is fine so my question is if I understand correctly then uh how do we actually enforce this uh uh ordering in the block uh without changing the consensus as you mentioned right so actually uh the keepers are generating keys in a decentralized way so it's not just if one is honest so you need actually uh many key shares to get a final decryption key right so uh you need many keyers to be available and they none of them can separately get the decryption key um so well that's one thing and then the other thing is that uh we actually can force technically uh the right order in the blocks but this would have again to

be done like a in a plug-in way um to the cons clients and that's why maybe we can add like additional U stake for slashing purposes and then we could slash like out of the contens slator basically um which is yeah the idea we have right now any more questions one question sorry if I missed this earlier please let me know if that's the case but um with regarding this encrypted menol uh it sounds very promising but what we just say are the downsides of such a model and also like the things that are

included okay yeah so that's a quite interesting question actually um well first things first this is really I mean also kind of research at this point so we have uh we have a spec we are implementing it but it's probably going to change uh from change a bit um I guess downsides are well if you're not implementing this in the conator um it there might be some issues right so for example slashing becomes more complicated uh if not every validator does that then we can still not guarantee that your transaction will get in a block in a timely fashion uh if for example we have like 5% of the validators um that are shter enabled

then potentially for a few minutes well no shutter enabled validator will um be proposing a block uh and then well your block will not your transaction will not get through right because it's encrypted so you cannot get it into a block so the only work way this actually works uh correctly is to force everyone to be shter enabled but that's well not for the time being another issue is that um it adds a lot a lot of latency right so you have to um create the decryption Keys decrypt the transactions and then still get them into a block and uh as mentioned before like with Proto D Charing we already not

have don't have that much time to actually build and propagate blocks right those 1.66 seconds um and this will make it even more complicated so I guess those are yeah two disadvantages I'm sure there's more but yeah hopefully that answers your any further questions all right then let's thank the speaker again thank you Philip