[FR] Tool for Tracking Cell Deps by Type ID

[phroi]

• [@phroi] @Hanssen0 I was wondering, is there any to make this upgrade activate automatically in CCC at the right time?

  For example, if the transaction can be created and signed ahead of time, then we know already the new OutPoint. At this point we put a sleeper update in CCC and it activates automatically the new CellDep once the time is right 🎊

  Let's assume a user was using a JoyID-enabled website at the exact moment of the upgrade, he would likely just hit refresh on the page anyway if he encounters the error

  This idea could also be applied for any upgrade of contracts of public interest to avoid disruptions 🎯

• [@Hanssen0] Possible. We talked about this with the JoyID team before.

  1. We have this issue because the dep group of JoyID has no type id, thus CCC can't track the latest outpoint. This should be considered a problem and should be solved by Feature Request: Support TypeID for contract dep_group deployment nervosnetwork/ckb-cli#639
  2. JoyID's upgrade is a rare case, which means spending too much effort on this might not be worth it.

  Recently, I considered adding more methods to CCC for tracking cell deps upgrades, such as fetching information from a URL or similar. Although I insist that tracking by type ID should be the only method considered, the fact remains that we need alternative approaches for historical reasons.

• [@phroi] It makes so much sense, let's spread the idea!! 😁

• [@Hanssen0] An idea suddenly occurred to me. We should add a tool to the CCC app that allows anyone to create dep groups (with type ID) that track other cell deps. This way, we can avoid having to update the SDK in any case by tracking these type ID dep groups.

• [@phroi] To be honest, I'm coming around your take that depGroup

  introduces too much complexity and implicitness without bringing a corresponding benefit.

  Just yesterday I was suggesting an improvement for Quantum Resistant Lock (Refactor the whole lock script cryptape/quantum-resistant-lock-script#14 (comment)) and it doesn't work if the QRL CellDep is packed as a DepGroup.

  Another thing to note is that (after QRL gains adoption) DepGroup will make even less sense cause QRL witnesses will already be in the order of KB...

  What if instead it was a tool that make it easy to create and share lists of code CellDeps?

  (DepGroup functionality without DepGroup)

• [@Hanssen0] Since Dep Groups are already there, I'd still start with them (to get them working and get us up and running as soon as possible).
  As for the tool you mentioned, I think it can work with Dep Groups. Instead of adding Dep Groups to the cell deps, we can expand them in the SDK and add them later.

[phroi]

I would say that the DepGroups created by this tool will be out of date in the same way as the current ones, unless manually updated by the DepGroup owner.

Possible alternatives:

1. We could create a CCC-controlled private key owns that owns the created DepGroups by the tool, but it would not be decentralized.

2. DepGroups are just molecule encoded lists of OutPoints, we could make directly an on-chain and/or off-chain lists of TypeID 😁

3. CCC could still check the existence of each OutPoint and if not still alive grab the next one by TypeID and just add them by code CellDep

Phroi %23

[Hanssen0]

I would say that the DepGroups created by this tool will be out of date in the same way as the current ones, unless manually updated by the DepGroup owner.

I would assume that the dep group owner should maintain the correctness of it. Usually, the owner should be the same as the script cell deps owner.

Possible alternatives:

1. We could create a CCC-controlled private key owns that owns the created DepGroups by the tool, but it would not be decentralized.

No... just... no.

2. DepGroups are just molecule encoded lists of OutPoints, we could make directly an on-chain and/or off-chain lists of TypeID 😁

That's possible, we may have a ScriptInfo list.

3. CCC could still check the existence of each OutPoint and if not still alive grab the next one by TypeID and just add them by code CellDep

I'm afraid this would introduce too much network overhead.

[phroi]

In a way this conversation inspired both:

• The tool to manage DegGroup by TypeID
• The switch to code cellDeps instead of depGroup to allow for an easy transition during JoyID upgrade

So I'd say mission accomplished 😁

Phroi