contracts: migration simulation: Test migration simulation

[bingen]

No description provided.

[bingen]

The initial scenario starts with a system of 1,000 troves, a first one supposed to remain (there always has to be at least 1 in the system), with MIN_NET_DEBT and an ICR of about 600%, and then 999 more troves with ICR’s rangin from 110 (mostly from 120) to 500% and different amounts of collateral and debts.
ETH price remains constant at $1,000 for this simulation.

The following simple strategies have been implemented:

• Close trove in the old system and then open in the new one, by descending ICR order.
  When the system is about to enter Recovery Mode, users fallback to redemption instead.
  An example of this execution goes from an original system like:

 ---- Global state ----
Num troves       1000
Total Debt       492779225.104398971747631500
Total Coll       1542138.971250465715951000
TCR              3.129472373604532573
Last trove’s ICR 1.225204002057848352
 ----------------------

to an original system with only the base trove:

 ---- Global state ----
Num troves       14
Total Debt       8906104.084098714066355000
Total Coll       15077.321331654009698000
TCR              1.692919955715946996
Last trove’s ICR 1.550797894995769548
 ----------------------

and a destination system like:

 ---- Global state ----
Num troves       975
Total Debt       474969117.941201538070269000
Total Coll       1517366.735693227518583889
TCR              3.194663986303776590
Last trove’s ICR 1.321594437099873739
 ----------------------

This strategy is missing to implement the collateral claims from redemptions, or a second pass, as the TCR is back over CCR, but with these numbers we can already see how it would work.

• Close trove in the old system and then open in the new one, by ascending ICR order.
  This method doesn’t work as the first troves are below the CCR, so when they try to open in the new almost empty system, the transaction reverts. In a real, less automated scenario, users could either open the trove with a better ICR (which would actually be good for the system), or wait until better troves arrive and then re-try opening.

• Close trove in the old system and then open in the new one, in random ICR order.
  This approach works with this scenario, but it would be less reliable with a less healthy initial system. An example of its execution goes from an original system like:

 ---- Global state ----
Num troves       1000
Total Debt       508624667.756715803043447500
Total Coll       1614745.877206418208549000
TCR              3.174729775353286232
Last trove’s ICR 1.349463823230441193
 ----------------------

to an original system with only the base trove:

 ---- Global state ----
Num troves       1
Total Debt       2001.004999999999932500
Total Coll       11.699999999999998000
TCR              5.847061851419660817
Last trove’s ICR 5.847061851419660817
 ----------------------

and a destination system like:

 ---- Global state ----
Num troves       999
Total Debt       508622666.751715798417902000
Total Coll       1614734.177206418208551000
TCR              3.174719261960558367
Last trove’s ICR 1.349463823230441170
 ----------------------

• Pure redemption, i.e., all the accounts only try to redeem. It doesn’t make sense because redemption rate ends up growing too much.