Context

A key takeaway from Lisbon Labweek was the uncertainty around Saturn L2 nodes, on two counts:

  1. The utility of L2s in the network architecture. That is, from an engineering standpoint, can we engineer actual utility for L1 nodes to cache-miss to L2s rather than just to the IPFS Gateway or to Storage Providers directly. Stations will be behind NATs and may switch on and off quite regularly and are therefore not the most reliable or performant data stores. If L2s are affecting the performance of L1s, the L1s may revert to cache-missing to the IPFS Gateway or SPs instead.
  2. How do we process Saturn (or other module) payments to tens of thousands of Stations before FVM ships?

Why does this affect Station?

The original plan for Station operators to get their first payment was by running a Saturn L2 node. Therefore, the above concerns from the Saturn team have affected the Station plan-to-first-payment.

The Saturn team is now planning the best route forward given the constraints and has the following options.

Table of Options

Option 1: Saturn payments, no smart contract Option 2: Sponsored payments as an impact evaluator on FVM Option 3: Client pays Station directly
Description With Saturn L1 payments initially being processed in a centralised way, we can extend this to L2 operators too. However, early traffic will be synthetic. (more details in appendix) We design a smart contract on FVM that takes funds from certain sources into a treasury. It then collects network measurements, evaluates them and then makes payouts from the treasury to the network node operators. Certain modules could work in the “pay-directly” model. I.e. a client wants a Station to do a job and pays directly with a FIL transaction or over a payment channel to the Station operator in exchange for the execution of the job.
First module Saturn Most likely Saturn. Could be Bacalhau, Network measurement Quarry
Timeframe ~3 months ~6 months ~3 months
Scale Only up to a few thousand Stations Scales well Scales well with good payment channels
Saturn only? Yes No. This payment mechanism could work more generally for Bacalhau, Network measurements and many other modules No. The pay directly model would work for any module if the business model makes sense.
Blocked by FVM No Yes No
Proof of Job Saturn centralised logs system Under research and development p2p so proof is localised

Current Proposal

We follow Option 1 in order to onboard the first few thousand Station users. We begin work on Option 2 to support payments for a wide range of modules, working towards a general framework for sponsored payments for Station jobs.

Appendix

Option 1 in more depth

As an interim solution, from November 2022, the Saturn network will be paying Saturn node operators based on a log processing and fraud detection module that is deployed and managed by the Saturn engineering team. Each Saturn L1 will be paid with a FIL transaction to their FIL address based on their contribution to the network over a monthly period.

Whilst this is not the ideal solution - payments will be moving to a decentralised verifiable mechanism as soon as possible - it is relatively straightforward to extend this mechanism to work for Saturn L2s too. See this page for proposed engineering details.

However, since the network traffic to the Saturn network at the moment is predominantly synthetic, the traffic that in turn flows through to the L2s will be predominantly synthetic. I.e. Not real network requests, but instead ones generated by test bots.

Furthermore, without multi-peer retrievals or other innovations, it is very unlikely that a cache-miss from an L1 to an L2 will be more performant than a cache-miss from an L1 to the IPFS Gateway. Therefore, any traffic to the L2s will not be in the critical retrieval path and will just be sent in order to bootstrap a network of Station Operators running Saturn L2s.