Eth2Real Workshop

Transcript

come in and people still hate frog power and uh like you know people we don't want either gpus or non-gpus something happens and and they start attacking the network and we want to just move over to Youth too quickly then like this is what an emergency transition will look like right basically what you would do is we would have we would need to have eth2 kind of start having start having East one blocks starting from some uh starting from some point uh some points in time right so there would need to be at some point in time and after that point in time you would just have you would just start having kind of in each one data field that just is part of these two blocks this could be kind of

formally designated as a Shard but if this happens before phase one then there were not B shards but that's fine we could just add this data field to the beacon chain now as part of this data field um this field we would of course also have to add State routes and from a state transition point of view like the state Roots still working exactly the same way and it would actually be a validity condition of uh and of the of this chain that the these one components are still fully valid now if we do this transition a kind of really ASAP right so like within this year then eth1 is not going to be stateless and so basically every E2 node would needs to have the full

each one state and this would be not very nice because the eth1 state is bulky and we're looking to try to make if to be kind of much more accessible and much lighter than each one is and so at least in at least initially that would kind of temporarily stop that objective but over time we could of course go uh go and make the ether one inside um inside of these two stainless again so basically you you would just before you would have your blocks inside of here and then after this chain would just kind of not be for not be used anymore and then you would have blocks inside of here now the challenge of course is like how do we handle this particular Moment In

Time right so basically the well the challenge here is that we need to decide on a kind of an East two side cut off and we need to decide on some is one side cut off um and you want these one side cutoff to happen before the E2 side cut off and so that basically by the time this happens everyone on this side would would be able to have consensus on basically which initial state which initial state route to kind of import over here as the beginning state right so at this point at this point in time like basically every eth2 node would have to also be in either one full node and it would have

to have the each one full state so that it can start processing blocks so the um so what do what ways do we have of doing this right so first of all the eth2 chain already has eth1 data voting right so we already have a mechanism by which the E2 chain is kind of aware of particular eth1 blocks and so in order to make a transition one of the things that we can do is we can just piggyback off of this mechanism right so we can say for example something like if the eth2 chain discovers and eats one block whose block number is greater than or equal to n or then and and that gets

approved by the E2 voting mechanism then some procedure kicks in and then asked possibly after some period of time the yeah use it clear what these two cutoff is right so basically the eth2 chain watches eth1 and eventually the uh there's going to be an if two block that detects the each one chain has reached some cutoff points which is defined by rules that exist inside of each one so for example the it's uh it's either one voting on a block whose block number is greater than the cutoff and then at that point in time there there might be some further delay and you if you have any one block you would have it State Route

and so you would have to inside this on what state to start from within that period of time everyone would have after enough update to that state and you would continue from there so I'll stop for a bit any any questions on this transition step hmm okay I want at least one question yes how do you get the loss so basically by using these one voting mechanism right so basic so if two already has a mechanism by which the eth2 chain is aware of some if one block and that block keeps on increasing over time and

the idea would be that we would expand State one voting mechanic so that it's also kind of directly aware of not just the block hash but also the state route and the block number and whenever the block number is greater than the cutoff then like this this mechanism would kick in oh yes that's okay good question minor incentive so basically if we kind of socially agree that no block after block 12 million kind of counts right so then the other right so the other thing we'd have to do for this to be safe is we'd have to like do a soft for or some kind of fork that just bans transactions

after block 12 million or whatever because the these two voting these one voting might end up like choosing a block after 12 million then miners need some incentive to continue mining um the simple and dumb suggestion that I have if we want to be lazy and do little work is that I think the ethereum foundation should just be donate to Ether to everyone every Miner that generates a block that's part of the longest chain for some time after 12 million and that base that allows us to just maintain an incentive that's exactly the same as the incentive that exists today and we can keep that running for like some number of hours whatever period of time is necessary to do a smooth transition

um if we do not want to do this then we could do something slightly more complicated and do it in protocol right so either way it works um yes specific us are coded inside so the challenge there is that that increased massively increases the amount of time um would be between the uh within the cutoff um basically because you would have to coordinate a hard Fork on the EQ side after the E1 chain already finished right so because we're expecting there to be dapps and we're expecting there to

