Address Space Extension Working Group #4

Transcript

okay so hi everyone to the fourth um address space extension working group call today we have some more charter calls scheduled where we basically wanted to go over the content of yesterday's calls call again but um produce like a tangible document where we where we actually list the specific um kind of use cases of or cases in which interoperability between these different personas and all the new address spatial spaces would be problematic so so this is kind of the topic for today um alex do you want to kind of

lead that once more yeah first of all i'm um yeah i want to thank everyone for the repeated um activity of joining this i'm quite surprised that we have a similar amount of people as yesterday and i try to listen to some parts of yesterday's call um just to to be able to add some more points to the document but i only ended up adding one um which i think is relevant to today uh it's this specific discussion um i guess mentioned by micah

that what happens for the case when um a legacy contract which is bound to only using the legacy easy recover it would recover an address different to um i guess like different to the compressed one and yeah i added that as a point and i think the other one you wanted to discuss is really this token balances with compressed addresses and if the compressed address is a persona um i suppose our goal would be to um maybe fill out these three points and and if there's anything else that

not something else um and and maybe before we get into that um maybe some of you have seen but on the cryptography channel on the eternity discord um um yeah my caster question if anybody would would have any idea how could we have a shorthand a compressed short address which is still distinguishable from a regular short address and yeah i don't think there was any any real um answers so far coming up um i did propose

sorry micah i think i think i was mostly convinced by potas that it will necessarily require reduction in entropy and we can achieve the same thing by just doing the like use the first end bytes i think we'd functionally be the same so i don't think there's any easy ones there yeah and and on that note i i proposed like a simple idea that um you would just have like a hash of the the remaining or like some kind of a checksum um after the remaining bits um and somewhat related to this other

proposal to instead of extending the address space rather just using the 20 bytes we did do some analysis on existing accounts in the state just to find any kind of prefix and there's plenty of like three byte prefixes which which could be used in in general but i think i realized that with even that proposal we do have a similar problem as we have here in case of you know any of these like like the compressed issues that we need some kind of a recovery option right i mean especially when it's not

eat right but if it's a token balance something then that could still be sent to uh like by mistake to to address with that prefix yeah yeah um yeah i guess in that other proposal um how it works is if you if your regular like um address generated from your public key would end up with having that prefix then you um just xor it or you you just do the next step to to generate the version which doesn't have the prefix um and obviously with the uh for these cases we would need some kind of recovery option okay just countries of time so

in the i guess one point we discussed this really this question what happens with token balances with compressed addresses do we want to do you want to spend a few minutes on that yeah so maybe just to to to get that kicked off um it's very pretty i thought about that since yesterday and to me it appears like in general that basically we can't continue to use the existing escs in the new address space so things like esc 20 right they define is a very specific interface including the exact methods that that that the contract um basically has to use to have and it is

the way that it works right now it hashes the exact um type of of of variable um in there and specifically it from any of these um functions methods on the contract uh the the address the variable type is address right and so like a 20 byte address and for new tokens uh you need to create a different function that takes in a 32 byte so this is for example send tokens to right the true address is just sent by a call data and now it's a different a variable type and so what i think has to happen is actually that we'll have to have a new type that's basically just a an extension of the sc20 that would be an

esc 2000 or whatever and that basically would have a different interface for this new 32 byte address type but then basically what it could have is it basically could have legacy support for the old interface so it could also implement all the old functions but every time you call the old function it could then basically manually go to the translation table as long at least as the translation table is indeed accessible by contracts and manually resolve that right and i think if we do this very clear separation i think many of the problems we talked about yesterday basically go away um so basically make it always very explicit when so basically like only

allow like if you deploy a new contract in the new space always very clearly define old like legacy interface kind of methods and then manually handle the translation there and so at no point just by accident do you have the case where you're being called from the old space um but then you interpret that as like a call from the new space or something so i i think that solves a lot of these problems i don't know though if that makes sense i um agree with angza um i think that we should have the that we don't like and i was talking about manually

i'm not convinced that it really has to be that manual i think that all that has to happen is every contract that's in the new address space has to basically define two entry points it has to define an old entry point and a new entry point depending on who calls it and then the people who call the old entry point uh and then but then solidity can just like generate the shim itself because it knows that like argument three of this function is an address and so in the old in the new interface it makes it a long address and in the old interface it automatically converts it to a long address by calling the by just using the translation table

