1-year Ongoing Free TON Testnets Support Contest

Ever TON Dev Experience Sub-Governance Contest Proposals
#1

1-year Ongoing Free TON Testnets Support Contest

Motivation

In order to support the testing of smart contracts without paying gas on the mainnet, and/or in order to test new blockchain features and functionalities, several test networks are required. These testnets should have clear rules for validators to join. There could be several networks set up for different purposes. Support for such networks will require long term commitment in order to preserve testnet stability.

Timing

Submission period – 1 September 2021 – 10 September 2021 23.59 UTC

Voting period: 7 days

Participants must:

  1. Provide a list of initial members of their network (testnet members), their public keys and multisignature wallet with those keys as custodians. Members/custodians of each testnet can change from time to time via on-chain voting.
  2. Clearly describe the purpose of the testnet.
  3. Provide a reference to a Telegram group where all issues related to testnet support could be openly discussed.
  4. Clear guide for new validators to join the network.

Evaluation criteria and winning conditions

Jurors should vote based on the experience of initial members, relevance of declared testnet goals to Free TON development goals, and transparency of the network’s guide.

Rewards:

Onboarding reward

  • 1st place: 30k TON
  • 2nd place: 30k TON
  • 3rd place: 30k TON

Rewards can be used as discretionary funds by an on-chain vote by testnet members.

By the end of each month for the period of 1 year, testnet members should prepare and submit reports with the following data:

  • Testnet uptime in % of time the network was available including DApp server availability (% SLA).
  • Usage report: number of smart contracts that were deployed, number of transactions, features tested, etc.
  • How many test tokens were obtained by validators as rewards deducted by slashed amounts (only rewards received in accordance with parameters equal to those in the mainnet should be counted).

Based on each report TONs will be transferred to the network’s multisignature wallet in amounts calculated as follows: (amount of validators rewards (excluding slashing) ) * (% SLA ^2) / 100

Members of the various networks should pay out all received TONs to testnet validators in proportion to their rewards for each given period.

Over the course of 2 months, members of the DevEx subgov will review and determine whether or not there has been any real usage of the testnets based on each network’s members and A&S SG reports. They will be able to vote to stop further support of any testnet program that is found to be unsatisfactory.

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 subgovernance groups can be added to this contest to provide additional technical expertise.
  • Each juror should vote by rating each submission on a scale of 1 to 10.
  • Jurors should provide feedback on each submission.
  • The jury should reject duplicate, subpar, incomplete, or inappropriate submissions.

Jury rewards

An amount equal to 5% 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 1 % of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

@anovi

@prigolovko

Procedural remarks

  • Jury voting should follow DevEx global proposal requirements
  • 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 count.
6 Likes
#2

As far as I understand, you need to have a lot of coins on your account to participate in the testnet?

#3

Less than 1/100 of validation rewards, received in accordance with parameters equal to those in the mainnet, in TONs, won’t be enough for testnet validators to ensure even minimum HW requirements. 1/100 of mainnet rewards comes to around 20$ per month now.

#4

No, since there will be testtokens. A requirement for a faucet support should be added in the contest terms

#5

There should be much less validators in a testnet compare to the mainnet. Network can live even on 5 nodes. Nil Foundation managed to run a network on 4 nodes.

#6

Seems like we discuss allready working networks. In case of new one we need much more time too prepare proposal and start testnet. 2 week more, I think, will be good.
Also not clear reward for initials, not only validators create new networks)
Validator reward also shold be rised, or formula changed.

#7

The number of nodes required depends mainly on the purpose of a test network. If the goal is to stress test a network with many workchain/threads, 5 nodes may be not enough. There probably should be some differentiation of rewards based on the purpose and desired number of validators.

1 Like
#8

We all know that Nil Foundation’s network is more likely is down than working. @Custler said that the minimum number of validators for all workchain shards are running is 13. I trust his opinion.

2 Likes
#9

