Counter Stake is Matic’s experimental testing event for everyone wishing to participate in the Matic network, by validating, testing the network’s limitations and earning mainnet MATIC tokens by showcasing technical skills. Counter Stake allows one to compete with other validators on our testnet and earn rewards.
Counter Stake comprises of 3 stages:
- Stage 0 (Status: Complete): We received an overwhelming response for this stage. Stage 0 was initiated in November 2019. In this stage the objective was to get familiarised with setting up a node for Matic. This would later be a foundation for Stage 1 once the community was familiarised with the process, components and requirements.
- Stage 1 (Status: Complete): We started Stage 1 on February 13, 2020. Stage 1 was where we tested out running the actual blockchain. There were 300+ registrations for Stage 1 and we onboarded more than 150+ validators through 6 testnets. Our current testnet, CS-2006, is running with 100 Validators.
- Stage 2 (Status: Ongoing): Stage 2 has now begun. This blog post covers all the objectives and plans for Stage 2 including details of available rewards. Our current testnet, CS-2006, running with 100 validators, has been carried over to Stage 2, and this testnet has been running for 3+ weeks.
What Happened in Stage 0?
During this stage validators were able to:
- Understand the core components
- Get their hands on setting up the nodes
- Run their nodes and keeping them synced
- Get familiar with the setup process and core components
What Happened in Stage 1?
During Stage 1, validators were able to:
- Set up their node
- Stake on Matic through CLI or Dashboard
- Delegate to a validator
- Claim and re-stake their rewards
- Replace validators via an on-chain auction process
- And unstake from the network
For more details on Stage 1, we released a blog post highlighting all the important points and milestones we achieved: https://blog.matic.network/counter-stake-stage-1-is-complete-the-final-stage-begins-matic-network/
During Stage 1 we ran a network which included 100 validators running their individual nodes for Matic. We then tested out all the important functionalities of Matic, such as becoming a validator, delegating to a validator, signing checkpoints, claiming rewards, etc.
And now this brings us to Stage 2!
What Will Stage 2 Involve?
Stage 2 is where we want our network to be “stress-tested” thoroughly. What this basically means is that we will be encouraging validators to:
- Test the network for resilience against explicit exploits that take down the network
- Try to successfully execute an economic attack and find bugs in the system/code
Getting Started on Stage 2
In order to perform attacks correctly, we encourage validators and community members to gain an understanding of Matic’s architecture and code. Without a thorough understanding of core components such as Heimdall and Bor, it would be difficult to perform attacks correctly on the network.
The Matic architecture is comprised of the following 3 layers:
- Heimdall – Heimdall is the heart of the Matic system. It manages validators, block producer committee selection, span duration, checkpoints, the state-sync mechanism and other essential aspects of the system.
- Bor – The block producer layer for Matic
- Smart contracts on Ethereum – Staking, delegation and Plasma contracts
Get started by going through the Matic architecture documentation here: https://docs.matic.network/docs/validate/counter_stake#architecture
Specs can be found here:
- Heimdall: https://docs.matic.network/docs/contribute/heimdall/overview
- Bor: https://docs.matic.network/docs/contribute/bor/overview
- Contracts: https://docs.matic.network/docs/contribute/contracts/stakingmanager
Codebase can be found here:
- Heimdall: https://github.com/maticnetwork/heimdall
- Bor: https://github.com/maticnetwork/bor
- Contracts: https://github.com/maticnetwork/contracts
You’ll need to be running a node, and one that is functioning at an optimum level. This includes uptime above 95%, Heimdall and Bor nodes running correctly, as well as Bridge and Rest-server running too.
We recommend all validators to run their own Sentry Nodes in addition to the regular nodes. Running a sentry node makes you more resilient to certain attacks such as DDoS.
We will be releasing detailed information on Sentry Node setup shortly.
Objectives of Stage 2
There will be several activities to be performed by validators during Stage 2. Validators will be encouraged to conduct attacks against the network – economic attacks or those based on bugs in the code. Reporting attacks without executing them but providing an overview of how to execute them will also be considered.
There are 3 major objectives for Stage 2:
- Network Attacks – This will include economic attacks and those based on bugs in the code. We have mentioned a list of example attacks that a validator could execute below.
- Uptime – For running a successful network, running your node and maintaining a high uptime is of the utmost importance. For Stage 2 this will be a major objective and reward criterion.
- Objective Tasks – There will be multiple minor tasks, not related to attacks. These tasks are optional, but by performing them validators will earn additional rewards.
Total Reward Pool for Stage 2
Here is a list of example network attacks that validators could execute:
Note that this list only includes examples to guide you in order to conduct attacks on the network. There may be more attacks that you can execute, however, they will be evaluated by the Matic team at the time of submission. The severity will also be determined after evaluation.
Whenever you have executed an attack successfully, it is important to report it in order to claim responsibility. You can report your bugs via this portal: https://forms.gle/Tnq8KQDhq6s1CYBD9.
We are in the process of migrating to a bug bounty platform for submission of attacks and bugs. Details regarding this will be announced shortly. For now, use the above form to submit bugs. This is the only way to ensure you receive credit for the report. No other reporting method will be considered.
In order to be in contention for a reward, you must submit proof of your attack/bug.
The following is a list of information that will be required from you during the submission of your report:
Note that providing this information is vital for the evaluation of your submission. Any other details (if required) will be requested by the team via email or Discord.
Attacks and bugs will be categorized mainly in 4 categories:
Each category of attack/bug carries a different reward value. The evaluation of all the attacks/bugs reported will be conducted by the Matic team. All evaluations once complete will be final.
The total reward pool for network attacks is up to 14 million MATIC tokens. As mentioned earlier, the bounties for each bug/attack are also different, based on their severity.
Rewards for reported bugs or successful attacks will be on a first-come-first-served basis – if two people submit the same bug, then the first will be given preference (assuming the first reported bug was correct). Once an attack is executed successfully, the first successful attack on a specific codebase version is rewarded. Subsequent attacks on the same codebase version will not be rewarded. This again will be at the discretion of the Matic team.
Reporting Attacks (When Not Executed)
It is also important to note to all the validators that if they are able to report an attack without executing it, by formally structuring it into a document, this will also be considered. The document will be evaluated by the Matic team and the verdict will be decided by the Matic team only. The severity of the attack will also be determined by the Matic team (if not already determined before).
You can submit your reports for such attacks using this form: https://forms.gle/Tnq8KQDhq6s1CYBD9
You will need to submit adequate information as per the template provided above so that the Matic team can evaluate your submission properly.
Rewards will be paid out only for valid attacks that are executed or reported.
As mentioned earlier, maintaining a node with high uptime will also be one of the objectives of Counter Stake Stage 2. Therefore, we have allocated a reward pool to be distributed between those who are able to maintain a node with high uptime throughout Stage 2.
People who are running the node for the entirety of the Counter Stake program (Stage 2) will be rewarded based on node uptime %. Uptime will be calculated on the performance of the blocks signed on Heimdall.
Note this is a testnet, and therefore it will be subject to issues and bugs which may affect the network and uptime. In such events, uptime calculation may be reset. All uptime calculations will be decided by the Matic project team at this stage. Uptime is calculated from the time the validator joins the network.
Typically, participants are not expected to do anything for qualifying for this bounty other than just stake their testnet tokens and have a high-uptime validator node setup to qualify for this phase.
All participants calculated based on uptime percentage will be rewarded with this pool. The reward distribution will be weighted based on relative uptime scores.
To determine the winners, Matic Network will primarily consider the uptime (votes on the blockchain) of the validators rather than the total bonded stake or the total amount of test tokens held. This means that delegating or transferring stake from Sybil accounts does not directly lead to winning.
Note that all rewards in the Matic Counter Stake program are awarded at the Matic project team’s discretion. Matic Network reserves the right to modify or revoke any rewards.
Also, there will be a separate bonus reward component for the top 10% of validators who demonstrate consistently high uptime and increase their stake by re-staking their rewards. As mentioned before, delegating or transferring stake from Sybil accounts will be disregarded from the total stake here. This bonus reward amount will be disclosed at the end of Stage 2.
After the completion of Stage 2, node uptime will be measured. If there are multiple testnets for Stage 2, then an aggregated value across all testnets will be determined. Node downtime because of attacks, bugs and node upgrades will be disregarded.
Note: The rewards stated in the ‘Total Reward in MATIC’ sections in the columns in the below section refers to the total reward pool which will be split evenly between all participants eligible to receive a reward (‘winners’) for each specific bounty.
Sentry Nodes are used for DDoS mitigation on validator nodes. Setting up a Sentry Node as a validator for Stage 2 will carry additional rewards as mentioned here:
Sentry Nodes can be set up in multiple ways depending on one’s own setup and configuration. We will release detailed info on sentry node setup shortly.
The governance of Matic Network is a significant module where validators can submit proposals to the network and other validators can vote on it. An example would be, “Proposal to change validator reward payout”. If the proposal is accepted it will automatically change the params in Heimdall.
Validators will be rewarded for voting for these proposals. If required, the Matic team will ask an external validator to float a proposal for voting as well.
Throughput Testing by the Matic Team
This will be an attack conducted by the Matic team, whereby we will be sending transactions at a high rate to stress test if the network is able to withstand the attack. The objective of this attack is to determine if the validator nodes are capable of withstanding such an attack, and the ones that do so will earn rewards.
Setting up a monitoring tool like Grafana will earn you more rewards. In order to setup a Grafana dashboard you can follow the instructions here: https://github.com/maticnetwork/node-prometheus/blob/master/README.md
Mentoring other validators in the community and helping them with issues they may face will also be a condition for earning more rewards. This again will be evaluated by the Matic team and validators eligible for these rewards will be selected based on the Matic team’s evaluation.
We will be creating a post on the Forum (https://forum.matic.network) to start this activity. There will be a separate announcement regarding this. The announcement will be posted on Discord. This forum post will act as a mechanism for matching validators.
Network Vigilance – Reporting Malicious Activity
Reporting malicious activity (that other validators could be doing to the community), will be rewarded. This will be evaluated by the Matic team and validators eligible for these rewards will be selected based on the Matic team’s evaluation.
To report malicious activity you can submit your reports using this form: https://forms.gle/Tnq8KQDhq6s1CYBD9
You will need to submit adequate information as per the template provided above so that the Matic team can evaluate your submission appropriately.
Terms of Counter Stake Stage 2
Payout Criteria for all Rewards
All rewards mentioned in this post will be distributed in MATIC tokens only. All decisions on payouts will be at the sole discretion of the Matic team.
Victory in Counter Stake is based on providing a convincing demonstration of interesting attacks on Matic’s Proof of Stake incentivization layer.
The Matic team will disqualify and, if necessary, fork out participants that undermine the goals of Counter Stake by attempting to carry out strategies to manipulate the incentive system.
The most obvious reason for disqualification is trying to “win” through a sybil attack on the registration process. If you simply registered accounts for your friends and then delegate or transfer all of your STAKE to a single or small number of validators, this will disqualify all of the accounts involved.
Griefing validators by delegating stake to try and get them disqualified is also forbidden. Cartel based attacks that require custom engineering are expressly in bounds.
While participants are encouraged to behave adversarially on the network, engaging in the following specific harmful adversarial actions is prohibited and could be cause for disqualification from Stage 2:
- Any attacks against nodes that violate Amazon Web Services’ Acceptable Use Policy and Google Cloud Platform’s Acceptable Use Policy, and other specific services you use. Please familiarize yourself with those policies, since violating them could not only disqualify you from Counter Stake, but could also get you suspended or permanently banned from those services.
- Social engineering attacks against other validators are expressly prohibited. Social engineering is the term used for a broad range of malicious activities accomplished through human interactions that use psychological manipulation to trick users into making security mistakes or giving away sensitive information. Activities like phishing, cloud account credential compromisation, malware distribution, and physical security attacks on data centers are out of bounds for this competition.
- Attacking any testnets other than the official Counter Stake testnet.
- Causing long-term harm to a validator setup.
- Any bugs that are discovered should be reported to firstname.lastname@example.org, or through our bug bounty program on HackerOne. Vulnerabilities that are disclosed by Counter Stake participants may be eligible for reward payouts in MATIC tokens, and participants who exploit vulnerabilities to gain stake will be disqualified from the contest.
We are excited to be working alongside our Counter Stake validators on Stage 2!