Address Space Extension Working Group #5

Transcript

hi everyone welcome to the fifth um address space extension working group call uh this this is kind of the last uh session for for now uh schedule is like the series of calls we basically have one big kind of topic complex left to discuss and that that is the um like the translation map itself and then like the exact form that you take the ephemeral persistent expiring these kind of variants with uh access lists and all of this and i'm sure kind of alex will go into into a bit more detail here in a second and um if we have some time at the end then we can also kind of come back to some of the other topics we discussed on previous calls

so um alex do you maybe want to take it from you yeah i think the the first one is as a simple one so it's point three a um which is a question about um what happens um so the starting point is that we have like this in-state translation map that's what the original specification was suggesting so let's start from from this understanding and then what happens with access lists you know any any long address in the

access list should we do we consider that to be added at the beginning of the transaction in the translation map and should the translation the transaction fail those additions are also reverted i think this yeah this is a generic question what should happen to the access list if you have an in-state translation map right um i i i personally think this is kind of multifaceted like like basically just uh just to say this briefly like my my ideal design decision here or like design goal would be to have have the access list or like the transaction map be designed

in a way that once most people have migrated over to the new space and basically very little activity still touches legacy space i would ideally like for the kind of translation map to shrink or just kind of go away over time where we don't or at least like at the very minimum not not constantly keep growing basically if it's no longer needed like five years from now saying right and so in that context i'm a little bit worried about just populating um the translation map with with all exodus list addresses uh at the same time i feel like

it it it really looks like a very nice thing to basically be able to do that from the outside to kind of like give some context into into the transaction or filling this this map so maybe we could have like a secondary kind of access list or something um yeah it seems seems to be tricky though but but in terms of technically how to do it i i to me it seems kind of it seems like treating it similar to other kind of state changes where if there's a transaction itself rebirths these changes also revert that to me seems like logical on on first glance yeah i guess what your i mean the distinction is if we don't introduce anything we just

have the the current access list then there's no way to at least no easy way to tell whether something will be accessed from a legacy context and the the easy decision is that then every single long address in the access list is added to the translation map and and that also means that many of these may not ever be used so we're just keep polluting the translation map um which is probably something we don't want to do because we discussed this um earlier as well that we we don't want to just keep rolling the map and as you mentioned one option is if we

separate um separate these um lists and there is like a separate one which just says you know what should be inserted into the the translation map um and we also had a small comment that the i guess regarding the revert case and even that is not not fully clear um because i think in other parts of the design [Music] we were i guess on the side that if a transaction manipulates the translation map

a revert should like a failure in the transaction should also revert that change in the map because that's in line how just um snapshotting works currently in the system um but there's i guess one one exception to this is like the nonce in transactions that is that is never reverted the nonsense um so one could argue on for both sides whether um this additional like translation map list in the transaction that should be always inserted or that is also reverted that's a good point actually the analogy with

um with the nouns like for example if if we end up basically also giving the translation map some interface way where a small context can interact with it and that includes some way of adding new in entries i feel like we all probably agree that that should have definitely revert because that that would then be happening inside the transaction and so if the transaction regrets that should we work but but of course the access list they didn't yeah i feel like the nonce is kind of a good analogy here where in a sense right you're paying for the access list cost still like like that that would have some extra cost right that kind of accounts for adding this state entry and so you don't kind of get that money back if the transaction fails so in a sense

yeah yeah and it's yeah and it's not something that we would ever want to revert right because it's like once someone has indicated that they kind of potentially want to access to use that address in the future in the legacy context it seems like you're always just safer of putting it in there especially if kind of like if the cost for it has been paid so yeah interesting i know from this non-technology kind of i think put me on the weak non-revert side of things i do think that um as far as when the transaction app gets updated it

should happen beginning of the transaction so that way you can stat a static call into things i'm gonna be static call into something legacy contract then it you can't update the transaction map at that point because you're in a static call context and that would be a state update and so we should make sure there are ways to update the transm transaction map prior to the transaction executing actually that's a good point i think we listed somewhere and maybe yeah i think we listed this in the spec and we forgot to put it into this document um but we had this question and what should choose to see and that's

for the static core to be able to yeah steady calls listed there at least oh yeah yeah i think that's that's maybe something we may want to come back um now that we understand like this much better right in a sense it doesn't even it's not even obvious to me that static calls should not be able to populate the list but but yeah we we can come to it later yeah that might be that might be another like

complicated point um in a sense right like i i think i think it's kind of the kind of the nature of the translation map even though it is kind of also state it is it is in some sense very different from from normal state right where i know the owner of some token or whatever this this state that that can be updated and change in whatever ways the map is really i mean unless someone kind of mines for a birthday attack or something that should always be a fully deterministic one-to-one mapping where it's not that someone has the power to set the end pre to kind of like change

where that points to it's basically just that it's purely informing the network about what the mapping is and so to me it doesn't really feel like modifying the state so much as just i mean of course it does modify the state but but yeah one i think the primary argument in my opinion for having it revert is if it is stored in state um it may just be simpler from like a architectural and coding standpoint to make it so all state changes revert like so you can just throw away your entire change set you don't have to worry about okay some of it needs to retain some of it doesn't um presumably you're right we do have

the nonce thing which is some piece of state that doesn't revert along the transaction um but i'm guessing it opens up more avenues for like ways you can architect in internally you know architect clients if we have it revert so there is um i think the next point in this list is is maybe like a good point to tie into that um which is point three b uh if we have let's say this so maybe just to close off like point three a um for a second um it seems that we we likely don't want to mix um like the currently accessing access list

functionality with this we would rather have like a separate list um which says you know what what needs to be inserted into the map and and if we have um such a transaction then we could consider this next point which is 3b what if we simplified the system in such a way that the translation map can only be populated from this list in the transaction so there's no other way to insert an entry into it my fear there is that it will mean that our transaction map is generally less populated and it's more likely people run into all the problems we have been discussing well we are still okay are we still

