Address Space Extension Working Group #3

Transcript

hi hi everyone uh welcome to the the third session of our um outer space attention working group uh call uh in the beginning of the call we wanted to briefly kind of like just um see where we are at um and then like like talk about the agenda for the call so the last two calls we basically went through this issue document the epsilon team are prepared and specifically last time we talked a lot about the ec recover side of things as well and now in that kind of impressive discussing that a lot of the questions around kind of how to deal with this new relationship between private keys and on-chain accounts that there's not no longer like a strict one-to-one relationship however like basically can individual accounts deal with these

different identities they have um these these questions were like um they're like supposed to be the main topic for today's call but then also just to briefly kind of like um uh maybe talk about that just for a minute or so in the beginning uh would you do you think it also makes sense to to talk about some of these bigger picture questions that i mean like just before before we started here the official recording like that that started to come up about like how realistic is this change what kind of which like like layers of the stack will be most impacted these kind of questions or do would you kind of prefer to focus on the on the actual kind of substantive discussion and i guess maybe the question is i

don't know first to alex or something just because you were you were in the process of talking a bit about these other aspects as well right now well i guess we also want to to maybe get mike on the call he was reaching out on the on the discord channel he probably got the wrong link and maybe unscared again you shared a link with him right give me a second then and i'll make sure he's on the call um yeah but on the last call we also agreed that this issue document we can keep extending the issue document um um just incrementally adding new points

and i added one point 1d which is the the main topic for today anyway should should all personas be accessible for eoas um and under so we use the term personas for basically different addresses a private key can refer to um and then the other point or like a bigger question we wanted to tackle today is um the transaction access list and and how they could interact with the translation map um more importantly maybe to have some kind of a

ephemeral translation map and and lastly if we have time whether we could have some kind of a translation map in which entries expire just to keep the size of the mac map restricted so um and end with my comment on the call as well so i guess we can just get started then and start about like the like this and what we were calling like personas different personas for one private key kind of situation

first yeah i don't fully remember where we stopped on that discussion last time um i guess we were in favor okay yeah yeah i do remember some parts so so the personas the first part of it which seems to be simple is for each private key obviously we have a public key slash well a address which corresponds to a given epoch and we also have the legacy like the short address and it seemed that there's just some really bad honking outside um and it

seemed that we we were in favor of these eoas be able to send transactions which with each of those addresses um and is there any yeah i mean since people had time to think about this anybody came across any issue with that or any comments on there i'd like to point out that like from a user experience standpoint um i don't think users know about or think about private keys at all in typical usage generally people just have

seed phrases um that then generate a list of an infinitely large set of addresses that they control and like beyond that so it might be quite confusing for users if like one if like suddenly like that some of their addresses are like magically related to each other in some way given that they've not had that experience before so i guess on the what you're saying saying is for example metamask if if this address space extension goes ahead suddenly uh users would see more addresses right but they they don't necessarily would

need to know which of those relate to which private key or whatever all they care about is that they see the addresses i i think they do because i understand what peter's getting that is if you derive your private key from an hd wallet from which comes from the mock those accounts can't be associated with each other unless you have uh the secret and so when you have two accounts in a meta mask they are two identities and you can operate under them independently and they cannot be associated however with multiple personas within one private key they are very strongly linked like this is still a u and so a persona is probably the wrong word here

because it's still just one person um one identity and b i do think it is important to let users know that they are not getting privacy from those stresses yeah my personal opinion is that we should just have and i don't think this is actually an like protocol level issue but i think like users and tools should be told that they should only either each private key when they store it should come with an implicit epoch telling you whether it's a private key for a legacy account or a private key for an epoch free account already put four or whatever and they should just and that they shouldn't like reuse private keys just like if you have accounts on

multiple blockchains you should use a different private key everywhere for obvious security reasons a similar concern should apply and i suggest we just need to like define a different hierarchical deterministic path well for each epoch so the keys just don't clash but this is basically just a recommendation um and it's the same way a recommendation how um the different chain like the chain id is incorporated in the path or not um because initially the hd wallets didn't made the distinction um and they only started to do that maybe a year after like the atc fork happened

um in the same way i guess it's like an educational issue that we want to we want to ask sorry um so we want to ask the the wallet providers to do not at least provide the option for users to to use the same private key for all of these like different epochs um but should we should we talk about like this this ux side or should we talk about the protocol side because it's one thing that the wallet providers do x y and zed but if we have the ability on the protocol then somebody gonna do it anyway so i i think

that it's a solvable problem on the ux side i tend to agree with peter that we should give advice to wallets when when this comes down the pipe we should advise you know this is what we recommend if everybody does this things will go smoothly if people don't do this things are going to go badly et cetera but i don't think we need to talk about it uh yet i think it's a solvable problem that we should bring up but we can do it later is my opinion um but on this like technical level is it is it inform because the currently at least the old transaction format doesn't have the the from address encoded there it just directly follows uh from the from the signature is it is it needed to to be changed

