-
Notifications
You must be signed in to change notification settings - Fork 263
feat(pyth-lazer-publisher-sdk): Add SDK for Publisher Transactions #2557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
5 Skipped Deployments
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Overall js packaging stuff looks great, just a few minor points to improve but overall lgtm
lazer/publisher_sdk/js/README.md
Outdated
``` | ||
cd to crosschain root | ||
$ pnpm install | ||
$ pnpm turbo --filter @pythnetwork/pyth-lazer-publisher-sdk build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
lazer/publisher_sdk/js/src/index.ts
Outdated
@@ -0,0 +1 @@ | |||
export * from "./generated/proto.js"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally recommend against barrel exports. Instead, just point the main export at generated/proto.js
directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good!
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.