Contest Proposal: Provable Storage Design Contest Proposal

Ever TON Dev Experience Sub-Governance Contest Proposals
#1

Submission period: June 15, 2021 00:01 UTC - July 31, 2021 at 23:59 UTC

Voting period: 20 days

Background and Description

Provable storage protocol. Faster and cheaper alternative to Filecoin. Might be
an alternative or an addition to TON Storage.

Instructions for participants

This contest supposes participants to design the provable storage protocol using
Groth16 proof verification mechanism or any other primitive.

General requirements

● Protocol design should force participants to prove the data replication and storage from time to time.
● In case the design contains circuits/constraints systems description, formal description with provable statements should be present.
● The design may involve Groth16 verification usage (technical specification may involve VERGRTH16 TVM instruction usage).

Evaluation criteria and winning conditions
● A participant should do a presentation of her solution at a convenient time agreed with DevEx members.
● The solution should be “safe” (no formal definition of safety is possible to be used here). “Nothing up my sleeve” motto should be aligned to.
● Traditional paper-alike format should be preferred.
● The design proposal which does not contain circuit/constraint system formal definitions cannot score more than 6.0 (because the whole purpose of the contest is to present provable storage, but not a “it works probably” storage)

Voting
● Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
● A jury from other sub-governance groups could be added to this contest to provide additional technical expertise.
● Each juror will vote by rating each submission on a scale of 1 to 10.
● Jurors should provide feedback on each submission.
● The jury will reject duplicate, subpar, incomplete, or inappropriate submissions.

Reward
Only submissions with an average score equal to or more than 6.0 can get a reward.

1st prize … 120 000 TONs
2nd prize … 100 000 TONs
3rd prize … 80 000 TONs
4th prize … 50 000 TONs
5th prize … 30 000 TONs
6th place … 23,000 TONs
7th place … 21,000 TONs
8th place … 19,000 TONs
9th place … 17,000 TONs
10th place … 15,000 TONs

Note: In case the winning submissions amount is less than the number of rewards available, any remaining rewards are not subject to distribution and are considered void.

Jury rewards
An amount equal to 15% of all total tokens actually awarded will be distributed equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect the reward.

Governance rewards
An amount equal to 2 % of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

  • @nemothenoone
  • @prigolovko
  • @Futurizt

Procedural remarks
● Participants must upload their work correctly so it can be viewed and accessible in the formats described. If work is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.
● Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not be accepted.

8 Likes
#2

please add half year vesting for rewards

#3

If not submitted on time, the submission will be accepted :slight_smile:

#4

What’s the point of vesting if it is only a design contest?

#5

I think it best practice for all rewards

1 Like
#6

Right, it should be “will not be accepted”

#7

I think proofs that parties have the data in storage are not enough. They should also be tested whether or not they are actually available and send the necessary data.
It’s not enough just to store the data, you should also send it when someone is requesting it.

#8

Agreed. Shameful typo. My bad.

#9

This is a design contest, thus there is no practical reason to do vesting

#10

Agreed. Corrected. Thanks!

#11

There were discussions during Subgov meetup that this contest could be broadened to include not only ZKP solutions. Since there were no comment on the forum how contest’s wording should be altered, I propose to go forward with it as is. The reason is that it is very important to proceed with development of ZKP based solution regardless of any alternative.

#12

Timing should be amended taking into the account discussion period. 25 June - 15 August I think should be fine

#13

I strongly insist to keep Free TON Contests inclusive. Otherwise, there is no chance for Free TON Community to be competitive, enterpreneur-friendly and open environment of enthusiasts, visionaries and techies.

Regarding this contest, I’m concerned about technical guidelines - they are mostly Groth16-related.

And these 2 quotes basically cut out any possible alternatives to the mentioned (F___c__n) technology.

Proposed Changes:

  • “General Description”: briefly describe the essential parts of problem domain, add broader context
  • “Evaluation Criteria”: Reformulates the “Groth16 and Filecoin enforcement” (criterias still insist that submission must include formal definitions and statement proofs where needed).
  • “Evaluation Criteria”: Introduce few more hard criterias, namely Storage Layout Compatibility , Economical Viability
  • Improve Readability

Contest Proposal: Provable Decentralized Storage Protocol Design

Submission period: 45 days starting from proposal acceptance.
Voting period: 20 days starting from submission deadline

General Description

Propose an alternative to present solutions for provable storage protocol, which is aimed to connect storage consumers and storage providers and shape a decentralized market of reliable data storage.

Consider following essential parts of such a protocol:

  • mechnism for provider to prove it has certain capacity available
  • mechanism for provider to prove that it keeps privacy, integrity, reliable replication and availability of consumers’ files
  • mechanism of provider incentivisation/slashing, ranking and price-formation for storage service

The participant is expected to design a decentralized storage protocol or adapt / improve an existing one.

