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.
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.
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)
}
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
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
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.
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:
- Use the deal system vs Use the sector system
- On-ramp on L1 vs On-ramp on L2
- 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.