Add a function to replace accounts in a transaction message using lookup tables

[mcintyre94]

This PR adds a new function useAddressLookupTablesForTransactionMessage to @solana/transaction-messages.

It takes as input a TransactionMessage and a mapping of lookup table address to its list of addresses. For each account that is not a signer of the input transaction message, and is not already a lookup, if it appears in one of the lookup tables then it is replaced by a lookup meta for that lookup table.

This means that a developer can build a transaction without worrying about lookup tables, and then call this with the lookup tables they want to use. This is similar to the legacy .compileToV0Message([lookupTable]) API.

This is not the same operation as is done when we compile a transaction message, this is simply replacing the accounts so that when the transaction message is compiled it will include the lookup tables.

Note: this is not as sophisticated as it could be, in terms of minimising the final transaction size. If you pass in multiple lookup tables, the output transaction message may use more of them than is optimal. Eg if we passed {lookup1: [abc], lookup2: [def], lookup3: [abc, def]} then it may use lookup1 and lookup2 instead of only using lookup3.

Also note that this doesn't guarantee that replaced accounts will use these lookup tables if the message is modified further. Eg if the message is modified such that an account becomes a signer after this is called, then compileTransactionMessage will change it back to a static account.

[changeset-bot]

🦋 Changeset detected

Latest commit: ea2f95d

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[steveluscher]

I like it! I'd like to change the name though.

Address lookup tables are an optimization that lets you compress a transaction over the wire. We should use one of those words.

• compressTransactionMessageUsingAddressLookupTables(message, luts)
• optimizeTransactionMessageUsingAddressLookupTables(message, luts)

I was initially going to say we should call it ‘optimize’ but ‘compress’ is alluring because of how specific and revelatory it is. An optimization could be anything, but what's really going on here is that you're replacing IAccountMeta with IAccountLookupMeta that result in smaller compiled messages.

If you pass in multiple lookup tables, the output transaction message may use more of them than is optimal

Ooh, interesting. We should maybe move this functionality into the compileTransactionMessage. There should be an algorithm in there that minimizes the number of lookup tables used.

[mcintyre94]

Thanks @steveluscher! I like compressTransactionMessageUsingAddressLookupTables too, will rename to that.

[lorisleiva]

Perfect! 👌

[steveluscher]

This isn't exactly true, I guess. This function probably actually widens every account from whatever it is, back out to IAccountMeta<TAddress> | IAccountLookupMeta<TAddress>.

What would be the implications of mapping over this puppy and making that so?

// Pseudo TypeScript...
): 
  | TTransactionMessage  // Unchanged, or
  | TTransactionMessage & TTransactionMessage.instructions.map(i => ({
    ...i,
    accounts: i.accounts.map(a => IAccountMeta<typeof a.address> | IAccountLookupMeta<typeof a.address>)
  }))
{

[lorisleiva]

Haha I thought about this but the content of AddressesByLookupTableAddress would need to be fully static for this to even work which will probably never be the case.

[mcintyre94]

Fair point! I did this just to keep ITransactionMessageWithFeePayer etc intact on the output message, but it isn't strictly accurate if you've got the accounts field typed more specifically.

[mcintyre94]

Not 100% on this type but I think this works? b643109

[github-actions]

🎉 This PR is included in version 1.95.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up.