right actually i had a chat with chris today and we i guess initially concluded that we would want to have a new type um for i guess long addresses um i mean that's that's very much in line with what you said uh i mean this definitely helps for anything on the the new space but has this exactly helping the legacy case what we were discussing with the compressed addresses i mean that's that's in already existing contracts so in the old address in the legacy space you you so there's

two types of calls that are hard there's calls that go from legacy space to new space and calls go from new space to legacy of space um for um new legacy space to new space i'm proposing that the legacy address calls the compressed address of the new contract um with some like legacy function with legacy addresses in that gets handed to the entry point for legacy code on the new address which does whatever conversions it wants to and this should be i think auto general auto generatable by solidity in most cases and then

hands it off to the contract code and that's the legacy of the new address um for the new address to um legacy calls um the reverse you know the legacy the new address contract has to like make sure it makes a legacy call to a contract it detects as a legacy contract so for example if you have like a new contract that wants to interact with an erc20 token it has to check whether the token it has been handed is a legacy contract or a new contract if it's in fact a legacy contract it then has to convert it has to serialize all the call

data um as if it was using the legacy solid linty interface it has to convert any long addresses it's got to into their compressed form and it can then hand them to the um that to the legacy contract and the legacy contract never has to know anything about these new address spaces which is like completely oblivious this is the the the regular cases we were happy with but i believe that the whole conversation we have about the compressed addresses is not the um it's not the nice case but the the problematic case where you didn't initiate any of this properly

from like a new address space to a legacy space rather somehow you ended up submitting a compressed address to the legacy space if you as you describe if you initiate the transaction from the new address space to the legacy i mean that's even with the current proposal that's well covered because and on the legacy side uh any any op code which returns an address would do the translation map insertion for you and uh such as like origin or sender or caller um and from i guess the api standpoint um the api for most of the contracts already

enforces a uh a 20 byte address and if you spend send more it would just rework so for all of these like happy cases when you properly initiate this from the the new address space to the legacy i mean all of this should work um but i guess what we were more concerned about is when when somebody messes up right and i i think like when we question this though kind of how how easy is it to basically mess up and i yesterday i was very concerned that some flows basically are really tricky to to to get right but i i know at least think that

with very strict kind of facility typing inside of new contracts at least you can um make sure that you you can't just kind of like accidentally point small contracts to each other in a bad way basically so that all of this will just work and so i think the only problematic case is really if incorrect address types come in from the outside via call data so like if you call a um in a legacy contract and you accidentally give in like a full 32 byte long address that's problematic and then also if you accidentally basically give a new token or some contract for example a compressed address from the outside

as a target for percent um but then i think yesterday what we talked about was like if we even think that special purpose kind of recovery methods make sense to provide from the protocol and i'm still of the opinion that if we can make it really kind of like very uh if we can ensure that this will never happen just normally accidentally and you basically have to actually purposefully do very weird things in order to trigger this then i'm very happy with just not providing any explicit recovery methods for these cases okay the the the most likely scenario

uh we we felt could happen is like a tooling issue from uh from the outs off chain signs or like from the wallets and uh and apps right but i mean even there right like a because you have this this clear typing you basically you'd have to send a compressed address to an explicit long address type or you'd have to send a long address to an explicit short address type which with this strict typing to me i mean i don't know i'm not an expert in tooling but this seems like tooling should generally just not do that on accident

okay so yeah so i don't think it's typing related as much as opposed to who how do you obtain these addresses in the first place on a wallet and the wallet um should be able to obtain the compressed address without ever i mean at least since the the method how we calculate the compressed address is public obviously a wallet can decide they just manually calculate it um and they don't interact with the chain for that and if they they end up manually calculating these addresses of chain then then they may as well just send it

um as call data um maybe this again is just a question of um education and and maybe if um i mean that's why we brought up this point that the translation map should be accessible through rpc to wallets um and maybe in that case you know we should really educate wallets that they shouldn't try to manually calculate any of these rather they should always check if a translation exists in the map and if it doesn't exist um they would need to do a transaction which inserts it and use the resulting compressed address so maybe it's it's an educational question but this is um i guess the the the concern we had