be optimistic Roll-Ups and like or and I heard Arbitrage is going really crazy with a a challenge period of four hours I'm I haven't personally confirmed this but there may be applications doing things like this so like the more we can the closer we can get to having a very short transition time between here and here the better um yes can we do shorter than the Thousand blocks that the beacon chain watches I don't and I don't know I'm not I'm not sure if it's uh necessarily a good idea

to do uh to do shorter than a thousand blocks like if we want we can reduce the voting period from 1024 to say 256 or some or something less but if we want an automated procedure then some way or another the EQ chain has to kind of come to consensus on some with one block in there and uh thatness um the real lower bound is basically what number of uh contributions on these one side we consider to be safe and then plus like how long it takes for the ethio side to come to consensus right like we can the voting doesn't have to be as part of blocks we can have votes come faster if they like if we add some attestation mechanism but then that just kind of

adds a bit more complexity so if we want we can push it uh say well under an hour by the end of the shorter we push the more brittle the thing gets just to kind of summarize you have like your last block then you have say 256 or a thousand blocks where you've kind of banned transactions on each one through a hard fork or soft work um and then maybe you want to keep mining those empty blocks but maybe the EF just like pays yes out outside of the chain exactly okay cool thanks foreign question um could you could you summarize how an

East one client like a guess would need to adapt to work in this new uh environment Okay so yeah a an E2 client would basically everyone running an ECU client would have to run in each one and he's one full clients at the same time so that's an increase from the current requirements which are that every eth2 node only has to run at least one white client um so basically if any if ever ethical line is also running an Ethan client then that that itself allows these two clients to kind of become aware of what they each one full state is and then after the cutoff like basically eth1 clients will have to modify themselves

so that instead of uh Point focusing on the proof of work chain like basically after whatever the cutoff block is they will kind of feed in blocks from the broom of sanction okay they just can't forget about their proof of work exactly they can forget about the proof of work mechanism and once these two side thing gets finalized then you know the code that does any proof of work stuff can just be deleted okay okay so I'll move on um and I will talk about kind of what benefits we get if we um instead of doing kind of eth2s phase this kind of

Rapid emergency transfer with eth2s phase 0.5 to the merge as uh kind of phase 1.5 right so the big difference there is basically um on these um on the East one side we have this um this road map right where basically one of the big things is we want to add uh stateless clients um and the and then there's also kind of some tinier things that I care about like there's I don't know 1559 there's um abstraction there's possibly enough more pre-compiles um but like State stateless clients are the big thing right so if

um eth1 becomes stateless client friendly then the big advantage that we get is basically that eth1 block verification becomes a pure function right so basically um on the Easter side um this kind of piece of data would actually have the blog and it would also have the witness and so you would be able to verify the block and the witness on the EQ side with just a kind of pure function call into eth1 as a library right so you would not need either one State Storage you would not need any of those other things so this makes the transition easier because first of all it means that an E2 quiet does not have to run an ether one

full client up until the cutoff up until the cutoff points all it needs is I need one light client right because if you have an ethanoid client then that's sufficient to learn the state route and if you have a stateless client then you don't need the full State all you need is the state route right so if there's some cutoff over here then all you need is you would just needs to get the route and you would just kind of transplant the root root into here and then there there isn't this kind of magic call out into into each one state and instead you would basically just be running a kind of pure function on the roots and the other nice thing that this gives us for efficiency is basically that the root

um well because you have the verification block processing as a pure function we can make eth1b a kind of one Shard instead of making it be mandatory for everyone um and because basically what that means is you can have kind of different subsets of validators be processing if one blocks and so it's a load of processing the kind of relatively heavy eth1 system can be shared and every validator only actually gets that load say 1 over 64 of the time or even well actually only one over 2048 of the time because you're only assigned to one so one on one Shard instead of it being something that everyone always has to deal with and so like staking on your phone continues to be viable as opposed to the phys 0.5 roadmap where that

