Address Space Extension Working Group #1

Transcript

okay so then let me just kind of verify this context so uh this call kind of like meant to be a bit more of a focused working group session we had like two weeks ago i think 23 weeks ago we had two calls where we kind of presented his state expert proposal and that specific flavor of state experience uses address space extension in order to um to basically make it efficient basically make exclusion proofs efficient so so like you'll have these trees that expire over time and you know do not always have to go back to the very first tree and kind of like proof exclusion of an address that you want to use for the first time all the way through history you have this nice format of kind of an extended address space where you have like a period

number in there and so you know that some addresses are fresh and you don't have to prove history for them and so that's the context but of course address space extension is tricky until now addresses in dbm were 20 bytes and now we want to move to 32 bytes if we go with outer space extension so that quite a few issues and vitalik had like a sketched out proposal then the ipstone team came in and tried to really kind of concretize that proposal change it a bit in the process and then they looked into kind of like the implications there a bit more and wrote up this this document and um exec one of the authors there is on the call and will kind of lead the discussion on where to go from here basically i think i think the goal basically for today

would be to get a better like get a better impression of how realistic is address space extension in the short term right like how realistic is it to to do address space extension in on a one to two year timeline so can we base state xperia on top of it okay um alex you want to take it from me thank you answer for the the intro um in the end i'm not going to share the screen because zoom only allows to share like uh the browser browser entirely or not like a tab um but micah has shared sorry you can break out the tab into a separate window and i think it'll let you share just that window i have i have like a bunch of tabs and windows and zoom only allows me to

select the browser instance and not even a window for some reason okay um so sorry for that but micah has shared the the document in the chat uh and yeah i hope that everybody has read it anyway um and i also shared a another document which is empty where we can't just mark down any any um decisions or ideas or anything else we come across this call it's open to edit for everyone um in this regard for the the process i hope that we would maybe go um point by point uh on this document some points our take would probably take longer to

discuss others probably shorter um but since we have like 15 points and we have like an hour that means uh on average we shouldn't spend more than three minutes on each um so i probably we won't make it all the way to the end thank you micah i think you have shared the doc so let's just start with the the first point which is just a generic feature of of this whole address space extension um that if if we have other space extension that means we have multiple ways to arrive at a account an address based on a private

key and in the the first case where we just introduce address space extension without introducing state expiry or anything else that means we will we will have two kinds of addresses we will have the current legacy addresses which are the short ones and we're going to have the long ones which uh likely only have like a virtual number in them and and nothing else really um but have uh more bits for the hash than the current format um and in that case we're going to have two different addresses which can be generated from this very same private key um however when we introduce data expiry this will become way more complicated because for each epoch there might be

there will be a corresponding address for the given private key and then lastly if you do have these compressed addresses which is not set in stone that might be like yet another um representation of the same private key so why would state x3 be a problem here my understanding with state experience it would operate entirely on long address only and the like transposition of short to long or the conversion short to long would just be basically at the evm layer just so it can have deal with contracts so each epoch you can create an account right and you can create an externally owned account in each epoch

and you can use the very same private key to do that right but like so when so so when first epoch happens like when we make the transition to state x3 my understanding which could be very wrong was that basically like internally everything is converted to and treated like the long address like we use a long address everywhere internally and the only reason we need to do this transposition is because of contracts and the evm is that not correct i don't think that's quite great so like if you look at the short address here so the moment we would do adder space extension the short address would basically become a long address just with leading zeros so kind of like um

the exact same same line and just leaving zeros and so that would be a different account from the the one that that is listed on that long both have the same private key yeah yeah so there should be different accounts so the issue here is the merkle tree i believe stores accounts as like a hash of the address is that right and then um we can't reasonably update the whole merkle tree until um epic two or three or whatever it is no no you can never you can never update it because that would okay i think we are steering away from from this point but um i mean this is relevant to uh in in in ethereum we don't require the

existence of a account you can just transfer or interact with any account whether there exists a private key for it or not and therefore it's not possible to even with a rainbow table or somehow it's not possible to retrieve the corresponding public keys um so there's no chance that at any point in the future we're going to be able to to change the the entries in the tree they're always going to be the shortest pieces you need the private key or the public key in order to generate the long address is that what you're saying yeah we cannot generate a long address from a short address yeah of course what you could do is you could have some

super complicated merge logic that emerges like as soon as you use the wrong address it kind of is merged with the third one but i don't like that successfully i don't like not not part of this proposal and i think it would be a bad idea yeah we told you that idea but it's it's it's very complex um but i guess just getting back to this first point um as long as we agree that you can use the same private key to to represent multiple addresses in different epochs um i'm not saying this is an issue but this is a property you know at this point you will have multiple addresses corresponding to the same private key and is that a problem i'm not sure but

yeah i think this is this is a new property we don't have today out of curiosity does this or other problems go away if we assume that the address extension does not increase security of accounts like the collision issue for example if if you can generate a long address from a short address by just pre-pending the epoch it was created in do we alleviate a bunch of problems no i don't i don't think you can i don't think this this property this cannot be this this can be removed and i don't think it makes sense to kind of consider it like a problem to be solved it's more like a property of of this proposal that is somewhat kind of unusual like or are we

different from how things were before and so we have to just decide is that a like that does that constitute a problem or is that just like a ux difference that people will have to get used to and personally of that opinion so i generally do agree that we should increase the bits of security but i would be loath to find out the state expertise gets halted entirely because we couldn't figure out how to do this whereas if we were to drop the increased number of bits of security requirements we could then get state x pretty super easily like it would just suck to miss out on state of three because we tried so hard to get we might be

we might be talking kind of like be beyond player like kind of about different things because i don't like what you're referencing here's just these extra six bytes of just like a longer hash portion of the long address um that to me is like a completely separate i i i don't see a relation between that property of the long addresses and the general property that now you have multiple addresses for the same private key even if you were to continue to only have this 20 byte hash part of long addresses that would still be the same situation well so if if you were able to convert a short address to a long address without having access to the public key then hypothetically one could imagine a scenario where we actually do update the film merkle tree and we do convert everybody

to long dresses which means state experience only has to deal with long addresses it doesn't have to deal with short addresses anywhere so everybody only does have one address it's just there's two ways of expressing it one is with a short address one is with the long address so for one i'm not sure like about the implications there it seems tricky but also once we then actually do state expiry and we have multiple periods then you have one address per period anyway that like that property you just cannot get rid of so there will be one account per period so like if we if potentially right you don't have to use that account so if i if i just have an ua within period three then i can still use that same ua with that address in period 15 but i could also with the same private

key create an account in period four five six seven eight and nine and so on and so those would be different accounts on the chain they they would have a separate balance and so on and like i can control all of them with the same private key so that that is the property of this of the system yeah i hadn't considered that um is is that a hard requirement or like can we do something to say hey if you already have an address in epec one you cannot use the same public key or same create new address in epic three wouldn't you need to submit like proofs that no such address exists i mean that's the only way to do it right

oh i see so the idea here is if if we do reference the account in fx3 then it would get upgraded to an fx3 account not not really so the like the it would still be an epoch whatever way it was first created a book zero or something account but it would now also live inside of the ebook 3 ebook three state three and so it would not no longer require kind of extra proofs but it's still a book zero address and and the balance in both the epic one address and the epic three address would mirror each other is that correct i guess you wouldn't have two separate accounts you would have one account that has two addresses no you well no no no so if you basically like if you have a long address with with a with uh basically in with an epoch

period prefix of letter seven and then you have a different create a different one with the same kind of hash bit but like in period nine then those that have separate balances they are controlled by the same private key but they have separate balances if you just copy over your address like your period c7 address two period nine because now we live in period nine you just kind of continue to use it then the balance keeps is the same because it's still the period seven address that you just keep using okay okay so that aligns with my understanding what i do what i'm unclear on is why we need this feature where we allow people to have both epic six and epic seven addresses that have the same everything except for the epic

so like where the only difference in the address is the first bite it's actually about allowing i mean this is by design so you could try to invent a scheme where you try to disallow it but it's yeah it's so okay so if the reason i'm impressing on this is just i want to make sure that we're not introducing requirements that are causing problems for ourselves that we can't get rid of because this is a very hard problem and so like if this is something that's like hey you know by default this is the behavior we get but if removing that behavior gave us some benefit and that's on the table that's fine with me so i think the problem is that you have these is that like epoch

7 stuff that happens in epoch 7 can't depend on whether or not something happened in epoch 1 because if something happened if say i created a address in ecot 1 if that changes the behavior of stuff at epoch 7 anyone who wants to do something in epoch 7 then has to go and find out by producing long proofs whether or not i created that account in epoch 7. so you just can't do it yeah for new accounts yes like in order to create a new account that you have to have the epoch prefix i i do agree with that part as a requirement yeah and so then the question becomes like why why i don't even like that's why i'm so confused we talk about

this so much like i don't even see the problem it's indeed like a somewhere somewhat new property of the system that now there's not no longer like a one-to-one mapping between private key and on-chain account i just like and that they will have some ux implications but i just don't yeah that that seems not like the problematic bit of this whole yeah if it doesn't if this doesn't bite us then that's fine um so so maybe a question for alex all the items on this list are they things that are problems we need to solve or is this partially a list of problems we need to solve and partially a list of things we should be aware of and think about and consider if they're problems but aren't necessarily problems and we try to it's it has all of these

and we try to differentiate them by um like the prefix property or feature or um the effects so this one might just be a something to keep in mind and think about but we aren't aware of any specific problems this will cause this property i mean it definitely will cause um extra work on the ux side and potential confusion okay the protocol level i don't think it will will cause any great issue right this is basically like if a user puts in their private key to some wallet or something that wallet needs to then

find out you know do they have an epic one address do they have an epic two address do they have an epic three address et cetera and that's painful yeah i mean that that kind of would work like um happy bip 32 works on bitcoin right just yeah effects richard uh which paths are used yeah but it's not it's like moving on for right like your wallet would just kind of like only display those that have ever been touched by default or something and usually that would only be a single one um and checking yeah taking five buttons wouldn't really be showing things like state experience specifics to users no but you like if you if you just restore your

wallet right you you enter your passphrase and then like not your passwords you see trace then it would just have to find the account that you used to use with this uh seed phrase ideally if you're in period seven you don't want to restore eight different addresses and so like by default it should only restore the the ones that it finds on chain stage for yeah i'm satisfied we can move on if no one else has questions about this one yeah earlier you you mentioned um yeah i guess there are some ways to at least reduce the the the duplication in terms of the like epoch zero

