Creator

Nicola

Created

May 22, 2023 10:23 PM

Problems

Problem 1: Expensive PublishStorageDeal

A Storage Provider that wants to store client data must publish their deals on-chain via PublishStorageDeal. The Storage Market actor which governs these interactions is unfortunately very gas expensive.

Problem 2: Very small and large deals

The current storage market does not allow for deals that are smaller than 128KiB and deals that are larger than 64GiB. These are artifacts that are specific to the deal definitions in the storage market.

Problem 3: L1 On-chain activity

All the deal data lives in L1, which makes it very costly to run existing operations (such as PublishStorageDeal) as well as potential future features (e.g. deal renewal, deal repairing, etc).

Proposal

The main proposal is to design a competitive Storage Market that can through time replace the existing one.

Proposal 0: Bypassing Storage Market via free CommD

The proposal is to enable 🕊️Free CommD: Unconstrained data applications on Filecoin.

Solving:

• Fixing Problem 1: Data can be stored in a sector skipping the storage market or via user storage contracts, so no need of PublishStorageDeal
• Fixing Problem 2:
• For small files: Thanks to Verifiable Off-chain Data Aggregation clients can be sure that their data is included in a deal.
• For large files: Custom software/contracts can split files in multiple subpieces that can be spread across sectors
• Fixing Problem 3: No need for deals to be happening on-chain

Cons:

• Deals information are not inspectionable
• No enforceable SLA on deals (unless user-based storage markets are deployed)
• Current deal making API potentially broken.

Proposal 1: L1 Simple Storage Market

The proposal is to create a new simpler storage market that offers minimal features where the deal data and the deal settlement lives on L1, keeping the same API as the existing Storage Market.

This requires of 🕊️Free CommD: Unconstrained data applications on Filecoin, but doesn’t require enabling user storage markets, since we could white list this storage contract.

Why this over Proposal 0?

• Deal information are inspectionable
• Basic deal SLA can be enforced by the smart contract
• Same APIs as today: There are some APIs that the current Storage Market offers that is used in a lot of tooling (e.g. PublishStorage Deal, reading on-chain data deals with software such as delta and boost).

Solving:

• Problem 1: PublishStorageDeal can become cheaper than today
• Problem 2: Potentially solved (requires protocol design)
• Problem 3: Not solved

What would change from existing Storage Market?

https://github.com/filecoin-project/builtin-actors/blob/master/actors/market/src/state.rs

• Full Deal Proposals x
• What has to stay?
• CommP
• End epoch
• Verified (emitted through an event or external contrac)
• ClientId (emitted through an event)
• ProviderId (emitted through an event)
• Label (external contract)

Proposal 2: L2 Aggregators Market

This proposal is to re-use the proposed L2 Deal Market as the alternative market. Both the deal data and the deal settlement lives on L2, while deal are still activate via an oracle interaction with L1.

Why this over Proposal 1?

• Problem 2:
• For small files: Thanks to Verifiable Off-chain Data Aggregation clients can be sure that their data is included in a deal.
• For large files: Custom software/contracts can split files in multiple subpieces that can be spread across sectors
• Solves problem 3: Deal execution lives on L2 (deal data potentially too)

Summary