anything in there yes we will need a at least one new transaction type with um address space extension so whenever that launches we'll have a new transaction type and i think the current plan is just to have one which is just long addresses um and so you can send a long address transaction type in which case you'll recover to that if we go with this uh proposal with personas then we'll probably need something else in that transaction to indicate which persona you're trying to work with and this is what the point one the in the document mentions and last time we discussed two i mean a bunch of different options but one option is that you would just include the the entire

address which might be just too big but we could also just include like the version byte and the prefix um and then depending on the version i mean that prefix might be shorter or longer and like version zero which is the legacy it would be just single byte but i guess this is like just like an optimization question then and i mean medium term of course we would if once we kind of talk about these things like moving away from trying ecdsa if i'm trying to use these kind of topics then medium term you'll have to move to transaction types anyway where you specify the address that you start start at and then

give it some just arbitrary bytes that that it uses for a verification or something so um i mean of course we can still go we have like for the meantime have something more optimized to the specific uh ecdsa and then period kind of type so you just have to kind of put the period number in there but i mean we could also just go ahead immediately and then move to the specify the from address transaction type um yeah just just briefly like talk about the on the topic of like do we have to make them accessible on the protocol side and there i think while while you could potentially like have a conversation about about it like in your content just as you have one chart better than one

notice where the period by it's kind of like still set to zero possibly basically that you can at least talk about you could have one transaction type that can only access the one and the one section that kind of makes the other but given that and again i feel like we should separate them but so at least have in mind that we are going to we really want to also do this the address like the static spring on top of this and so if we end up having multiple periods anyway we can't have one transaction type per period so like we'll have to have um like ways to specify which one to use anyway so i don't really see why that should not also be between legacy like basically version zero and version one um addresses as well so for me it seems clear that you should be

able to always access both i think it's like what we also talked yesterday last call about which is a more complicated question is should you also just somehow be able to kind of like directly send from from the compressed address which like intuition seems to clearly be no because it's not an actual address it's just a pointer um but we kind of talked about that last time as well so that's a more complicated question but just from like the short address and then the long address they can that both kind of like run to the same private key seems like they're really like we really have to allow sending transactions from both yeah the compressed one is the second question but i just wanted to at least close the conversation on you

know the easy part do you want to allow um like sending from any of these addresses and the but the compressed one i guess is a different question but then sorry yeah did we i mean there doesn't seem to be anyone seeing any issues so far with it apart from like the the ux issue on wallets for privacy issues and wallets right and in a sense uh i don't know this is probably silly but there's this weird failure case that could happen if you ever have a long

address that for some reason reaches somewhere that it shouldn't and then gets kind of truncated or something and like just of course i mean kind of by accident but also kind of like of course by design you kind of end up with the short address that happens to correspond to the same private key in case it's just truncated not actually compressed so in a sense maybe this is also somewhat of a failed save for at least for uas but i i mean ideally that this would never happen just just saying though it could help something to add to the list for after we talk about compressed addresses um what about contracts can contracts execute from different personas

wait so like the situation right is that even for you for accounts you basically have one private key and then multiple accounts and those are just distinct accounts on chain whereas for contracts because you don't have private keys they control them in the first place each contract just as each account lives at a separate kind of locations um and now each contract also looks at several locations so there's never like a situation where one account has multiple addresses well i mean except for it compressed that's the risk so you meant that in the you meant that in the context of the compressed addresses so yeah okay yeah but then that's maybe this is basically like if you say anything then before we move compress addresses i mean i'll set a point here to kind of

try and separate that is there anything like for the just for the pure kind of yeah short long seems reasonable to me i see no problem okay and then um i assume what we talked yes the last time about as well but like how maybe ways to make the existing ecdsa compatible with that indicating which one to use something like that i assume that that should also be separate discussion then similar to how we talk about compressed separately i take that as yes so what's i i don't understand the question what's the well if we have a context last time we talked about how

um while we probably will have to have a new kind of easy recover too or modify the existing ec recovery if indeed it turns out that you can just kind of like put optionally give in extra input data or something right but at least they'll have to be new version of easy recover for for long addresses right for the native world but but the for situations where you have to be backward compatible with existing contracts that use the existing ec recover you we were thinking ideally you don't want to just break compatibility with long addresses so ideally like once like once you call into ec recover from an old address yeah you should basically just have a way to indicate which address to resolve to

like which period basically which version of the of the pro of the private of the key to it to resolve to yeah yeah i think name personas can solve that as well but i think if we agreed on this last time right like um i mean i documented what we discussed there all right and the i mean just to recap uh while it would be a nice hack to have like an optional extra input um after the current 128 bytes of dc recovery pre-compile it unfortunately doesn't have a length checked so far so there might be

contracts which send extra input um so the better option is just not to touch the the current pre-compile and introduce a new one and for the new one i suppose we just we just have to discuss uh this personal question in terms of the new transaction type and just apply the same rule to this easy recover so whether we decide that it needs to include like an address or it just needs to include a prefix or you know whatever i guess we could just make use of the same logic in both places all right although i would i would argue that the easter caller the new one should be