operating under the assumption we said yesterday that we follow this optimistic case that we are able to distinguish compressed from legacy addresses uh i'm not convinced that's a viable path yet but i thought we're gonna talk about that today yeah i guess what is like this 0.3b if we are operating on under this optimistic path then this seems to be an okay choice because um legacy contracts will be able to tell that you know it doesn't

exist so it would just and try to fail i mean that's also yet to be discussed what would happen but um in in that case you don't need the map to be you know populated like at every single location it is fine to explicitly populate it in such transactions but let's just briefly kind of like recap here the the exact occasions where the other like the the default plan would also populate the list is just for it's basically just for up codes that return um short addresses in legacy contracts

but they are now kind of like technically would have to return long ones and so they instead return the compressed one right so like call our origin address and these can pop codes and so in this spec we actually have two cases um so in the new context uh i think we said when yeah i mean when you call um a short address then it would already insert your account into the translation map and then from the legacy side as you said any

um any op code for like incoming addresses would do that interesting what's the kind of the reasoning for putting your kind of caller address in there already like because either it's never accessed and you don't need it or if it's accessed then it's accessed via like caller or something and then you could just add it later like at that point because i'm i'm kind of like i'm sympathetic to your kind of uh i don't know i mean i i generally like your point of trying to keep it simple and basically not not polluting the list there i'm on board i just feel like

basically every time the system already does the compression so basically like if you if you call caller and then basically the system sees oh caller was a long address but you but you called it in legacy context so you're expecting short address so the system is actively internally the evm is internally computing the compressed representation at that point i feel like the likelihood is so so large that at some point later on this value will have to be converted back that we have like a very strong indication that it is needed in a translation table so i feel like just basically adding it every single time the evm does the compression seems like a very low pollution way of doing things um

the other advantage of angstar's um proposal is that it actually makes like the properties of the translation map like reasonably easy to read about reason about because the rules that are then that you are if you have a compressed address and either that compressed address has been attained in the course of executing the evm you know it's in the translation map and then you just require that anyone who comes into the system from the outside and sticks a compressed address into the evm has to make sure they also include it in the um translate in the access list for and then it will get

stuck into the translation map and then you can relying people do what they're supposed to do have pretty strong guarantees that when you access a compressed address it will be in the translation right of course this is again on the spectrum of how much do we want to add extra overhead to reduce the likelihood of making mistakes so similar to how basically this whole question of do we want to make compressed addresses kind of distinguishable by prefix or whatever this also adds overhead um but reduces kind of error error probabilities and i feel like this this whole kind of conversation here again is is a similar kind of trade-off where

i do agree that basically it's it is preferable to have a a simple translation map and ideally a small one at the same time relying completely on the users seems to be very error prone to me and so then it seems like it's not not not worth worth basically the savings and complexity of course how to tell with these trade-offs always i think i'm tempted to take the position that firstly relying there as a gas cost for putting something into translation map and that gas cost is priced correctly

but it doesn't actually matter if people stick too much in the translation map and secondly if that gas cost just means that interacting with legacy accounts becomes more expensive that's just creating an incentive um to switch over to the new system with everything because it will come to if unit swap switches to a new account it will become cheaper to interact with uni swap and eventually of course um we're going to have state expiry which is going to make interacting with legacy accounts even more diff more expensive and the translation map will slowly shrink as less and less people interact with legacy addresses and so

less entries get added and the translation map that already exists is going to recede into state expiry see that's kind of confused what is what is anscar's proposal or what is that yeah i don't i don't think that there's technically an um a proposal by me i think it's mostly just kind of like going with your with the epsilon with the main epsilon proposal instead of this additional alternative proposal of only feed only um adding things to the translation map via access lists so it's basically going rejecting 3b i think is is what

and peter there referred to is my proposal so not to have 3b what but rather just populate the map based on the op codes well and the 3a what we discussed about that they should ideally be ideally not this not the existing translation an existing access map access list but but like a new second type of x list on the transactions that also populates it so doing doing 3a i think we kind of yeah you summarized that well earlier that we agreed that it seems very useful to be able to do that from the outside as well but basically not not going with the more extreme version of 3b where you completely disallow population from any

other source yeah and specific proposal i was talking about is that we have a rule that whenever the evm in the course of its execution um takes a long address and compresses it to a short address it also adds that long address to the translation map that is part of the spec already that's the the core idea but that's what i'm saying it's it's not really my proposal too much it's just the existing epsilon proposal um just kind of without this modification well i mean this is the this is the original proposal even from vitalik so that's that's a

core idea of this translation map okay maybe just one question on 3a [Music] i guess this this new list in the transaction that should only need to list the long addresses and then transaction processing should derive the the compressed one based on that right that seems great to me and of course that also runs into the same question that we still have to answer of what what happens if there ever should be a conflict

in the table but besides that i yeah i think that was a great this is a trade cpu versus network bandwidth yeah well and if you let's say you do have like a map of like long to compress then you would also need to verify that that that mapping is correct right so there doesn't seem to be any any point including the compressed one um in the transaction right um yeah but regarding 3b um yeah can you clarify why do you think it's um

it's better to still have the opcode directed one as opposed to have the user directed approach because 3b is basically delegates the task to the to off chain uh whereas the the op code based one is is keeps it on chain right so i just feel like um there are many scenarios in which the user is not in control of all parts of the authentication flow basically and so especially if sometimes errors just silent or like transactions just silently fail what they what users might do is they could

just make parts of the transaction kind of fail right so i don't know i i do some swap or whatever but i don't want the other side of the swap to actually receive the funds so i don't and that happens to be some interaction from long to short to legacy and so i just don't populate that part and so then that part of transaction might fail but for some reason that's like self-contained failure and and the that doesn't like bubble up and make the whole like overall transaction fail or something and so then i get my part of the swap but i don't have to pay out the other side or something i don't know i'm just making that specific scenario up but basically i'm just saying that the user might just not be interested in making all parts of the transaction work at all times so so it

