The addition of the Delegated Migrator contract to add transparency and community voting on protocol upgrades.
\nThe introduction of the Delegated Migrator contract to perform upgrades on-chain in one or more steps. Migration scripts, once proposed and after a waiting period has elapsed, can be executed by the protocolDAO which will delegate ownership to the migration contract for the duration of the transaction. However, during the waiting period, the community can vote to reject any proposal.
\nSynthetix protocol upgrades are currently performed in a faily complex manner. Each release, the core contributors run through the publisher script which determines which new contracts need deploying and which owner actions are required to connect them together. The system is suspended by the protocolDAO, the owner actions are staged and executed by the protocolDAO, and then the system is resumed.
\nThere are a number of issues with this approach:
\nAs such, in an effort to fully decentralise the Synthetix protocol, this SIP proposes limiting the protocol upgrades to only those performed on-chain by a contract readable by anyone, and with a reasonable time delay for community participants to reject the proposal by on-chain vote.
\nIn principle the idea is as follows:
\nDelegatedMigrator, which is nominated and accepts ownership over all Synthetix contracts. It implements IDelegatedMigrator (interface below). The sole exception is the SystemSettings contract from SIP-64, it will remain owned by the protocolDAO to continue to perform SCCP updates without requiring the use of the Delegated Migrator .IDelegateMigrator contract is the protocolDAOIMigration (see below).execute may be invoked by the protocolDAO sequentially for each step in the migration.reject it will not proceed. The specific details of this voting process are TBD.interface IMigration {\n // Views\n function numOfScripts() external view returns (uint);\n\n // Mutative functions\n function migrate(IAddressResolver resolver, uint256 index) external;\n}\n\ninterface IDelegatedMigrator {\n // Views\n function waitingPeriodSecs() external view returns (uint);\n\n // Mutative functions\n function propose(string version, IMigration target) external; // onlyOwner\n\n function reject(string version, IMigration target) external; // onlyTokenVote\n\n function execute(string version, IMigration target, uint index) external; // onlyOwner\n\n function setTokenVote(address tokenVote) external; // onlySelf (i.e. only via a migration script)\n\n function setWaitingPeriodSecs(uint secs) external; // onlySelf (i.e. only via a migration script)\n}\n\nimport \"synthetix/contracts/interfaces/IAddressResolver.sol\";\n\n// Example Migration script\ncontract AtlairUpgrade is IMigration {\n\n function numOfScripts() external view returns (uint) {\n return 1;\n }\n\n function migrate(IAddressResolver resolver, uint256 index) external {\n require(index < 1, \"Invalid migration script index\");\n\n migrate0(resolver);\n }\n\n function migrate0(IAddressResolver resolver) internal {\n Proxy synthetixProxy = resolver.getAddress(\"ProxySynthetix\");\n synthetixProxy.setTarget(0x00000000000000000000000000000000000000000);\n\n Synthetix synthetix = resolver.getAddress(\"Synthetix\");\n // etc.\n }\n\n}\nIn order to integrate with the current Synthetix release process, the aforemented publisher script would be configured to output a migration contract, which would then be committed to mainnet, verified and submitted as a proposal.
\n\n\nFuture Improvements
\n\n
\n- For the initial phase of this migrator, the suggestion is to limit invocations of
\nexecute()to theowner. This is to prevent any confusions for the core contributors during partial upgrades (which take more than a single transaction). In the future however, we envisage thatexecute()will be callable by anyone.- Additionally, the eventual aim is to have
\npropose()also callable by anyone. This would then require approval by vote rather than veto by vote as suggested above. This is something to look at in future iterations of the migrator.
There will be a configurable time delay between when a proposal has been accepted and when execution can begin. This time delay exists to allow the network to review the proposed upgrade.
\n\n\nNote: all migration contracts and any associated contracts must be verified on Etherscan before proposing so that the community can review them appropriately once proposed.
\n
If the holders do not agree with the upgrades, they may vote to reject the proposal. Morever, if the proposal is not verified on Etherscan (or some other verified source), then the community should simply reject the proposal.
\nThe migration may take multiple steps (in the case where the migration requires more than the 10M block gas limit to complete, meaning in those cases that the migration isn't atomic).
\nIMigration, then fail the transactionTBD
\nIDelegatedMigrator.waitingPeriodSecsCopyright and related rights waived via CC0.
"}},"pageContext":{"id":"f246ffe1-73e2-5a7f-9418-7fd341cf943b","frontmatter__sip":59,"__params":{"frontmatter__sip":"59"}}},"staticQueryHashes":[]}