like it's more important to that before compatible because we can't we can't really easily change that afterwards whereas like a transaction type we could always change so i would kind of like i think it's more important for that design to be kind of more more forward compatible but yeah i agree with you that we discussed it last time sorry but i wasn't clear when i summarized that previously like i didn't actually want to recap that like or talk about that part again but there's this other aspect of easily recover that we didn't talk about last time or like only briefly talked about last time and this is how to make existing contracts compatible with like existing contracts that use easy recover compatible with long addresses we briefly touched upon that last time as well but that's a like a distinct question right because

like the new version of vc cover can only be used by the new contracts but all contracts already use a specific the the old easy recovery they only send the existing input to that so you can't kind of like modify that behavior and so the question is yeah i think personally sold that as well like we can welcome almost the same system but it's not the same right because sometimes your situations where the center for transaction um is is not the same as the recovered so the question is so who is it it was authorized to kind of indicate yeah so transaction congestion so transaction can just contain a list of um assigned personas basically so you

basically just attach a signature to the transaction that is signed by some private key and say anytime this um like my address like me anytime this public key is used this is the address i want returned for this whole transaction and you can have like a list of 10 of these or 100 of these just like an access list sort of thing where it's just attached on the end and you can it shows up when you do easy recover you see recover 2 whatever well yeah i don't i don't think it's necessary with eco cover too but uh i agree that this seems the most feasible way of going forward specifically to make easy recover for legacy contracts compatible with new

long address signatures basically yeah and i think we can if from a complexity standpoint if we don't mind doing a trade-off in terms of transaction payload size versus complexity we can use that same like recovery list or whatever you want to call it for the primary transaction personas as well if we wanted and it would blow the size of the transactions but not worth it but it would decrease complexity because now you just basically have one place where you go and this is anytime you do an easy recovery check here if it's not there then fall back to some reasonable default which is probably legacy well the ec recover is already at least the current one

deviates from transactions because it doesn't have um it doesn't have the the check um you know for the it accepts both no no well that doesn't yeah that also is missing but it also accepts both priorities all right although it is important to know that the kind of the signature you would put in the transaction itself to indicate how you want the easy recovery behavior to work would be a different signature from the signature that then during transaction reach just easy recover so the transaction unchanged that

recover would follow the easy recover rules whereas the signature in the transaction that indicates how easy recovery should work that would follow the transaction level signature kind of rules i'm not sure how much we want to mix like whatever is in the transaction and whether that influences how precompiled works because we don't really have you know too much prior art for that but also just in terms for our discussion we seem to have geared to easily recover again i'm not sure we should discuss easy recovery today um and maybe just

you know we haven't we haven't finished the other point and the compressed address and there's a bunch of other stuff to discuss so i'm not sure you see recovery is like a priority for for today i think we really discussed it last time yeah yeah we can move on i just think that like what might i kind of conceptualize it as being part of this persona uh conversation because it's like private keys should have a way within the transaction to indicate which of the on-chain accounts for for like for the context of this transaction kind of is the one that's the colony for one for them but i feel like we have talked about it indeed now and so we should we should move on and um i think next

then would be the compass addresses that right can you can you summarize maybe like the question there can we have a compressed address as a persona can someone sign a transaction and say for this transaction use my compressed address right an important of course to notice that for the compressed address there is not actually at least in the happy case there should never actually be something unchained at the compressed address location so whereas with for short and long addresses you actually have an account a separate account living only at each of these locations for a compressed address

that should only basically be a pointer that every time it's being used on chain kind of resolves to the long address location where then they are actually the account lifts or the contract well i mean but if we're talking about transactions in the account so there's nothing actually at the location of the of the of the of the compressed address so this only ever becomes relevant once things kind of reach the compressed address by by accident basically because it wasn't yet in the translation table and someone sent funds there or things like that so this is more like a failsafe like it gives us a really nice fail safe if we allow people to operate as compressed addresses we wouldn't want to like encourage

wallace to make this normal operating behavior but it does give people a way to get out of situations that they might get themselves into which worry us so the the case where this happens well okay one example cases um the the way the translation is populated if you start a transaction from the long address side uh so if you if you uh interact with from a long address context with like a legacy contacts then the the translation is translation table is populated and you have the compressed one but in the case of like a ux failure somebody already has like the compressed

version and creates a transaction not involving a long address that this will just create the uh since the translation table doesn't contain it it will just create a new account at that address um but i think this can i mean this obviously can happen for both cases not just eoas but contracts and and by contract one simple realistic example is like gnosis safe right and if you only make this possible for eoas then there's all distill this large surface for for like contract wallets and then why do we add this complexity if we are not solving it

properly so maybe maybe that's one reason we shouldn't shouldn't think about this right also maybe maybe even more than just physically that we don't need it or that it's kind of like just just like a partial solution because because it would only work for uis i think i'm convinced at least that it wouldn't like that it's not just a complete non-startup or security reasons like to me at least it seems like once you allow this then basically calling from such a from such an address into a into a context that doesn't know whether it's being been called into from a from like a legacy or a or a long address context so so say basically

