Solana loves squeezing every bit of scalability it can from every possible avenue. In that spirit, messages to solana validators can not exceed 1280 bytes in size to ensure speed and reliability.
Furthermore, a solana transaction must specify up front what on-chain state it’ll read from or write to. Essentially, you list all the accounts your transaction will “touch”.
This is bad news if you want a single, atomic transaction with a bazillion account inputs, all the while remaining under 1280 bytes. In fact, it’s impossible.
Enter “Address Lookup Table (LUT) Program”. Using this program, you create an on-chain lookup table stuffed with all the accounts you want your atomic transaction to use.
Now, the transaction, instead of enumerating all accounts, can use 1-byte indices into the on-chain lookup table. Pretty nifty, if you ask me.
In our case, though, we were slightly early to the party. The core LUT program was up, but the developer-facing SDK was missing. With no documentation whatsoever, using the program was gut-wrenching.
The solution was a simple 3-step approach.
@solana/web3.js.In 2022, Solana was famous for being a black box and it seemed like the LUT program was being worked on “silently”. You couldn’t find much online except for a somewhat vague but technical proposal.
It was so bad that we weren’t even sure if LUTs would solve our original problem. Probably because nothing online explained, in simple terms, what the program was for.
Fortunately, Solana is open-source. When all else fails, you can chug a couple of red bulls and start digging into code, which is easier said than done for a team who had only been working with Solana for two months.
After our in-depth perusal of the codebase, the situation turned out to be: