Add Canyon Network

[liuchengxu]

Grant Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the Terms and Conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once the first milestone has been accepted.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks for the new grants application. I have a few questions/comments:

• Regarding data sharing, you could potentially use state channels for this. See https://github.com/celer-network/cApps-substrate and we recently signed a grant with https://perun.network/
• Are you aware of https://github.com/common-good-storage?
• Are you planning to scale up your team?
• Why don’t you use SPoRA (Succinct Proofs of Random Access) in your whitepaper?
• Are you planning to integrate off-chain workers (see for example https://rs-ipfs.github.io/offchain-ipfs-manual/)?

[liuchengxu]

Thank you for the review. @Noc2

Regarding data sharing, you could potentially use state channels for this. See https://github.com/celer-network/cApps-substrate and we recently signed a grant with https://perun.network/

Yeah, the state channel is being considered, which is also used in Filecoin. These two links look quite interesting, I'll revisit them once the canyon development comes to this stage. Before making the final decision on data sharing, we'll also do some research on swarm to see if we can learn some lessons from it.

Are you aware of https://github.com/common-good-storage?

I did not know that. With a quick look, the common-good-storage project attempts to implement a Filecoin like storage network using parachain. The logic of Filecoin does not make a lot of sense IMHO, the miners drop tons of garbage data for the reward and the entry for becoming a miner is so high.

Are you planning to scale up your team?

Yes, that's planned, but probably not now, the timing might be after the grant delivery of this round, just want to do some more fundamental works for expanding the team.

Why don’t you use SPoRA (Succinct Proofs of Random Access)? Your current solution doesn’t seem to be able to deal with the data redundancy problem?

Basically, SPoRA is the successor of PoA, which does help mitigate the obvious data redundancy problem with PoA, but can't say it resolve the problem completely. As far as I know, the AR team is still trying to find more effective solutions. We'll keep watching this and see if we can find another way out ourselves. The PoA consensus is relatively easier to understand and code, so we want to firstly implement PoA with confidence, and then implement SPoRA. The report of the last canyon grant draws a conclusion about the differences between PoA and SPoRA:

The most noticeable change in SPoRA upgrade is that the miners now have to
compute a slow hash to locate the random recall byte, rendering those who request data from the remote storage
pool at a distinct disadvantage. To put it simply, MultiHash(S, x) in 1 Algo 1 is replaced with randomx hash,
and the mod operation is replaced with searching in a limited search space.

Edit: with regard to your latest question, the answer is I'll update the paper after I have a deeper understanding of SPoRA (by coding it? :P)

Are you planning to integrate off-chain workers (see for example https://rs-ipfs.github.io/offchain-ipfs-manual/)?

This is also being considered. It's pretty cool to also support hosting data on ipfs protocol. I even left an issue several months ago to ask the future of offchain-ipfs(rs-ipfs/offchain-ipfs-manual#22), but no feedback so far :P.

[Noc2]

@liuchengxu Thanks for the quick reply. Makes sense. You are actually the second team that is interested in the future of offchain::ipfs today. I will see what I can do about it. In this case do you think it makes sense to potentially only start with the first milestone and after this discuss if we should go ahead with milestone 2 or maybe a different approach/solution. Also could you potentially include further research into the data redundancy problem into the deliveries of milestone 1?

[liuchengxu]

@Noc2 That's reasonable, I have updated the application accordingly. Without the block import verification, the consensus is just incomplete so I merged it into M1. About the research on the data redundancy issue, I'll replace the current PoA with SPoRA, the other potential solutions are merely uncertain.

[Noc2]

Thanks for the update. I’m happy to support it and I will share it with the rest of the team.

[semuelle]

Glad to see testing and documentation in the deliverables. :)

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at [email protected] in case you're interested (at least two weeks notice is preferred).