feat(SIP-57): allow for better observability into package upgrades#57
feat(SIP-57): allow for better observability into package upgrades#57admin-aftermath wants to merge 1 commit intosui-foundation:mainfrom
Conversation
|
yes. please. |
| ```Rust | ||
| public struct UpgradedPackageEvent has copy, drop { | ||
| /// The address of the original package (the first version that was published). | ||
| original: address, |
There was a problem hiding this comment.
maybe "genesis" or "initial" or something else will be a better name? "original" is a bit vague
There was a problem hiding this comment.
Original as in the package address that is created during sui client publish. previous + new would be dynamic off of what version of the contract is being upgraded, but original will always point to a package's initial address.
| ```Rust | ||
| public struct UpgradedPackageEvent has copy, drop { | ||
| /// The address of the original package (the first version that was published). | ||
| original: address, |
There was a problem hiding this comment.
same concern about "original" field name as above
|
Today's events are a good showcase of how this SIP can make an impact. A number of DeFi packages upgraded + versioned their contracts in response to a widespread vulnerability. As a result, the many aggregators that integrated with these products were temporarily disabled (some still are) until either they disabled integration with the newly versioned package or upgraded to the new package version. From our view, there was great communication about new package versions as they came out but, due to the nature of the vulnerability, the protocols needed to be versioned directly after they were upgraded. This meant that by the time the upgrade was communicated, it was already too late if the protocol was not already blacklisted. I assume the other DEX aggregators experienced the same level of communication but this shouldn't be a strict requirement for the proper maintenance of package versioning / upgrades. With this SIP we and other teams can build proper tools to notify of package upgrades to allow us to better prepare for or automate our responses. |
3 participants
No description provided.