uh yeah basically to me that seems that they could make collisions uh even more problematic um in a sense but but yeah i i'm not i'm not sure yet i haven't really thought the implications fully through but i i'm yeah i definitely agree that it looks weird that because it would only be a partial solution so yeah my intuition is very much say we shouldn't allow this but i haven't yet found like a very clear is there any way we can allow this same sort of uh persona for contracts like if if the contract can sign or can

do arbitrary transactions i can imagine ways of like authorizing a thing um but if the contract like for gnosis say for example like i feel like we could solve that one specifically but it is not nearly as clear to me how we'd solve it for contracts that do not have the ability to do arbitrary execution so i think the thing that makes this slightly confusing is the compressed address isn't really an address or a separate account it's just a pointer to that refers to um allows you to refer to long accounts in a legacy context so like ideally what should be happening

is that you have some operation that goes on in the log address world and it wants to call into the legacy world so when it makes that call into the legacy world all of the long addresses in the long address world get converted into legacy addresses by compressing them and then the legacy world can like go about its business never has to know anything about these long address existing all it knows is there are these compressed addresses that refer to long addresses and then at some point it calls back into the log address world at which point all of the compressed addresses have all the legacy addresses that are passed through have to be resolved um and the ones that are actually legacy

addresses and don't appear in the translation table get turned into however the long address world stores legacy addresses which is probably like a special epoch prefix or something and all the ones that are compressed addresses get resolved through the translation table back into long addresses and i think that's like the basic model we're going for the problem is that like how do we make sure that process can't go wrong somewhere and we end up with like some long address or some compressed address um making it into the legacy into the long address world

and actually being treated as a special legacy address there and so on right um i i think that's so basically yeah there's a specific failure cases that i see are twofold so one is that just like raw ether if someone sends raw ether directly to the compressed address before it actually ever reaches the translation table so um say i don't know some some some i i don't know we don't have to come up with a specific example but it seems seems very very feasible that that could happen also like especially we have here to talk about the exact nature of the translation table but

there are words in which we have like a completely ephemeral optimization table or at least like an expiring translation table this kind of situation so it could well be that sometimes even like once something was in a translation table it might not be in the future or something so so that raw ethos reaches that because if it ever is like a token or something uh and it's it's in the in the legacy in the legacy token contract you should always be able to still call from your full long address and then that just gets converted while it's being used inside the token contract so it's only raw roika and the other the other one big one that i see is just if someone on accident deploys old solidity code at a long address that basically where basically this little it still truncates

long addresses right because there the up codes would return the full long address like for the caller or something not that not the compressed version and so they are basically the only way to ever kind of like recover funds or something that have been mis kind of attributed to like compressed edges or something would be by kind of calling into it directly from the control from the compressed address because that part they will be able to pass through the the code kind of unharmed but both of these seem to be complete like at least the other one seems to be like obvious just like a fail safe from a misuse of the blockchain which to me just doesn't seem worth it especially because it's like a special case solution just for uas the first one kind of like could be

worth it just in just in situations where we will go with ephemeral translation tables or something like that but even there we would ideally want to have a solution that also works with contracts of course so for both of those i feel like they can be solved independently so for the first one where you end up with eth in a compressed address that has never been seen before so you pre-send some ether whatever i feel like we should be able to solve that one by just creating some new transaction type or something or a precompiled you can call that will just allow you to just extract you from your compressed address so you can basically say hey that's my compression address that eth got there it's a mistake please send it over to my actual thing

and that's something we can just verify the signatures and it seems super simple um for the second one um yeah i was i was considering the same option um because there is uh there was a proposal uh an eip proposal for this uh recovering you know some locked eater um and that proposal covered like one of these early etern.js bugs and some other stuff i'm not sure if you remember that proposal but i mean this would kind of be you know similar and uh yeah and i guess um i guess it doesn't need it doesn't

necessarily need to be there from the beginning uh but rather it could be considered if uh if we see you know like a growing amount of such cases happening on chain so maybe or maybe it's possible to not have any such solution in place at the time of um ase introduced uh but rather have it on the back burner and if you see that there's like a significant amount of of such cases happening on chain then maybe consider hitting it can i suggest like an even simpler solution um just make the operation of adding something to the translation table

if this only works if we go in a world where the translation station is stored in chain also it's like add the address to the translation table take any ether that has been sent to the compressed address and move it to and move it to the long address that corresponds to it and then like it's just impossible because any ifa that gets sent after the compressed address has been added to the translation table gets forwarded to the long address and any effort that gets sent before gets moved when the um compressed address is added to the table actually this in the specification but it seems to be too much at that complexity

for the protocol yeah so i like that right i think it's pretty very clean um i used to worry a little bit about cost just like it's expensive to do like state lookups every time for example also again this one thing that kind of like becomes much more complex once we add static starry on top just because it could well be that the uh original put the potential kind of original account that is attached to the compressed address might have already been expired and so what that that means is basically you'd need to have exclusion witnesses every time you add an entry to the translation table or of course you could you could have other rules like you only kind of recovered in case it happens to be in the active

state or things like that um but but yeah like basically with with exp expiry this becomes even more complicated also we have the same problem for compressed address um if we do like a pre-compile or a special transaction regarding the needing proof of in state expert world we need extra what do you mean if it's a special transaction type that that's nice because then it's up to the person doing this special transaction type to just provide all the proofs and that's fine oh i see it gives us a request and then it's only actually used once there is an extra problem so it's like only in a fraction of the

cases does actually have to be taken so i generally yeah but this only works i mean this first proposed solution only works for like uh end user account so if if the compressor graph corresponds to contract this special transaction will not help here uh no i think we can i think we can make it so anyone can call this it doesn't need to be permissioned like is that correct like we can just say hey if you notice that there's money in a compressed address and you can show me the uncompressed address then we will move the money through the uncompressed address and we'll add it to the transaction map and you provide

witnesses so as long as someone's paying for all that then it doesn't matter who is that correct well kind of so yes we could do that the problem here is and that's by the way the problem with all of these potential like compressed uncompressed merge proposals is just the but their tech uh issues right where for example i hear i could just grind out a long address and a shot at like in the short address that where basically the compressed form of wrong address is the short address and then i kind of create a new contract at the short address and i convince people who send funds there and then i later on just basically do this special transaction type where i show that i have the private key for the long address and then just basically

claim that the short address was only like a error that should not never have existed and just has funds in there and i i claim the funds so of course you could now have like special cases rules where it has to also check that the code is zero or whatever right but this is starting to really get very complicated and um so i just i just in general with a lot of these kind of merge issues i just worry about uh digitization table then becoming a an intake vector for both attacks kind of a similar opinion that like we're kind of reproducing the issue

we're currently trying to solve which is the the 80 bit uh security of the of the hashes so the kind of like other ways to to actually exploit this this lower security uh and i think that was mentioned in multiple places already in the in the in the issues list maybe it would work i mean i i can't kind of like resolve it in the terms of security uh but it's it's it's kind of a worrying sign of that i thought we agreed last meeting maybe i'm misremembering that um counterfactual short addresses or short addresses that are used for

counterfactuals are broken and you should not do it and this is just another instance of that but haven't we already nobody that what why is it perpetual in this case it would be a contract as my contract that is actually deployed with a shot with like a short address in legacy space contract that's actually deployed and people have sent funds to it and now the funds can basically be merged out on like taken away yes so for that specifically we can just check to make sure the code's not zero like just right before we send the fund just make sure that there's not something there just like this new eip we just added is doing for um right but then we just kind of starting to create like more and more kind of narrow like like a

rescue kind of operation for more more narrow kind of use case i mean like we yes we need to do validation we need to validate a number of things but i don't feel like that should be a blocker for the solution especially since we don't have in my opinion any better solution like this is the solution to beat for me right now is is this and that situation that you described doesn't prevent it because we have an easy fix for it which is just you know a simple check to make sure that before the transfer happens just make sure there's nothing living at that address it's got no nonce it's got no code and that's it if someone has a better solution you know that's simpler i'm i'm interested but so far that's the solution

though uh why not because because you have to time time this properly right if you if you so in the case um uh you make like this wrong transaction first so you interact with the the contract without having at the translation table and then somebody else interacts properly uh and and you don't have like an automatic merge or anything like that um then you need to insert this like a fixing um transaction in between those two because after that uh you won't be able to so i mean so basically

i feel like that that sounds like a counterfactual problem misunderstanding like you're you're saying that the you have an address it has no you meant the argument did not send everything for for the compressed address account right yeah so when when you submit this transaction or this calls free compile that says withdraw the eth out of this address and move it into a corresponding long address um when you do that it checks to make sure the nonce is zero and the code is zero at that address if they're not then the thing fails and it won't work you can't withdraw these it's stays there forever if there are zeros both then it just lets you withdraw and then it wipe

you can delete that out of the state tree and add to the translation map and that can compress address will never be used again because it's now in the translation map i'm not convinced that this this is needed at all because this is still just solving a subset of the problem and we are so the other half of the problem which i never got to because we got distracted uh the other half the the solution it feels like is um was the contracts deployed with old celebrity code something else oh okay what's something else then um i mean just tokens is an example or anything else

because we only say that you know i mean with this discussion we only say that we care about locked up ether and nothing else but you know in the same note um you could also just assign tokens to like a compressed address um but i guess after but it will always be if you're in a legacy contract then it will always be accessible by the long address because it'll be compressed when it comes to receiving yeah well but is it that's what i'm just trying to figure out so let's say you have a and a token deployed at a long address right so it's a new token that kind of like stores full 32 byte addresses and their mappings but then someone accidentally within that sends to the compressed address