am i correct so if you have a compressed address um and you're given and you're shown that this long address converts into this compressed address you can be cryptographically confident that that compressed address actually refers to that long address um in general the one exception to that is that it is possible that the ei that the um birthday attack problem applies and that there are in fact two long addresses both of which have been created by the same person

and that person has spent a very large amount of money to do so that have the same compressed address and so in most cases if it you know be if you're given a compressed address and a long address that like hashes to that compressed address you can counter factually treat that compressed address as if it refers to that long address and be confident if you want to be super duper confident you need to send you need to go and do the lookup on the blockchain and find out whether someone has inserted that compressed address that long address into the translation table at which point you could be confident

that that compressed address for all time refers to that long address maybe to clarify i think in this discussion my concern wasn't coming from the collision issue rather that um since you you can be you can calculate your compressed address on the wallet and if all that does that they may just interact with a a legacy contract and send that compressed address in the call data without ever having populated the translation map and if this happens then um that legacy contract will i guess in the utter case we'll we'll

just create a new account um and that's what we discussed yesterday for the token case i suppose it's not a problem because once you you populate it then it should it should work right although by the way yeah i also have a i can i think i can come up with a with the scenario in which the token is also problematic so say i um want to do a swap from a legacy token to a new token using i don't know uni swap or something and i start with the um basically i want to like the ultimate recipient should be a long address but it's not yet basically it's never interacted with legacy world so it's not in the translation table

and so i offchain just calculate its compressed representation and then i go to legacy uni swap basically and initiate the swap there with the with the compressed address and then unisport kind of i don't know deducts whatever to all token balance all that works but then uni swap now wants to send to that uh compressed address and so it kind of calls the legacy interface of the new token and it gives it the compressed address and then the legacy interface of the new token recognizes that this is a short address and so it has to convert it it goes to the translation table however the translation table does not know the compressed address and so at least if we don't have like a compressed address prefix which we just discussed earlier the three bytes so if it's not clear if this is a compressed address or just a short

address the translation table would say i don't know this so the kind of uncompressed representation would still be the compressed form and so then in a new token contract this would still be accounted for as basically belonging to this compressor address and then it's stuck because then we can't ever get this out so there are scenarios in which if it's if you if you just rely on it being in the translation table and it's not yet in the translation table it can also not only can either be stuck forever but also tokens can also be stopped by rightly so you and alex am i correct in my understanding that this would also be solved by just if if you could just if you would also just populate the

translation table from access lists every time and so it would just be wallets would just have as like a best practice and they would just have to include the long address in the translation table if they want to use the compressed form the call data and so in that case they would ensure basically that that it's in the translation table yeah well so if we i guess that access list is like it's like a separate question but um even before we got to the access list part we were considering that um [Music] i mean basically the cheapest you can do

is just to like an x balance or something like that um um or well the cheapest is just to do like a collar so there could be a very simple contract on the legacy space all of um all of what it does it just executes one instruction the the color instruction and you just call it from the legacy space and this would populate the in-state um translation table and basically what wallets would do is they would just create a transaction to this this contract and therefore populating the translation table but one could also think about like having an actual interface

for the translation table and just sending a transaction there and of course if you go the way with access list that that makes this nicer right yeah that makes a lot of sense but i mean you're you're correct though that like okay i understand i was kind of convinced that to enough comments i thought that maybe tooling would basically have to really be voluntarily choosing to do something incorrect but you're right that like just forgetting to do this is something that seems realistic that it could happen that ideally what you should do is you should make sure the thing is in the translation table but because most of the time it works even if you don't do it

because most of the time it's already in the translation table anyway some tooling some wallets might just forget to implement this step or just not not kind of consistently always do it or something and so we could indeed end up in with situations in situations where this misbehaves and the question is is there anything on the protocol side we can do to um well like for example with the sending east to an address i think we can prevent this by just having this prefix for compressed addresses and then if you ever actually send each to com to choose to an address that with its prefix is clearly a compressed address um but but it's not found in the organization table then the transfer

could just fail um right so you know we were talking about um about like recovery processes i think i've i think i've thought of the like right primitive is it possible to solve all of this um with a combination of firstly fur like if like do some sort of merge count stuff and um for recovery of tokens to provide um a call the ability for accounts to in impersonate their compressed address so for example let's say that i had one

