We are in favor of separating Trust functionality from HUB1.0 to a different contract (called TRUST or HUB2.0). The TRUST (or HUB2.0) contract should be very simple.
We considered not migrating the trusts to the new contract and just read/write into the HUB1.0. And concluded that although it's easier to keep trust in HUB1.0, we would retain legacy clutter - that can cause confusion amongst developers(especially new devs). Also, it might be costlier in gas fees when a contract calls another contract, as opposed to calling info stored in the same contract.
We should take into account that if we separate the HUB1.0 in 2 contracts, we are also increasing the amount of contract calls, and actually we might not "save" gas fees compared to keeping trusts in HUB1.0.
The next questions are: What we are keeping in each of the new contracts? Are transferThrough and signup methods going to live in the same contract than trust information?
Alltogehter, we decided to migrate trusts from the HUB1.0 to the new TRUST or HUB2.0 contract to avoid legacy clutter
Approach:
There's a script running on the client, and for each user that migrates (first time they open the app during the migration period), the Trusts from that user are run again. The script is executed in the circles.garden app during a migration period (6 months). It looks like this:
Webapp checks if your Safe is in HUB2
if not then Migrate()
def Migrate =
signup in HUB2
read trust list from HUB1
execute Trusts in HUB2
Risks:
There's a window period when some users have migrated and others not, causing confusion for users.
Benefits:
Clean up the WoT (many users that used the system only for testing, bots, etc.)
Having a time limit for the migration is positive because:
reduce exploitation time
not maintain the code / script forever
Some doubts to clarify:
Do we continue to offer the migration after the 6 month period, even if not supported - technicall shouldn't be a problem.
Is our assumption correct? That is cheaper to migrate the trusts to new contract than read/write into HUB1.0.
Where the migration logic should live? In app level or contract level (for trusts and for balances)
Background: https://aboutcircles.com/t/earth-circle-ip-1-circles-2-0-architecture/428/5
Summary of what we have said in our meetings:
transferThroughandsignupmethods going to live in the same contract than trust information?Some doubts to clarify: