Skip to content

Instantly share code, notes, and snippets.

@ZenGround0

ZenGround0/MessageContract.md

Last active November 4, 2022 12:23
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ZenGround0/e5d476b43d5e3c9be8da8d5775a975ff to your computer and use it in GitHub Desktop.
Save ZenGround0/e5d476b43d5e3c9be8da8d5775a975ff to your computer and use it in GitHub Desktop.
Download ZIP
A statement of purpose and system overview of the Filecoin Message Contract
Raw
MessageContract.md

Contract as a Deal Client for Archiving Filecoin Blockchain Message Data

Motivation

  1. Use web3 infrastructure to solve the filecoin message archive problem currently solved with web2 clouds
  2. Provide an EVM contract template for contract as a client data storage on the filecoin network
  3. Identify sticking points in the current model of data preparation, data transfer and deal negotiation for contract as a client storage deals. For example learn how the ask protocol should change to support this model.
  4. Demonstrate a new model for FIL+ auditing with significantly better fraud resilience properties

The core idea is that as system and protocol developers we will benefit from building a small application to understand how to adapt the network to similar applications. The nice thing is that fil infrastructure has a concrete application today which serves PLs broader goal of using our own tech.

System design

FEVM Contract

The Message Contract is a user defined FEVM contract. Its state is a simple map from commPs to existing deal count, the "wishlist". These commPs are the cids of packed message car files that fit inside a sector. The contract also has a max replication factor, i.e. 5. The contract has some datacap. SPs make regular storage deals with the market actor and this contract address as a client. This contract implements the authenticate message from FIP 44, so market actor deal validation will call into it. If the deal is for one of the cids on the wish list below the max replication factor then the contract will accept the deal and grant datacap, otherwise validation will fail. Since we are making a deal with the market actor the datacap to QA power flow is all taken care of.

The contract has three methods:

  1. AddToWishList: Add a set of commP cids to the wishlist. This is part of setup
  2. FreezeWishList: Freeze the wishlist. After this point FIL+ notaries can audit and then grant datacap to the actor
  3. AuthenticateMessage: FIP44 method called by f05 as part of PSD as described above

Packing Software

This is an open source library for packing messages into sector sized carfiles and doing car padding. It is the data preparation needed to

  1. generate commPs to add to wishlist,
  2. generate data from source of message data to seal and activate deals to claim QAP
  3. audit the contract as part of FIL+ notarization process

Contract preparer must use this. SP storing the data and FIL+ notary can use this. Thought SP might get the data elsewhere:

Optional data availability

To make this easy for SPs we could put the packed CAR files on IPFS or some http endpoint. Then we could publish this either into the message contract or somehow integrate into the datanetwork, i.e. as an evergreen tenant, or as a direct storage client serving data offline. This should be strictly optional in theory as SPs should have access to all message data anyway and could use the packing software on the raw data directly. This may be required for the FIL+ notaries at least during the notarization process to lower burden on auditors.

Putting it all together

This is the rough order of events

  1. Deploy EVM contract
  2. Process historical message data and pack it into CAR files
  3. Add these CIDs to the wishlist
  4. Freeze the wishlist
  5. (optional) Provide data on IPFS / web2 cloud
  6. Apply for datacap pointing notaries at (1) on chain wishlist (2) the data of wishlist cids. Notaries can then do audits to check that data is actually message data.
  7. Datacap is granted
  8. Storage provider gets prepared data OR gathers message data itself and runs open source packing script to do preparation
  9. Storage provider makes deal with contract as client
  10. Stoarge provider seals and commits data and gains QAP

Extensions

These are things we SHOULD NOT do for the message contract but that a basic template contract enables others to build up

  1. A framework for making this dynamic. A simple direction is to redploy and independely apply for datacap for different epochs. If you want to give up nice FIL+ auditing and use trust then this could be a trusted verified client key. If you want to make it on chain governance you could have voting decide on the wishlist and remove the freeze method.
  2. Policy for miner selection. Using oracles, using simple heuristics like min power etc
  3. Use error correcting codes to increase replication factor per storage used
  4. Instead of preprocessed CommPs use IPFS hash directly + proof of merkle translation
  5. Efficient packing of wishlist ids to reduce gas cost of creation + proving inclusion
  6. List goes on...

System design v2

Use the truly programmable storage market interface described in FIP discussion 298 to circumvent f05. This will be a valuable testing phase to validate the design and implementation of this system refactor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment