Improve separation of concerns in ALP contracts to enable deeper upgradeability #274
Description
Context
Issue #166 introduced minimum upgradeability changes by making it possible to upgrade data structures in the future and reducing the size of our biggest contract. However, as noted in that work, separation of concerns has not been meaningfully improved and all parts of the ALP remain strongly coupled.
This issue tracks the next level of upgradeability work: decomposing ALP components to reduce coupling, which will make the contracts easier to upgrade, maintain, and reason about.
Current State (after #166)
- It is possible to upgrade data structures in the future
- Our biggest contract is smaller than it was before
- However, separation of concerns has not improved and all ALP components are strongly coupled
Goal
Decompose the different components of the ALP into separate, less-coupled components. This would give us:
- Improved separation of concerns across ALP contracts
- Easier targeted upgrades to individual components without affecting the whole system
- Code that is easier to reason about, test, and maintain
Ideas / Potential Work
- Replace the map of position locks with a resource representing mutation rights that can be retrieved from an
InternalPositionreference. The reference would only give away one such resource at a time -- replacing "provides safety if all callsites use the lock map properly" with a type-level guarantee that is easier to reason about. (originally from Explore options to improve future upgradeability/maintainability #166) - Identify other tightly coupled components that can be extracted into separate contracts or modules
- Evaluate which couplings are highest priority to address before launch
Relationship to #166
This issue picks up where #166 leaves off. The work in #166 was scoped to minimum viable upgradeability. This issue covers the deeper structural improvements discussed as a follow-up.
Notes
- Identify which improvements are "must have" before launch vs. longer-term