of these erc20 tokens um my erc20 token had got stuck my had got stuck um under my compressed address that are in a a new long account um erc20 token but stored as the legacy form at the legacy version of my compressed address in order to get out of that situation all i would have to do is call the new erc20 token um and send a transaction to it to transfer it from my legacy address compressed address to my long address and when i did that i would have to set a flag of the

transaction that says rather than setting message.sender to my long address set message.sender to my compressed legacy address all right i think we kind of briefly touched on that as well yesterday i think the main problem with this is that this only works for externally owned accounts so if you have something like hypnosis safe that that you use to then interact with with other depths or whatever and then the compressed address of this you can also save is the one that kind of incorrectly received funds or tokens or whatever and then you can't like it seems very dangerous to allow you from the outside

to just basically arbitrarily set this flag for any intermediary smart contract that the transaction touches because they can just break other interactions you could just kind of like set that flag maliciously for contracts you don't control kind of in a sense and so this solution seems to only work for eoas and so our question basically is is it worth adding this extra functionality that only they can only kind of recover from these areas in the very specific ua case is that to set up a summary yeah yeah i think that's a fair story i kind of came around based on what was

mentioned earlier today that um i mean that was one of the the main issues with this translation map logic in the spec is that we have no ability just to distinguish a compressed address from a short address um but hypothetically what if we do have that ability and this is what like this prefix discussion is somewhat about hypothetically what if we do have the ability to distinguish a compressed address from a short address if we do have that does that mean that everything is solved because in that case translation maps map would just say

we just return an error or something it to me it seems indeed like this would solve so it seems like it would solve the immediate ether case because the ether transfer would just fail if it understands that it should resolve the compressed address but it can't but it seems like it would also catch cases where at least like you're entering a new token via the legacy compatibility interface and it understands that it should ideally resolve this address but it's unable to because it calls the public kind of function from the transition map and the translation map understands that it should be able to translate the thing but it can't because it's not in the translation map and this could also just

return an error and so these new token contracts could also just throw in in this case as well so i feel like the only case in which this would continue to be problematic indeed is if you directly send in a well i guess even like new token contracts could even have could even um do the same check even within the normal transfer function so i feel like yeah to me it seems really seems like this should make it possible to write completely safe code on the new side and the old like the legacy side should never have any issues to begin with because it deals with short addresses anyway and so it never incorrectly has a compressed

address because it like yeah because compressed addresses are like in legacy space are always like there by by design so so it feels like the new space can has now has a tooling for catching these mistakes and the old space basically never will have mistakenly like have to deal with compressed addresses in the first place so to me first impression this this indeed solves the problem but i could have overlooked something i don't know what would other people think micah has a comment about contract callers like knossos wallet

but i don't fully know yeah micah is your is your mic just not really working due to the internet speed or if you type it out i can also read it up unless that was in reference to peter's proposal but i like looking at the timestamp it looks like that was actually addressed like in reference to my comment so just to point out though by the way the the prefix solution has of course the one extra drawback right that it instead of making the collision resistance or the issues for collision resistance a theoretical

problem with 20 bytes now we actually only down to 17 bytes and i'm not an expert there but to me it feels like that moves it from a theoretical concern to to like a somewhat practical concern and yeah and i think i mean i don't want to bring this into this call because we discuss it tomorrow but i would combine it with kind of like the ephemeral map because at least then you don't have the collision issue for all the in-state stuff rather you have to provide these on a per transaction basis but maybe that's that doesn't make any difference right although in a sense that's you

could also argue the other way around right like where at least if it's in state you detect collisions and you can at least kind of like just not allow a second entry with the same compressed address and that throws wait so you only have problems with counterfactual situations whereas if it's ephemeral then you basically are unable to detect this that this is kind of like a an attack in a sense and unable to kind of yeah so basically in a sense i think the ephemeral could also weakness but you complete right we should discuss this tomorrow so then like it seems like the summary

here um so so let me let me get this right so basically i think we we seem to be at the in a position to say that we're using the prefix and and also the extra logic to prevent normal addresses to ever have this prefix in the future um we would be able to distinguish between compressed addresses and normal chart addresses and that would mean that at least looks like all of the mistakes around kind of around sending things to the compressed address could be

