- Use web3 infrastructure to solve the filecoin message archive problem currently solved with web2 clouds
- Provide an EVM contract template for contract as a client data storage on the filecoin network
- 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.
- 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.
The Message Contract is a user defined FEVM contract. Its state is a simple map from commP
s 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:
- AddToWishList: Add a set of commP cids to the wishlist. This is part of setup
- FreezeWishList: Freeze the wishlist. After this point FIL+ notaries can audit and then grant datacap to the actor
- AuthenticateMessage: FIP44 method called by f05 as part of PSD as described above
This is an open source library for packing messages into sector sized carfiles and doing car padding. It is the data preparation needed to
- generate commPs to add to wishlist,
- generate data from source of message data to seal and activate deals to claim QAP
- 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:
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.
This is the rough order of events
- Deploy EVM contract
- Process historical message data and pack it into CAR files
- Add these CIDs to the wishlist
- Freeze the wishlist
- (optional) Provide data on IPFS / web2 cloud
- 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.
- Datacap is granted
- Storage provider gets prepared data OR gathers message data itself and runs open source packing script to do preparation
- Storage provider makes deal with contract as client
- Stoarge provider seals and commits data and gains QAP
These are things we SHOULD NOT do for the message contract but that a basic template contract enables others to build up
- 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.
- Policy for miner selection. Using oracles, using simple heuristics like min power etc
- Use error correcting codes to increase replication factor per storage used
- Instead of preprocessed CommPs use IPFS hash directly + proof of merkle translation
- Efficient packing of wishlist ids to reduce gas cost of creation + proving inclusion
- List goes on...
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.