becomes just totally crazy um now another thing is that as part of the stateless client roadmap there's also kind of reforms that we might want to do uh so be examples of reforms that we might want to do one big one is this is like is the hexary to uh is the hex to read a binary tree uh another one is the two level States the two level State going to a one level state so we kind of merge uh basically make contract storage just be part of the top level tree um another thing might be like I don't know account versioning um and like basically there's a bunch of kind

of changes that we might want to do to the state and there's also the possibility of like basically having some kind of pre some kind of pre-processing procedure happen at this point and I personally like I'm kind of increasingly of the opinion that the safer thing to do is to have all of these different things happen um like at some point before the cutoff so basically come up with ways for them to happen just on these one side um both because periods up as at least I feel better

than not splitting them like basically just uh because uh and if the more you split the less risk there is in each part of the transition you don't have to kind of face all the risks all at once um and then the other challenge is basically that if you do these transitions as part of the the transfer then every EQ client actually will have to have an ether one full note of some kind and this seems uh kind of less not so desirable yeah unless of course the thing that you do is you just make the transfer be something that happens on each one on these one side but that uh and if after they're cut off with that but that's also rest game so yeah I'm like my own kind of weak preference is definitely for this stuff

to just happen before the transfer so okay any more questions at this point yes um no so this stuff basically these are kind of changes to the ethereum state structure so like making the Merkel tree binary instead of hexary making this hb1 level instead of two level adding account versioning how does the sales client fit in um so for example making the Merkel tree be binary instead of hexary is just necessary for stateless clients to work because of witness size reduction

uh-huh um yes so I'm basically like I'm arguing here that if either one is stateless before the merge then which in my opinion has the risk of basically kind of centralizing ethereally on because realistically eth1 is considerably kind of bulkier and more difficult to run than eth2 is and is going to be um yes okay last question um full um okay so stateless client migration I imagine future presentations might also

touch on this but generally most contracts do not have to modify themselves at all to be stateless client friendly so the one thing that stateless clients are going to mandate is that the gas cost of esselode is going to go up the gas cost of external cost is going to go up the gas cost of accessing code is going to go up and possibly like quite a bit but on average we expect that gas costs of regular operations are not going to change all that um all that much but there might be like weird outlier exceptions and we do need kind of more tools to help and we should be starting to develop these tools now to help detect these outlier exceptions but

that's more of an more of an eth1x thing than it needs to a transfer thing and is there a plan for um this database which database the the database that provides this state that is not on chain okay good question um so by the way I like the words database yes okay so the so the only nodes that kind of strictly speaking need to store the database for the um in a in the current stainless client proposals are the block producers now if we do is if so uh how about this for our congrats so once you're syncing you have this time where you take blocks

per range so you aggressively ask for blocks any blocks any time from your blur just hope to end up over the final of State uh you verify the books of course but then like once you reach this Justified part they start to become this period where you may not have one local chain that people are in doubt about where to go so you have a little bit of working and then once here at the very end you start gossiping about the very latest blocks and you can have more of working like it either it is there are no Forks there's fast aggregation of stations to determine the canonical chain but sometimes you end up in a bad luck or there's some attack and you need to transition not just fast forward that

you need to transition fast with all these black all this backtracking to recover on other states and foreign so let's analyze the beacon state so what are all these fields that are being tracked and what makes thinking so tough so there's these few tiny Fields don't worry about these like we have the Ford versions of data a little bit about ethereum one floating which are like very minimal constant size data instead what you want to look at are like starting off with medium things like these things only change one at a time they make up like 10 percent of the storage size depending on how many photographers you

have on the State and then the larger parts are also super necessary and then like if you're in one um if I'm too uses binary tree I'll explain differences between three types later and what you have to I remember her is that's previously the minimal

configuration we only had like say a thousand validators at maximum right now we have tested marks that are trained which offered a hundred thousand validators so to do this correctly is really important um so let's talk about data structures so there's this idea of persistent data structures or say functional data structures or immutable that structures you may know so what happens is that there is this collection that's backed by three and then whenever you make a modification you make a new tree represented by new rules referencing most of the older data so you don't copy as much around and this works redeveloped with Mercury