I propose to add to the Participants must section:

  1. Clear guide for new validators to join the network in form of the document in the Github repo.
  2. Provide the network itself, i.e.
    5.1. It should be available through GraphQL interface using DApps server.
    5.2. Anybody should be able to become a validator using the network configuration published on Github.
    5.3. The network configuration should be up to date (no more than 1 hour delay).
    5.4. Github issues should be responded to within 24 hours and adequate issues should be resolved within one month.
  3. The provided network requirements are
    6.1. The minimum number of validators is 13.
    6.2. The servers should be placed in several different geographical locations.
    6.3. The network operation center should provide the network health indicator which could be accessed by web-browser.
    6.4. The network should withstood 100 external and 100 internal messages per second.
    6.5. Restore time in case of the network failure should be no more than 3 hours.
    6.6. Support Groth-16 TVM instructions;
    6.7. Automatic giver for developers;

In the Onboarding reward section I propose to make rewards different, for example, like this:

  • 1st place: 40k TON
  • 2nd place: 30k TON
  • 3rd place: 20k TON

IMHO, We need to figure out how to avoid a situation when a lot of validators will run in and the servers of initial members will no longer pay off.

Also I did not understand the formula of the reward which has reward as an argument.
IMHO, it should be assigned every month reward for initials. That will be enough.

2 Likes
#10

Initial members are only required for a testnet start and relaunches (just in case). The idea is that it is actually validators which decided to support a testnet (including IMs) will get rewards.

#11

Each testnet validator gets some Rubies (test tokens) as validator’s reward (minus slashing). Total rewards in TONs for all testnet validators is calculated based on total rewards recieved times squared SLA % and devided by 100. The idea is that IMs will pay to those validators from thier miltisig.

#12

Since the amount of Rubies mined by validators depends on the huge amount of factors (including but not limited by the length of validation circles and network settings) and to avoid abuse, I propose to fix the monthly reward to some particular amount, let’s say,
20K TONs for the 1st place,
15K TONs for the 2st place,
10K TONs for the 3st place.
At the current rate, this should be enough for 20-30 good validation servers and 24/7 admin changes.

1 Like
#13

Как отбор валидаторов будет проводится, если желающих будет много?

#14

How to deploy a new test network?

#15

В сообществе не так много людей которые будут валидировать, выплата кристаллов за количество полученных рубинов является лучшим вариантом. Благодаря этому те кто валидировал тестнет смогут перейти в валидаторы на мейн, что благосклонно скажется на всей сети.

1 Like
#16

Подразумевается, что валидировать смогут все желающие. Цель тестовой сети в том, что все, кто хотят потренироваться в разработке или в валидации должны иметь возможность это сделать без оплаты за газ.

#17

Спорное утверждение. Думаю, это зависит от окупаемости. Заработать всегда много желающих.

Что бы понять, является ли это лучшим вариантом, надо составить список всех вариантов и плюсы/минусы каждого.

Минимальный стейк в мейн-нет сейчас около $350K TON. Это получится очень дорогой тестнет, дороже мейна.

#18

Это неплохое начинание перед тем как валидировать в мейне. Это и тренировка и получение кристаллов для валидации в мейне. Кому-то может не хватаеть 100к для того чтобы стать валидатором и он сможет добить их на теснете. Опять же стекинг+фарминг. На мой взгляд большинство из тех у кого появится 350к предпочтут отправиться валидировать в мейн, а не просто хранить кристаллы на кошельке. Тем более имея опыт. Но это только мнение.

2 Likes
#19

I propose to divide it to two sections:

  1. Initials who start network and support it’s basic functionality - 13 nodes + dApp server - get in vesting manner every month 5k TONs.
  2. Validators - anyone who want to become mainnet validator - can setup validating node in testnet and after N cycles of validating (for example 1 year) get’s opportunity for lock stake on his DePool in MainNet.
3 Likes
#20

