-
Notifications
You must be signed in to change notification settings - Fork 39
chore(lazer) How Lazer works #879
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
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
We call relayers and routers in our pyth-lazer code, but sequencers and observers in our internal docs. Are we going to rename stuff in future? I went with what was written in the code for brevity. |
pages/lazer/how-lazer-works.mdx
Outdated
|
||
<Callout type="info"> | ||
The Douro Labs-operated relayer follows a strict, deterministic processing model: | ||
- **No price dropping**: All validated updates are forwarded to the message queue without dropping any prices. |
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.
It's not entirely true right now. We don't drop updates entirely, but relayer can mark any update as rejected. Its logic is not fully deterministic because we still have a circuit breaker. (We plan to remove it.)
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.
let's describe the policy that is implemented here -- "no price dropping outside of circuit breakers"
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 was trying not to mention circuit breakers at all as we are planning to remove it.
Sequencers and observers are the names used in early docs that predate the code I think. Let's stick with relayers and routers. |
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.
Overall looks good, i'd approve once you apply my comments.
- **Channel types**: Supports real-time and fixed-rate channels (1ms, 50ms, 200ms) | ||
- **Multi-chain support**: Generates on-chain payloads for Solana, EVM, and other chains | ||
|
||
#### Aggregation logic |
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.
this is where deterministic behaviour is important, all the aggregators produce the exact same aggregate solely relying on the consistent stream of price updates.
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.
here if you are not mentioning Douro running the service and think about the future that this part gets more decentralized, the publishers signature should be checked too (otherwise Douro can forge them). You can add that the aggregator validates the signatures of publisher update transactions.
p.s: we don't do it now, but will do in the future.
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.
So should we mention that right now?
Description
Type of Change
Areas Affected
Checklist
pre-commit run --all-files
to check for linting errorsRelated Issues
Closes #
Additional Notes
Contributor Information
Screenshots