Sukhavati PoC Module

[williams824]

Grant Application Checklist

• The application-template.md 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.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• 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 we've successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[mmagician]

Thanks for your application, one of the Grants team members will provide you with feedback over the following days.

[mmagician]

@williams824 Apologies for taking so long to get back to you. I've looked at your proposal and read through the whitepaper and both looks fairly good, though I still have a couple of questions regarding your protocol & application:

1. Which part of the protocol is actually utilising the TEE capabilities? As far as I know, the big promise of using a TEE-enabled device is being able to load some code and run exactly that code without even the device owner being able to tamper with it. I don't quite see which part of your protocol requires this feature. Are you referring to: "On each proof cycle, the storage miner performs integrity verification and challenge verification on all stored documents and submits the results to the blockchain"? If so, could you explain the details of what you mean by integrity & challenge verification, and how does TEE help there?
2. Based on "In the initialisation phase, miners first create public and private keys, and then generate a series of HashMap data files according to the protocol and save them on the hard disk" it sounds like some kind of a trusted/permissioned set-up is needed. Can new nodes join the protocol at any time, and how does that happen?
3. It is not clear to me whether the work you want to do for this grant includes any connection with substrate, and how exactly is this going to work (I assume a substrate pallet?) - or is it just an independent library that you're building that you later hope to use for such integration? As part of the Open Grants Program, we can only support the development of software that directly benefits the Polkadot ecosystem. Could you perhaps be more explicit in your milestones regarding the integration?
4. The claim that "Currently the MASS PoC network has a total of about 230PB in capacity power" is fairly bold - where have you gotten this information and how could I potentially verify its validity (I can't even open the mainnet on MASS' portal)

[mmagician]

Closing due to inactivity. Feel free to re-open the application with a more complete proposal upon addressing the above mentioned concerns.

[williams824]

@mmagician Sorry for the late reply.

Thanks for your feedback and for taking the time to read through our whitepaper! Below is more information about this proposal and our project.

Which part of the protocol is actually utilising the TEE capabilities?

Sukhavati’s storage verification mechanism is based on TEEs. Sukhavati consists of three layers: the consensus layer, the storage layer and the application layer. This proposal is actually only related to the PoC part of the consensus layer, so TEE is not used here.

If so, could you explain the details of what you mean by integrity & challenge verification, and how does TEE help there?

In the storage layer, we designed a storage verification mechanism similar to Filecoin’s but instead of building on top of pure cryptographic methods, we rely on hardware-based TEEs. We use TEEs to load specific codes to check the integrity of stored files. That’s the integrity verification. While TEE implementations are not 100% secure like pure cryptographic methods, we added an extra challenge. On each proof cycle, storage miner needs to insert a random string (given by a reliable source of randomness) into the stored file according to a random rule, and submit its integrity hash to the chain along with the random string. These results can be challenged by anyone later. We call it the challenge verification. Both of these two processes need TEEs to protect it from tampering.

Can new nodes join the protocol at any time, and how does that happen?

Yes, actually new nodes can join the Sukhavati Network freely at any time.

"In the initialization phase, miners first create public and private keys, and then generate a series of HashMap data files according to the protocol and save them on the hard disk"

This init operation is not a trusted or permissioned set-up. Anyone can create this public/private key pair independently and generate HashMap files based on it. More details are described in this proposal in “Plot Algorithm and Capacity File Import” section.

As part of the Open Grants Program, we can only support the development of software that directly benefits the Polkadot ecosystem. Could you perhaps be more explicit in your milestones regarding the integration?

We have updated the milestones. Milestone 1 will deliver a PoC capacity management tool. Milestone 2 will deliver a poc consensus pallet for substrate and a farmer implementation that can reuse existing MASS capacity power.

where have you gotten this information

You can get this information from a third party mining pool: HPool(https://www.hpool.com/) and a MASS community explorer(https://explorer.masscafe.cn/).

[williams824]

Closing due to inactivity. Feel free to re-open the application with a more complete proposal upon addressing the above mentioned concerns.

@mmagician Sorry, it seems I don't have the permission to re-open this PR. Should I create a new one?

[Noc2]

@williams824 I reopened the PR. Feel free to update it.

[williams824]

@williams824 I reopened the PR. Feel free to update it.

Thanks!

@mmagician I have updated the proposal. Milestone 1 will deliver a substrate pallet for capacity management and milestone 2 will deliver a Sukhavati PoC consensus pallet. With these pallets, developers can easily build their own chain that can reuse the MASS capacity power.

[mmagician]

@williams824 That makes more sense. I'm happy to go ahead with it and will share the proposal with the rest of the team. Best of luck!

[semuelle]

Hey @williams824, we recently signed a grant for a POC consensus module: #357. It would probably help if you mentioned in your application how your project is different.

[Noc2]

Could you maybe more specifically mention the part about TEEs inside the application, since this seems one of the main differences between the protocols?

[williams824]

Hey @williams824, we recently signed a grant for a POC consensus module: #357. It would probably help if you mentioned in your application how your project is different.

Could you maybe more specifically mention the part about TEEs inside the application, since this seems one of the main differences between the protocols?

Thanks for review!

I have read Subspace's proposal (their idea is great) and I think the main difference between Subspace and us is the positioning of the protocol. Actually Sukhavati doesn't want to create a new PoC algorithm from scratch. What we hope to do is to integrate and reuse the existing PoS/PoC consensus power to form our own consensus layer. We are starting with MASS, and probably Chia next (still studying it). And then we will promote our blockchain to these existing miners. Our purpose is to utilize their idle resources to provide services for Web3.0 dApps and incentivize them to become service providers in the web3 ecosystem.

In this proposal, we hope to make the capability of reusing existing PoS/PoC consensus power available as a substrate pallet. It's a special consensus pallet that will allow developers to access these existing miners and build applications on top of them. We are willing to study and integrate the consensus power of any successful PoS/PoC protocol in the future to extend the influence of our protocol.

TEEs are actually not needed in the PoC consensus layer. It will be used in our storage layer as the basis of a efficient storage verification mechanism. The storage layer and PoC consensus layer will be completely decoupled. So it's not mentioned in this proposal.

[Noc2]

Sorry for the late reply here. You should probably also take a look at the following:
#357 (comment) There are some problem when it comes to pow (including poc or things like chia) and xcmp, see paritytech/polkadot#2203 Maybe you can also research this as part of the grant. Independent of it, I’m willing to support this project at this price.

[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 grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

[alxs]

Hey @williams824, care to share a quick status update along with an ETA if possible? We were expecting to receive your first delivery a bit over 3 months ago now. As long as you're actively working on the project, delays aren't a big problem, but please keep us in the loop.

Note that if we don't hear from you within the next two weeks, we'll assume you're no longer interested and terminate the grant.

[alxs]

This grant is being terminated due to inactivity. Feel free to apply again if you're still interested.