WIP practical on ramps

practical-on-chain-on-ramp.md

Practical on chain on ramps

Zenground0

May 1 2024

An “on-ramp” is a system that helps users easily store data on filecoin. An on chain on ramp is such a system that works by sending blockchain messages to blockchain systems. With the FVM we are able to build on-chain on-ramps but they don’t exist yet. There is at least one fledgling project – Eastore, running on calibration net– that is fairly far along. This document lays out the issues and opportunities in quickly deploying smart contracts to filecoin and L2s that get us web3 native on-ramps in 3-6 months.

Disclaimer

FilOz is not interested in building or maintaining new production systems. This presents an extra challenge in figuring out how to coordinate the necessary work and system ownership. This document will ignore this altogether.

A basic definition

On ramps can have many possible features and properties. But the following simple interface is a good approximation to the core functionality users probably want:

interface OnRamp {
  struct DataRef{
    Cid commP;
    int64 storage_duration;
    // optional location informs where to find data: http addr, ipfs hash etc
    string location;  
    uint64 value;
  }
  
  // An integer ID tracking data refs being stored
  type DataRefID = uint64
  
  // This incentivizes storage of data in ref and assigns a unique id
  function offer_data(DataRef ref) returns (DataRefID) public payable;
  
  // This is emitted by offer_data and consumed by storage providers
  event DataReady(DataRef, DataRefID);
  
  // This could be augmented with an event emitted in `prove_data`
  function verify_data_stored(DataRefID id) returns bool 
  
  // This function is called by storage providers or facilitating parties, its not important for the client
  // The proof data type and even the function signature can differ a lot based on
  // the implementation.  For example AuthenticateMessage and NotifyDeal together satisfy this interface for the client contract.
  function prove_data_stored(DataRefID id, Proof proof)
}

Less information

This could be simplified down to struct DataRef{ Cid commP} by context in the on-ramp contract, i.e. location is well known, value and duration globally specified. But the specified level of detail is a good compromise

More information

The above simple interface can be extended in many ways. On ramps could also include

• provider level configurations: replication factor, reputation score requirements, physical location preferences
• payment variations: market pricing, ERC 20 payment, client refunds, DAO financing of storage
• robustness variations: renewal, repair. Decent extension interface here
• retrieval incentives and guarantees
• etc

Focus

Since we are 1 year out of FVM launch and there are no production on-chain on-ramps at all it is clear we should consider these extensions only after building the core functionality.

Implementing the basic definition

The implementation of the offer_data funciton in a contract is straightforward. However to make it useful there must be a way to claim

There is a decision tree of choices one can take in implementing the basic definition. The top level choices are:

1. Use the deal system vs Use the sector system
2. On-ramp on L1 vs On-ramp on L2
3. Aggregate vs Don't Aggregate

Eastore, the closest system to production today is 1. using the deal system 2. hosting its on-ramp contract on L1 3. Not aggregating. These are the easiest choices to implement today requiring no filecoin protocol changes, fewer relaxed bridging security assumptions and no aggregation or POSDI proving logic. The primary downside to these decisions is higher gas costs than are strictly necessary.