pyth_solana_receiver_sdk: up anchor and borsh dependencies#3798
pyth_solana_receiver_sdk: up anchor and borsh dependencies#3798IliaZyrin wants to merge 1 commit into
Conversation
- remove unused pythnet legacy SDK - remove unused pythnet solana-program dependency
|
@IliaZyrin is attempting to deploy a commit to the Pyth Network Team on Vercel. A member of the Team first needs to authorize it. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| impl Hasher for Keccak160 { | ||
| type Hash = [u8; 20]; | ||
|
|
||
| #[cfg(feature = "solana-program")] | ||
| fn hashv(data: &[impl AsRef<[u8]>]) -> Self::Hash { | ||
| let bytes = hashv(&data.iter().map(|x| x.as_ref()).collect::<Vec<&[u8]>>()); | ||
| let mut hash = [0u8; 20]; | ||
| hash.copy_from_slice(&bytes.as_ref()[0..20]); | ||
| hash | ||
| } | ||
|
|
||
| #[cfg(not(feature = "solana-program"))] | ||
| fn hashv(data: &[impl AsRef<[u8]>]) -> [u8; 20] { | ||
| let mut hasher = Keccak256::new(); | ||
| data.iter().for_each(|d| hasher.update(d)); |
There was a problem hiding this comment.
🔴 Removal of on-chain keccak syscall causes significant compute unit regression
The solana-program feature-gated implementation of Keccak160::hashv that used solana_program::keccak::hashv (a cheap syscall at ~100 CU) was removed. Now all on-chain merkle proof verifications use the sha3 crate's software implementation, which costs thousands of CU per hash. Since pyth-solana-receiver uses pythnet-sdk with features = ["solana-program"] and calls root.check() in verify_merkle_proof (target_chains/solana/programs/pyth-solana-receiver/src/lib.rs), each price update verification requires ~10-20 hash operations. The CU increase from ~2k total (syscall) to ~50k-200k (software) could push transactions over compute budget limits for existing integrations.
(Refers to lines 1-18)
Prompt for agents
The file keccak256_160.rs previously had a feature-gated implementation that used solana_program::keccak::hashv when the solana-program feature was enabled. This syscall is significantly cheaper on-chain (~100 CU vs thousands of CU for software keccak). Since anchor-lang 1.0.2 re-exports solana_program, the syscall is still accessible via anchor_lang::solana_program::keccak::hashv. The fix should restore the conditional compilation: when the solana-program feature is enabled, use the syscall for on-chain efficiency; otherwise fall back to the sha3 crate implementation. The cfg attributes should check for the solana-program feature and import from anchor_lang::solana_program::keccak::hashv.
Was this helpful? React with 👍 or 👎 to provide feedback.
| pub mod accumulators; | ||
| pub mod error; | ||
| pub mod hashers; | ||
| pub mod legacy; | ||
| pub mod messages; | ||
| pub mod wire; | ||
| pub mod wormhole; |
There was a problem hiding this comment.
🔴 Deletion of legacy module breaks cosmwasm and near packages that depend on it via path
The pub mod legacy was removed from pythnet_sdk, but multiple packages in the monorepo still use it via path dependencies (path = "../../../../pythnet/pythnet_sdk"): target_chains/cosmwasm/contracts/pyth/src/contract.rs imports pythnet_sdk::legacy::{BatchPriceAttestation, PriceAttestation, PriceStatus}, target_chains/cosmwasm/contracts/pyth/src/governance.rs imports pythnet_sdk::legacy::ErrBox, and target_chains/near/receiver/src/lib.rs imports pythnet_sdk::legacy::{BatchPriceAttestation, P2W_MAGIC}. These packages are in separate workspaces with their own CI and the breakage may not be caught by this PR's checks. This violates the REVIEW.md cross-service impact rule.
(Refers to lines 1-7)
Prompt for agents
The legacy module (pythnet/pythnet_sdk/src/legacy/) was deleted but is still used by target_chains/cosmwasm/contracts/pyth/ and target_chains/near/receiver/ via path dependencies. Either: (1) keep the legacy module in pythnet-sdk behind a feature flag so existing consumers can opt in, (2) update the cosmwasm and near packages to remove their dependency on the legacy module, or (3) move the legacy types to a separate crate that those packages can depend on. The affected files are: target_chains/cosmwasm/contracts/pyth/src/governance.rs (uses ErrBox), target_chains/cosmwasm/contracts/pyth/src/contract.rs (uses BatchPriceAttestation, PriceAttestation, PriceStatus), target_chains/near/receiver/src/lib.rs (uses BatchPriceAttestation, P2W_MAGIC), target_chains/near/receiver/src/state.rs (uses PriceAttestation).
Was this helpful? React with 👍 or 👎 to provide feedback.
| idl-build = ["anchor-lang/idl-build", "pythnet-sdk/idl-build"] | ||
| pro-compatible = [] | ||
|
|
||
| [dependencies] |
There was a problem hiding this comment.
🚩 Anchor-lang version mismatch between SDK (1.0.2) and on-chain program (0.32.1)
The SDK now uses anchor-lang = "1.0.2" while the on-chain program pyth-solana-receiver still uses anchor-lang = "0.32.1" (via workspace). These are treated as separate crates by Cargo. Types like PriceUpdateV2 defined with anchor-lang 1.0.2's #[account] attribute implement AccountSerialize/AccountDeserialize/Owner traits from 1.0.2, not 0.32.1. The on-chain program's Account<'info, PriceUpdateV2> requires these traits from 0.32.1. This is a type incompatibility that should cause a compilation error for target_chains/solana/programs/pyth-solana-receiver. The workspace Cargo.toml at target_chains/solana/Cargo.toml:30 still has anchor-lang = "0.32.1". The on-chain program likely needs to be upgraded to anchor 1.0.2 as well for this PR to work.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
Rationale
To make the receiver SDK buildable with modern Solana & Anchor.
How has this been tested?
To verify the changes I just confirmed buildability of my own crates depending on this.