2

Exceeding computational limitations (due to non ALT accounts invoking).

When creating a transaction mainly versioned one, we can have ALTs which is nothing but a way to use read only accounts

in CPI accounts take 32 bytes we on runtime can make it 1 byte and load it from ALTs

We will not store the ALTs in program, but what happens is it expands in the transaction and we are able to use that account as 1 byte storage, 1 ALT can store 254 addresses that I have seen to it's handy to use them to reduce the transactions size.

Any recommendations /doc on how to Invoke ALTs from a CPI stand point, front end wise/script is ok. Mostly from a program communication stand point.

It allows us to expand the account usage within our computation.

1 Answer 1

0

Apending a new address to ALT itself sizes 32 bytes per address:

https://solana.com/docs/advanced/lookup-tables#compressing-onchain-addresses

It does not help you increasing transaction size dynamically by adding new addresses to ALT. You should create ALT and extend (add new addresses) it before you execute the versioned transaciton with the ALT pre-initiated.

There is a CLI to create / extend your ALT:

solana address-lookup-table create -k authority.json -u RPC_URL

solana address-lookup-table extend ALT_ADDRESS -u RPC_URL --addresses ADDRESS_1,ADDRESS_2,ADDRESS_3,...ADDRESS_N

Plesae note that extending ALT also has transaction size limit to 1232 bytes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.