PDP Contract Change

[ZenGround0]

There is currently a push to do a hard upgrade of the PDP contract changing the address of the proxy without upgrading. The reasoning for this is outlined below

Benefits

1. Renaming. People want to rename the PDP concepts as outlined here. It is trivial to do this in an upgrade. The problem comes from subgraph indexing and explorer presentation. A contract with a split history of two names for one conceptual method pushing naming complexity to application code that we'd like to avoid. More discussion here
2. CommpV2 everywhere. We want to move PDP to forcing commpv2 as the content identifier in PDP. If we have a clean slate contract we can enforce CommpV2 onchain everywhere without needing to resort to migrations.

Deprecation Strategy

Option 1: Total Deprecation

We will upgrade the contract to be a stub that reverts on all messages. This has the benefit of being very simple to implement and very informative to users and systems relying on the old contract. Everything will fail fast and force a resolution within the weeks after upgrading. This keeps the conceptual overhead of the transition light.

I'm advocating for this approach because there is limited usage on calibration net and seemingly no outside usage on mainnet apart from my node.

The biggest downsides are that existing datasets will no longer be proven and storage provider deployments will need to be reset or manually wiped to clean out, for example, the curio databases tracking these deprecated proofsets.

To maintain proving of existing datasets we would only do the deprecation upgrade weeks to a month after deploying the new PDP contract allowing users time to migrate important data to a new proving node referencing the correct contract.

Option 2: No new data

In this scenario we would upgrade the existing contracts on mainnet and calibnet to disallow further addRoots and createProofSet calls but would not interfere with existing proving and next proving period calls. This could ease the transition for applications relying on PDP proofs by maintaining live proving of existing data indefinitely without doing any migration work.

I suspect this is more development and operational trouble than its worth so am advocating for Option 1.

Feedback

For all existing users please respond in the comments if this plan is going to cause issues with your deployments. Especially interested to hear @frrist and @hannahhoward weigh in on the deprecation strategy for the old contract on calibration net.

[rvagg]

Would it be a lot of work to just do both? Have a period of option 2 and then go to option 1? I prefer abandonware to brickware if I'm forced to make a choice and I don't love sending the signal that we're brickware developers to anyone who's not following the details of what we're doing.