Filecoin Dev Summit 6 takeways

[LesnyRumcajs]

Noting down some key takeaways from the FDS in Toronto that touch the Forest team directly.

[LesnyRumcajs]

F3 Augmented RPC snapshots

Notes already taken in #5627

Gist:

• F3 snapshots live together with regular snapshots,
• No infrastructure changes (no separate files to host)
  • There might be some if the file extensions change, i.e., .forest.car.zst might no longer work. There might be some existing wildcards that would stop working.
• Green light to format breaking changes.
  • Could be something we build ourselves or an existing well-known format,
  • New format should accommodate for potential changes in the future,
  • Old snapshots must still be readable,
  • New format will be rolled out during a network upgrade to ensure clients are updated.
• F3 data (initial power table and certificates) would take roughly ~3 MiB/day, so an additional 1 GiB in snapshot size per year. This seems not that significant compared to the current snapshot size. It could end up being potentially less with compression.

Action items:

• Forest team to come up with a design to satisfy the requirements above and propose it. There can be a light FRC out there to have a written record somewhere.

[LesnyRumcajs]

Dependencies (not blocking the design and drafting):

• Add API for exporting certificate chain for Filecoin snapshots filecoin-project/go-f3#480

[LesnyRumcajs]

Common Node FIP/FRC + conformance testing

filecoin-project/FIPs#1027 (comment)

The common node API is roughly accepted, especially as a first step of formalizing the Filecoin node API. We will iterate on that for future API versions and ensure proper tooling is built around it.

Action items:

• Aleksei to generate an up-to-date JSON-RPC spec and create a new PR (FRC-0104). The spec should live in the FIP repo resources.

Conformance testing

Implementers came to conclusion that the best way to ensure API conformance would be to re-use existing Forest RPC snapshots testing.

Requirements:

• the RPC snapshot testing suite lives outside of Forest for clear separation and ease of contributing,
• Snapshots are publicly available and everyone can upload them (right now they are stored on ChainSafe's Digital Ocean bucket). Snapshots should also be easily verifiable. We might want to have some web RPC snapshot file explorer.
• Node implementations will use the above for RPC regression tests.

[LesnyRumcajs]

Snapshots with PDP

We did a small hacking around having the snapshot service feeding the snapshots to a Curio PDP. We didn't produce much code due to some technical issues, but had some pretty good food for thought.

Challenges with snapshots with Curio PDP:

• additional infrastructure code + monitoring & alerting on the Curio PDP node + we might want to host our own RPC node (Lotus or potentially Forest)
• We don't want to decrease the quality of the actual snapshot offering, so there needs to be a decent, high-speed link, geographical diversity., high-availability... that's a lot of work, maintenance and on-call challenges!
• Uploading files to PDP doesn't preserve naming - a web server serving snapshots from the Curio instance would need to keep some mapping and contain pdptool complexity.

Potential approaches:

• Keep snapshots on Cloudflare R2 and in parallel upload them to Curio PDP and slowly try dog-fooding that (and potentially sunset R2 in the future). This could take one of two forms (or more!):
  • snapshot service uploads the file to Curio instance after its uploaded to CF,
  • there is some kind of an independent listener that checks if a new snapshot is available and if it is, it downloads and uploads to Curio. It could also live on the Curio instance itself.
• Curio PDP could potentially operate on remote objects in S3 buckets. In such a case, the file is not uploaded to Curio directly - Curio just does the proving and requests required file chunks. This would be a nice approach as it would give both proofs and all the guarantees that are already there from Cloudflare.

Next steps:

• Decide on the approach. Can the remote file be implemented by Curio?

[joshdougall]

In addition to the above potential approaches, the architecture design should include Curio running as a cluster for regional diversity and redundancy. We also would reduce retrieval latency for users closer to the deployed node (eg. China).

[LesnyRumcajs]

Rust-F3 revival

Implementing a light rust-f3 should be possible, which follows the fast finality chain. Some of this might already be implemented in https://github.com/ChainSafe/rust-f3. Note that any integration with Curio would still need a full go-f3 or a complete rust-f3 translation.

It could open pathways to using it in the browser, though the most significant benefit would still be Forest's binary cleanup.

[LesnyRumcajs]

Node-side F3 improvements

We primarily rely on features from go-f3 to follow the F3 chain and all operations around it. That said, certain improvements need to be implemented on the node level.

Some of those are:

• feat(f3): load the power table once per tipset filecoin-project/lotus#13106. Do we do this already? If not, we should backport it to Forest.
• chore: increase the F3 GMessage buffer size to 1024 filecoin-project/lotus#13126. What about other parameters?
• Add cached MapReduce operation filecoin-project/go-hamt-ipld#143. This change would first need to be implemented on the ref-fvm side, correct? From what I gathered, it gives ~10x boost to performance.

Is there anything else?

[LesnyRumcajs]

Store the circulating supply info in actor state

Forest Team could, potentially, work on filecoin-project/FIPs#777, making it a formalised FIP/FRC and implementing it.

[LesnyRumcajs]

Simplifying miner state

There is some potential work in the future around simplifying the miner state and terminations that the Forest Team could chip in, both on the design and the actors' implementation side of things. This is a broader topic requiring expertise from CEL.