FIP: Storage lending

[aditiharini]

Title: Storage lending
Type: Implementation FIP
Authors: aditi, sanjay, v

Problem

Apps want to sponsor users so that they can onboard users for free. If apps are paying for storage, they need a way to reallocate storage as they wish so that they don’t have to allocate an infinite budget to for signups.

We propose a mechanism to allow one fid to lend storage to another fid (and revoke it), so apps can buy storage for themselves via the storage contract and then lend it out to their users for free.

Specification

Message specification

/** Type of the MessageBody */
enum MessageType {
  ...
  + MESSAGE_TYPE_LEND_STORAGE = 15;
}

message LendStorageBody {
  uint64 to_fid = 1;
  uint64 num_units = 2;
  StorageUnitType unit_type = 3;
}

message MessageData {
  MessageType type = 1; // Type of message contained in the body
  uint64 fid = 2; // Farcaster ID of the user producing the message
  uint32 timestamp = 3; // Farcaster epoch timestamp in seconds
  FarcasterNetwork network = 4; // Farcaster network the message is intended for
  oneof body {
    ...
    + LendStorageBody lend_storage_body = 18;
  } // Properties specific to the MessageType
}

We add a new LEND_STORAGE message type. The lender’s fid is the fid on the MessageData. This message set has no “remove” message type, similar to UserData. Snapchain stores the last submitted MESSAGE_TYPE_LEND_STORAGE message per (lender, borrower) pair. In order to revoke storage from a user, the lending fid should submit a MESSAGE_TYPE_LEND_STORAGE message setting num_units to 0 for the borrower.

Snapchain implementation

Shard 0 will include BlockEvent messages in its transactions upon successfully processing a LendStorage message. BlockEvent messages will be consumed by shards 1 and 2.

enum BlockEventType {
  BLOCK_EVENT_TYPE_HEARTBEAT = 0;
  + BLOCK_EVENT_TYPE_MERGE_MESSAGE = 1;
}

message MergeMessageEventBody {
  Message message = 1;
} 

message BlockEventData {
  uint64 seqnum = 1;
  BlockEventType type = 2;
  uint64 block_number = 3;
  uint64 event_index = 4;
  uint64 block_timestamp = 5;
  oneof body {
    HeartbeatEventBody heartbeat_event_body = 6;
    + MergeMessageEventBody merge_message_event_body = 7;
  };
}

Validations

• The lending fid must have at least num_units + 1 of storage available that they have not lent out, not counting borrowed storage. We disallow lending borrowed storage because this makes it very difficult to track down where to evict storage if storage starts to expire. We require lenders to maintain at least 1 extra storage unit so they have the ability to revoke storage they’ve already lent. Rate limits are based on a user’s available storage.
• The timestamp on the message may be more than 10 minutes in the past (relative to current block timestamp). We have this constraint to protect against backdated storage lending. A user can otherwise track all storage lends submitted by another user and resubmit arbitrarily old storage lends that were revoked and eat up another user’s lending budget.
• The lending fid must have at least 1000 total units of storage purchased. This is to restrict the set of users who can lend storage and offer some protection against users spamming the network by repeatedly lending, then revoking storage. We can relax this constraint later if there is sufficient reason to.
• A user can lend at most 5000 units of storage in a single LEND_STORAGE message. This is to protect against accidentally lending way too much storage to a single user (e.g. fatfinger, app bug).

Pruning

The number of LEND_STORAGE messages maintained on the protocol for a given lender fid is bounded by the number of storage units they own. The protocol supports at most 1 message per unit. Messages that set lent storage to 0 are pruned immediately upon merging to avoid bloating storage. Snapchain will emit separate MERGE_MESSAGE and PRUNE_MESSAGE events indicating revoke is merged then pruned to work cleanly with existing event stream consumer implementations.

Using borrowed storage

Shards 1 and 2 consume MergeMessage block events from shard 0 containing the storage lending information.Shards 1 and 2 compute the total storage available for an fid (used for rate limits and pruning) by subtracting units the fid has lent and adding units the fid has borrowed. The number of messages pruned will be determined based on this computed storage number.

Client updates

The changes requires to handle LEND_STORAGE messages in shuttle will be shipped with (or prior to) the Snapchain changes.

In addition to shuttle changes, clients may need to consider updating any logic that computes the total storage available to a user to account for borrowed storage.

Apps that intend to lend storage should carefully consider how to go about revoking storage from users they no longer want to sponsor. If a user has no storage (including borrowed storage), all their data will be pruned from Snapchain the next time they attempt to submit a message. The user can retain their data by purchasing their own storage, but they should do this before the app revokes their borrowed storage to eliminate risk of losing data on the protocol.

Future work

Storage unit expiration

As of yet, no storage units have expired, but if units do expire Shard 0 must realize that units have expired and decide who to revoke storage from if a lender no longer has enough storage to support all the lending it has done. One logical approach is starting to evict from the earliest lent storage and proceeding until the user has lent less storage than it has available. This mechanism will be implemented with some grace period so that the lender has enough time to purchase storage again to back the lending they’ve done.

Release

This change will go live in Snapchain mainnet on October 7 as a part of the next release.