Beta Phase 2 Week 1 Leaderboard

Hello everyone, its that time again, and the team has complete our first leaderboard for Phase 2 of the beta :rocket:

1 Like

It’s asking me to sign in @rusty.spork

1 Like

Yes, give me a few minuets to fix it.

1 Like

It’s a good idea to test links in browser’s private window before publishing.

1 Like

Just a quick calculation shows

  • the top 10 this week got more than 2/3 of the total reward, out of 428 participants,
  • the top 3 got 46%,
  • the person ranked 11 got less than 10 times the reward of the person ranked in 1st position.

Is it what the Autonomi team intended ? The exponential decrease in reward seems a bit steep, and does not reward as much home contributors (with smaller amounts of nodes, but who actually bring more real-scenario-value for tests than nodes in data centers). What do you think ?

5 Likes

This is the reality of the live network, if this is going to put some people off it better happen now.

Having said that, I think that when the network starts the Foundation will try to get rid of its available tokens as quickly as possible and maybe we will see 2 billion or whatever is left pouring into the market as a subsidy so maybe with a few nodes from home you will be able to to be at a very good profit…


Check out the Dev Forum

2 Likes

When I wanted to launch more nodes but they failed to launch, you instructed me to reset the nodes and launch again, but after the reset the earned nanos were deleted in Launchpad. After launching the new nodes the earned nanos started counting again and I then asked @JimCollinson im if those earned nanos prior to the reset were lost:

Before the reset I earned 2 nanos and after the reset I earned another 8 and on the leaderboard I should have 10 nanos but I only have 8.

Can you explain why the earnings were not counted as Jim wrote?

1 Like

The best is the optimal sizing for the world. That is what will gain fastest adoption. Its a trade off between best size for data centre (or high performance networking systems at home) and the majority of the world. The optimal point is somewhere inbetween. This sizing is not it, thats all.

Talking about how people have to push for better conditions based of the high quality networking found in data centres and many areas in the EU is not the way to get people on board. Work with what you have now in the world and progress higher as adoption has been made. Otherwise it is just an elitist thing and ignored by the majority

2 Likes

It is a reality that the more nodes you run the more you will earn.

The reward structure is even, what is the the alternative, pay those who invest more resources less?

5 Likes

We comment on the results of last week’s test. We will comment on this week next week.

In any case there will always be harmed, you feel harmed with 10 nodes, but I ask if it is good for the network to have dozens of nodes on 40mbit internet?

I believe that the team will reach the optimal option…


Check out the Dev Forum

I am not thinking of myself. I’ll always find a way around to get better with technology and considering I have so much more than I could ever earn I’d be fine personally not running nodes ever. Trying to make my thoughts a result of personal feelings is not going to progress discussions and makes it seem you ask this because that is what you are doing. I hope not.

Without comments on whats happening is also going to harm the test. Too often we wait and the team have no feedback on how the changes are affecting the network in the real world and what people are experiencing. I read all the issues people talked about in the discord. From people in the EU, UK, USA, Australia (not me) and elsewhere I do not know their location. And our discord people are typically in a better position with better internet connections than other areas like Africa, etc and poorer regions like rural India and other rural areas in the world.

But to imply that if you don’t go with premium setup is not going to help progress things. Too often we look at our situation and think that is what we should use even if our situation is at the lower end. We need to be inclusive and not exclusive.

The reason why going with the highest possible configuration is not needed to be designed for is that firstly it’ll leave behind the majority since it requires a well above average setup. And best to design for the future but bring along the present. That means configure for the present and reconfigure in 2 years when adoption has happened and the world has progressed.

This is not a design of the software issue, so designing for the future is good and should be done. But its a configuration issue, the configuration of the sizing. And we have to comment and complain when the sizing has these unintended consequences and trying to silence those raising the issues is akin to putting ones head in the sand and saying its works on my superior network so thats the future and all you guys have to push for better. Especially bad when the world is already pushing for better connectivity in a big way. 5G mobile is a result of this pushing, optic fibre connections is a result, EU cities having better internet is a result of the pushing, so saying that we have to go with a configuration that deprives the majority of the world and they need to push for better gets my back up seriously.

Above all we don’t need the biggest immediately. We can easily upgrade the configuration in a 2 step upgrade path that even David mentioned at some stage. Its not a pie in the sky thing we can do. So have a easy to adopt node configuration now that will draw in the people with average setups to create that volume of adoption, storage, etc and then when the time is right upgrade that configuration to something more if needed.

3 Likes

I commented on your setup because you give it as above average, which is not what I see in the world stats:


Check out the Dev Forum

I have 750-1000Mb/s download speeds and 70Mb/s upload dual homed, Well above your displayed world average. Also lopsided due to 10/5/2.5/1 Gb/s home connections

Again assumptions are not good to make

When i said 35Mb/s it was a self imposed limit (30-40Mb/s) for my router and is why I used that figure since its close to average world wide. This limit is what i have had for all the testnets so a good bench mark

Indeed it looks like the reward is proportionate to the number of nanos earned. I thought the nanos earned were here mainly to establish a ranking between all the participants, then rewarded using another distribution, a bit more even.

1 Like

That was the previous stage of the beta program. This phase is purely worked out on the proportion of nanos you earned. 1/10 the nanos then 1/10 of the 125K

1 Like

Thank you for the info; I should have read better that the rules had changed.

This new mechanism seems to favour centralization, and nodes hosted on VPS or data centers rather than encouraging the participation of home nodes. It worries me a bit, but I am not saying top earners do not deserve a better reward for their investment.

1 Like

Why do you think so? My calculations show that at the current token price and subsidy, my workstation will pay for itself in 3 months and then cost me €45 per month (electricity and internet), compared to €160 for a similar one in the cloud. I.e. almost 4 times cheaper. I don’t see how anyone with an VPS will be able to compete…


Check out the Dev Forum

4 Likes

This is possibly the problem. As far as I can see, at least in my case, there are many times when a node needs up to 70 MB/s. continuously both upstream and downstream, so asymmetrical connections, and with such a difference as yours, can suffer a lot.

2 Likes

I have similar numbers, VPS nodes cost me 3.5x more per node then nodes I am running at home.

1 Like

I disagree the difference in download speed and upload is immaterial. As long as the download speed is higher then the controlling factor is the upload speed as that affects how your node is perceived by other nodes when checks are being performed. Like supplying chunks during churn events. If your upload is swamped then packets will be lost and the receiving node will give your node a strike.

For download your node is requesting the packets and the speed is controlled by your node and not the requesting node for upload. Packets are unlikely to be lost since your node only requests more packets when it can handle them. Actually it is the OS that does this

2 Likes