Closed kunstmusik closed 2 months ago
Thanks @kunstmusik
You're correct that Ethereum addresses are not case-sensitive, in terms of their functionality. Having said that, there is a convention known as "EIP-55 mixed-case checksum" that uses case sensitivity to add an additional layer of verification against typos.
Using the checksum address format helps in detecting typographical errors. If an address does not follow the correct checksum format, it indicates a likely typo. Wallets and other Ethereum tools often display addresses in checksum format to provide this additional verification layer. In other words, this mixed-case is a common and well adopted convention in the Ethereum ecosystem.
This is what the ref impl of the ao Compute Unit implements. You can see the entire implementation for converting the base64url encoded public key to an Ethereum address here.
@TillaTheHun0 Thanks for clarifying that. So is it safe to say for guidance in working with ETH addresses:
If so, I think it would be nice to have this documented somewhere (if not already) and for blueprints to be updated accordingly.
@kunstmusik
I hope that makes sense. We will try to get this documented somewhere in the ao Cookbook (PRs welcome 😃), and perhaps as well as the spec. Thank you for bringing it to the team's attention!
https://github.com/permaweb/ao/pull/941 the pr add EIP-55 verify on token standard
Documented this behavior in ao Cookbook here
@kunstmusik is this issue good to be closed out?
@TillaTheHun0 Yes I think so. If anything else comes up I'll raise a new issue. Thanks!
Related to https://github.com/permaweb/ao/issues/862 and https://github.com/permaweb/ao/pull/863, I was working with ETH addresses and found there are issues stemming from case insensitivity for ETH addresses and wanted to get clarity on address format.
What I found in testing with ETH signed messages is that the msg.From could have mixed-case values, e.g.,
While Arweave addresses are case-sensitive, EVM addresses are not, as they are string representations of the 20-byte
address
. In EVM ecosystems, given address strings that differ only in case, they will resolve to the same address.However, in AO, common practice thus far has been to use values such as msg.From or msg.Recipient directly. (e.g., https://cookbook_ao.g8way.io/guides/aos/blueprints/token.html). While msg.From is derived from msg.Owner for ETH addresses, things like msg.Recipient may be entered in by users. If the case differs, token transfers may end up being recorded in multiple entries in the Balance table.
Additionally, when sending messages like Credit notices, I do not currently know what would happen if a message sent to
0xFCAd0B19bB29D4674531d6f115237E16AfCE377G
and one sent to0xfcad0b19bb29d4674531d6f115237e16afce377g
would be routed to the same address. I would like to see the behavior here defined.Ultimately, I think how ETH addresses are represented in AO messages should be clarified and a standard case used. I do think due to adhoc user input that AO devs will have to do some manual handling of ETH addresses in their process code, but at a protocol level I think it needs to be clarified for message parameters and targets.
(I think if further signature types are added (e.g., SOL), case sensitivity should be considered.)