feat(pyth-lazer-publisher-sdk): Add SDK for Publisher Transactions - #2557
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
5 Skipped Deployments
|
darunrs
changed the title
cprussin
left a comment
cprussin
left a comment
There was a problem hiding this comment.
Nice! Overall js packaging stuff looks great, just a few minor points to improve but overall lgtm
| ``` | ||
| cd to crosschain root | ||
| $ pnpm install | ||
| $ pnpm turbo --filter @pythnetwork/pyth-lazer-publisher-sdk build |
There was a problem hiding this comment.
Usually build in and of itself isn't a goal -- usually you're building to do something else. My general advice is to document the actual things you might want to do in the docs (e.g. "run tests" or "run this example" etc) and let the build happen automatically with the task orchestrator
There was a problem hiding this comment.
Yeah that makes sense. I will add in a followup PR an example showing how to use the SDK to create some of the types, sign them, and then encode them.
| @@ -0,0 +1 @@ | |||
| export * from "./generated/proto.js"; | |||
There was a problem hiding this comment.
I generally recommend against barrel exports. Instead, just point the main export at generated/proto.js directly.
There was a problem hiding this comment.
By this, do you mean changing main and types in package.json to point to the proto.js instead of index.ts?
| message SignedLazerTransaction { | ||
| // Type and signature should match | ||
| optional TransactionSignatureType signature_type = 1; | ||
|
|
||
| // Signature derived by signing payload with private key | ||
| optional bytes signature = 2; | ||
|
|
||
| // a LazerTransaction message which is already encoded with protobuf as bytes | ||
| // The encoded bytes are what should be signed | ||
| optional bytes payload = 3; | ||
| } |
There was a problem hiding this comment.
After yesterday's discussion I realized that this structure is not very well suited for governance mesages that are based on wormhole. Maybe we need something like this?
// replaces old SignedLazerTransaction and LazerTransaction
message LazerTransaction {
oneof message {
PublisherUpdateTransaction publisher_update = 1;
GovernanceTransaction governance = 2;
}
}
message PublisherUpdateTransaction {
optional bytes signature = 1;
// protobuf-encoded PublisherUpdate
optional bytes payload = 2;
}
message GovernanceTransaction {
// encoded in wormhole format, with guardian signatures inside
optional bytes payload = 1;
}
There was a problem hiding this comment.
I like to have a fixed transaction layout and then have customisability in the payload layer. I see transaction as something for sequencer and content of it as something for the aggregator. It's good to have permissioning over who does what. And then, you can say that the sequencer only streams txs from verified pubkeys. Otherwise, you'd need to either think of continuing the tokenized gateway (which is kind of like sigs) or verifying wh messages (which is very expensive)
8 participants
Summary
Created new publisher_sdk which will store all sdk related code for publishers. Publishers is now more of a gneral term for anyone who publishes transactions to Lazer. Right now that's only Feed Publishers but in the future, there will be Governance, and maybe others too. The new publisher_sdk has proto files for which types are generated. Pyth Lazer will use these for encoding/decoding incoming transactions to the system in the future.
Rationale
Lazer needs to support more types of input and be capable of changing its input schema as updates happen. Using a new format for input provides this flexibility. Using protobuf for message passing provides additional flexibility for updating schemas and also improves the message compression size.
How has this been tested?
Was able to generate types successfully.