and the current short addresses um but yes as we discussed four four going forward unless there is a specific mechanism in place which rejects creating such addresses which is going to be there but this rejection i don't think this rejection can can work nicely because in any case like token transfers or anything like that happens outside of the the realm of the the protocol so people can definitely just transfer to to such an address and if we reject the creation of such an account then it's just another way to lock up things yeah but we definitely spent extreme

amount of time on well i guess this is an important question that's why it was number one but yeah should we move on to the next point that's good yeah these next two points are more just like an explainer um and it sets the the stage why this this whole outer space extension is complicated and this comes from how existing contracts behave um and this is two points are solidity specific because solidity is the biggest um i i guess by good producer in terms of a number of accounts currently

um i haven't fully validated whether viper does um similar optimizations or not but i believe they may do it um but solidity regarding solidity so one point is that uh these existing bytecodes um can behave very differently whether they were compiled with optimizer on or off um in solidity addresses are considered like um 160 bit number and in by default um there is masking applied so for any kind of like handling this address value there is a mask applied 460 bits um but then if the

optimizer is and by default optimizer is turned off and that means that the mask is stays for any kind of assignments and and reads etc but if the optimizer is turned on then some of these are removed um they're removed on on stack items but when they are read or stored into storage the masking still applies so that means if suddenly all of these op codes returning addresses would output more than 160 bits in the evm then depending whether a contract was using an optimizer or not it would just behave differently and in very in various random ways

and then the the second point is uh there is this thing called api encoder v2 so the api is just the specification had to have contracts and uh like external um dapps interact with contracts how do they encode the data passed between each other and the this api has a specific type for an address which is 160 bit type and in solidity there are two codecs dealing with the api there is like the abi encoder v1 or the legacy which was there since uh the beginning and then we have to say bianca v2 which has been enabled probably two

or three years ago but has been made on by default um in the last breaking release which was um like six months ago so there is a mix between what existing byte codes use but if they do use the v2 then input validation is much more strict and that means if a input is lower like an address input is longer than 160 bits then it will just rework which i guess is nice because you know if you just pass like a long address to an old contract they would just reject it but anything which uses like the old abi encoder they will just silently accept it they might truncate they don't they might not

it really depends on the version um these two things are why all of this is kind of complicated yeah question so basically um in in my understanding that basically means this so so what one of the things i want to point out here is that things like the call opcode that all the upgrades that take in addresses i think today uh just truncate the input right so like if you if the like leading 12 12 bytes of whatever you have on on the stack as the address is not zero they just truncate that and then ignore that and so um in indeed today basically you could have like dirty addresses reaching the call up codes and the contract still works and so in my understanding that means that in order to just keep like what compatibility

contracts that like have legacy addresses so like accounts that live in this version zero space would forever have to keep exact behavior as today so basically they would they would have like all the call up codes and everything would have to truncate the first 12 to 12 bytes which would have to ignore that and all of this so basically there would forever be no way even if you deploy a new shiny facility 1.0 or something contract at an all within the old kind of space if that's somewhat possible um then basically those would always like they they could never directly call into the um into the extended outer space they would always have to go through these compressed addresses

said like a fair kind of understanding yeah so there's these two properties yeah and exactly the i mean that's why the masking can be removed because because um all of these upgrades taking in an address will just truncate themselves um and yeah i mean as you explain that's the reason uh we need to keep like if you don't want to break anything we need to keep existing um byte code not to change any behavior and that's why we need some kind of a translation if old contracts want to interact with new contracts and the question arises whether you want this interaction first of all and

it seems that we definitely need some kind of interaction otherwise um otherwise like there's there's no way to to migrate um it's like another option if you don't have like a translation another option would be to somehow upgrade existing bytecode with new one in like an opt-in basis uh migrate like all the accounts uh to bytecode which can handle both but this seems to be you know quite a bit more complicated thing and yeah that doesn't seem realistic yeah and and and like one question that i had there specifically is so so basically one of the design goals

here that i'm really kind of focused on is to make sure that long term the kind of the situation won't be much more complex than had we just started with a 32 byte space in the in the first place so like when we later on talk about the translation map i really like the ideas of like having at least expiring translation map or something where like we don't have to have this extra overhead forever into the extent or something but also here already one design goal that i would have is that new strategy contracts that are designed to be deployed at like new accounts that are a period away and all of this that they don't have to have like extra branching and checks to to to to basically understand where they'll where they execute right because if they of course have different behavior depending on if

they are executed in a legacy context or in a new context worst case solidity would basically always have to check do am i deployed at an old address or the new address and then kind of have branching behavior ideally what i would want is that new solidity code just kind of like treats addresses as 32 bytes and then just kind of like it doesn't matter if it's deployed in all the new context um but of course the problem here is that if call and all these are codes truncate then like a new new kind of contract that things it can deal with along addresses all of a sudden can't and so even if the op codes like caller and origin and so on they return short addresses in these short contexts from like the outside via call data or

something there could still be long addresses that reach these contracts and so i'm just wondering would we would we just assume that it's basically a user fault to deploy new solidity code at all addresses and then they contract these contacts potentially just break or would solidity just forever have to have like a case distinction where it looks at its own address and branches its behavior depending on this what's kind of like our understanding of how solidity would deal with this what this is like a ux devex question it's not really a protocol question and i mean obviously people can deploy whatever they want today or in the future you know we don't really make safeguards um but one i i guess one um

