Skip to content
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

POC legacy mechanism alternative #938

Conversation

eternauta1337
Copy link
Contributor

Considers the removal of legacy contracts, their compilation, and their inclusion in tests.

In short, a legacy contract is an old contract, that is not supposed to ever be upgraded. This is because of the proxy mechanism used in Synthetix v2, which cannot persist state between upgrades, and thus needs central state to be isoplated in separate contracts. Legacy contracts are compiled when running npm run test:legacy. This runs the unit tests, but hacks the mocha require statement to go fetch legacy contracts, instead of official ones, which ensures that new contract code will work with these non-upgradeable contracts.

The mechanism described above is rather complex, and might be overkill. Instead, we propose an alternative lightweight mechanism which "complains" if a developer attempts to change a contract marked as non-upgradeable.

"ExchangeState",
"FeePoolEternalStorage",
"FeePoolState",
"Proxy",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this should be the name of the actual contract label - not just the source - so ProxySynthetix for instance. Though it would be cumbersome to list all possible proxies. Perhaps instead these entries can be a regex?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, and this is the current functionality. For example, TokenState in this list will cause TokenStateSynthetix, TokenStatesUSD, TokenStateJPY etc to be considered non-upgradeable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right sorry I missed the includes. Perhaps it's better to have a pattern match of /^.../ to ensure it starts with not just includes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... would ReadProxyAddressResolver be upgradeable?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it wouldn't

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But a new ReadProxy would be ok if we needed one. So perhaps the whole ReadProxyAddressResolver is best?

@eternauta1337 eternauta1337 merged commit bb624d6 into migrate-to-hardhat-master-trigger Dec 3, 2020
@eternauta1337 eternauta1337 deleted the migrate-to-hardhat-no-more-legacy branch December 3, 2020 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants