First draft of FIP-0076: Direct data onboarding

[anorth]

Adds new ProveCommitSectors2 (method 33) and ProveReplicaUpdates2 (method 34) methods to the miner actor
which support committing to data and claiming verified allocations without requiring a built-in market deal.
Adds a sector→deal mapping in the built-in market actor and deprecates the storage of deal IDs in the miner actor.
Removes the legacy PreCommitSector (method 6) and PreCommitSectorBatch (method 25)
in favour of the existing PreCommitSectorBatch2 (method 28) which requires
the sector unsealed CID to be specified while pre-committing.
Removes the legacy and unused ProveReplicaUpdates2 (method 29) (giving that name to the new method 34).

Existing onboarding flows that use the built-in market actor remain fully supported, but optional.

Discussion: #730

[ZenGround0]

Probably planning to cover this in incomplete Design Rationale but make sure there is some discussion of the internal changes to sector termination and its role in motivating sector number => deal ids index in market actor

[jennijuju]

@anorth - should the ./idea be committed?

[jennijuju]

Peer: Ideally I would prefer a new method number to be assigned, and deprecate the old message/drop the code an upgrade after. Imagine a user sends legacy PRU2 message right before the upgrade, the message will fail upon block inclusion if it happens right after the network upgrade. It is a failure we could avoid for users with minimum cost imho.

[anorth]

See design rationale. It's just not going to happen - it has never been used.

[arajasek]

These names are gonna get confusing. Can we consider naming them something more specific, instead of just having ProveCommitSectors and ProveCommitSectors2 (and so on)?

We can also rename the older methods too if we so wanted to.

[anorth]

Can you suggest some names? I've been unable to find something appropriately concise yet more descriptive of the difference.

[arajasek]

Yeah, I didn't have any good ideas either :(

[jennijuju]

Suggested change

	- Continue supporting existing onboarding methods to give participants time to migrate their workflows.
	- Continue supporting existing onboarding methods to keep existing f05 storage markets flow and functionality remain supported (for clients who would like to have onchain payments) and give participants time to migrate their workflows.

[anorth]

Parties can have on-chain payments without using the old methods. The old methods remain only for transition.

[jennijuju]

Parties can have on-chain payments without using the old methods

I understand - however, I think it is too soon to assume all network users want to migrate to the new flow. if we can have a quick mention on if one would like keep their exact existing flow - how should they do so might be useful. i.e: PSD -> PreCommitBatch2 -> ProveCommitSectors/ProveCommitAggregation; or PSD -> PreCommitBatch2 -> ProveCommitSectors2 with RequireNotificationSuccess=true && RequireActivationSuccess==true

[jennijuju]

could you please specify if a sector contains both f05 deal pieces and non f05 pieces, when notification failed for f05 pieces yet the sector is successfully activated - what would the deal pub activated: ChainEpoch, value be?
and how would sector_start_epoch & last_updated_epoch be updated accordingly? (if it is specified in the later session, please kindly send a premark link, thanks.

[anorth]

If the notification fails the deal is not activated. So there is no activated epoch, sector_start_epoch, or last_updated_epoch.

[arajasek]

This looks pretty close to landable, just a couple notes.

[jennijuju]

editorial: is there any reason why we are still using go spec actor convention even its already deprecated and we are only implementing in rust? it would took less time to look up code reference if we just using require_notification_success here (and same for the rest of the fip

[jsoares]

I have nothing to point out at this stage. The proposal is well supported and very well described, addressing all key concerns raised in discussion and review. Looks ready to merge. Excellent work.

[kaitlin-beegle]

Just so I understand- the only group of people who would still be using these methods and submitting sectors via the builtin market actor are those who are (theoretically) working with clients on-chain? Am I misunderstanding this workflow?

Please note this is just a curiosity; it's unrelated to my editorial review of this draft.

[anorth]

Initially, everyone will be using these methods because it will take time for operations to migrate to the new flow. They remain as part of a two-stage migration to avoid requiring all operations to update in synchrony.

In the long run, no-one should use them and I think we should remove them. Parties can still use the built-in storage market actor with the new methods too.

[kaitlin-beegle]

Is this jargon that I'm unfamiliar with? Either the hyphen should be removed, or it should read as "state-per-sector".

[jsoares]

I believe you're supposed to read it as the per-sector deal IDs in the miner actor state.

[kaitlin-beegle]

Editorial review in. A few (very small) nits. Otherwise, great proposal. Sorry for the delay on a detailed review.