one hope from our side is uh with this related uh somewhat related proposal on on the evm object format um if we have that in place then it's easy to to see you know have like um you would be easily able to tell if a bytecode is an evm object format and then if it's like the certain version which which is is designed to to work with the long addresses then it's it's easy to distinguish but i'm not sure if we want to really cover like all this devex and ux and protocol level yeah it could be out of scope for today but i

still think that it's it would be unfortunate if we end up with a solution that just doesn't allow for good that ux devex kind of solutions right if basically whatever we do on the protocol side makes it really terrible for for like forever to write facility contracts because they have this huge overhead every single time that wouldn't be ideal so i still think it's kind of like something worth taking into account but but but i i agree with you it's kind of like it's not part of the challenge so just to make sure i'm on the same page with you guys the issue here is that if let's say message.sender um returned a 256-bit address some celebrity contracts that are currently deployed today will break

because they don't truncate the first 12 bytes is that correct right and so so messenger sender in like basically mr center now the behavior the post behavior messages off of like um caller the opcode would be to check if i'm running inside a legacy context so basically if if if the address that i'm deployed at is is like like a version zero address and if so it returns a short address and and that is either the caller address if the call address happens to also be a legacy address or if the call address was a new address type then it returns the compressed format of that instead that is basically a different behavior from the caller of code then inside of non-legacy context where the

call of code would return the full caller i think yeah i might be wrong but yeah and what i'm i'm missing not not understanding why this is a problem so like yes there's a little bit of we'd have to have a conditional in the evm that says you know if address starts with one then do return this else return something else and i think it's like a minor issue i think ansker is speaking from the devex point of view where i guess your expectation answer would be um that solidity would output bytecode which can operate in both contexts right that it could operate under

being a legacy account or be a like a long address account and it's certainly possible to do that because you can't just call like caller or origin and see if it's a long address and if it is or rather call address your address and see if it's a long one and then have different behavior depending on that i mean we there's no way to to reject anybody trying to do that but your concern is whether solidity should do this by default or not and we should avoid solidity doing this but i don't think this this really applies you know for the protocol design i think there may be a more salient problem which is

um there will be people who deploy contracts in epic one that were compiled some time before epic one and so those contracts will not like so even if solidity does the right thing in next version it doesn't help people because i mean i see people deploying facility code compiled with you know compiler 0.4 still like today and we don't have a way of saying no you can't deploy that code because we know it's bad they're there people will deploy old all the compiled by code right and that that's that's a problem on its own so basically that's the user fault that i don't think you can really do anything about short of maybe something with the kind of object format thingy that alex you just mentioned but like besides that it's basically

we just have to accept that deploying old code at new addresses will just break i i i don't think there's a way around this really no like i think you just have to treat it like the 32-bit versus 62-bit like x86 extinction and just say that bytecode is either um old legacy byte code or new post address space extension byte code and it just can't be one or the other and like you make that decision at compile time and then you're stuck with it right these problems this issue is it compiled it's not compile time check it's you need to do it at a runtime check and we don't currently have a way of checking

whether the bytecode was compiled with a new compiler or an old compiler at runtime well no i mean the but the they could be checked that just the new quotas or something but but yeah the problem is it doesn't automatically fail right if you just use old byte code and then you on a new address unfortunately at least right now we don't really have a way of stopping you or just stopping the contribution at all it would still run and it would probably work 90 right and then it would only break in some edge cases and so this is really unfortunate ideally what we just want is that all contracts just don't work if you deploy them and get new addresses but if they almost work that's a problem can't we just use um evm object format by that

for that and just say when you compile like post address station asbest address space extension code um that it has to be evm object format and it has to have a flag in the evm object format like table somewhere that says this is new style code and if it doesn't it immediately crashes when you try to execute it or something yes let's suggest same thing it just creates a dependency it means we can't do address space extension therefore we can't do statex free until after we have the evm object format which maybe is fine like that maybe is that might be the easiest way out of a lot of these problems is just by saying uh as a dependency of address space extension we have the object format stuff

yeah so the easy solution is just um i mean depending on on when any of this gets in but let's assume that maybe um this doesn't well i guess address space extension would get into the next hard fork but maybe maybe the the object format gets into next hard fork and then the hard work after that the address space extension gets in and and we see that the object format v2 um because there's a version right in there so now we only allow v2 to be deployed which is like a long long address bytecode but yeah i would suggest

we move on because well this is very interesting but yeah i think this is more more of a devex question as opposed to the core issues we have yeah i think kind of reflect it as like a thing to further discuss but but yeah pro pro best when i moved to the translation map because i i feel like that's the big one the big topic yeah so this um i think the point this uh 2a point in accessible funds case is um also has like a second part uh which

means uh when the user so it's it's again like a ux issue um from the wallet side they can if they they use like the the wrong encoding of this and just pass it on like use a compressed one um i mean it's very easy to to make mistakes that's the the whole problem um with having all these different kinds of addresses and all of these mistakes can be initiated from the different wallets and apps and i don't think we can do anything about it apart from teaching wallets to to act nicely can you give a quick example of one of

