Question Invent an easy-to use "Eclipse Score", based on at least 3 metrics, to rank validators who are not effectively representing their delegators via voting.

(For example: if you participate in only 5% of votes but are in the top 5% of validators by LUNA delegated, you should have a terrible Eclipse Score!)

Provide a table and at least 1 visual that displays validators according to your Eclipse Score, e.g. a bubble chart with LUNA Delegated vs. Votes Attended. Additionally, analyze the top 5 best and top 5 worst validators according to your Eclipse score.

For making an Eclipse Score system we need to know what proposal is more important. Maybe There were many spam proposals that few people have participated in. on other side there are important proposals that many people have participated in. so if one validator doesn’t participate in a spam proposal it doesn’t matter. But if a validator doesn’t participate in an important proposals, a high score will lost.

section 1-1 : proposals score

The proposals and the number of participants in them have been showed in above chart. Most participation belong to proposal 349 with 797 participation. so we determine the score of proposals as below: Case When number<200 then 1 When number between 200 and 400 then 2 When number between 400 and 600 then 3 When number>600 then 4

And the results have been showed in below table:

Section 1-2 : staking amount and deligators number

Section 1-3: transaction nmber done by validators

In this section we are going to find how many transaction done by each validators. if a validator done more transaction then it is more important.

Introdutions

What is a validator? The Terra Core is powered by the Tendermint consensus. Validators run full nodes, participate in consensus by broadcasting votes, commit new blocks to the blockchain, and participate in governance of the blockchain. Validators are able to cast votes on behalf of their delegators. A validator's voting power is weighted according to their total stake.

What is a full node? A full node is a program that validates the transactions and blocks of a blockchain. Validators must run full nodes. Full nodes require more resources than light nodes, which only processes block headers and a small subset of transactions. Running a full node means you are running a non-compromised and up-to-date version of the Terra Core software with low network latency and no downtime.

It is possible and encouraged for any user to run full nodes even if they do not plan to be validators.

What is staking? Staking occurs when Luna holders delegate their Luna to a validator. Staking increases a validator's weight, which improves the likelihood of being selected to validate blocks, and in return, delegators get rewarded.

The Phoenix-1 Mainnet is a public Proof of Stake (PoS) blockchain. This means a validator's weight (total stake) is determined by the amount of staking tokens (Luna) they delegate to themselves plus the Luna bonded to them by external delegators. The weight of a validator determines whether or not they are an active validator and how frequently they can propose a block. Validators with a higher weight will propose blocks more frequently, and in turn generate more revenue.

The active validator set is made up of the top 130 validators who hold the most Luna. The barrier for entry into the network is dictated by the value of the lowest stake held in the validator set. For instance, if a validator is created with a higher stake than the bottom validator, then this newly created validator may join the active set. If validators double-sign, or are frequently offline, they risk their staked Luna, including Luna delegated by users, by being slashed by the protocol to penalize negligence and misbehaviour.

What is a delegator? Delegators are Luna holders who want to receive staking rewards without the responsibility of running a validator. Through Station, a user can delegate Luna to a validator and in exchange receive a part of a validator's revenue. For more detail on how revenue is distributed, see What are the incentives to stake? and What is a validator's commission?

Delegators share the benefits and rewards of staking with their Validator. If a Validator is successful, its delegators will consistently share in the rewards structure. If a Validator is slashed, the delegator’s stake will also be slashed. This is why delegators should perform due-diligence on validators before delegating. Delegators can also diversify by spreading their stake over multiple validators.

Delegators play a critical role in the system, as they are responsible for selecting the validators to which they stake. Being a delegator is not a passive role. Delegators should remain vigilant, actively monitor the actions of their validators, and re-delegate whenever they feel their current validator does not meet their needs[1].

References

1.https://docs.terra.money/full-node/manage-a-terra-validator/faq/

Methodology

For determining The Eclipse Score we need to define a couple of metrics. We define them as follow:

1. How validator participate in proposals? According to participation on proposals, validators will get score. terra.core.fact_governance_votes, terra.core.dim_address_labels, and terra.core.fact_msg_attributes have been for this purpose. The addresses of validators on vote table differs from label table. For example 'terravaloper14q4vvp2vtmfcaejx4qy8nw9autudx0zjt30r24' is an address of a validator on label table. But this address on vote table is 'terra14q4vvp2vtmfcaejx4qy8nw9autudx0zjt3f4ds'. we can see vote address of validators don't contain 'valope' phrase and 5 last letters differs also. so first we separate terravaloper from first and 5 last letter with command: substr(ADDRESS,13,len(ADDRESS)-5) then stuck ''terra phrase to extract address with commans: concat('terra',substr(ADDRESS,13,len(ADDRESS)-5)) now we have vote address and can use it. We need to know the date of creation of validator and proposals. If the age of a validator is less than a proposals then it could not participate on it so the negative or positive score does no assign to validator. For this purpose we determine the age of validator by using terra.core.fact_msg_attributes. If a proposal be more important a higher score will be assign.

2. How much staked Luna does validators have? And how many delegators does staked their Luna to validators?

The more Luna staked and more the more delegator, brings more responsibility. If a validator has more Luna staked or more delegator with participation in a proposals get positive score and if don’t get more negative score. For this purpose terra.core.ez_staking have been used.

3. How many transaction each validator have done?

If a validator do more transaction it shows it is more important. So participation of these validators on proposals are more important than others. terra.core.fact_transactions have been used to find the number of transaction dine by validators. We explored the validator of each transaction by using json phrase 'tx['body']['messages'][1]['validator_address']' then we counted them.

More delegator number bring more responsibility beside this more deligators bring more responsibility too. so we define a factor based on number of deligators and luna staking as below:

case when luna_staked<1M then 1 when luna_staked between 1M and 5M then 1.05 when luna_staked between 5M and 10M then 1.1 when luna_staked between 10M and 15M then 1.15 when luna_staked> 15M then 1.25

for deligator numbe:

case when deligator_numbe<1K then 1 when deligator_numbe between 1K and 3K then 1.05 when deligator_numbe between 3K and 5K then 1.1 when deligator_numbe between 5K and 7K then 1.15 when deligator_numbe> 7K then 1.25

these factors will multiplied to proposal scores.

The more transaction done the more importance. so like staking we define a factor for this too as below:

case when transaction_number<1k then 1 when transaction_number between 1k and 10 k then 1.05 when transaction_number between 10k and 20k then 1.1 when transaction_number between 20k and 30 k then 1.15 when transaction_number between 30k and 50 k then 1.2 else 1.25

this factor will multiplied to proposal scores. Now we can score the validators

Section 1 : making an Eclipse Score system

For making an Eclipse Score system we explore validators on proposal voting, staking amount , deligators number and number of transactions done by validators.

Section 2

Now we can Implement our scoring system. we have 4 metrics : 1-proposal score 2- staked factor 3- deligator factor 4- transaction factor. each validator gain the voting score if they participate on it but if they dont their negative score will multiplied to 3 other factors like below:

If participate score= proposal_score if dont participate= -1proposals_scoretransaction_factorstakind_factordeligator_factor

Section 2-2: top 10 validators

In this section we have explored the top 10 most scored validators functional. also on the following we can see the daily voting of them.

Section 2-1

Section 2-3

In this section we have explored the worst 5 less scored validators functional. Also on the following we can see the daily voting of them.

So on the table we can see validators scores and their staked lune, tranasction number and deligator number. smart stake, orbital command have most deligator, luna staked and transaction and participated on all proposlas. contrary to them mango cloud, zeus staking and ustc buyback have the worst functional.