station whereas your binary Merkle tree you have to redo a lot of work if you don't Dash anything or so if a tree everything can be tested in place you can put the hashes right at these binary nodes and you end up doing minimal work so in here you only pay for this new Branch from the uh star to E uh to do a more efficient website so compare this to ethereum bomb which has this miracle partition tree I really like this old visualization because it explains it really well but it doesn't show is that the three inefficient so for uh your binary tree or for your Mercury you want your Windows data to be

minimal so that means that if you go back from a leaf node to the root note you want the least amount of data possible to prove that it's there to do like this first minimal transactions on chain whereas this thing is more optimized for storage so it tries to defragment the three by putting nodes together is both witness size but it is kind of nice for storage so if you try and explore these titles between storage optimization having this recommended memory the amount of changes the difference in finalized State and so on so let's talk about pruning so if your

bonus this nice property of pure finalization so at some point you can just trust the states and come back to that and forget about everything that happened before the state in the beginning um however if you do forget about this you are not an archive note you can only like serve others with like blocks from your storage but you could can serve them with these older States you can because you don't have straightforward fast access to them uh so instead what we can do if we do want to take the optimizer out is use a finalized State and only put the devs on top the differences to minimize the amount of binary trees used and have this faster iteration

okay so that's all the optimization and three stuff let's talk about the Fatal data clients for a moment so besides just running the beacon chain and sinking nothing it should be like a little bit more clear now to you we also have these separate clients which produces data on the network and participates in the network it's not just thinking it's response to duties or like these tasks it gets from the beacon nut so the challenge here is like how does it get these duties how does it know what to do so that's a little about API design and hopefully later when there are these different clients but compatibility so I can use different bigger notes there's

the same validator and then Ethan vendor is a book or some problem with unbeacon notes you're able to stay online with your fertilizer and then our security of course you don't want to separate the validator away from the beacon notes away from the network and protect it from all these attacks so let's dive into apis so there's this api's repository you can take a lookout it currently it only offers this really minimal API so how to work with your validator in the future we try and expand this and we really need inputs from even from adaptive developers to now like what kind of data do you need how do you like it served what's the best process here for now it's just this really simple API

then last but not least testing so one more challenge is to just get it right and you never know like how many books are lurking there or like where to go from here so what they do is we have uh these shared unit tests so clients are not just writing their own tests they also share these consensus tests then we have first thing shout out to Maddie and others from the sigma Prime and they're doing great work trying to learn more about the beacon notes find these little books and test the different clients then we have test nuts so other testing data that's public is on this repository we try to actively share that have

community members open up a test net try it for themselves and then we have the start of network tooling so previously we had white block and others produce these custom tests or these more specialized tests that right now we're looking into testing the full suit of networking and you can try this Ripple out so to like start your own mocked notes be part of the PHP Network interactive existing real clients and see how they interact with the supposed specified networking protocol um and then there's audits so I think it's to be announced but we will have at least 30 audit results very very soon

and with interesting results about networking about possible those factors but they are actually working to make this like as resistant against these attacks as possible and there's many much more like this work just testing and integration testing of different kinds I'm going to match into detail if you're interested do reach out and are always looking for more like initiatives for people who like to test the different parts of firm tool that's the thing this is the finish and uh Vector completed congratulations you're now expert Professor uh for you if you are interested there's

this specs repository there are many different documents that explain it in human words instead of unreadable cards um and you're actively trying to like onboard more people find more contributors and you're very welcome to take a look at the if you're into a specification thank you [Applause] oh and the next one we have and Scar yeah from quarantine to introduce the status in these two hi everyone um yeah I just wanted to give a brief overview uh that's pretty last minute so actually some of what I uh had here that

that's the talk I gave it 222 last a week ago in Stanford um part of that will already um present it but I'll just skip over those parts so basically uh wow yeah so um we had this post um a few weeks ago about State provider models in E2 and we already talked about how basically we have these three different models here the diagrams that you couldn't see earlier so here they are um so basically uh that's the die push model that's what we would go with in SSA so there you basically only need State providers to like get some initial state to the users the users still need