these failure modes like just uh tell a little story about how someone screws this up yeah we have we have nice cases in the the test cases link um i'm not sure andre do you want to give a clear example yeah there was actually a paragraph in this previous document in this one yeah the last paragraph in this section gives one simple example so it's basically a new style wallet that accepts maybe both long addresses and shorter dresses but then someone passes a compressed address to it

and then the transfer is initiated to this compressed address without doing a lookup because uh because it was not added to the translation table before so that's like the problem on the tooling level maybe and then the transformation yeah ends up at some not random but compressed address which is not a very addressing state gotcha okay so the issue here is that because compressed addresses are also um 20 bytes we can't distinguish them from legacy addresses and so someone could get into a situation where

they send some stuff or something or they store something related to a compressed address when they meant to sort related to a short address is that correct yeah we can't distinguish between them unless this address is added into the translation map already and the wallet contract actually can access it and check may make it look up itself so question like that and i don't think it would solve all the problems but vitalik had like a different proposal to do basically state expiry without

address space extension and there he proposed to find like a prefix that isn't yet used and basically do address state kind of reduction even and could we could we use like a similar trick here to basically find it prefix that no actual address has used so far in ethereum and just only ever used that prefix for compressed addresses that would of course make them even shorter and so even less collision resistant but um at least you could like if you look at an address and it has this prefix short address then you know it's only like a compressed address whereas if it doesn't have the prefix you know it's not a compressor just would that help i worried that we'd have to shave off a lot of bits of security to achieve that the problem with that isn't um

i mean when you try to create something new and you collide with the prefix then you get like a new address assigned um and that's in the proposal but i don't think it just addresses any existing the problem of any existing account which is not created yet in this state but is in like token balances or is um you know like a destination of the create 2 or anything like that you mean with the same prefix yes i mean there's well there's just a lot of accounts which are only currently uh listed as targets of like owners of different tokens um you know a lot of people

just get tokens to an address which never transacted before and at some point in the future they may want to transact with that address but they haven't yet so there's right a ton of addresses in existence which are not represented in the state stream sure but if it's only part about finding a good prefix then one you can make very clear probabilistic arguments that like there's only like a one in 10 000 chance that that has ever happened so far and also if you want to be really certain you could even do at least for unchained bit you could do like more clever analysis and look at i don't know all the um call data items that i wish that were ever kind of passed into contract or

something and make sure that this there's never ever been a 20 byte value that had this prefix or something i i think if you really wanted to you could you could find a prefix that doesn't have issues um i i worry more that like it would completely remove collision resistance even in the short term from from the translation map which i think has really unfortunate implications i mean both the i mean if you if you probabilistically don't want to have any um i mean collide with any existing um address even addresses used like in token balances

then you may realize that you want to have quite a long prefix and that really it's into collision resistance was proposing three bytes was it three bytes three or four bytes i think that's sufficient that would not surprise me but at the same time yeah even that might be sufficient to completely remove collision resistance right i i think we're kind of 20 bytes is kind of still mostly infeasible but i wouldn't be certain i i'm not an expert though but i wouldn't be certain of 16 bytes are completely infeasible even today also yeah i guess the distribution of the prefix um or like the the the higher bits are not uniform across accounts because

um at least for early accounts and accounts created by parity and there was this uh really early proposal like in 2015 to have these addresses called icap addresses which is um like these international bank number encodings um which i believe can only represent like 100 43 bits or something like that um which means a lot of addresses start with zero for the first byte so at least that that may help in the in the sense that maybe there are more

addresses starting with the zero byte and then not so well obviously you don't want a prefix starting with zero yeah but but of course i mean the over point by the way of this point remains right like the just you xyz it's really easy to make a mistake so if you just send in basically if if you deploy a token a contract at a new address and then at some point you kind of by accident uh assign someone with a compressed address a balance that can never actually ever be retrieved from from from that token contract because yeah the token contract internally will always when it rain calls caller or something it will always get a long address and so it'll never get the compressed form and and because there's no actual

real private key for the compressed address basically the yeah so so it's still really easy even if we were to do something like this to just make mistakes from the outside and use a compressed address where you shouldn't yeah and of course this is not a new problem and people can can make mistakes already and they're free to send whatever addresses and they frequently do but you know with having these multiple ways to to encode addresses i mean just the probability goes up for the number of mistakes wallets can do can we make it so you can sign over your compressed address like this is not a transaction but it's

not about the transaction this is um i mean it may not be you making the transaction inserting your address you know it may be the sender just uses like the wrong version of your address sending you something right so but the issue is is that if they let's say to send you a token to your compressed address so they say hey what's your address you give them your compressed address for whatever reason so they send you a token now there's somewhere in the state tree there's a estate entry that maps you know your compressed address to a balance if i understand correctly the issue here is is that you can't actually sign a transaction where message.sender is your compressed address can we make that a possibility can we introduce a new transaction type that is just like every other transaction type with the difference being

that the message.sender for that transaction is your compressed address instead of your full address yeah i think this is connected to the to the last two points we have um you know what should happen with ec recover and eip37 because i mean based on the very first point right you have a private key which can correspond to various number of addresses and we need to do something with easy recover extend it or something in order to recover all these different versions and the same question applies to transactions right whether um yeah i mean

