FIP-0076: Add ListAllocations/ListClaims verified registry methods.

[anorth]

No description provided.

[jennijuju]

Not a blocker and would like to suggest maybe rename to GetAllAllocations and GetAllClaims to match the names we have been using for other functions ,

[anorth]

I don't see any GetAllXXX in the linked FIP, or are there any in the actor codebase. There are a bunch of GetXXX methods, but these all return a single field. Sometimes that field is a short list, but it's always returned in full. These are the first built-in methods that iterate over a large collection and return partial results, a very different semantic. These names are consistent with FRC-0053 though.

[jennijuju]

editor review ✅

could you please add a link to the implementation PR? would love @Stebalien @aarshkshah1992 @arajasek @LesnyRumcajs to give the proposed implementation spec & implementation a peer review.

This is somewhat the first time we introduce an function params like the cursor data structure - it would be great if we can have an example for clients on how to actually use it.

[raulk]

(Peer review)

(I may be lacking some context here, but @jennijuju requested my input).

Do we have a sense of the gas costs of iterating over all entries in mainnet today, for each method? And maybe a cost projection for expected growth? My train of thought:

1. I assume these are publicly exported because we expect EVM contracts (and upcoming Wasm actors) will wish to invoke them on-chain. If these methods existed only to encapsulate the logic for observability purposes, they wouldn't need to be exported, hence my assumption.
2. The cursor as designed will be interrupted on a state update. This design only works if (a) the caller can fit the intended enumeration access all within a single transaction [atomic read], or (b) across transactions iff something guarantees that the verifreg state won't change halfway. AFAIK there is no such latter mechanism, and thus this spec diff rightly notes that a cursor is only valid immediately after return.

How do you foresee this interface being generally useful? I think stability across transactions is a desirable property. But the underlying fields being HAMTs make that difficult.

A design that awards some stability at the expense of some extra complexity involves taking advantage of the fact that HAMTs are persistent data structures and retaining a bounded buffer of size S of past roots so that they remain reachable from actor state after S mutations occurred. But even that solution presents variability.

[anorth]

Moved to #730 (comment)

[raulk]

Editorial comment.

Can we specify explicit signatures for all methods being added in this FIP, as well as their computed FRC-0042 method number? The former can be reasonably assumed from data structures, and the latter can be derived with some work. But simply adding these details would reduce spec indirection, would make signatures normative, and the spec more self-contained/clearer. Thinking about library implementers like filecoin-solidity devs.

[anorth]

I have added the missing computed method numbers.

I'm not sure what you're requesting for a more explicit type signature. The data structures provide it. Are you requesting adding lines like:

method ProveCommitSectors2(ProveCommitSectors2Params) -> ProveCommitSectors2Response

These seem a bit redundant to me, but I can do so if you wish.

[anorth]

I'm merging this to unblock Last Call. We can add some form of method signatures if a clear schema for them is suggested, and I don't think that will constitute a substantive change to the FIP.