feat: merge CAIP69 into CAIP10 for specifying EOA wallets

[jainkrati]

The goal of this PR is to empower CAIP 10 to specify EOA across EVM Chains with chainID of 0.

We raised a PR for this earlier in CAIP repo https://github.com/ChainAgnostic/CAIPs/pull/268 and based on review comments/suggestions, we are raising this PR.

[jainkrati]

re-requesting review from @bumblefudge to confirm if changes look good and I did not miss any review comments.

[GregTheGreek]

I'm really not a fan of this, namely this adds a weird edge case that is non-specific to the naming convention of chain_id. I would much rather append a new variable to the string, where EOA == 0, Smart Account == 1, and reserve future numbers for any future account types that may arise, specifically if L2's adopt some sort of unique case.

I'd suggest the following:

chain_id:    namespace + ":" + network_id + ":" + account_type + ":" + reference
namespace:   [-a-z0-9]{3,8}
network_id:    [0-9]{1,19}
account_type: [0-9]{1,2}
reference:   0x[a-fA-F0-9]{1,32}

We can still maintain backward compatibility by doing a simple check:

if (chainIdString.match(/:/g) || []).length === 3) {
  // Contains account type
} else if (chainIdString.match(/:/g) || []).length == 2) {
  // Old chainIdString
} else {
  // error
}

We can then verify if this account is EOA or SCW by doing the following checks:

1. EOA: Have them sign a message, and try to perform ec_recover
2. SCW: Have them sign a EIP-1271 message
3. Counterfactual SCW: Have them sign a ERC-6492 message

[bumblefudge]

this adds a weird edge case that is non-specific to the naming convention of chain_id. I would much rather append a new variable to the string

by "append a new [segment] to the string" do you mean breaking CAIP-10? non-EVM devs might consider ethereum's evolving concept of an account the weird edge case, in that the EOA/SCA distinction is entirely specific to EVM wallet interfaces (I can't think of any other namespace that would use this new segment). What I'm getting at is that if we added a segment to all CAIP-10s, every non-EVM CAIP-10 would A.) break, and B.) have to insert, going forward, a :0 segment that expresses a distinction their addressing namespace doesn't make or need...

in defense of the original proposal, I don't think this edge case is so weird in the EVM tradition-- it continues the tradition of the wallet_ namespace for dapp<>wallet RPCs (as opposed to eth_ namespace for node RPCs), in the chainId namespace. By shoehorning the wallet_ context into the chainId system, they are encouraging people NOT to mix wallet_ methods and eth_ methods. This would also make "off-chain signatures" impossible to replay on any chain...

1. EOA: Have them sign a[n offchain] message, and try to perform ec_recover
2. SCW: Have them sign a EIP-1271 message
3. Counterfactual SCW: Have them sign a ERC-6492 message

The way I see it, 1/2/3 is already status quo, or to put it another way, what you describe as the verification step in the future where CAIP-10s mark accounts by type is today's clunky discovery step for lack of any such type discovery. Both the original proposal and your "additional segment" counterproposal both add a declarative standard notation for what, today, is guessed at or deduced at the last minute. My argument is that 2 and 3 ARE chain-specific and 1 is specifically chain-independent/offchain, and I feel like future types (the values other than 0 and 1 in your proposal) will all be either chain-specific or off-chain, so i'm not sure we need to hold space for future wallet-typing. If anything, typing of wallets is a legacy problem, and the "let's phase out EOAs forever" crowd would probably like us to sunset the special case of EOAs and move to an entirely abstracted future in which there is no need to type (or sniff) wallets...

[bumblefudge]

@GregTheGreek I hope that didn't come across as dismissive, just trying to read you in on the history of CAIP-10 design (and implementation) before this PR and explain why the odds are so stacked against a new segment. Does this new information address your qualms? Would merging this make you less likely to use or trust CAIP-10s in future multichain/cross-chain projects? Can you think of other alternatives that might be more palatable to CAIP-10's existing users and downstream projects?

@jainkrati @GriffGreen are you guys happy with the new version? feel free to roll back individual edits or push back, i'm just an editor here. Sorry to slow things down, I was just trying to factor in a few corner-cases I know of from other implementers.

I talked to Obstropolous out-of-band (well, at a public meeting of the CASA editorial WG) and I don't think his approval needs to be staled/rerequested, he workshopped my edits and is happy either way as long as nothing normative/major changes in further edits. he's pretty deep in implementation on the topic from Spruce days, after all.

[jainkrati]

Thanks @bumblefudge ! Really appreciate your help here for progressing this PR

[bumblefudge]

OK I'd say that's affirmative consent enough to merge, but DO feel free to tag each other and any other stakeholder you think would have useful feedback in follow-on PRs if you still have misgivings or if new counter-proposals or extensions come to mind over time, @GregTheGreek and @griffgreen !