the the problem with transactions is right now we don't have the address we just recovered the address based on signature um but in the future if you have multiple epochs then i suppose we need the epoch number in the transaction type um in the transaction and and then we will try to recover the address corresponding to that ebook right yes at the least we'll need need that and then i think we could also in theory have some other bit that says recover this as a compressed address versus recover this as a long full address that way if you need to withdraw some

token that you got sent to your compressed address you can you'd have to construct a transaction that recovers to your compressed address instead of recovering to your long address i think with all of these proposals it's really tricky to think through all the implications i i'd like on the first impression that sounds feasible but of course like there might be kind of really tricky implications downstream but also i think that would only solve the problem for compressed ua addresses for compressed contract addresses i assume then that would mean if you want to have full compatibility with these kind of situations we would also need to introduce a new call to opcode or something that or like a compressed call of code and then every kind of con new contract would

basically have to have a call this function instead if you made a mistake downstream so that now i'm using a compressed call opcode just so you can recover things that that kind of quickly explodes in complexity yeah it's fair okay from the point from the point of view of um like legacy contracts what's the difference between a legacy address and a compressed address like if i send like sorry a legacy address in the long press if i send some money to a compressed address surely that's just a legacy version of sending it to the long address that that compressed address refers to so from the inside of the old contract

so if you actually run in the old address space and you that then using a compressed address like basically would hopefully of course if the translation table works and the entry is still in the translation table oh these kind of things but but hopefully these uh it would be the exact same so the the the kind of the compressed addresses the only a pointer to the to the long address and so all the money or whatever you're sending it actually indeed arrives successfully at the at the long address that it was supposed to drive it if you use the compressed phone i don't know if that answered the question yes it did okay i think we only have ten sir micah do you do you want to go very

quickly i'll try uh could we include something in the transaction that is similar to an access list very vaguely similar where we basically just say hey when this address is looked up return the compressed address in this transaction so yeah okay if something is that is one of the points um um to yeah using transaction access less uh instead of like an you know in-state translation i actually think that micah was specifically referring to the case where even inside the new context where you could just return the full long address you would still want to return the compressed address because you made a mistake earlier and now you want to be able to kind of

act as if you were the compressed address and i think that part would really open you up to a text because then kind of users could set that for contracts that don't actually want to be compressed and and then yeah so you really don't want to just leave something like this up to the user but yeah i agree with axis so we we should try to at least talk a little bit about the the other topics as well and then last few minutes yeah we move on um okay just skipping um maybe skipping like two point b for the

for the moment um because two points c d and e are kinda related um um so basically in in two point c we say that um because this wasn't defined like in the initial proposals how does like this translation table works how does like insertion works in terms of of gas and rewards and um yeah we think that it should work as if it would be like a regular address slot and that means you cannot extend the translation map with a static call under static call context

and the insertion to the translation map should be reverted in case the the call reverts any any comments on this is there any known problems with that approach or is that just like just the thing when we build this we need to make sure we do that um yeah we don't see any problem with this but we do see like complexity if we don't do this because then we have like different rules on rewards and i would only want to comment on like should the translation table um expire or not but but that's probably not what you have to

talk about separate yeah um okay completely i think we can just move on if no one yeah like to see a second reason just a note yeah the i guess the next point is that um it would make sense to make this translation map accessible uh to both contracts and off-chain tools because right now at least in the proposal the only there's no way to access the the map really you you cannot inspect the map you cannot see what a input translates into or whether an input exists in the map and yeah we felt like that it would be nice for contracts to be able to check that because

then they could have safeguards whether something exists in the map or not um but yeah it's it's i'm not 100 that we need this for contracts but i'm i'm more certain that such inspection capability must exist for off chain tools so like wallets should be able to check if something is in the table because if it's not then they may need to do like another like a poking transaction too so in the case from externally you are trying to interact with an old token contract but your destination like a recipient is a long address then the wallet would first want to check if the translation exists and if it doesn't it would need

to send a transaction first which ensures that the translation table is populated so the easy way to do that is just to do like a balance op code or something um this this feels like something could very easily be solved by a precompile and it seems very reasonable to me yeah i mean the like the off-chain kind of support that should just be yeah that that feels like it's even outside of consensus like the clients could just implement uh some some interface for that but of chain i orange and i i even think it's like ideally it should even be like a precompiled way where we can think of the stock like the state as being part of its storage i mean of course we haven't had pre-compiled with storage in the past

but like basically for all practical purposes the whole translation map to me should just basically be a precompiled with storage that would be really though that would solve a lot of these yeah that's that's the idea um and then you don't even need like an rpc method it just can be cold and while this never happened so far and in mainnet there has been proposals like that so notable one is eip210 which tried to do that for block hashes so there's this conversation to refer back to um okay so yeah i mean there's a bunch of other stuff so what we noted as well

is that the the map size would be quite big says of like a month ago there have been 156 million um accounts in the state and if he and that's for the past five years or six years and let's say even if um the the number the growth rate would wouldn't continue as it is um but it would be slower we could reasonably expect to at least have like another 150 million accounts you know in in a few years but if like uptake of ethereum is much faster then this growth gonna be bigger um but with 150 million new accounts