feels kind of fragile to to rely on the on on the user to to make all of this work and in addition it also seems to run into this kind of issue around dynamic state access by the static state access where sometimes it might just be really hard to tell which x which which address actually might be required and so it's it's hard to kind of statically give yeah put that in a list when when creating the transaction yeah that that was our concern and i mean that's the same concern for like the ephemeral one do you have actually like any insights

if the the current access list is used in practice currently i mean it's any like tool or wallet generate the for example full access list to make the cost cheaper well bullets can i think they did no i think they did implement it but i mean matt is not on the call but um i don't remember matt had a an eip proposal he identified that the access list the pricing of the access list currently sorry the pricing of the access list currently makes it not too useful below like four

entries uh it's just more expensive that way and he tried to reprice it um but yeah i mean i i would expect that not many people use it and maybe one last comment on it martin svendes said that his i mean as a response to this proposal that his motivation for the access list wasn't um like a gas savings feature rather a just a backwards compatibility feature should something break during the increase of the gas prices

i think uh geth might have an implementation if you're just looking to create an access list i think you can do it through the json rpc i think pavel's question was better are there transactions actually using the access list today any you know what percentage of them i see i didn't yeah i don't think anybody is but also just to to of course i mean this is still a really new feature i mean when was berlin again the sim feels like it was like two months ago or something so and any new feature like this especially if it's that only has marginal benefits and as you were saying is

still mispriced a bit today will take quite quite a bit of time for take up so i would i would hope that a year from now a few more people use x list than they do today but i do know that there is some usage of it even today already okay i'm i mean as we go at least today i i kept updating this list um i think like a line called update or note to each of the points um about what we discussed and uh yeah i guess with 3b the biggest concern is

um but validity of this list um especially like dsa and maybe just need in the case of dse and maybe this needs to be explored further um if there if there's maybe no more comments on 383b i guess we could move on on this tree c and which is the ephemeral map um and then go into an expiring map as the as the last option of discussion um does it sound like a good way sounds good to me and then i also just if you want to reiterate that i to me it's really two separate concerns that like for one this esa ssa like the

predictability of it but then also the potential for malicious omission by the user basically for in some in some situations so so these these to me are two separate concerns about depopulating from that so the militia is the most malicious omission if we do have the capability to distinguish compressed from legacy what um what issue um can happen in that case i think so basically the way i see it's like again i'm not an expert on this i'm just just kind of brainstorming here but i i would worry that some legacy transactions

now fail they try to send each and it fails because they can't i can't kind of look at the lookup of the compressed address fails and because usually there's just no reason for for the transaction to for the transfer to fail something that might this this might end up failing silently i mean i'm not sure this is like a common pattern because solidity usually just by default throws if if the call fails but then maybe some the surrounding function could catch that or something so i i don't know if this is at all like a practical worry or not it just feels like you can make things fail or even interactions between contracts that trust each other or something so basically you you can make you can make like

things fail that used to never fail and so that that way kind of legacy contracts might not have the required precautions in place i don't know this this could be completely off this one might might be might be baseless but it's just a worry that that i'm having currently yeah i'm not sure i got a good idea about the militias omission but the validity is is um i guess a big enough concern anyway sounds good but then yeah let's let's

move on to the ephemeral because that's definitely a really interesting idea yeah the ephemeral has the same problem regarding validity but otherwise the idea is that this translation map is ephemeral that means it's always empty and combining of what we discussed so far basically always start off with an empty translation map and it is populated based on these submitted well okay so i suppose this ephemeral has also two

subcases so the first one is is what what i said so far is that it's populated based on the um this list submitted as part of the transaction and then um the in the on chain um i mean these op codes they wouldn't populate it so that's case one and the case two is that those op codes do populate them uh the the translation map but at the end of the hmm and that's a good question are we yeah i guess at the end of the the given transaction so this is um and the translation map is specific to a given transaction and

not to a given block or anything else so at the end of the the transaction i mean the trans translation map is empty again it is really just for for that given trans um transaction and the because the benefit we get is we don't need to be concerned about any of the state pollution aspect or any any space or even io in the state because nothing needs to be looked up everything is in memory and yeah we weren't sure but maybe it can be simpler because um in this case we don't need to get rid of revert rules um because we can just keep this uh translation map in memory throughout

the um the transaction um so that that might be a difference and the the last positive effect is since you need to submit this list with every transaction um this is an incentive to migrate fully to the long address word because in in the the new execution context you don't need to submit any of these things and it's much easier much easier to interact with with that side of the network but it definitely is um much more complex to interact with the legacy side but but yeah the biggest

negative effect is and maybe transaction validity right and so just my take on this um as you yeah as you were saying basically it runs into the same problems why i still think it's interesting is that basically the payoff is my my kind of view is basically bigger because we get rid of all of these worries about the permanence of this extra state object where you just have this map that always just ever grows and um and you have to carry that on forever which is very antithetical to the whole like motivation for a state expert that led us to this address physics extension um in the

first place so i feel like there's more incentive to try and make it work just because because it would be real nice if we could get this feature that we don't need need this this state object um i personally like i i like in my view at least i mean i just realized this now um as you were saying alex i think like like two minutes ago something that um this also depends on whether we end up being able to distinguish compressed addresses and just chart addresses right like with this prefix it to me it seems like i think i would be very strongly opposed to any of these kind of ephemeral only kind of pro proposals if we don't end up with

that so if you really can't distinguish short and compressed addresses because then it seems like we just basically always will end up sending things to compressed addresses or something but if we end up being able to distinguish it to me that seems like we might end up in a world where just transactions really fail unless the user is careful about sending the correct um or like yeah producing the correct uh access list and that might be more okay right because then it's just basically it just means tooling has to be good but at least like if it's not good enough you notice so so i feel like yeah um and again i i think i think we like i

would really try want to try and kind of make this work um and of course my preference here would again be the version that also populates from up codes just because that seems to to make it much easier for things to normally not break in the in the happy case basically but um but yeah i think that's all my thoughts yeah so based on comments uh uh the the the feature that it populates on up cause i think for this one is it's pretty cheap because it's never stirred so uh never stored in the states so i think that makes sense uh so i'm just like um

based on on comments from from you as well that in this case having the ephemeral list uh a firm up to be to be to be populated based on the the transaction list and the upgrades i think it's it's it's a good idea because it doesn't really cost much more to to include up codes in this process yeah that sounds that sounds good yeah that's that's a good point actually that that like when you don't have to store it then permanently that makes it cheaper to er

on the side of caution and just add more things even if there might be unnecessary yeah it also makes the transaction list shorter or maybe even empty in this case right because you might only i mean it's it's in the end it depends on the like the quality of the tools producing this and like the determinism of the execution uh so this is like big issue i think i find with these um some some some of you like had more concerns about that i'm not really like familiar with the practice with how this uh even the gas estimates are not really accurate at the moment that's my observation

so it's it's also maybe some sometimes difficult to to yeah to have the the uh proper list of for the translation one but anyway so i think uh we might need to to keep this two different uh kind of specification for now uh that's that would be my preference so improve the the original spec but also keep this affirmative version i'm not sure how to decide later which is better maybe some simulations on existing uh yeah i don't know what i think that would be

somehow resolve some of the some of the questions at least for now right and also i think on the other side basically a better understanding of how how big the trans like a persistent translation that would become and how much that kind of like will be a an overhead that that will be with us forever right if we at least had a good understanding that likely this will never be bigger than 10 gigabytes or something then we could say yeah sure it's not not ideal but maybe it's it it might be okay or something right like so so basically also i feel like a better understanding of the

exact cost of the of ap system like translation map would also be informative for making this decision so just to to maybe write down what we discussed before we forget it i mean we can always um listen back to these calls and then fill out the bits but um is a good summary the the following that the ephemeral translation map should should be just happened only during the the lifetime of the

transaction and the more ways we can add entries um the better it is so we should do it on every possible instruction um just so that the the number of uh inputs required is reduced and the and it doesn't matter you know how how much you pollute this ephemeral list because it's thrown away and it doesn't need to be stored on disk anyway is that like a good summary i would be a little bit more cautious in writing in that way just because like

you could kind of really go overboard with what to add right you could even just say like every time you do a call you just like chunk the call data and just edit in case there's an address in there or something so these kind of things right so it'll be like within reason i would say kind of populated with whatever makes sense um but generally yeah i would agree yeah i think the call data would be a quite a bit of an overreach yeah i think it won't be much more than we already specified maybe like the specified list is it's already full of that i mean i think it's it's a matter of adding addresses that evm kind of things

are addresses and maybe some like pre pre like initial values for uh transaction origin yeah uh d minor and stuff like that right although we might not have miners put the coinbase address basically yeah okay so what i when i wrote ephemeral map should be populated via all address producing instructions the coinbase and the submitted um list is that like a

concise way is the coinbase 256 bits no i clients it's an rlp field right in in the header so i guess it's unrestricted there well i mean the header also has difficulty as 256 bits we just found out recently that geth implements that internally with 80 bits and it is very hard for them to change that and so i'm concerned that they may have done something similar with the coinbase so addresses are one of the very few things which are actually specified in length in the yellow paper and there's 160 bits or like 20 bytes

so that that may be the case for ethereum but the yellow paper doesn't really specify a limit for i think pretty much anything else but the address is it does yeah so i guess whatever it's the the coinbase op code can actually address this for coinbase yeah be like for long addresses let's just just briefly mention that like i feel like this is basically the most cautious approach that we could take here i feel like we should visit definitely revisit these individual things and only end up adding things that at least remotely make sense

to me for example at very first glance it doesn't really make sense to add the coinbase there preemptively because like we can just do that whenever someone calls the opcode or something i think there's a coinbase output right there should be sounds sounds reasonable um so these kind of things so i had but like at least in the initial spec like doesn't hurt to have it in there and then we could always kind of see if we really if it really makes any sense uh yeah i think you're right you can't reliably uh use the coinbase address in the execution except calling the coinbase

of code right and so generally i i basically i i do feel like that for like at 99 plus percent of your cases it really it's really sufficient to only add things for these op codes that that actually do some compression um and so i i do still wonder if even even for the ephemeral where it's almost free to add more if it if it's really if it really makes any sense to add like everything that remotely looks like an address just just so we are safe um but i don't see your harm in kind of like starting at least with with that and then whittling it down over time

so this is the very few times i really need to leave on time so we have like at least i have 10 minutes left should we talk about the expiring translation map i would like to just ask um have we talked about or thought about block producer provided ephemeral transaction translation maps the block producer does so it's something like we talked about for witnesses so it's not but is it attached to the transactions or is it attached to the block level i could presumably be attached to the

block level i mean the the block producers may get those that information from users but the onus is on the block producer to actually produce it not the user like in terms of who's responsible so i think the problem there is that like the um contents of the ephemeral translation map um have the effect of causing your translate your transaction to revert um if data is missing and that cost users money so if the so the block would be invalid if any of the transactions tried to hit something that wasn't in

the map wait that's what i mean you can just trigger that as user trivially right you just give in the compressed address that no one knows the or like just a fake impression yeah the block producer would not include a transaction like that because that would result in an invalid block sure but that's quite after 10 million guys yes so you now have a denial of services it has it has a header that has all the the the ephemeral transaction map for that whole block and either the block is valid because the map is sufficient or the block is not valid because the map is insufficient where the block producer gets the fills that map in from is a separate problem and not a protocol problem so the this doesn't work because

