feat(solana-receiver-js-sdk): verify & post TWAPs

[tejasbadadare]

Purpose

Add postTwapUpdates and associated functions to the Solana Receiver JS SDK, which enables users to verify and post TWAP updates from Hermes to the Pyth Receiver contract on Solana. This allows the TWAPs to be consumed on-chain.

Implementation details

• This SDK uses the same instruction layout as in the rust CLI, which is implemented in buildPostEncodedVaasForTwapInstructions.

• Compared with the standard layout from postPriceUpdates (calling buildPostEncodedVaaInstructions twice for the the start & end VAAs), the new layout uses 1 less transaction and has more efficient packing.

  • The layout is as follows:
    • Tx 1. Create, init and write initial data for start VAA
      • 1143 bytes (92.78% of max 1232 bytes)
    • Tx 2. Create, init and write initial data for end VAA
      • 1143 bytes (92.78% of max 1232 bytes)
    • Tx 3. Write remaining data for both VAAs and verify both VAAs
      • 730 bytes (59.25% of max 1232 bytes)
    • Tx 4+: Post updates to receiver contract. One tx per price feed.
      • each tx is 1103 bytes (89.53% of max 1232 bytes)
    • Any additional price consumer ixs
    • Optional close ephemeral accounts ixs

• The IDL file that describes the receiver contract interface was manually updated to reflect the new postTwapUpdate function. We couldn't auto generate the new IDL because the account data models were moved from the receiver contract to the rust SDK at some point after the initial IDL was created. The new IDL wouldn't contain the necessary accounts.

  • The most straightforward way to solve this would be to upgrade to anchor-lang 0.30.0, which introduced a new "build IDL via compilation" strategy, which allows them to pull in types from external crates (like our SDK) into the IDL. However, we are on anchor 0.28.0, and 0.30.0 introduces several breaking changes. Critically, the wormhole SDKs have a hard dependency on 0.28.0. We could fork it and upgrade it to 0.30.0 ourselves to unblock our own upgrade path, but that would be a time consuming process.
  • I didn't think that was worth delaying this PR over, so I went with the path of least resistance of manually patching the IDL.

• Misc: update README, tune CLI ix compute budgets, add example. Example relies on HermesClient update, coming soon.

Testing

Manually tested, no test suite for the JS SDK.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
api-reference	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 19, 2024 7:25pm
proposals	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 19, 2024 7:25pm
staking	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 19, 2024 7:25pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
component-library	⬜️ Ignored (Inspect)	Visit Preview		Dec 19, 2024 7:25pm
insights	⬜️ Ignored (Inspect)	Visit Preview		Dec 19, 2024 7:25pm

[guibescos]

maybe initInstructions and writeFirstPartInstructions could be in the same group

[tejasbadadare]

hm yeah they can be consolidated. but i think for newcomers to the code, seeing them split out as (init, writeFirstPart, writeSecondPart) is a little conceptually clearer imo

[guibescos]

tyvm