uh if they still uh want to interact with like the the old contracts like the existing stable coins and whatnot then it's quite a lot of data to store in an in-state translation map uh it seems like the bare minimum 450 entries would be around like nine gigabytes of data um and that seems to be a lot right and so just because we seem to be running uh kind of out of time although i'd be happy to stay on a little bit longer but like of course most people have to drop off um so just to fight this here i actually like i've like met and now we are closing we've talked about that like previously and like because i think it seems like this

translation map is really kind of and specifically like the overhead that it kind of imposed on that was really the main question here is like i think all everything else seems like we can make it work somehow the question here is just and i think it's two dimensions one what gets added to the translation map so i think somewhere you also have the question of like should should any long address that ever gets created immediately be added or should it only be added once it's first accessed from inside the legacy context so i think that's a really important one for me because if it's only ever accessed on the legacy side then at least kind of like over time it will be like rarer and rarer that things get added so at least that balance it if it of course every new address will always be added

there then that kind of like makes it grow forever and then the other question and i think that's the also the big one is like how kind of ephemeral was this persistent should it be so i think one extreme is your proposal like that that's like under three here so basically like the make it completely ephemeral only ever build it within a single transaction then forget about it totally the other extreme would be keep it forever and never forget anything about it and then there would be like the middle case of just have it follow the normal aesthetic expiry rules and i think the the question the problem here is like to truly get a good feeling or like a good solid understanding of which one of those would be the way to go i think it's really important specifically here to do case studies of

like look at existing contracts how would they be impacted like how easy would it be to do really undesirable behavior if you have like misses in the lookup table and and things like that so basically like i i really think that this is something that deserves like a lot of further study of like use case yeah like like case studies and all of this to really like the the line space like for example my favorite is like only add once they are first accessed on the legacy side and uh make them expire but but not completely ephemeral and have like access list and all this to kind of like give users tools to further populate it if needed um but again this is like a huge design space and it's really important that we figure out i think which of these works by not being like

too much overhead but also not breaking too much of the legacy part um i don't know yeah i don't think any of the proposals suggested that the table is populated on every single time when like there's a new address interacting on the network it is only populated if the old context is trying to reach a new context um so it's it's it's not populated for for everything but if you so one example is like die which is quite popular and i has has really just seen one upgrade on the main token right when going from

the single uh backing token to like the multi version and anybody using dye would still interact with this old contract unless we expect that dai and all these like popular tokens would upgrade to like the new address space and maybe this this can happen if there is like enough incentive uh meaning interaction you know from the old address space to the new one is really expensive then of course they would have an incentive to upgrade but that's like another another big question yeah just to briefly mention i think

even for those projects that wouldn't immediately migrate and i think it's really important if we were to really go down this path that we should be really public once we have a concrete plan and that there's like a lot of time between publicizing the plan and actually doing it on chains so all of these projects can have their migration plan plans kind of like in place before that but also i think even for something like die it's very likely that there would at least be a like a long address wrapper for dye that then kind of like gets used for 99 of die use cases and people only people are actually dealing with the kind of the cdps and things like that would you ever ever touch the legacy side even before the migration happens so that sounds very i am

no but also like what i was thinking like it's important to note as soon as we start actually expiring things and of course that will only happen a year after the address space extension uh goes live but like once we actually start exploring things legacy you continuing to use legacy contracts will become more expensive at least where they continue to kind of occasionally write to new previously unused storage slots right because writing like writing to new storage slots will become more more expensive so sending that die natively to an address that never hold has never helped die before will become more and more and more expensive and so i think that's just like a very natural pausing function to for people to just use the wrapper that has the same behavior but just works

natively and yeah the deep reptile um i think it's nice and um as an idea but then i mean die is not used on its its own i mean you know the majority of transactions for die don't exist for just holding it they are dyes used in other protocols so you need to also upgrade all these other protocols to use the reptile there's like a lot of interdependency there right i'm just saying that's why i feel like we should really like there should be a between a please project be aware we are doing this and a now we actually did it there should be a lot of time between these two time

points yeah yeah i think yeah i just wanted to say we i guess we ran out of time i could stay maximum 10 more minutes if anybody wants to stay but yeah i guess we need like another call and many more calls and uh yeah i mean it's another big topic um so i thought long addresses to compressed addresses can is a deterministic process right why do we need a map for that long address to compressed address is deterministic but you can the the inverse you cannot do

right and the the problem you're having is is the inverse process is what the old old address space tries to reach a new one gotcha all right also just briefly then because as we alex we were just mentioning this about like future cards uh how do we feel in general about these kind of working group approaches i assume of course i don't know like uh about most of some of the other people here on the call like was it generally is it generally like a useful format do we because if it's really like a focused call and only people want to continue discussing this uh join then i would be i don't think there's anything wrong with just

having several more of these um in the coming weeks um yeah is that something people kind of are interested in though or is it or should we kind of really keep that in like by like just like individual teams jumping on calls just within them i feel like the semi-open format is kind of like good fit um so people can get involved if they want to i don't know what what's the situation i found like this format yeah i think this is really valuable it feels like there's still a ton more to this like it feels like there's a lot of like initial i'm not sure if level setting is

like the right word but like that maybe for the next two or like two weeks it makes sense to have like a weekly call and after that it might make sense to start spreading them out a bit more or something like that um but it does feel like there's like a lot to cover up front and having like a couple more of these uh like initial semi-open calls would be really valuable um but i there's probably an obvious answer here that i don't know but why spread them out over a week like why not just have a call tomorrow or the day after or whenever we can find oh time sure i i guess my my hunch would be like attendance will probably drop because but that might be false yeah