the block the block producer can only find out that they can't roll because like everybody's interacting with the same unicorn contract you only need to include it once the problem is i can deny i can submit a transaction to the block that is very long very expensive and the block producer is required to execute it for a long period of time get to the end and discover that the entire transaction is valid because they don't know the answer to some transaction question and then you can deny all of service that by submitting loads of transactions that require lots of producers producers to um execute lots of computation on just to discover that they're invalid and

can't be included right so i'm with peter here i don't i don't think that that specifically works i think it it could be interesting to talk about like should minus provide like a supplemental be able to provide some preventable entries that like persist through the entirety of the block or something but it can't be required for execution or anything um and i i do think though and i like just because um as alex kind of has to have to leave on time um because i do want to kind of briefly talk about the expiring list and i think that's that's actually a that's actually a good good kind of transition just because

um to me basically the expiring um the expiring translation map is is a bit in a similar direction right so basically instead of having having it having the entries only persist within a single transaction or only within a single block basically go one step further and have it be i mean of course now this this brings state expiry into the discussion and in the end like uh and i know like alex the team you try to keep this the specification separate and so i i basically think that that would mean that in the in the pure addition specification this would look identical to the persistent um map but with the with the understanding that

once we reached once we introduced that expiry we would treat this storage as part of state expiry so basically what that means is that any entry to the um to the translation map that hasn't been touched in over a year or like over two years kind of depending where the like period boundary is but once it basically hasn't hasn't been touched in quite a while it gets expired and forgotten and then i basically the idea basically is that you you would um need to to add it again if you want to use it and so um i thought about it a bit and i think it's actually it doesn't work

quite identical to into normal state expiry because normalcy experience a transaction just fails if it reaches a point where it wants to access state and it doesn't find it um here uh you wouldn't actually fail you would basically just say you would just return the value it's not in the map right we don't know if it ever was but it's not in there and also for adding new entries you wouldn't have to provide witnesses about if if the entry has ever been added before so you just you're just allowed to override can i interrupt you for a second yeah yeah go ahead um yeah just for the sake of the discussion um um do we do we assume that the translation map just exists as a regular account and with regular storage

or do you envision like a separate um separate state which can be then revived i assume that the first it's just a regular account as we discussed like a special contract or whatever yeah no it's it well it's a bit a bit tricky because the i think the storage itself could could be it could end up being stored by clients as normal as regular storage would um under maybe the precompile address or whatever if we end up giving it a precompile address but the the rules for actually accessing it overwriting it interacting with it would have to be modified and and so basically normally if you basically want to write to a field in in an old contract that's

that that basically is not not not within fresh state anymore which the translation tab table after two years two years or so would be then you would have to always provide an exclusion witness and for the translation map you would not have to be right because unless for birthday attacks one like basically it's always deterministic right so so there's always like any long address will always right any short address longer mapping will always be the same so you don't have to to prove that there hasn't been a like an entry in this mapping yet you can just override it so so it does behave somewhat differently so you could i i still think for like client logic you could just store it as normal storage but then for for kind of the the way how

how you interact with it that that would have to follow slightly different rules if that makes sense so if it's like regular state objects then all of this is in the legacy epoch right epoch zero um yeah i mean so in suffice you you say you can say that about pre-compiles but but i think i think that's correct so then the the cost of reviving that i mean that's just like another incentive to

bend on the legacy epoch right wait and i'm not i'm not sure i i understand that part like so if which is so if this um okay maybe i'm missing something on city expiry but you know the the the longer um in the past uh you know the the um the more we go into the past the more i mean it's only just the last two epochs which are cheaply available anything besides that is um is much more expensive because it has to be revived into the current epoch and if we

assume that um this translation map exists in the legacy epoch where the legacy contracts are then that's like another like cost increase in how to interact with those and that's like another incentive to to get away from the legacy ebook right right although i would well i'm not sure i'm not sure i agree here generally yes but i think that might be it one of these special cases in which it doesn't follow the normal behavior of normal storage and that i don't think you would ever want to revive any entry you just you just override it because like there's there's no reason that you'd

ever want to prove anything about about the mapping you can just add the entry in you so i think this like specifically wouldn't it would just not have support for resurrection or for like yeah um so so it would never actually require um like work of witnesses the translation map so the problem with that is that it makes quite nasty versions of the birthday attack possible and in particular if we're doing this um distinguishing like compressed addresses from non-requests addresses

thing like the birthday attack will be very expensive but like actually feasible like at the moment if you want to the birthday attack you need like you know state actor level money but um i think we're proposing to make it um 490 4096 times easier by making this distinguishability thing so we need to like create a system that is robust against the birthday attack it's not really good enough to say well this doesn't matter unless there's a birthday attack because if there's a birthday attack possible then a whole bunch of things become insecure right but um um and i assume we'll

probably go over time again but then alex um well i will have to do it's really best but and um but but basically my point here is just that the birthday is even more of a concern for the ephemeral list because they are basically you could just have one one account that gets compressed then is added to some storage of some contract for some balance or whatever and then even in the next transaction even in the same block you could have a different address claiming it with the same compressed form so the like state experience basically i see that as a compromise where as long as you keep it active it can never be a target of this attack so basically like as long as you access it once every two years basically or at least once every year let's put that

way as long as this this um address is touched once every year it can never be the target of a birthday attack and so you basically you only have to worry about if you kind of if you use very old things and i feel like at that point it's starting to to just basically be an acceptable kind of trade-off but but basically my point is just it it is it is like a strict improvement in security for the birth attack of the ephemeral list um but it is it is indeed worse than the permanent in state um sorry that i'm deviating from the birthday attack um but i'm going to leave in a very few minutes um