Hello! As written before I rewrite and compile @p.prigolovko original contest, change scheme for rewards and add Road to MainNet block, I propose to discuss it promptly (also in DevOps SG weekly call), and if we get consensus - put it to DevOps SG proposal for voting!

1-year Ongoing Free TON Testnets Support Contest

Motivation

In order to support the testing of smart contracts without paying gas on the mainnet, and/or in order to test new blockchain features and functionalities, several test networks are required. These testnets should have clear rules for validators to join. There could be several networks set up for different purposes. Support for such networks will require long term commitment in order to preserve testnet stability.

Timing

Submission period – 13 September 2021 – 23 September 2021 23.59 UTC

Voting period: 7 days

Participants must:

  1. Provide a list of initial members of their network (testnet members), their public keys and multisignature wallet with those keys as custodians. Members/custodians of each testnet can change from time to time via on-chain voting.
  2. Clearly describe the purpose of the testnet.
  3. Provide a reference to a Telegram group where all issues related to testnet support could be openly discussed.
  4. Clear guide for new validators to join the network in form of the document in the Github repo.
  5. Provide the network itself, i.e.
    5.1. It should be available through GraphQL interface using DApps server.
    5.2. Anybody should be able to become a validator using the network configuration published on Github.
    5.3. The network configuration should be up to date (no more than 1 hour delay).
    5.4. Github issues should be responded to within 24 hours and adequate issues should be resolved within one month.
  6. The provided network requirements are
    6.1. The minimum number of validators is 13.
    6.2. The servers should be placed in several different geographical locations.
    6.3. The network operation center should provide the network health indicator which could be accessed by web-browser.
    6.4. The network should withstood 1000 external and 1000 internal messages per second.
    6.5. Restore time in case of the network failure should be no more than 3 hours.
    6.6. Support Groth-16 TVM instructions;
    6.7. Automatic giver for developers;

Evaluation criteria and winning conditions

Jurors should vote based on the experience of initial members, relevance of declared testnet goals to Free TON development goals, and transparency of the network’s guide.

Rewards

Onboarding reward:

  • 1st place: 30k TON
  • 2nd place: 30k TON
  • 3rd place: 30k TON

Rewards can be used as discretionary funds by an on-chain vote by testnet members.

By the end of each month for the period of 1 year, testnet members should prepare and submit reports with the following data:

  • Testnet uptime in % of time the network was available including DApp server availability (% SLA).
  • Usage report: number of smart contracts that were deployed, number of transactions, features tested, etc.
  • How many test tokens were obtained by validators as rewards deducted by slashed amounts (only rewards received in accordance with parameters equal to those in the mainnet should be counted).

Monthly based rewards:

Based on each report TONs will be transferred to the network’s multisignature wallet in amounts calculated as follows: 5 000 TON x (100% - Penalty rate)

TestNet availability A (% per month) Penalty rate (%)
99.90 > А ≥ 99.72 5
99.72 > A ≥ 99.45 10
99.45 > A ≥ 98.9 15
98.9 > A ≥ 96.71 20
96.71 > A ≥ 76.98 50
76.98 > A 100

Road to MainNet

At the end of the contest cycle (1 Year), each testnet validator who participated in the testnet validation process will be nominated for MainNet validation and get Lock Stake to his depool proportional with number of the validated cycles.

Relevance check

Over the course of 2 months, members of the DevEx subgov will review and determine whether or not there has been any real usage of the testnets based on each network’s members and A&S SG reports. They will be able to vote to stop further support of any testnet program that is found to be unsatisfactory.

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 subgovernance groups can be added to this contest to provide additional technical expertise.
  • Each juror should vote by rating each submission on a scale of 1 to 10.
  • Jurors should provide feedback on each submission.
  • The jury should reject duplicate, subpar, incomplete, or inappropriate submissions.

Jury rewards

An amount equal to 5% 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 1% of the prize fund will be allocated to members who participated in organizing the contest, to be distributed equally among them:

@anovi

@prigolovko

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 count.
3 Likes