FILDevSummit Singapore'23: SP Tooling & Stack

[jennijuju]

What's FILDev Summit ➡️ here.

Track Lead: @rjan90

This technical deep dive focuses on the tooling and technology stack to scale a storage provider's business while increasing profitability. We will connect with development teams and users in an open forum on the impact to lower gas fees, reduce costs and scale profitability.

Full agenda ⏭️ fildev.io
Subscribe this discussion to get updates from this track!

[rjan90]

This is a first draft/post of some of the takeways from the SP tooling & Stack track at the Fil Dev Summit in Singapore.

Takeaways from the SP Tooling & Stack track:

The SP Tooling & Stack track offered a wealth of insights from a wide variety of people with deep knowledge about different parts of the Filecoin network. There were many productive discussions about the current bottlenecks in the SP stack, and we examined numerous potential solutions, striving to align on how we can make a larger impact on the network.

Here are some notes from the various discussions. I might have missed some topics, and would appreciate if those who attended the sessions could post their own learnings and insights in this discussion.

🏎 SnapDeals

While the promise of SnapDeals are good, there are gaps and bottlenecks that needs to be addressed for them to be a viable option for storage providers. Some of the things that where highlighted during the Fil Dev Summit in Singapore:

Gas costs for SnapDeals

The current gas costs for SnapDeals are too high for CC+Snaps to be a viable path for SPs that want to onboard deal data. One of the reasons for this high gas-cost is because ProveReplicaUpdates messages can´t be aggregated.

• The SuperSnaps FIPs are looking SuperSnaps: Snarkpack for Snap deals FIPs#752 at ways to apply snarkpack to ProveReplicaUpdate to get costs down. It was highlighted that estimates/numbers on the potential costs reduction this FIP could bring to SnapDeals would be beneficial to evaulate if that FIP alone would make the savings be large enough for CC+Snaps to be viable option for SPs wanting to onboard deal data.
• Additionally we can allow batching of ProveReplicaUpdate which is already supported by the network to drive the costs down additionally.

SnapDeals without sealed sector transfer to workers

Snapping deal data into CC-sectors does not work well on PiB scale, as CC-sectors needs to be moved to the sealing-worker before Snapping the deal data into the sector and finish the remaining sealing steps. This causes a large data overhead on sealing-workers, and congestion on the storage providers network.

SnapDeals to exact sector

Storage providers want the ability to specify an exact sector (or range) for snapping in a more automated way. This is achievable today, but there are some obstacles that make it difficult.

• Sending a single extension message for each sector at the time of snapping will be very costly.
• FIP0045 made SnapDeals and sector lifetime selection a lot harder, as a CC-sector wanting to be snapped must have a duration that is no longer than 90 days in excess of the deal term that is being stored in said sector.

A potential solution for both of these obstacles is to remove the deal term and sector lifetime relationship, which makes it possible to have long-living sectors that can be snapped and re-snapped without having to think about extending the underlying sector or finding a suitable CC-sector for snapping.

🔁 Interchangeability of SP-implementations

Sealing, Proving, Chain, and Markets are key components in the SP stack that could greatly benefit from interchangeability between implementations and also custom software. If implementations can align on an interface that allows SPs to "choose their own stack from different components," it might allow for greater specialization and less redundant work being done by implementations.

🧰 Worker-address and trust-issues

The SP worker-address introduces some trust issues today as it is responsible for both block signing and message-sending (PreCommit / ProveCommit).

A potential resolution is to only allow the worker-address to handle block signing, and have control-addresses manage the sealing messages.

🌊 SaaS <> SP workflow with client data

At a high level, client data complicates the pipeline between SPs and Sealing-as-a-Service providers. Data is expensive to move over the wire between SaaS providers and SPs, and client data is not something SPs want to share with a SaaS provider. At a lower level, we explored some bottlenecks/issues/potential solutions around:

Split messages in the sealing pipeline causes congestion.

The split messages in the current PoRep system cause congestion in the SaaS pipeline because SaaS providers are waiting for SPs to send the message on-chain. See the NI-PoRep section for a potential solution to this.

CC + Snaps approach is costly

Using CC + Snaps mitigates a lot of the problems introduced when dealing with client data in the SaaS <> SP workflow, but the problem today is that this flow comes with a large overhead in costs, both in time and gas.

Sealing-time for CC is still high, although specialized SaaS-providers would be able to generate these faster then a lot of storage providers. Adding snaps into the mix for adding client data incurs additional gas-costs when sending the ProveReplicaUpdate message.

Another point to note is that onboarding CC-sectors before snapping them requires the CC-sectors to be online and provable from the point in time they have been sealed. This adds additional OPEX costs (electricity, proving-costs), and is something some SPs take into account when wanting to just store client data, and then often opt-in for using the regular sealing approach for onboarding data to sectors.

See NI-PoRep section and SnapDeals sections for some ways of mitigating these bottlenecks.

📮 PoSts-as-a-Service

We need new SaaS APIs to make PoSts-as-Service possible. Overview of the current SaaS APIs can be seen here.

⭕️ Non-Interactive PoReps

Non-Interactive PoRep + together with some grace period where the sector does not have to be activated came often up as a potential solution for making the CC + Snap approach a lot more viable. A couple of items that needs to be addressed, community needs to align on w.r.t NI-PoRep:

Positives:

• Removes the PreCommit and PreCommitDeposit step which simplifies and offers flexibility in the sealing pipeline (trustless seperation between sealing and proving).
• No fixed schedule to add sectors to the network
• SP can follow their own sealing schedule according to their setup and prove sectors on-chain when ready
• PoRep Security now independent from Consensus

Negatives:

• Per sector resulting gas costs are likely to be higher than today (more inputs, more challenges, more snarks needed). Numbers needs to be provided for us to fully grasps these negatives.
• Proving overhead of potentially ~8.7x compared to today.
  • SupraNational improvements (C2) might mitigate these additional costs, and make NI-PoRep the same proving costs as today.

🩹 Resealing corrupted sectors with deal data

Resealing a broken sector with deal data in it is difficult today, as getting the ticket from an old PreCommit1 is not easy today.

SP clients can add a cmd that allows for getting those params, but ideally there should be either a reseal cmd / or community tool that makes resealing a corrupted deal sector easy together with getting the ticket from an old PreCommit1.