sometimes and now were you to withdraw to that kind of address something and it would actually send things there that they would resolve but if it just kind of checks if the sender was authorized or something then the sender will always return the full kind of wrong address and so if you ever call the monometer if the kind of the unfortunate owner of this of this kind of uh yeah right if how so isn't this like another big issue so let's say uh you assign a token to the compressed address because you were in the legacy context like i said legacy token or modern token it has to be much more otherwise it's

not a problem yeah yeah modern token okay and then you need to deal with it on the legacy side you cannot deal with it on the other side maybe with approvals this approving like an old contract could work but yeah this sounds like this sounds like a complex question [Music] so for yeah i wanted to propose maybe um that we write it down this this rescue transaction approach uh because this seems to like a lot of details uh that is difficult to catch uh on the call

uh but one more more comment is i think instead of just transferring the effort you actually need to execute the the contract that is on the other side if it happens to be a contract so that's also like code execution involved but i think it's it's reasonable to like write it down and see how it looks on paper um yeah that's all i have yeah i think that that sounds reasonable and i like last last kind of thoughts on that topic from my side is just that um in in some sense especially like these

these questions are like new let's say new token basically and and funds there being misattributed to a compressed address or something like that i think that's just a prime example for how we should just very clearly never allow oh like wow we should never write code that has old contracts called into new ones right because that's just that that direction just doesn't work we are backward compatible where like new contracts can call into legacy code but legacy contracts actually interacting with new new tokens or things like that it just doesn't work and because then then kind of yeah they draw things out of call data that isn't aware of 32 bytes and all of these kind of things like like unit swap calls into any token

that you throw at it and we would expect unit swap would not break suddenly with this introduction no but it wouldn't break but you could just it wouldn't it wouldn't actually no no it would break in a sense like you can't just take the existing legacy uni swap and point it to a new kind of shiny new token and it wouldn't work like it wouldn't break unispot but it would break that specific swap that just wouldn't work because the the two or four for the transfer would come from call data and so it would be a compressed so so it would work in some scenarios but then they're not in others and it would just be a huge mess so just don't don't don't don't do compatibility that way like don't start a legacy and go into the new world

so that feels like a deal breaker then because we're back into the problem of if stuff doesn't work with new addresses people will not create new addresses and we'll get zero adoption like if you can't use uniswap with a new token token no tokens will be deployed with the new code like they'll all deploy old style because you need to if you want to work with unison okay so then like yes yeah and i was going to say that like it's actually even worth worse than that because of um defy composability um so for it like so for example when you actually do a swap on

unit swap v3 what actually happens is you call into uniswap say i want to be swap um the contract uniswap sends you what you've bought um calls um your callback and then after the callback is completed make sure that you actually paid for what you bought and if you didn't pay it reverts everything so you can't so like no one it'd actually be quite difficult you can find a complicated i think you could do it but you'd need a special like shim um just to even use uni swap um and you could never take out a flash

loan which is like one of the most standard operations and it's becoming an increasingly standard operation for people to do from legacy world so i agree with micah that it just completely breaks everything okay so then like yeah so without like what i i'm taking from this is that i really want to spend some time over the next few days and i'll basically just do a couple case studies at least one let's say like at least like a uni swap how what would what would happen if basically you mix you you just using the existing uni-swap code as an example because it's reasonably kind of simple but also complex enough that it probably has problematic behavior in it like a different combination of what if the one of the tokens is in your address

what if what if the quality new address what if the recipient is kind of like just different scenarios just play it play it all out and see like when at which stages would address actually be compressed where would they be truncated which will basically is there something that really looks like it's really hard to make forward compatible um i don't i don't think we can really that that's not something to be synchronously done on the call but i'll definitely spend some time just basically step by step going through like a very specific example i think that would help at this point because i think we all write that basically i think we can admit that address does not break the legacy world

we all agree that right maybe not fully but right but like i think we are kind of reasonably confident that at space extension itself would kind of like you could continue to work live within the legacy world and everything would kind of work fine you can live in the new world and everything would work kind of fine and we hope that there's some kind of some compatibility between the two layers but i feel like we all still don't really have like a really clear picture of what exactly works and what doesn't work and that the current kind of ideas we have in the in the interoperability between those two address spaces um and that's that's i feel like what we really have to drill down um understand whether there are problems um and then

looking at looking at the clock it's already kind of like creating you know on our like 60 minute deadline um would do did we want to talk a little bit today uh then as well uh about like the translation um that's i think right alex can you confirm that that was the second thing you had on your uh that you mentioned earlier today um and if so do we want to briefly start talking about that or do we want to spend a few last kind of ten minutes or whatever five minutes plus whatever we go over um continue this specific discussion it was but i wasn't optimistic that we're gonna get there um

i mean i'm fine basically discussing that just we can also stay on this topic if you if you feel like that that makes sense i think yeah the only point we could do on like the the access list or ephemera translation map is just to give like an intro but we would need to do that tomorrow or next time anyway so maybe it's not worth um doing anything with that today yeah i think my my takeaway is is really just this token balance question is is it's a bigger one again and and because of that i'm not