yeah i'm wondering we could also do of course smaller just working group calls really frequently and then just occasionally i don't know if that when we should just drop back to the basically the state statelessness or state expiry calls that we could continue to have regularly as a check-ins for people who don't want to follow every single working group but like session but just want to keep updated in general um i don't know it depends i i'd be generally like i'll be mostly working on this for for the next while anyway so i i'm happy to basically do it more or less tomorrow again but but of course it would be up for if at least like most of the really interested people can kind of all our free so that might

might restrict things i have no personal life so i'm always free at this time that's good um yeah i could i could join tomorrow at the same time um but friday we have all cordov so that probably is a bad time i mean what what we could do is we could just map tomorrow it's like a one-time experiment see like how many people come if it makes sense to continue that um or just kind of if we want to do these really frequent ones just have them privately private sessions or something we could do it one time tomorrow just like same time just just to see maybe and then then decide if we want to continue that

um but of course i feel like for maybe there's some people here also who join because they're like generations and services want to keep track and then i would say it's probably better to kind of wait for these more like broader sessions these like monthly or whatever statelessness calls i think um we'll also keep them up and probably have the next one i don't know within the next two weeks or something two or three weeks um for like a general check-in and then only join these working group sessions if you're like specifically interested in this topic and in this case an address based extension does it sound so good that we could just schedule like a one-time

session tomorrow same time and continue from there okay uh maybe last question then for today and probably best to then keep it there and like not spend three more minutes talking about specifics here um but uh what what's people like initial impression here after one one hour of conversations is do we do we think does that just space extension looks like something that's kind of probably feasible even though quite a bit of work to to get it to a good point do we think that it's likely to kind of really derail and we won't be able to do something of that on a two-year timeline or like ideally of course one year

timeline uh what's like i'm generally like an optimist so i to me it feels like there's something there we should be able to kind of get it to a reasonable kind of state relatively quickly but would be would be helpful to other people's impression my general feeling is that there's a lot of complexity and that complexity spans many different layers of the stack and because of that we may struggle to find a solution that everybody is satisfied with enough that we can push it through the core devs basically that's my biggest concern it's just like when complexity reaches a certain threshold it just becomes really hard to just get changes pushed through

complexity affects people other than the core devs because the core devs tend to be side on the air of caution when it comes to impacting people outside that group i think this is definitely similar to some of the other more complex projects the ecosystem had over the years and it seems like that there's only so much we can do with brainstorming and there needs to be likely a few different prototypes and having um like

wallets and and so not just like core but also tooling providers involved um in order to to maybe you know figure out is there anything which was missed is any of these like ux issues addressable to them and i feel like that with it's much easier to to get them to engage if there's a prototype so there's like a testnet or something it's really hard to engage them and even in that case it's hard to engage them but um it's really hard to engage in if there's nothing like that and there's only like paper planning so it seems like quite a bit of work in general yeah that makes sense yeah i also feel like basically trying to get to a

the best possible version that we can see right now kind of like relatively soon over the next few weeks even ideally lock that in start developing prototypes i mean of course continue to iterate on its own theoretical side as well but like actually start implementing things and at the same time we start reaching out to these these yeah important projects in the space i mean even just like to the solidity team right to start like getting getting them to look at get their feedback that i think they'll be very familiar with like or like in a good position to to to kind of assess how it'll impact existing contracts maybe yeah i don't know start with like a broad outreach once we once we are in the beginning to move into the prototyping phase um but i think that that would be ideal of course

so so yeah but then i feel like it makes sense to try and have these working group sessions even even if it's small right if tomorrow there'll only be five six seven people i think that that's that's fine that'd be helpful as long as people are not too annoyed by all these invites that they get they might then have to decline um yeah i i i think that's that's really helpful just to try and iterate as quickly as possible uh last question then from my side before before that's that's all from my information here like um uh alex uh with like yoti with the epsilon team it's like uh just to kind of understand where you're at is that like something that you're kind of willingly prepared to have have be like one of your primary focuses for like the

next while or what's the situation there i mean of course apparently you put quite a lot of effort already into like just like to this point so is that something you're prepared to continue also going forward i think like for example quilt team we kind of also are starting to kind of focus more on it um in the future so yeah trying to assess like how many people are working but to what extent on this yeah the two core projects we work on right now is the the object format and this okay that's that's good to you and also given that there might be synergies um between them as well awesome okay and that's all from my side

is there anything anything left left for today for today's call um for for tomorrow um yeah please try to to also read the uh the specification which is linked on the top because that should at least give a baseline of um yeah what what is the current like idea makes sense and should i continue to just kind of like use the existing full statelessness call list for invites for these working group sessions i don't really see a good way of kind of

narrowing it down to only people interested so i assume it's probably best to just keep it wide and have people decline if they don't want to come rather than handpick people who might be interested yeah so i'll just go ahead with that um yeah and i'll try to include the links again just saying this kind of specification primarily just to get people to to to read them then from my side at least that's all um thanks everyone for coming and thanks thanks alex for leading uh this session and probably also

leading tomorrow sessions already um yeah all right that's what's good so okay talk to you tomorrow bye thank you everyone