Allow Onchain Query Order Status And Order related Proposal on Market Actor

[FroghubMan]

Summary

Market actor provides methods for querying order-related information

Motivation

The built-in storage market actor does not currently support other actors to query its order status and the proposal corresponding to the order. When the FVM makes user actors possible，Basically al storage-related use cases require on-chain querying of order status.

Use Cases

• Data dao needs to make on-chain decisions based on the storage state of valuable data.
• To achieve the goal of permanent storage, it is necessary to conduct mining incentives according to the state of the data, etc.
• Insurance protocols needs to decide whether to pay compensation according to the status of the data.

[kaitlin-beegle]

Hey @FroghubMan! Thanks for opening up this discussion! I'd love to see some early specs or design ideas for this proposal! Is this something you plan on putting together, or would you need others to assist with this?

[FroghubMan]

We participated in the FVM early builder,The goal is to build a unified pricing cloud storage market for users based on Filecoin,We are currently encountering the problem of not being able to query order related state.

There may be two approachs to implement market actor state query:
1.The market actor need to provide similar to the following two view functions for the user actor to query order related state.

1.1 query deal proposal 

#[derive(Serialize_tuple, Deserialize_tuple)]
pub struct GetDealProposalParams {
    pub id: DealID,
}

fn getDealProposal<BS, RT>(
    rt: &mut RT,
    params: GetDealProposalParams,
) -> Result<DealProposal, ActorError>

1.2 query deal state

#[derive(Serialize_tuple, Deserialize_tuple)]
pub struct getDealStateParams {
    pub id: DealID,
}

fn getDealState<BS, RT>(
    rt: &mut RT,
    params: getDealStateParams,
) -> Result<DealState, ActorError>

2.The user actor can query the current state cid of market actor in some way.After querying the state cid, use it to query the raw data, and then deserialize it into market actor state.Although this approach is more general and more flexible，it destroys the private internal state. And after the actor is upgraded, it may affect the query of the actor state by other actors.

[FroghubMan]

We currently do not know which approach of market actor state query will be implemented. And we are happy to contribute if needed.

[anorth]

Agree we will need this, unfortunately other higher priority things are preventing me from getting to it.

We don't just want APIs for the built-in market actor, but a standard API that alternative storage markets can also implement, so that programs like yours can work with deals from any market. To that end, I will recommend we don't expose the DealProposal and related structs directly, but a collection of methods to return the same information, abstracting the internal storage details.

I made some sketches some months ago here, and hope to get back to it soon. There are some other more basic programmability things to address first.