to get State somewhere in a stateless World they could basically if they really want to they can just like listen to the chain just keep the state they they need for themselves but if they don't have sufficient State they like need to get it somewhere then they just create their transactions they already include all the state they need and then the transactions just as they need one just go to the mempool and at some point The Miner slash blog proposer just takes them bundles them up produces a new block that's it that's the simplest model but it requires SSA um then we had this relay push model um I mean it's a bit more complicated basically the idea is you submit the transactions to like a relayer state provider they attach the state and then

they send them off to the network and then we had this third model I'm going over those a little bit quicker because they're not as relevant to this talk right but the pool model um will mention that as well where you basically have the blog purpose that would be responsible for pitching the state um you already know this so um basically the the different different advantages disadvantages um for direct push um we need SSA but then we get a lot of things that we want to have so uh yeah that's why we started looking into it can we actually like get away with moving to SSA is it um uh feasible what are the bad benefits

um uh first I wanted to like give a quick um definition again um it is rather imprecise given that the whole wording around static State access it's a bit unfortunate how that all came about so we are still looking into other wording and stuff um but that's just like one rough go at it so like basically uh if you if you to Define it on a transaction level like any given transaction is like uh purely SSA if if you can basically and you see already how how imprecess that that that that becomes if you can create a reasonably small witness for it that basically is always sufficient to run the transaction so what that means is you might not be able to completely predict what stated access is but maybe

you can at least uh predict like it'll have it'll have to access one of these 10 different locations in state and that's fine because like a witness with 10 look 10 said locations attached is still really small you can send it everything is fine but if all or those 10 locations maybe become a million then you can't like send a one gigabyte witness right so so the pro so basically um static State access really just means reasonably small witnesses that are always sufficient so um that's where where that comes from and then obviously uh if all functions are all possible transactions you could create against a given contract are SSA then the whole contract is SSA and so our goal for E2 would be to have all

contracts be fully SSA if that's possible um yeah naming we had a few different ideas here um we'll see how that evolves uh hopefully not as uh bad as the plasma thing oh God uh okay so then um benefits those are just like a few that came to mind so first you have like the simplified State provider model you have synchronous cross-e communication and it's also helpful for account abstraction a bunch of other benefits as well um it's just uh if we can can have it it's really nice to to go that route so the question is uh can we actually get away with it um so basically what I've been doing for the two weeks before before Stanford

basically was to look a bit into like um does the limit functionality are there any existing projects that would have problems in an SSA world and then what Sam has been doing um was to like look into developer experience um this 10 analysis solid thing how can how could developers deal like develop contracts in an SSA world and so as will already mentioned I was looking at um a few of the most popular um Texas um um first just because um taxes are like um one of the examples where we were thinking well maybe there are problems there because uh you don't really know

the counterparties in on all examples right so so those are like really Advanced examples of count a defy ethereum usage so the biggest one was uni swap so we started looking at Uni swap as the largest Unchained exchange it is an easy example though because uniswap is not like a full decks in the sense that it's it's one-sided right your counterparty is always these the unit swap smart contract so you don't actually have this full two-sided Tech experience here um and we uh you know in order to like analyze it we actually didn't look um at the um original uni swap code because that's written in Viper um for version two they'll transition to this ellipty

version but there is like an equivalent to literary version as well so we just went with that for the analysis um it basically just consists of two contracts that's why it was easy to look at right you have this Factory contract where every time you want to like create a new uni swap exchange for a new token that is not yet uh where there isn't yet any deployed exchange you just call the Factory and then you create a new exchange for that eic20 token basically and then that deploys a new exchange contract so looking at the uh so basically the idea was to that we quickly we walk through the code there so you can actually get a feeling for like what what what actually does it mean to be SSA instead of DSA right so that's like one part of the factory code uh that's like the main function that's

where the factory magic happens in uni swap um so you create a new exchange here um basically you can see in the beginning if you just like very naively go through it and and think about like where here could we have problems in a like like uh where might we not be able to predict State access right at the beginning you only have requires you would always just those are no problem um and then if we go a little bit further down we come to to this line right it just deploys a new exchange and uh here we see like one of the many examples of how as we were talking about earlier like for existing ethereum one like the DSA SSA just wasn't the like consideration right so it's trivial to