Evaluation criteria

  • The purpose of the contest is to present provable storage, not “it works probably” storage. Thus, the design proposal MUST contain formal definitions and proofs for scientific statements (where needed).
  • In case the design contains ZKP circuits/constraints systems description, formal description with provable statements MUST be present.
  • Storage compatibility with TON. Proposed data structures and layout MUST be Cell-/TOC-/BOC- aware (TL-B schemes of such structures serialization are desirable).
  • Economical viability (both for providers and consumers) in comparison with known solutions.

Other criterias / remarks

  • Traditional paper-alike format (or at least “informal specs”)
  • A participant should do a presentation of her solution at a convenient time agreed with DevEx members.
  • The solution should be “safe” (no formal definition of safety is possible to be used here). “Nothing up my sleeve” motto should be aligned to.

Participants’ Rewards

Only submissions with an average score equal to or more than 4.0 can get a reward.

1st prize … 120 000 TONs
2nd prize … 100 000 TONs
3rd prize … 80 000 TONs
4th prize … 50 000 TONs
5th prize … 30 000 TONs
6th place … 23,000 TONs
7th place … 21,000 TONs
8th place … 19,000 TONs
9th place … 17,000 TONs
10th place … 15,000 TONs

Note: In case the winning submissions amount is less than the number of rewards available, any remaining rewards are not subject to distribution and are considered void.

Jury rewards

An amount equal to 15% of all total tokens actually awarded will be distributed equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect the reward.

Governance rewards

An amount equal to 2 % of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

Voting

  • Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
  • A jury from other sub-governance groups could be added to this contest to provide additional technical expertise.
  • Each juror will vote by rating each submission on a scale of 1 to 10.
  • Jurors should provide feedback on each submission.
  • The jury will reject duplicate, subpar, incomplete, or inappropriate submissions.

Procedural remarks

  • Participants must upload their work correctly so it can be viewed and accessible in the formats described. If work is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.
  • Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not be accepted.
1 Like
#14

Following discussions at latest DevEx meetup please see the final version of this contest:

Submission period:
June 21, 2021 00:01 UTC - August 5, 2021 at 23:59 UTC

Voting period:
20 days

General Description
Propose a solution description for provable storage protocol, which is aimed to connect storage consumers and storage providers and shape a decentralized market of reliable data storage, as a part of Free TON architecture (e. g. a specialized workchain).

Groth16 proof verification mechanism or any other approach could be used for such a solution.

General requirements

Consider following essential parts of such a protocol:

  • mechanism for provider to prove it has certain capacity available
  • mechanism for provider to prove that it keeps privacy, integrity, reliable replication and availability of consumers’ files
  • mechanism of provider incentivisation/slashing, ranking and price-formation for storage service
  • The participant is expected to design a decentralized storage protocol or adapt / improve an existing one for Free TON architecture.

Evaluation criteria

  • The purpose of the contest is to present provable storage, not “it works probably” storage. Thus, the design proposal MUST contain formal definitions and proofs for scientific statements (where needed).

  • In case the design contains ZKP circuits/constraints systems description, formal description with provable statements MUST be present.

  • Storage compatibility with TON. Proposed data structures and layout may be Cell-/TOC-/BOC- aware (TL-B schemes of such structures serialization definitions might be considered as well).

Other criteria / remarks

  • Traditional paper-alike format (or at least “informal specs”)
  • A participant should do a presentation of the solution at a convenient time agreed with DevEx members.
  • The solution should be “safe” (no formal definition of safety is possible to be used here). “Nothing up my sleeve” motto should be aligned to.

Voting

● Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.

● A jury from other sub-governance groups could be added to this contest to provide additional technical expertise.

Participants’ Rewards

● Each juror will vote by rating each submission on a scale of 1 to 10.

● Jurors should provide feedback on each submission.

● The jury will reject duplicate, subpar, incomplete, or inappropriate submissions.

Only submissions with an average score equal to or more than 4.0 can get a reward

1st prize … 100 000 TONs

2nd prize … 90 000 TONs

3rd prize … 80 000 TONs

4th prize … 70 000 TONs

5th prize … 50 000 TONs

6th place … 30,000 TONs

7th place … 25,000 TONs

8th place … 20,000 TONs

9th place … 15,000 TONs

10th place … 10,000 TONs

Note: In case the winning submissions amount is less than the number of rewards available, any remaining rewards are not subject to distribution and are considered void.

Jury rewards

An amount equal to 15% of all total tokens actually awarded will be distributed equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect the reward.

Governance rewards

An amount equal to 2 % of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

Procedural remarks

  • Participants must upload their work correctly so it can be viewed and accessible in the formats described. If work is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.
  • Participants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not be accepted.
#15

Contest Voting Extension: #29 Provable Decentralized Storage Protocol Design

As the participant can not do a presentation of the solution to DevEx members as stated in the contest requirements due to his health reasons, We propose to extend the voting period.

Contest

#29 Provable Decentralized Storage Protocol Design

New voting deadline

Thursday, Sep 26th, 2021, 23:59

1 Like
#16

The reason for the voting: small number of jury members voted (2 - abstain, 3 - reject).

According to the the voting conducted in the chat of sabgov, it is proposed to accept results of the contest as is and make payments for governance and jury reward only, as the submission was rejected by 3 jury members of 3 voted.