convinced that we need to think about like these partial solutions of like recovering ether because why do we elevate that over any of these other risks just because it can be kind of solved is that the only reason we want to to solve it right i'm i think i'm with alex here it feels like this is over optimizing for a very specific failure case that could turn out to be 1 out of 20 and then we have we basically have all this extra logic of swift case handling for it i definitely am open to that any kind of complete address space extension proposal in the end could end up having something like this

in there if we if we really figure out that this is the one thing we can't otherwise solve but i feel like at the gun stage that we add i don't think it makes sense to have a provision in there specifically for sending from compressed addresses uh it would be helpful if someone has a time um to i think to just go and write out or add to the document maybe um very personally like very succinctly um each of the example scenarios that we'd like to solve for

um for example someone sends each to a compressed address that has no code deployed to it no non's used um we need to handle that or contracts deployed with old solidity code and you need to handle that or someone change the token to a address that has no code or no not associated with it need to handle that um just so that when we're having these conversations we can just refer to like situation 7f instead of having to redescribe it every time this is purely just for facilitating communication just um it's actually as a number it's one g

in the in the list do we already have those ones well i only added the heading that needs to be written well they ignore me then if we already have them oh as you're saying you're saying you could add that to 1g um yeah i guess before we we close off um yeah is there i think you need to refresh the document in order to see the additions but is there yeah that was my problem is there any other point we should add

um maybe that would be a good thing to do just to list these these questions and say that you have a record of them we can we can go through them next time do you think there's anything else which could be added i don't have anything specifically coming to mind immediately um if no one else has like basically the follow-up

question that yeah so i'm back to bearish on address space extension i flipped every one of these calls i flipped back and forth i'm bearish bullish bearish bullish yeah but maybe maybe this is just like basically a sign that we have to get more concrete or something in in the actual kind of like workout specifics or like just looking at specific scenarios or um i i have to admit for example i haven't really looked a lot at the ase test cases document yet so i'll definitely kind of do that a bit more and then also um come again try to come up with some kind of intro scenarios that i find

particularly interesting or um problematic as well but but then for as alex was kind of just not asking about like points to add for full kind of discussion and do we want to i feel like because we still have this one topic left of the translation table kind of the the ephemeral one and the atmosphere at this list and maybe also kind of like ideas around uh alternatively to the ephemeral one maybe the expiring one seems like that's kind of like one natural kind of block of of content still to be discussed um so so how do people feel about um about the rhythm of these calls going forward to me it seems like there could be a scenario where we can

do one more of these kind of relatively soon so in the next days or something and then maybe afterwards uh have i have maybe like a a couple days break or so to to to actually kind of look into these um kind of scenarios individually or something or what's the because i think we can't just continue to have daily calls for the end of time so i'm just i'm just wondering how people feel about that but also i'm sorry if if anyone wanted to because i waited a little bit i won't mention any points for alex to put it in a document but if you have any feel free to to to say that as well now i think he had a good strike and at these and um i would say it's not unrealistic if you if you want to

have you know maybe one or two more of these goals this week um just to i mean just judging based on how much time we spent on this list so far i think we're lucky if we can finish like this uh trans the the access list and and you know ephemeral or expiring translation map topic in a single call i think that is um maybe possible but maybe a tiny bit optimistic um and and if we if we still want to talk about like this token balances stuff and the compressed addresses i think that that's we shouldn't mix those two topics into a single call

because then we're gonna spend the whole column compressed addresses again my preference is to um not move on until we have some viable solution here or until we at least agree that we don't need to solve this problem one of the two because just because i don't want to waste work solving all the other problems of address space extension if we have some blocker like for me this currently is a blocker and maybe with more conversation i can be convinced that it's okay that this will break though i'll definitely need some hard convincing um but i just like until that's fixed like everything else is doesn't matter like if if we can't fix this in my head right

now if we can't fix this problem we cannot move forward with address space extension and so there's no point in wasting time and effort and energy discussing all the other aspects of it because this is a non-starter that's my personal position a slightly different take there and that i don't think i think the problem really is that we don't quite understand the exact nature of the blocker like we always kind of end up having talking about very specific examples where we think oh yeah no this might not work and then we sometimes we kind of find a specific solution that works for that specific example but i feel like we really need some time now i think we all kind of like have like a really good grasp on the with a with kind of expect exception of this of the topics we didn't you talk about right so the kind

of specifically the ephemeral translation app but but but like on most other topics we have a good kind of understanding of at least what the challenges are but i i feel like what we need is a little bit of time to just kind of figure out exactly what the nature of the problems are and which one of these could be boxes or something i'm not sure if continued calls are the best format so i i agree with alex take that basically like one one more or or two more depending on like if we if we get to the rest um on one call uh immediately like as basically as soon as possible kind of makes sense but then afterwards i feel like it's probably best to at least you know have a little bit of time in between it doesn't have to be much i