like have like a contract deployment bssa but like the normal version the create op code obviously like depends on the nons right so so if you have our contract you deploy other contracts then the address you reply at depends on the nodes of the of the contract so you can't predict at the time you create a transaction where the new exchange will be deployed at right but for example even in solidity you can totally change that because we have been having this nice create two for a while so if you just basically include the fixed salt then that that's used instead of announce in that case it's just like as an example you just take the address of the token as the salt and then that's all of a sudden SSA

so that was all that was needed to make that line SSA so that's just one example of how most of the changes that are actually needed to get to SSA from for current contracts are really just like technical like tutorial things right nothing nothing conceptual that's going on here the only other part here where we also would have to have a look is down here where we actually use an array to store all the exchanges that were deployed um and the unfortunate thing here again is that arrays as they are working right now um on insulinity on each one would be DSA the problem is again like if you push to an array right you don't know actually like maybe three transactions

run before you and they also like push to the array and then you don't know the index at which you'll push the array but I mean there are a few different workarounds um I mean you you can solve arrays for for SSA too that that would mean issue but but you actually would have to adjust it somehow uh but with those two changes basically um the whole Factory contract for units were put already be fully SSA and then to just very briefly look at to the actual exchange contract as well just to to the the thing complete so first of first to note is that the units of exchange actually is in esc20 so it inherits from esc20 because uh I'm not sure if you know uni swap they use like

this internal liquidity tokens if you provide liquidity you get these tokens um good good news esc20 in its current form is already fully SSA so no issue here uh then we just go through the contract a little bit um one more thing that's just another General pattern um we are like here we have like a very simple example of uh branching right we have an if statement um uh exactly and so so basically um because it's branching right in this case it's very trivial you only have two cases either you get a refund or you don't right in and you can basically just create weaknesses for both cases but again you'd have to think about what

if you're very complicated branching Behavior where there could be like a lot of different cases so maybe you'd have to you'd have to like find some way to to to to to deal with that um and then one one more thing that you also can see the same same thing here is the the transfer function um and again basically all that's relevant here is that if you actually send it to the buyer uh in in ethereum right now you basically if the buyer is actually like a contract you'd execute it a fallback function I think it has a new name right with the new soluti version but basically the four big function the function that's called when you get eth and in case that function is not SSA itself that would be a problem here as well

um yeah but but basically with with those a little arcadic caveats um basically uni swap would already be SSA so you'd fix these you just find solutions for them and then unit swap just works in E2 even if we go with SSA so um that was encouraging uh we also looked at a few um oh wait wrong direction uh we also looked at a few other um uh Texas but I don't didn't want to go into too much detail but just uh it's fair to say like the second largest idex um it's a full decks but as the matching of the orders is actually performed off chain right so you find that counterparties that want to trade with each other and then you just basically

match them and only then do you execute the trade on chain um that uh all of that also would work in SSA so that's the contract here but it it just would work um so that's that's basically our first impressions uh SSA for E2 seems feasible and because we have all these benefits right now we basically want to explore like like go down the route of using SSA obviously if at some point we find any problems with it with it we might still like change our minds but for now it looks like SSA is the way to go for it too um further analysis is however necessary um also like one important thing that I wanted to not like forget about is like

are there maybe further use like future use cases use cases that aren't used right now by your projects on the chain that would be problematic in SSA those obviously we also want to be like future proof so we look into those as well uh if you have like any um questions or comments or whatever you can always reach out to me to discuss that further but that's basically all to for regarding the feasibility and then um I'm not sure Sam if you want to quickly talk about the tent analysis uh not sure if with the amateur who you're in the room has like overview about the time that's left about 10 15 minutes oh yeah

um if you want to like maybe like just a few words uh yeah oh yeah sure if you have any questions uh regarding uh this SSA thing right now obviously sure I'm not sure if there's like a mic we can uh yeah um are these solely the SSA shots for for these two worlds or does this equally apply to East 1X transition to a status model

um so this is this is just like if we transition each one to a stainless model it could still remain or keep its dynamics that access patterns so just because like moving all contracts to SSA pattern seems to be infeasible right I mean every con like most countries would have to be redeployed and so the plan right now is most likely to just keep it ethereum one as DSA for like for the foreseeable future and still move it into e32 but have like special handling of that so we we can support DSA there but have the rest of the E2 system bssa so but I like our top priority obviously

