pyth-sdk-solana: Add constraints between SDK and oracle program types.#104
pyth-sdk-solana: Add constraints between SDK and oracle program types.#104
Conversation
| [dev-dependencies] | ||
| solana-client = ">= 1.9, < 1.15" | ||
| solana-sdk = ">= 1.9, < 1.15" | ||
| pyth-oracle = { path = "../../pyth-client/program/rust", features = ["library"] } |
There was a problem hiding this comment.
Relative path just for now because it relies on the upstream PR being merged first.
| //! | ||
| //! The definitions here should be in sync with the definitinos provided within the pyth-oracle | ||
| //! Solana contract. To enforce this the tests at the bottom of this file attempt to compare the | ||
| //! definitions here with the definitions in the contract. |
There was a problem hiding this comment.
why bother having the definitions here if you want them to be equivalent to the ones in pyth-oracle? seems like redundant code and we should just import from pyth-oracle.
There was a problem hiding this comment.
I'll fix the comment as I think that wasn't clear, they aren't identical, just isomorphic and it is difficult to tell that's the case which is exactly why I wanted to add this. Even if they were identical, having the API exposed by an SDK library and not the contract I would say is a good thing. If anything I would argue that this library should expose the types and pyth-oracle should depend on them but that's a large shift.
In other words the byte layout is the same, but the API exposed isn't the same. I didn't like that it wasn't easy to tell at a glance if those conversions were in sync. This is just adding some conversions that will error out/fail to type check if pyth-oracle were to change and this library does not.
|
|
||
| // We then compare the type sizes to get some guarantee that the layout is likely the same. | ||
| // Combined with the isomorphism above we should be able to catch layout changes that were | ||
| // not propogated from the pyth-client program. |
There was a problem hiding this comment.
Thanks, will fix, along with definitinos in the above comment as well after I clarify it a bit better.
|
Instead of duplicating struct definitions, would it be feasible to expose pyth-oracle types as a dedicated crate/module in the future? This could allow the SDK to depend on the contract’s types directly while still exposing its own API. |
4 participants
The types defined here in theory should be byte-equivalent to those defined in the
pyth-oracleprogram. It is difficult to check this without comparing the two sources together. This PR adds the oracle contract as a dependency during testing and attempts to convert between the prices and compare byte sizes to add some confidence that these don't go out of sync. It's also possible then to have this library directly depend on a specific version of the oracle program so that we're forced to identify which version the types depend on for better release numbering.I did this because I have need for this library within pythnet and this was a pain point.