Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix: typos #9

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix: typos #9

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,7 @@ The client contract consists of three conceptual building blocks

### How it works with Storage Providers and actual transfer of data

Contract clients can work with an offchain party synchronizing with the chain and pushing deal data to miners. Alternatively contract clients could work with a pull based model where the contract provides an incentive and a location to pull from and the storage provider initiates everyting. Deals wity contract cliehts are similar to current deal making protocols. However there are key differences. In particular deal proposals can't be cryptographically signed by a contract. So none of the exact software needed for SPs to complete contract client deals is written yet. The lotus team is actively prototyping modifications to data transfer and deal making software to allow for miner initiated deals with client contracts.
Contract clients can work with an offchain party synchronizing with the chain and pushing deal data to miners. Alternatively contract clients could work with a pull based model where the contract provides an incentive and a location to pull from and the storage provider initiates everything. Deals with contract clients are similar to current deal making protocols. However there are key differences. In particular deal proposals can't be cryptographically signed by a contract. So none of the exact software needed for SPs to complete contract client deals is written yet. The lotus team is actively prototyping modifications to data transfer and deal making software to allow for miner initiated deals with client contracts.

## Some Extension Ideas

Expand All @@ -65,22 +65,22 @@ If you are looking for ideas the following is a non-exhaustive list of things yo

### Medium
1. "Simple Perpetual Storage" -- Start with a contract with a bounded replication factor. Parse the deal duration from the proposal and track the earliest the deal will expire in client state. At this date allow the contract to clean up state and track a reduction in replication factor allowing a new deal to track this cid.
2. "Quality controlled providers" -- Determine the provider's power by querying the builtin power actor and only accept deals from proviers with a high enough power. This is a very simple sybil resistence measure since the storage provider needs to stake pledge and store files before it can claim deals.
2. "Quality controlled providers" -- Determine the provider's power by querying the builtin power actor and only accept deals from providers with a high enough power. This is a very simple sybil resistance measure since the storage provider needs to stake pledge and store files before it can claim deals.
3. "Freeze feature" -- the cid list is added to and authorization is turned off. When the list of authorized cids is frozen then the contract can be funded as a whole by a funding party and authorizations turned on. This has some interesting data auditing applications -- the whole set of data tracked by a contract could be audited before providing funding (either in FIL or a FIL+ style data cap token)
4. "CID Charity" -- see "Trustless third party data funding" above. The end state is a client which uses donated funds to incentivize storage of data.
3. "Integrate with builtin market APIs" -- there are many ideas some easier some harder. By polling the builtin market state you can make the deal client aware of deal state changes beyond the original authorization hook. For example you can see if a deal has been terminated early and correclty track replication factor without waiting for original expiration time, and you could determine if the deal has actually been activated by a sector and perform some event in response, such as giving the miner an additional payment or minting a specialized DAO token to that miner.
3. "Integrate with builtin market APIs" -- there are many ideas some easier some harder. By polling the builtin market state you can make the deal client aware of deal state changes beyond the original authorization hook. For example you can see if a deal has been terminated early and correctly track replication factor without waiting for original expiration time, and you could determine if the deal has actually been activated by a sector and perform some event in response, such as giving the miner an additional payment or minting a specialized DAO token to that miner.


### Hard

1. "Client Data Insurance" -- integrate the deal client with a data insurance mechanism that pays out in the case a provider terminates their data
2. "Market Market" -- make the client a proper market matching bids and asks directly on chain. Note that this is a pathological use of the builtin storage market, at this point we should definitely be using a different interface and dropping the builtin storage market altogether.
3. "Data Swap" make a trading market where one provider agrees to store cid A if another provider agrees to store cid B. This could be a useful primitive to handle cases when providers have mismatchd value and access of their data. You could also extend this into a research project by including verifiable function computation as another commodity to trade on the market.
3. "Data Swap" make a trading market where one provider agrees to store cid A if another provider agrees to store cid B. This could be a useful primitive to handle cases when providers have mismatched value and access of their data. You could also extend this into a research project by including verifiable function computation as another commodity to trade on the market.


### Needs Research

Pin IPFS hash directly -- there is a nuance with the filecoin deal cids in relation to the cids of their underlying data. Deal cids are the merkle root of a particular serialization and specially padded chunk of data. So if you want to add an arbitrary IPFS dag the raw cid will in general be different than the cid tracked by filecoin. An active area of research is developing a protocol / cryptographic proving techniques for estabilishing some provable link between these two cids so that a client can prove with some confidence that a proposal deal cid matches with the client's desired deal cid. Some [good ideas are proposed here](https://www.notion.so/pl-strflt/Proposal-Non-interactive-Proof-of-Wrong-Merkle-Tree-Translation-9736f54e911241ce8bfb23b9cee29709).
Pin IPFS hash directly -- there is a nuance with the filecoin deal cids in relation to the cids of their underlying data. Deal cids are the merkle root of a particular serialization and specially padded chunk of data. So if you want to add an arbitrary IPFS dag the raw cid will in general be different than the cid tracked by filecoin. An active area of research is developing a protocol / cryptographic proving techniques for establishing some provable link between these two cids so that a client can prove with some confidence that a proposal deal cid matches with the client's desired deal cid. Some [good ideas are proposed here](https://www.notion.so/pl-strflt/Proposal-Non-interactive-Proof-of-Wrong-Merkle-Tree-Translation-9736f54e911241ce8bfb23b9cee29709).


## Coming up
Expand Down