one part i'm i'm i'm still not fully clear about is that you said that there might be like different ways whether it's whether it's a regular state object like a con whether this translation map is like a contract um but you may have said maybe i misunderstood that there's like a different way to deal with this as part of state expiry um can you maybe elaborate on that right i'm just saying because it it it needs these modified state like state experience rules anyway i i i'm not sure i would have to kind of think about it more but it could be that it's just easier to implement for clients to treat it as special state and very explicitly

uh kind of implement its own expertise rules and that those would still be the same rules then the that we just talked about so um it basically needs these slightly modified state expert rules the question is just do clients basically treat it as normal storage with just modified rules or do they just treat it as like its own thing and very explicitly give it different rules i i'm not i'm not sure so you are seeing that in in both cases we just likely have a a contract or whatever at an address with storage but for because this is a special address there might be different rules we're getting state expiry for it is that what you're saying

yeah kind of i feel like if we end up having a precompiled or something that exposes it to other contracts then the pre-compile i'm not sure if you want to think about it as the quick about having storage and then basically interacting with that storage or if you want to think of it as the pre-compile just accessing this special state that that is treated differently inside the client i feel like those are kind of the same in a sense so so yeah i i don't think it necessarily has to be contract storage it could i mean i assume you would want to have it live inside the vulcan tree um yeah in that sense yes but i'm not i'm not i'm not sure i am convinced that it has to live inside the work retreat

i think in the simplest like in state version it is really just a contract it's um it's added in a in a hard fork but it is a contract with the regular storage and it in that case you can just apply regular state expiry rules to it there's there's no special handling needed right and i i i just feel like basically um you ideally don't want to do that because that has very sub-optimal um effects once the once the map is like two years old basically because then you would have to always have these exclusions and resurrection witnesses and whatever

that just become really expensive and yet you can of course say yes that's a good example like incentive to for people to migrate but it's still it's just unnecessary because of the specific nature of the translation map it's basically just adding overhead to to the cost of interacting with it that is just not necessary and so i while it simplifies the state expert part of it i i prefer a solution where it gets its own state experience i think the simplification is very much worth it in this case personally like i understand what you're saying that it's unnecessary like the the witness the proofs but i suspect a proofs for these are going to be very uncommon

and b we just get so much of a win from a client complexity standpoint well i'm just saying that basically means that once we're two years in ever adding new entries to the list will be extremely expensive and so basically all of a sudden interactions between the new and the old space will become really expensive where they just weren't before and that's just a property of the system that i personally very much don't like because it doesn't even necessarily incentivize migration you can if you live completely inside the legacy world you don't have to pay that because you never interact with the translation map um so it kind of effectively just very much disincentivize just incentivizes

interoperability between the two layers um yeah i i very much don't like that property but i see the point that it might be simpler to apply the exact same expert rules yeah i i need to leave but yeah thank you for explaining this because i was wondering you know what do you mean exactly by the expiring one and i was i was um i kind of worried that this would be some some like special rules introduced somewhere but yeah in this case that we we delegate the expiry takes the rules for expiry and revival to the larger proposal uh i think i don't really have anything in essence against you know going this

direction but it's clear that we already have like two big questions on on this topic right what we have been discussing in the last few minutes um yeah yeah um yeah let me know if just on on discord if if another call is organized or anything but i really need to hop off now um and it's been great thank you guys sounds good and thanks again for reading all these calls i think this has been really productive mostly thank you yeah talk to you bye-bye bye okay uh i i think we shouldn't kind of like try and go over that time too much

though um i'm happy to discuss this like a couple more minutes um can i make a request rather than like continuing the technical discussion that we discuss how like the process is going to go going forward now we've reached the end of these calls and leave the technical discussion until alex is back at a future call that sounds reasonable to me but i would really as i mentioned couple times before i would really like to resolve the things that i see as blockers before doing much else like as far as process goes i would love to find a solution to these things we've come up with that stop us from implementing this so what

what are the big blockers for you micah basically from your perspective um oh i can never remember them so in discord i post that big long list of all the different combinations of things you can do between various addresses um having an answer for all those basically every time we go through we find one or more that doesn't work with every solution we've come up with um i forget at the moment because it's very late for me um what the last one we came up with was but it was a blocker and we haven't resolved it i think it was a new token like a

a long address token which is sending to a compressed address i think and i'm also not convinced that we can differentiate between compressed and non-compressed addresses i think we have to sacrifice way too much entropy in order to get that um and so i think that's a i personally believe that is a non-solved problem and because we haven't solved that problem the ability to differentiate then that leaves open just you know a ton of other problems that we have that we've been talking about okay so um just to preserve kind of i guess yeah this is so just roughly so it's fun i'm very happy if you want to if you ever like just jump on a call like the two of

us and just go through this humongous list of yours and just see if there's really anything that doesn't just work out of the box because i'm reasonably optimistic that um by now that i think we have a solution that we would work with with all of them are you as yeah are you assuming that we can differentiate a compressed address from a legacy address yeah i'm saying like in our ideal happy case i think all of these work so i don't think that happy case is realistic i do not think we can distinguish compressed address from legacy addresses in isolation like i think that is like we've talked about it but like i have not heard a solution that i think is actually viable like the best one we have is we can sacrifice some bits of entropy in order to do like a crc or you know prefix or

whatever but i think the number of bits we need to sacrifice in order to get a sufficiently good crc check that's not going to conflict with the legitimate legacy address is so high that we just have lost all security basically like we have to drop down to you know from 160 bits down to you know 100 bits because we need the rest of them for a crc check that's obviously not going to work wait wait wait but but how is that how is that a problem like i mean it is a problem but like it's only for entropy in the translation map right it doesn't take away from the entropy for legacy addresses it doesn't take away from the entropy for new addresses it only takes away from the entropy for

basically counterfactual contracts that in the new space that want to be able to interact with the legacy space um so are you basically arguing that like just hypothetically just throwing some numbers out there you think that if we only had 80 bits of entropy for compressed addresses that would be okay basically that's it so basically should we should basically we we need we need the entropy that makes it impossible to specifically target existing right and i don't even think that's necessary so i think the basically what we need is just that we never have a collision just by on accident right so because that that just breaks things so but but as long as long as we train this

i i think except for the ephemera always like that the ephemeral trans um translation map is indeed to in my mind and i i think we kind of unfortunately only touched upon it like looking back and we didn't mention it when we talked about the the problems with the ephemeral list but i do think that the ephemeralist is vulnerable to birthday attacks much more and so if we end up going with the feminist i i i'm back on board with all of these concerns if we go with either the expiring or the full permanent resistance in in state one i feel like even 80 bits of collision resistance would be sufficient yes all right i mean i'll think on that um i'm not convinced yet but maybe i can

be convinced that we only need enough security to prevent accidental collision and it's not really security even it's just we just want to make sure that people don't have a bad time because they collided and then can't do things but doesn't mean uh does this mean like pre-image collision like 80 bits of pre-image collision that's what i mean it's enough and i'm sure it's enough but i i think the 80 bits i think were just my car being trying to make a point i don't think any of the proposals has like specific 80 bits so like it's just like basically is it okay to sacrifice some of the natural 160 bit uh uh collision resistance that we would

get with a pure translation and so i think if we go with like three bytes of prefix wait wait a little bit that's like um yeah is is there any likes like even prototype of this specification because i'm not sure how it's supposed to work so it's set foot for the prefix yeah i mean like there's like some bytes that's this checksum and if the checksum matches the rest of the bytes that's compressor address otherwise if it doesn't match it's not right that's that's the idea yeah i'm personally even more in favor of just the the even simpler approach of just basically having a pre a fixed prefix of like three bytes that

have never been used as an address prefix or mainnet before and just designating that as the compressed address prefix yeah i i don't think that would work because like all of the hardware like all of this like hd and hardware wallets you can't really control like what address it will generate or it's even like possibly generate so like they would need to add some additional code to reject such accounts right i mean it might not be used right now but like there's possibility like it will be generated by some existing tools and then it will right so that's right so this this is where it gets into how many bits would you sacrifice in order to

make that very uh unlike unlikely enough to occur that we don't have to think about it so three bytes probably not enough um like it's it's reasonably likely that three bytes will get hit naturally over the next couple of years um whereas you know if we sacrificed out of our 20 bites we sacrificed 10 it's very unlikely that you're gonna someone's going to hit this specific 10 bites in the next two or three years or four years or whatever and so the question is is i think we'll have to sacrifice quite a few bits in order to achieve that level of no one's going to accidentally run into this you could attack it but you can't accidentally hit it and that's what leads the question of is it okay if this map can be attacked like are there no ways you can benefit

from such an attack can you do nothing bad by creating collisions in this map and if the answer is no you can't do anything bad by green collisions map then i think it's reasonable to pursue um that's a bit i'm not convinced yet on but like maybe can be so i think you can get the um you can get to a point if you are very careful with how you design the transaction translation map and you're very careful to make sure that stuff gets into it and that it's permanent and it can never expire you can probably or if it does expire then you would you can resurrect it properly and stuff you probably can get there the problem is once you're cutting 10 bits off like getting an intentional collision is probably not

even difficult it's probably something that someone on like one gpu can probably do i'm very ballpark there but it sounds that sort of level and at that point you are yeah what once you're at that point um you really have to worry about like the birthday attack problem because like we really want to keep this um counterfactual contracts thing as secure and pop as possible and it looks like if we're going to distinguish between the counterfactual contracts case and if we're going to get this distinguishing between

compressed addresses and normal addresses we're going to lose counter factual contract security in the case where it's a compressed address the yes and just like if we've like going to completely lose it no one is going to have any security and like some random person who is prepared to like spend a few thousand pounds can break your account factual contract if they want to right so i mean i i feel like we have to to to kind of take a step back here because i feel like there's too too much of a kind of detail discussion now but but i i agree that like they're definitely unsolved concerns around this detectability of compressed addresses

so i i agree with both of you there at least in in that point um also though like on on a different point i think i don't think that any of the kind of solutions that we came up with in general rely on the detectability i think a lot of them just become much cleaner so i i i think you know that's where i disagree i i think lots of stuff breaks if we don't have that detectability like all the other things we run into like that was that's how we stopped that discussion was by just saying let's pretend that we can distinguish and so we can move on because we kept getting stuck every time we tried to solve it without being distinguished we had problems like i don't think that solved

it i i think the problem at this point is we have like got to the end of like random discussion about the problems that we could do like i think what needs to happen at this point is that the people who think they have solutions need to go away and write down and like battle test their solution and like come back in a week or two and say this is what i've done this is what i think the solution is and then we can go and analyze that i think if we keep having calls we're just going to end up going around in circles um i think we've got to a point where like we know what the really big problems actually are and i don't think we need to keep having calls to like work that out but i think the two things we should do

next is firstly we should like try and write down a definitive like list of all of the like serious problems that address space extension has that we need to solve include it and like just i think everyone who thinks that there are serious problems needs to write down what they think their blockers are and then we need to compile those into a list and then someone needs to people who think they have solutions to these problems need to sit down take that list write a like outline proposal what they think they're going to do and try and persuade people that their proposal solves all the problems on the list and when we do that one of two things is going to happen

either it's going either we're going to get a proposal that like everyone agrees that works or we're going to end up in a situation where this where like we discover that one of these problems is like actually a fundamental problem we don't have a solution for and then we can focus on that problem right i think i generally agree um i i think we talked about it in first of all that like it makes sense to after this kind of call basically to after this call specifically to to stop and um basically also i mean at least i don't know for some people um i think involved uh there there will be

