Sui Lazer contract governance #3316
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Depends on #3317 |
ali-behjati
left a comment
ali-behjati
left a comment
There was a problem hiding this comment.
i reviewed only the sui contract. it seems correct but i think the structure can be improved. There are mutations happening in both state.move and governance.move [on process incoming message] which makes reading hard. if possible, my recommendation is to keep state minimal and move all the business logic affecting state in governance.move file itself.
| # supported, and testnet one is already outdated, so we either want to have the | ||
| # package at MVR at some point, or maybe want to consider creating our own | ||
| # branches with symlinked `Move.toml`. | ||
| rev = "sui/mainnet" |
There was a problem hiding this comment.
the story about this is that they were blocked on some issues with the move package manager handling multiple local packages to upgrade. they haven't fixed it yet
| /// Reference: | ||
| /// https://wormhole.com/docs/products/reference/chain-ids/#__tabbed_1_1 | ||
| /// https://github.com/pyth-network/pyth-crosschain/blob/b021cfe9b2716947f22d1724cd3fa7e3de6b026e/governance/xc_admin/packages/xc_admin_common/src/chains.ts#L274 | ||
| const RECEIVER_CHAIN_ID: u16 = 21; |
There was a problem hiding this comment.
Is it possible to make this a customizable parameter (initialized on package init)? we might deploy to multiple SUI-like networks.
There was a problem hiding this comment.
meta comment: couldn't we put it in governance.move?
There was a problem hiding this comment.
we might want to use it for parsing payload data as well.
it's not super clear to me what value we get out of this wrapper. but it's fine.
| assert!(self.chain_id == chain_id, EMismatchedEmitterChainID); | ||
| assert!(self.address == address, EMismatchedAddress); | ||
| // TODO: See https://wormhole.com/docs/protocol/infrastructure/vaas/#verified-action-approvals | ||
| // - is this enough to avoid replay attacks? |
| /// would give them their current address or version, we track it manually here. | ||
| /// | ||
| /// WARNING: Construction of `CurrentCap` requires this version to match the | ||
| /// `UpgradeCap` version, and thus attempts to publish or upgrade the package |
There was a problem hiding this comment.
how does the upgrade cap version change? does it increment by 1 each time?
🚧 in progress 🚧
Summary
Implements support for Pyth governance messages provided as Wormhole VAAs, and exposes actions for initialization, upgrading and trusted signer updates. Updates
xc_adminandcontract_managerto support new types of messages and maintenance actions.The PR adds a new "Lazer" module for governance actions related to Lazer contracts, as these don't map well to existing Core actions. From my understanding, existing Lazer contracts seem to use custom payload for governance, or do not consume governance messages at all, so they don't seem to be affected yet.
Rationale
How has this been tested?
I've updated and run
lazer/contracts/suitest suite and extended (and run)xc_admintest suite to cover new messages.