Add address map program

[jstarry]

Problem

Users and protocols need a way to store addresses on-chain for transaction v2 address lookups.

Summary of Changes

Added address map program

• Number of entries is capped at u8::MAX since transaction v2 account indices are typed as u8
• Activation is instant but deactivation of on-chain map accounts has a cool down period to ensure that address maps can't be re-initialized at the same address.
• Support closing address map accounts but use derived addresses based on the current epoch to prevent address maps from being re-initialized at the same address.

Fixes #

[codecov]

Codecov Report

Merging #19473 (8f4312d) into master (8c5401e) will increase coverage by 12.1%.
The diff coverage is 28.5%.

❗ Current head 8f4312d differs from pull request most recent head d1f6225. Consider uploading reports for the commit d1f6225 to get more accurate results

@@             Coverage Diff             @@
##           master   #19473       +/-   ##
===========================================
+ Coverage    70.2%    82.3%    +12.1%     
===========================================
  Files          35      475      +440     
  Lines        2066   132434   +130368     
  Branches      295        0      -295     
===========================================
+ Hits         1451   109119   +107668     
- Misses        515    23315    +22800     
+ Partials      100        0      -100     

[jackcmay]

Should these be exposed via the sdk?

[jstarry]

Should these be exposed via the sdk?

Yeah, definitely. I think I can use cargo features to have the sdk directly depend on the address map program crate without bringing in the program runtime.

[joncinque]

Looks really good! Most of my questions are nits and ideas about the interface, but I did look at the implementation as well, which looks safe

[joncinque]

I'm worried that this will make discoverability of address maps difficult. One of the great features of the associated token account is that you can immediately find someone's token account with just their wallet and the mint. Here, you may have to iterate through a bunch of epochs in order to find their address map, or you'll just use find_program_address and do it the "easy" way.

What if, instead of an epoch, this is another Pubkey? That way, you can setup a different address map for each program that you interact with. Since you've cleverly put this on a PDA dependent on the signer, there's no way for one of these to get hijacked after CloseAccount.

[jstarry]

I agree that it's not ideal and I did consider this point when reimplementing the program here: #21616. However, I think indexing or creating a known registry of on-chain lookup tables is going to have to be the way forward here. I think it's more likely that bots and protocols will manage their own lookup table accounts and users will never have to manage them.

[joncinque]

Similar to an associated token account, should we discourage people from reassigning authority? Immutability makes sense, since you may want to setup an address map for your program as a one-time procedure, and have it hard-coded into the program.

What are the use-cases for reassigning authority? I'm thinking that a user may create an address map for a program, then give the authority over to one of the program addresses which performs the setup and adjusts it as needed after updates.

[joncinque]

take it or leave it: Since we've had potential hijackings in the past, we may want to have a signature from the authority as well. This way, bad integrations that just look for any account map for an authority can't get duped.

For example, if it's a defi application, the attacker sets up trap address map accounts for a bunch of addresses, using their own token accounts as the receivers, and just hopes that a bad integration uses the trap address map.

[jstarry]

Great call, I modified the create instruction here (#21616) to use the authority in the PDA and enforce that it's a signer. It's also no longer possible to set the authority address to another address.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jstarry]

Addressed all relevant comments and closing this implementation in favor of a more dev-friendly version here: #21616