hcc which will at least an offer for example format and me will take away attention for the next week or so a bit more than a week basically um but but i i i think we indeed we at the point where it makes sense to just work through these things kind of specify like write some more specifications and then um probably come back together in two weeks or so maybe even have one um full statelessness call i'm not sure maybe we should have one more walking group called beforehand or something but it could also make sense to kind of pull this back into the statelessness call and just basically say okay

we had these four alternatives and now after two weeks it looks like this is realistic this business problems whatever but basically our initial results from this address space d dive are as follows um that to me makes a lot of sense and i don't know if people have preferences of whether we should like say two weeks from now whether we should pick this back up in the form of the working group calls for now or if we should if it would make more sense to bring that back into the

full state of the state business or i don't know state expiry i would like to see like um like peter suggested i would like to see some solutions proposed before we re-gather or like a a concrete thing to talk about like i'm at the point with these calls where i don't have any solutions and i'm so far not convinced by any of the proposed solutions and i'd like to see them written down and be convinced or at least written down enough that we can then discuss a specific solution rather than something vague and hand-wavy i was going to suggest why don't we declare a date let's say two weeks from now by which people who have solutions

should like submit a draft in writing and then in two weeks time not on a call we people we can look at what's been submitted and if there are solutions that we think are like worth discussing we can have a working group call to see whether they like stand up to muster of like a reasonable amount of an access and if based on the working group call we have a solution that looks reasonable and looks like it might work we can then bring that to a full statement yeah i feel like again the the only you know just in general the only worry that i would have there is um yeah that basically the next i don't

know i i'm not so sure that like how much time i'll have to work on this uh specifically over the next two weeks so i'll only kind of return home we can choose a different different date i think two weeks was just meant as a straw man date like a month that'd be better yeah but i also don't want to kind of keep like have that slip too much so so we could yeah if we want to pick a date i feel like something like that three three weeks out or so makes sense if we want to just say like as soon as we have proposals we get back together we could also do that um hey this is uh justin from the baysu team i think we love that idea the date not so much anything past

london would be awesome um two weeks is you know i hear what you're saying it's just a placeholder right no no no that makes sense so then basically you're also saying that they that you you prefer just the once we have proposals we'll continue from there approach is that right yeah i like i really like this idea what i'm hearing is hey let's come up with an interface and a test suite um and then agree on what is in that test suite what are the what are we talking about what are the different problems that we're trying to solve and then we can start applying different solutions to those different aspects of the test suite yeah i mean i personally think that that sounds good the only question is like are we confident that this will happen if we just like go to

asynchronous communication then for now or is that basically the enough teams that like internally will be working on this so that we'll make progress or will we just kind of like come back three two weeks from now and notice that no one really did anything so we are i i promise that i will not work on this right i'm again i'm unsure if i can like just spend time on it within the next two weeks but afterwards i'll definitely kind of work on this i'll take it back to the team and see what kind of uh commitment we can we can offer right now i think on my micah's page um i can i can promise you that i'll think about it but i don't know about working on it

and again i'm very new to the group it's i'm still very behind as far as um the thinking and understanding of the problem space so that's going to add a lot to our um our ramp up sure yeah no but but i mean it's uh really really great to see you here and see you stay to the very bitter end here just the four of us but yeah um no that's something that's good though um so so basically like let's we could also just say like we we don't set a date now but like we could just two two weeks from now once basically one's physically like i don't know we we have one then and is it that should be in two weeks something is that roughly roughly well it's three weeks from now i guess london so

but basically like two to three weeks from now we just kind of like uh at least kind of come back to together on the on the channels like the the communication channels and then we we see where people are at and then we then we set a date for whenever we want to pick things back up and in what form does that sound good yeah it sounds good this is fine okay yeah and also i also definitely try and start working a bit at least on sketching out the the exact version of all of these different proposals that we talked about that i personally think makes the most sense or at least would be the ideal case and um yeah hopefully we'll have something there

soon okay then i guess we'll leave it at that um thanks all i mean thanks thanks to three of you for for coming um yeah so those were those i think productive calls in general and um i'm kind of i'm definitely looking forward to kind of like keeping this active and really pushing for for i don't know i'm still i'm so like on another point i'm still kind of worried that all of this might end up being too complex for all codefs to even consider actually going forward with it but if there's a chart for any of this to actually happen i'm i really want to make this happen so or at least yeah unfortunately it's unfortunate because we have to do something like we

can't just ignore this problem forever like it has to be solved the address space extension the the issue is we either solve it some way like we're talking about or we launch each two like an actual east too like a separate chain that starts from scratch i think it doesn't have this problem like there are not a lot of good options here right but i just feel like physically the point is like we for the longest time we had the vision that once e2 comes around we basically kind of deprecate the existing chain we built this fancy new chain with execution environments and evolution and everything and now we decided against that and i feel like not everyone has like fully realized that what that means we basically we have to now

make the ready these one chain for 10 more years of flawless like operation and probably even more than that and so like even though all of these changes are not necessarily immediately pressing um they just have to happen anyway so we might as well start facing facing those big decisions now yeah so yeah yeah i mean i think in the back of everybody's mind i do encourage you like if we can't make this work are there any other options on the table besides a brand new chain like is there anything else like even if it's extreme it's can't be possibly more be more extreme than just starting a whole new

blockchain and so um that's what's on my mind right now is because i'm not convinced we can solve this in this way and so in the back of my head i'm trying to think is there anything else we could do short of just forking off a whole new blockchain yeah that's a good point that's a good but i mean that that is a topic for a different day um yeah i mean i feel like we we can definitely make said it's very work some other way not just quite as well but others but like at some point we just have to to kind of face the collision resistance problems so yeah any case um that's probably that's then all for today i would say that though um we should definitely follow up on this in general but um and come soon close here so thanks all

and talk to you all soon thanks see ya see ya bye