prevented if we don't do this we think that if everything if all tooling and all contracts behave ideally this should still never happen so this is kind of like we everything could be designed as to never cause this mistake but it is easy for tooling to make mistakes um because it's like on chain you can't kind of you can't catch those mistakes on chain so you basically have to rely on tooling to never make the mistake in the first place and so if it's at all kind of realistic and feasible to go down this prefix route it seems like the

safer choice um for compressed addresses my internet is not working so i probably will chop up i try to talk okay yeah but is it in general like a fair summary would people say yeah yeah i suppose as next steps um uh it seems that we we have um we have two different work streams um one potential stream is assuming that we solve uh this i guess this uh distinguishing congress address is from

from legacy addresses and uh with that assumption i guess just work um just working out the entire specification and see if any of these i guess test cases which were listed or any of these cases we have encountered would there be an issue in that case and it seems like that that this option would be simple enough um at least solve these problems but then a sub work stream of this is actually figuring out what would be a good way to to create create compressed addresses in such a way whether it's a prefix

then how big is the prefix etc um and that's definitely some kind of a work appropriate for a cryptographer um and then the sec second quite big separate work stream is assuming that this prefix stuff or distinguishing option is not working um and in that case we do have um these three questions we we started off with today is what to do uh with like mistakes with compressed addresses um and i'm kind of leaning towards that maybe the the more rational the next step is choosing this first

work stream um and being optimistic about it and and because the the number of steps seems to be smaller in that case um and maybe this is the the option maybe team epsilon would like to um explore in the next few weeks but yeah i wonder um how do you guys feel about this it's just like a realistic path to at least explore and is anybody else interested in this or the other path so to me i think i i think that that

kind of distinction makes sense i am also like i would also i also think it makes sense to prioritize the optimistic case of um this this that we are able to to to distinguish the compressed and the short addresses um i think given that like we support him also at least thinking of of being involved and in kind of working on an space extension a bit i think we'd also kind of like want to kind of follow uh with with this optimistic uh stream and i think there might be like there's further branching off points tomorrow like if we could if we follow through with our plan of kind of talking

about the ephemeral list and the excess like ephemeral transition table in the access list tomorrow because i think at least that we might be more interested in like maybe exploring alternatives around like an expiring translation app or something there so basically not branch off here kind of follow your you you with with the on the optimistic side and then potentially maybe branch off for the last topic tomorrow is what my feelings if that makes sense and also it seems like at least that even in the unhappy case that we are not

able to distinguish compressed and non-compressed addresses basically the just do nothing and if mistakes happen too bad approach which would just be the default would kind of would still like be a possible path in there that i feel like even if we end up having to default back to this we we kind of like we don't lose work right because it's still it would still work it would just then basically we might have missed better ways of catching mistakes but then we can we can always still work on that so i feel like even if we have to default back to that case we like all we've been doing on top of the happy case will still be valid it might just not be the quite the optimal thing to do so i feel like yeah

i i think it makes sense to kind of focus on on the heavy case for now i guess we wanted to limit today's call to 30 minutes and we're already like 14 over um yeah i wonder micah if you would be able to write down maybe your concerns about this case especially like this gnosis wallet on maybe the address space extension channel and yeah maybe take it from there tomorrow but it would be nice to really just dedicate tomorrow to the actual translation map itself

and what you want to explore is like an expiring option or an ephemeral option or just like the fully in-state version that seems to be like well contained topic for tomorrow sounds good to me and i think micah actually it could be that he's just like very very delayed that this his comment was actually was was referencing peter's um like ua specific solution after all because also like when you unmute it it sounded like commented on not something that was said a minute earlier so it might be there well but i guess we can see offline

about this so then um sounds like everyone is still on board for the plan of having one last session tomorrow in this at least in the series and then maybe um afterwards probably um yeah maybe pick up later but but not not quite in this in this frequent frequency so would we then just do tomorrow the what used to be the usual time so like the um one hour earlier than today um i think that that's the normal slot right one hour later than today and scheduled for one hour he said would that work for everyone yep sounds good to me

works for me then let's just go for this no need to have 10 minutes of planning at the end of every call so uh if if there's nothing left for today um thanks everyone for coming thanks alex again for believing this and see you all tomorrow i'll send invites out after this call thank you see you tomorrow