is not to break any existing contract so we won't just to add to that uh if it doesn't clear so it's in DSA and sa it's only really different for the proposer for and for people that create transactions but on chain it's the same on chain it's still the same business data you get the verify the block and so making this account special guys would not necessarily mean this huge amount of Legacy software like on chain we can introduce it sir well and also just maybe maybe that's too too um confusing but even in E2 even if we

go with SSA you could technically still like have DSA transaction make it into the into blocks because they would be just as valid it's just that usually basically they wouldn't be able to make their way to the bug proposal because by then the witness wouldn't be sufficient like wouldn't be sufficient anymore but if you for some reason basically if some book proposals wanted to choose to also support DSA in some complicated form they could always do it so basically SS is just limiting ourselves to make the system more easy we can always then go like add functionality back for first is true um hello I'm quite skeptical that SSA is is feasible uh if we want to retain the

current um functionality of the Ethan chain I mean there's there's plenty of examples and I and I could list a few that I think would be difficult to do um but as a sort of General remark we can think of anything that is front runnable being something that would be um DSA right because the the semantics would change when when uh another transaction is squeezed in and there's quite a few things that are front runnable um but maybe the more General remark is um say that we don't uh

given that there might be you know even if if they are constructed uh examples that wouldn't be possible with SSA what would be our sort of rationale for for calling those examples pathological and saying that that we don't really care about their functionality because there will always be somebody's app that will break if we go with pure SSA so I think that's like a two-part question as a first first of um I agree that there might definitely be examples that are problematic but I assume I assume at least you might think it's more more problematic than it really is because the issue is not with like the state changing before you run

your transaction because that's not an issue if I basically create my transaction and I believe the state will be in a like in a specific state but then before my transaction actually gets run the state changes that's not an issue then you can like like nodes in the network can always just like update my transaction while it is pending so if I basically want to do this will I want to send a transaction to UNI swap but someone else does it that's a transaction first then obviously the price like the the rate at which my exchange will happen will change but that is fine because my transaction doesn't actually like it it has data with it that it wants to use to run the the transaction but the data can be updated if someone else changes it

beforehand it's only problematic this very very specific use case if the location at which I want to use the data changes that's like a small subset of uh well I I think that's that's a larger subset than you seem to apply uh for example the deposit contract uh has this this feature that when you play something in a deposit you know it's dependent on the the deposit count and so if somebody goes before you then it ends up at a different location uh also all the auction contracts um where the the winner of the auction is something determined by the current highest bidder and and stuff like this which is powering um the maker for example or or stable coins

like this um I believe for most of those you can actually uh work around that and make make that SSA I'm happy we can we can hopefully talk and actually the whole point here was to like explain what is SSA good enough that enough people understand what the what the question is so that we can then see if anyone can come up with real problems like like use cases legitimate use cases and that's the second question you had was the difference between a legitimate use case and like Edge case um to then see whether whether it's feasible um and that that just like very briefly remark on like what is the legitimate use case uh obviously we always have to like choose trade-offs I feel I feel we can definitely go a little bit with um not not like supporting use cases that definitely

look like they are just arbitrary constructed just because this is just how like what kinds of use cases E2 will support right you can always remain on the eat one chain even Within These two system and have full DSA support so we don't we don't we don't like want to break any existing use cases it's just like what will we enable for you for additional use cases for each two and so we can be a little bit more like aggressive in not not supporting anything right just just for for legacy for legacy reasons so we would actually look at is that a legitimate use case and as soon as there are problems with those we would reconsider but if you just come up with like a artificial constructed one and we actually came up

with artificial things that wouldn't run anymore right if you go with block hash things and so so you can construct use case that might not work anymore but those are really weird edge cases and we can definitely let's talk afterwards and see whether any legitimate things would also be problematic sweet thank you awesome I think that's it for my side I'm not sure if now same or not well I'll I'll just be gone but thanks again [Applause] thank you everyone for attending this and sorry we don't have enough time and

have a good uh time schedule here yeah thank you sorry because I think everyone goes to botanics show and I'm sure yes this picture