know maybe we even just or something but um just just so we can actually work out exactly what the what what if if they are blockers and how the hubbles look like but yeah but it sounds like physically we will definitely like it seems like everyone agrees at least that we that make sense at least have one more kind of schedule called for for the um for whatever we kind of didn't yet get to so should we try to do it tomorrow wednesday thursday or friday which day should we retarget

personally besides i'd have a week preference wednesday i think i can make tomorrow work i'm not quite sure if i'll be able to make it i have a week preference for not thursday so to simplify tomorrow or wednesday those are fine with me around this time sorry mike what did you say

both work for me at this time if we like if we were able to just go like to do another 30 minutes to the right i think i'd be confident i could make tomorrow as well um but i'm not sure if that's if that works with people 30 minutes later you said yes so like at the time we started today today or 30 minutes after no no unfortunately 30 minutes after but um i mean for me that's fine but i think micah might be the them does anyone here go to the uh

network research call which i think is at that time apparently wait no i i don't think that's that's right though i think that would be the one immediately following so basically we should we could just not run over tomorrow so i was gonna say that we do not do good and not running over it says yes if we bumped it up half an hour then we'd be back to back with the network research call so someone needed to make that we'd have to cut exactly off at that time okay how about we do that and and that also limits us how much time so we we should then still discuss like

this persona and compression stuff and maybe we could target to to finish it you know earlier not like one hour and not get into the the translation like the access list and ephemeral stuff yeah about that and we target like 30 40 minutes tomorrow sounds good and then we can have maybe one last call on wednesday potentially here sorry good no but you're glad uh just to be clear i don't have any ideas how to solve this so if you guys have ideas that you want to bring to the table or try to convince me this doesn't need to be solved then the call will be valuable um when i'm going to show up to the call though

with no idea so hopefully one of you too will bring something on the table or someone else wait i i thought the idea was to kind of try and have the call the call or calls tomorrow and on wednesday uh be focused on whatever we didn't yet talk about basically not not continue this question after that oh yeah like i said i find it uninteresting at this stage but if you guys want i don't mind i feel like it just kind of makes sense because we have this document like by the epson team we talked about kind of all the other aspects just this one aspect not yet so i could just take a good conclusion of the series of faults and then we can kind of take a step back work through these kind of problems we saw in all these different topics

and then kind of reconvene maybe a week or two later something and take it from there so i think it's worth to to talk about uh access list uh because i think it might open some uh some ideas for solutions and i think we even mentioned some of these um so these are the complete solutions but at least you can you can additionally include some some information in the transaction that prevents some some cases we don't want to happen so at least maybe on ux side it can help with some of the key cases we

have been discussed yeah i i agree with pablo that like there's just on the meta level here is like basically having the full picture see seems like a good idea to then talk about the problem figure out the problems right because only if you have like a good idea of how the full system end-to-end would look like can you really kind of determine if something ends up being a problem or not so i feel like that's like the one piece that's missing so yeah to me to me it seems like a good idea to to just have the call and then i feel like we can just if we just schedule something for 45 minutes say tomorrow um like basically starting 30 minutes after today's session and ending 15 minutes after today's session

basically so i mean we already 10 minutes after day session so i feel like basically yeah similar to today then the end um yeah and then we we see if we have we basically need one one last on wednesday and then afterwards we'll take like a week or so a break and everyone can like look into this individually does it sound like a good time if no one disagrees i would just say we'll do this this way and um yeah and then is there any any closing anything left for today any any shot sure sorry let's bring up just to confirm

are we are we talking about the access list and ephemeral maps tomorrow or right oh sorry what was the alternative well i guess this this compressed stuff to me so maybe tomorrow is not a good time for that but yeah i feel like this compressed stuff we would need to write down like um all this what has been said in to like some concise paragraphs and and think about it so maybe we shouldn't try to do that um yeah i guess we can try the the access list tomorrow so that's likely gonna take like the full full hour

all right wait wait so then did i misunderstand you earlier like they so you were proposing to continue talking about compressed addresses tomorrow what was that your proposal like ten minutes five minutes ago um yeah i think i would continue given we can write down you know all of these and because i think some of those questions were not fully clear to everyone um okay okay so then change of plans that's fine but that's it no no whatever you suggested is fine with me um i think we spent like 15 minutes trying to figure out what call to have and what can't you hear for it no but but then now i feel like it makes sense like okay

let me just be clear unless someone protests we'll do it the following way we'll have a 30 minutes scheduled call tomorrow for just kind of formalizing the problems we discussed today and then afterwards on wednesday we'll have one last one-hour call to discuss ephemerals and access lists uh transition map and the access list idea and then afterwards we hopefully i'd like a good point to pause is that like anyone that sounds good okay and then that's the this way awesome um at the same time tomorrow half an hour or half an hour later uh no like half an hour later would still work for me best

that's so that that should still give you like a 30 minute buffer between the the end of that quality state cargo okay awesome thanks everyone thank you it was great talk to you tomorrow bye yeah bye